SpringCloud实战与原理分析--第一章：微服务架构

伟大的人不是生下来就伟大的，而是在成长过程中显示其伟大的。 ——马里奥·普佐《教父》

1、技术架构的演化

1.1 单体架构

1.1.1 简单单体模式

简单单体模式是最简单的架构风格，所有的代码全都在一个项目中。

• 优点

（1）项目的开发人员都可以随时修改任意的一段代码，或者增加一些新的代码。开发人员在个人电脑上就可以进行开发、调试、测试整个系统的功能。
（2）项目不需要额外的一些依赖条件和准备步骤，就可以直接编译打包整个系统代码，创建一个可以发布的版本。
（3）这种方式对于一个创业团队，需要迅速开发，抓住时机实现产品最短时间推向市场，可以省去各种额外的设计，开发直接进行开发，节约了模块设计的时间。

• 缺点

（1）简单单体模式的系统存在代码严重耦合的问题。所有的代码都在一起，就算是按照 package 来切分了不同的模块，各不同模块的代码还是可以直接相互引用，可能导致了系统内的对象间依赖关系混乱，修改一处业务代码，可能导致多个模块功能无法正常使用。

（2）简单单体模式的系统变更对部署影响大，并且这个问题是所有的单体架构系统都存在的问题。系统作为一个单体部署，每次发布的部署单元就是一个新版本的整个系统，系统内的任何业务逻辑调整都会导致整个系统的重新打包，部署、停机、再重启，进而导致了系统的停机发布时间较长。每次发布上线都是生产系统的重大变更，这种部署模式加大了系统风险，降低了系统的可用性。且打包的大小过大可能导致业务系统启动很慢，进而也会影响系统的可用性。

（3）简单单体模式的系统影响开发效率。如果一个使用 Java 的简单单体项目代码超过100万行，那么在一台笔记本电脑上修改了代码后执行自动编译，可能需要等待十分钟以上，并且内存可能不够编译过程使用，这是非常难以忍受的。

（4）扩展性受限，也是所有单体架构的一个问题。如果任何一个业务存在性能问题，那么都需要考虑多部署几个完整的实例的集群，或者再加上负载均衡设备，才能保证整个系统的性能可以支撑用户的使用。

• 总结

简单单体模式比较适用于规模较小的系统，特别是需要快速推出原型实现，以质量换速度的场景。并不适合长期稳定发展的系统。

1.1.2 MVC模式

MVC 也是一个非常常见的3层（3-Tier）结构架构模式，它把每个模块划分为模型层（Model Layer）、视图层（View Layer）、控制器层（Controller Layer）等部分。模型层：代表业务数据实体部分；视图层：代表前端的展示部分；控制器层：代表请求分发，处理调度部分。

我们甚至可以添加数据操作层（Data Access Layer）等，形成一个 N 层（N-Tier）结构模型。整个系统由多个模块组成，每个模块又由这种不同的部分组成。这样一来，我们就把整个系统拆解成了很多粒度较小的零件。

• 优点

（1）MVC结构简单，直观，可以非常有效的上手；

（2）经过MVC模式的三层设计，我们从代码功能作用方面已经把系统拆解为三个大模块，不同的模块和分层结构，本身就可以作为一个开发层面的子项目拆分结构，这样我们就可以把系统拆分成多个不同的子项目，非常有利于分配开发工作；

（3）基于 MVC 模式，又陆续发展了 ORM 等简化数据操作层的技术与框架如Hibernate、Mybatis、JPA，以及相应的代码生成工具等，极大的提供了软件开发效率。

• 缺点

（1）MVC 模式也存在定义不够明确，对于简单的业务场景拆解过细导致复杂度增加等问题，需要在实践中不断摸索和总结应用经验。

（2）基于单体架构下的 MVC 模式依然解决不了单体架构本身存在的问题，特别是对于可用性和扩展性的影响。

1.1.3 前后端分离

传统的 Web 系统都是 BS 结构的，一般的 JSP 或页面标签 Tag 技术、后端 FreeMaker 或 Velocity 等模板技术导致 HTML/CSS/JavaScript 等前端技术与后端的处理逻辑和数据耦合到一起。最近发展的前后端分离模式是，前端代码逻辑和界面全部都由 JavaScript 完成，后端只提供基于 URL 的 JSON 数据接口。这样 Web 系统就由原来的 BS 系统，变成了提供 UI 和交互的前端 B 系统，提供数据接口的后端 S 系统，从而达到了前后端分离的目标。

这种方法解决了前后端的耦合问题，但是依然解决不了后端业务单体架构本身存在的问题，特别是对于可用性和扩展性的影响。

1.2 垂直架构

随着我们的系统业务增多、访问量增大时，我们会发现一台单机运行此系统已经无法应付压力。此时，我们可以将系统业务拆分成几个互不关联的系统，分别部署在各自机器上，以划清逻辑并减小压力。此时，用于加速前端页面开发的Web框架(MVC)是关键。

1.3 分布式服务架构

当我们的业务越来越多、应用系统也越来越多时，自然的，我们会发现有些功能已经不能简单划分开来或者划分不出来。此时，可以将公共业务逻辑抽离出来，将之组成独立的服务Service应用 。而原有的、新增的应用都可以与那些独立的Service应用交互，以此来完成完整的业务功能。

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

1.4 流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

这是Dubbo官方给出的架构的发展演进：

2、微服务架构

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务的9大特性如下：

• 组件以服务的形式提供

• 围绕业务功能进行组织

• 产品而不是项目

• 强化终端与弱化管道

• “去中心化” 地治理技术署

• “去中心化” 地管理数据

• “基础设施” 自动化

• “容错” 设计

• “演进式” 设计

微服务架构的优势在于：

（1）更加彻底的组件化，系统内部各个组件之间解耦的比较干脆，单个系统的规模小很多；
（2）可以组建每个服务独立的维护团队，利于各自团队独立的开发和维护；
（3）每个微服务独立部署，只要服务间的接口稳定，各系统可以相互之间互不干扰的独立发展；
（4）微服务架构使得每个服务本身可以独立的扩展，性能出现瓶颈，优化或增加这个服务的配置即可。
（5）微服务架构的劣势也很明显，拆分的过细则要求自动化测试能力必须跟得上。一个全流程的测试跨 8~10个系统是所有测试人员的恶魔。
（6）问题的排查，数据的一致性保障，系统的监控等等，都会因为拆分的太细，复杂度大幅度增加。
根据这些特点，我们可以看下网易云给出的微服务架构方案：
（7）如果代码或设计上有一个修改涉及到多个不同的微服务，那么在团队之间协调配合成本也会增加。对旧系统的微服务架构和组件化改造也是一个比较大的问题。

根据这些特点，我们可以看下网易云给出的微服务架构方案：

完整的解决方案，网易云认为，应该包括微服务治理、API 网关、容器服务、DevOps、AIOps、和测试服务等 6 个模块，各个功能模块的作用如下：

完美的设计方案固然重要，但是在组件化上所做的任何工作的成功度，取决于软件与组件的匹配程度。但是合理的组件边界应该如何确定，这是非常困难的，演进式的处理方式是我们觉得比较合理和靠谱的。因此，不要一上来就以微服务架构作为系统设计的起点。相反地，要用一个单块系统作为起点，并保持其模块化。
当这个单块系统出现了问题后，再将其分解为微服务。

在本专栏，主要是讲SpringCloud的一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。而节约了我们在做开发时技术选型的成本以及降低框架整合的风险。