微服务和传统服务架构

单块架构应用：功能集中，代码和数据中心化，一个发布包部署后运行在同一个进程中的应用程序

单块架构的优势：

1）易于开发

2）易于测试

3）易于部署

4）易于水平伸缩(所有的功能都会打成一个包，在集群中新建一个节点，配置好节点的运行环境，复制软件包到响应的位置，保证负载均衡的分发策略有效分发到当前节点即可)

面临的挑战：

1）维护成本增加，代码量过大，不利于快速定位问题

2）持续交付周期长：构建 部署和测试的实际都会随着代码量的增加而成倍的增长

3）新人培养周期长：业务熟悉和环境部署都会有很大的难度

4）技术选型成本高：较大规模的系统，最初的选型会影响新技术的使用

5）可扩展性差：

a 垂直扩展：增加服务器

b 水平扩展：在集群中添加节点，使用负载均衡(若应用有一部分是需要内存密集型缓存大量数据，有一部分是需要CPU密集型，需要进行大量运算，那么每次扩展新的节点都需要足够的内存和CPU来满足需求)

6）构建全功能团队难：会出现功能的扩展需要跨团队沟通

微服务架构：

是一种架构模式，提倡将单一应用程序划分为一组小的服务，服务之间相互协调，相互配合，为用户提供最终价值，每个服务运行在独立的进程中，服务间采用轻量级的通信机制相互沟通(通常是基于http的restful api)，每个服务围绕自己的具体业务构建，可以独立部署，应尽量避免统一的，集中式的服务管理机制，对于具体的一个服务而言，应根据业务上下文，选择合适的语言 工具来进行构建，也就是：

通过对特定业务领域的分析和建模，将复杂的应用分解成小而专一的，耦合度低并且高度自治的一组服务，每一个服务都是一个小的应用

编译语言有良好的语言类型约束和编译期检查，但代码比较复杂

动态语言灵活性高，运行时可以改变其内存结构，无类型检查，无需写交较多类型相关的代码，但不方便调试

开发 测试 部署完全独立，语言独立

服务与服务之间相互独立，相互隔离

在单块架构中，应用程序的代码虽然被分成逻辑上的3层或者4层，但并非物理上的分层，所有的功能经过编译，打包，部署后还是会运行在同一个进程中，这就意味着对应用部署时必须停掉正在运行的服务，部署完成后再重新启动进程，无法独立部署

一般为了代码的重用性，会把重复的代码封装成组件(可独立升级，独立替换掉的部分)，传统架构中，通常是共享库，比如jar包或者是win下的dll等

但在微服务架构中，应用程序由多个服务组成，每个服务都是一个具有高度自治的独立业务实体，每个服务可以运行在一个独立的进程中，不同的服务可以轻易的部署到不同的主机上

理论上可以把不同的服务部署到同一个节点上，运行到不同的进程里，但是不推荐，既然是微服务，最好保证高度的自治性和隔离性，运行在同一个节点上，虽然省去了节点的开销，却增加了部署和扩展的复杂度，部署某一个新的服务时，可能会对该节点的原有服务造成影响，另外随着业务的发展，可能某些业务需要水平扩容，有些不需要，如果不能有效的组织服务，可能会给服务的水平扩容带来不必要的麻烦

docker：

1）可以更快的交付和部署，开发者可以使用一个标准镜像来构建镜像，开发完成之后，运维人员可以直接使用这个镜像来部署

2）可以更轻松的迁移和扩展，包括物理机，虚拟机和公有云，私有云等，这种兼容性可以很方便的将应用程序从一个平台直接迁移到另一个

3）更简单的管理，使用docker，所有镜像的修改都可以用增量的方式发布和更新，从而实现自动化和高效的管理

可以有效的解决微服务架构下，服务粒度细，服务数量多导致的开发环境搭建，部署以及运维成本高等的问题

微服务的本质通常包括：

1）服务作为组件

2）围绕业务组织团队

3）关注产品而非项目

4）技术多样性

5）业务数据独立

6）基础设施自动化

7）演进式架构

对应解释：

1）服务作为组件

在传统领域，我们通常把公用的部分抽离出来，构建出共享库，从而达到解耦和复用，但，共享库是平台和语言相关的，并且要和应用程序运行在统一进程中，也就是共享库的更新，意味着整个应用要被更新，需要重新部署，如果有多个共享库组件组成，任何库的变更都将导致应用需要重新部署

微服务也可以认为是一种组件，运行在不同的进程中，每个服务的变更仅需要重新部署自身服务即可，可以跨平台，跨语言

当然，微服务也有它的不足之处，就是分布式调用比进程内通信需要消耗更多的时间，并且严重依赖网络的稳定性和可靠性

2）围绕业务组织团队

传统架构里，我们通常会按照技能去划分团队，懂服务器的运维人员，用户体验设计师，DBA，后端开发人员，当团队按照这个维度去划分后，某些简单的需求变更，可能都会出现跨组织跨团队的协作，沟通的成本高

微服务是主张以业务为核心来组织团队，团队中的成员具有多种多样的技能

3）关注产品而非项目

项目模式就是项目启动后企业或者组织会从不同的技能资源池中抽调不同的资源，组成团队并完成项目，项目完成，团队解散，这种模式的弊端在于团队成员缺乏主人翁意识，难以制定有效的奖惩机制，团队成员也缺乏成就感

4）技术多样性

在微服务架构中，由于彼此相互独立，可以针对不同的业务特征进行不同的业务选型，有针对性的解决业务问题，比如要求快速开发的模块可以使用php python等，对性能有较高要求的模块可以使用C C++等，对于单块架构，切换语言或者框架，难度就会比较大，若没有完整的功能测试集，就很难平滑替换，且系统规模越大，风险越高

而对于微服务架构，我们可以挑选风险较小的访问作为尝试，快速得到反馈后再判断是否适用于其它服务，这样一项新技术的尝试失败并不会影响到整个产品的发展

5）业务数据独立

在微服务中可以使用不同的数据库类型来管理不同的数据，比如

在一个复杂的CRM系统中，产品数据种类繁多，更新也比较频繁，可以使用monogo这类文档数据库，它可以灵活地根据需求动态的调整

对于用户访系统时产生的临时会话信息，可以使用redis等键值系统进行存储

报表数据的结构变化不大，而且要求数据一致性，可以使用传统的mysql数据库

在采用微服务架构后原先一次就能部署完成的，现在可能需要每个部分单独部署，每个服务都需要部署带来的健康监控，错误回滚，日志分析等成本会明显增加，自动化部署的要求也就越来越高，可以使用云 devOps docker

单一的大而全的平台已经没办法满足我们的需求，单一的技术平台已经无法适应市场的快速变化，组织应该随着业务的发展不断去尝试新的架构设计，真正去做到业务驱动架构，架构服务于业务

微服务的优势：

1）独立性 2）单一职责 3）技术多样性

部署需要注意的问题：

1）分布式系统的复杂度 2）运维成本 3）部署自动化 4）devOps与组织架构 5）服务间依赖测试 6）服务间依赖管理

分布式系统的复杂性：

1）性能 由于是跨进程跨网络的调用，因此必须要考虑网络延迟以及带宽带来的影响

尤其是多个服务相互协作时，响应时间及性能对系统的影响

2）可靠性 由于网络，带宽，节点等自身可靠性因素的影响，任何一次组件间的远程调用，都可能失败，且微服务数量很多时，潜在更多的单点故障，所以 保证系统的可靠性，降低由于网络，组件引起的单点故障率，也成了构建系统的挑战

3）异步 由于夸网络调用，需要考虑异步的通信机制，这样出现问题时的调试就会变得很麻烦

4）数据一致性 为了保证数据一致性，我们通常考虑分布式事务管理，但是它会涉及到跨多个节点来保证数据的瞬时一致性，比起传统的事务成本就会高很多，通常，也会用最终的数据一致性来解决数据瞬时一致带来的系统不可用

5）工具 IDE工具，并没有为分布式调用提供良好的支持

有效的构建组动画部署流水线，降低部署成本，提高部署频率，是微服务架构的下一个跳战，传统的系统被拆分成多个相互协作的独立服务后，随着微服务个数的增多，如何清晰有效的展示服务之间的依赖关系，逐渐成为挑战

微服务强调的就是一种独立开发 独立测试 独立部署 独立运行的高度自治的架构模式，也是一种更灵活更开放和更松散的演进式架构

任务拆分：

1）同一时间聚焦一个任务

2）能够对每次完成的部分做持续集成

3）整体的进度容易追踪