微服务架构演进史

时间:2022-05-23 Brand 人气:0

1 传统单体系统介绍

物理服务器的CPU、内存、存储器、连接数等资源有限，单体系统能够承受的的QPS也是有限的，某个时段大量连接同时执行操作，会导致web服务和数据库服务在处理上遇到性能瓶颈。

为了解决这个问题，伟大的前辈们发扬了分而治之的思想，对大数据库、大表进行分割，可以参考我的《Mysql数据库分库分表全面瓦解》，以便实施更好的控制和管理。

同时创建多个服务实例，使用多台服务机进行CPU、内存、存储的分摊，提供更好的性能。

1.1 单体系统的问题

1、复杂性高：由于是一个单体的系统，所以整个系统的模块是耦合在一起的，模块的边界比较模糊、依赖关系错综复杂。功能的调整，容易带来不可知的影响和潜在的bug风险。

2、服务性能问题：单体系统遇到性能瓶颈问题，只能横向扩展，增加服务实例，进行负载均衡分担压力。无法纵向扩展，做模块拆分。

3、扩缩容能力受限：单体应用只能作为一个整体进行扩展，影响范围大，无法根据业务模块的需要进行单个模块的伸缩。

4、无法做故障隔离：当所有的业务功能模块都聚集在一个程序集当中，如果其中的某一个小的功能模块出现问题（如某个请求堵塞），那么都有可能会造成整个系统的崩溃。

5、发布的影响范围较大：每次发布都是整个系统进行发布，发布会导致整个系统的重启，对于大型的综合系统挑战比较大，如果将各个模块拆分，哪个部分做了修改，只发布哪个部分所在的模块即可。

1.2 单体系统的优点

1、系统的简易性：系统语言风格、业务结构，接口格式均具有一致性，服务都是耦合在一起的，不存在各个业务通信问题。

2、易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，简化了测试过程，无需额外测试服务间的依赖，测试均可在部署完成后开始。

3、易于部署与升级：相对于微服务架构中的每个服务独立部署，单体系统只需将单个目录下的服务程序统一部署和升级。

4、较低的维护成本：只需维护单个系统即可。运维主要包括配置、部署、监控与告警和日志收集四大方面。相对于单体系统，微服务架构中的每个服务都需要独立地配置、部署、监控和日志收集，成本呈指数级增长。

1.3 单体服务到微服务的发展过程

EUREKA的注册中心逐渐被ZooKeeper和Nacos等替代了。

2 关于微服务

微服务是一种架构模式，是面向服务的体系结构（SOA）软件架构模式的一种演变，

它提倡将单一应用程序划分成一组松散耦合的细粒度小型服务，辅助轻量级的协议，互相协调、互相配合，为用户提供最终价值。

所以，微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常包含如下特点：

2.1 单一职责

微服务架构中的每个节点高度服务化，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，包括数据库和数据模型；

不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。

2.2 轻量级通信

通过REST API模式或者RPC框架，实现服务间互相协作的轻量级通信机制。

2.3 独立性

在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试、部署、运维。

2.4 进程隔离

在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上，实现高度自治和高度隔离。

进程的隔离，还能保证服务达到动态扩缩容的能力，业务高峰期自动增加服务资源以提升并发能力，业务低谷期则可自动释放服务资源以节省开销。

2.5 混合技术栈和混合部署方式

团队可以为不同的服务组件使用不同的技术栈和不同的部署方式（公有云、私有云、混合云）。

2.6 简化治理

组件可以彼此独立地进行扩缩容和治理，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。

2.7 安全可靠，可维护。

从架构上对运维提供友好的支撑，在安全、可维护的基础上规范化发布流程，支持数据存储容灾、业务模块隔离、访问权限控制、编码安全检测等。

3 微服务演进史

我们前面已经了解了微服务的概念，通过百度指数可以看出，从2012年之后，微服务的发展有显著的发展趋势。

目前业内的微服务相关开发平台和框架还是比较多的，比如较早的Spring Cloud（使用Eureke做服务注册与发现，Ribbon做服务间负载均衡，Hystrix做服务容错保护），

阿里的Dubbo，微软的.Net体系微服务框架 Service Fabric，再到后来进阶的服务网格(Service Mesh,如 Istio、Linkerd）。

那从12年开始到现在，微服务到底发展到哪个阶段了，在各个阶段的进阶过程中，又有哪些的变化。所以我们需要了解微服务技术的历史发展脉络。

下面的内容参考了 Phil Calçado的文章《Pattern: Service Mesh》，从开发者的视角，详细分析了从微服务到Service Mesh技术的演进过程，这边做了进一步的整理和总结。

3.1 第一阶：简单服务通信模块

这是最初的模样，开发人员最开始的时候想象的两个服务间简单的通信模式，抽象表示如下，两个服务之间直接进行通信：

3.2 第二阶：原始通信时代

上面的方式非常简单，但实际情况远比想象的复杂很多，通信需要底层字节码传输和电子信号的物理层来完成，在TCP协议出现之前，

服务需要自己处理网络通信所面临的丢包、错误、乱序、重试等一系列流控问题，因此服务实现中，除了业务逻辑外，还包含对网络传输问题的处理逻辑。

3.3 第三阶：TCP时代

TCP协议的出现，避免了每个服务自己实现一套相似的网络传输处理逻辑，解决网络传输中通用的流量控制问题。

这时候我们把处理网络传输的能力下沉，从服务的实现中抽离出来，成为操作系统网络层的一部分。

3.4 第四阶：第一代微服务（Spring Cloud/RPC）

TCP出现之后，服务间的网络通信已经不是一个难题了，所以 GFS/BigTable/MapReduce 为代表的分布式系统得到了蓬勃的发展。

这时，分布式系统特有的通信语义又出现了，如服务注册与发现、负载均衡、熔断降级策略、认证和授权、端到端trace、日志与监控等，因此根据业务需求,完成一些通信语义的实现。

3.5 第五阶：第二代微服务

为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的通用开发框架出现了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等，

这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。

3.6 第六阶：第一代Service Mesh

上面的第二代微服务框架目前看着挺完美了，但整套微服务框架其实是很复杂的，比如Spring Cloud，聚合了很多组件。所以在实践过程中，会发现有如下诸多问题：

侵入性强。想要集成SDK的能力，除了需要添加相关依赖，业务层中入侵的代码、注解、配置，与治理层界限不清晰。
升级成本高。每次升级都需要业务应用修改SDK版本，重新进行功能回归测试，并对每一台服务进行部署上线，与快速迭代开发相悖。
版本碎片化严重。由于升级成本高，而中间件版本更新快，导致线上不同服务引用的SDK版本不统一、能力参差不齐，造成很难统一治理。
中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着"枷锁”前行，无法实现快速迭代。
内容多、门槛高。依赖组件多，学习成本高，即使通用分布式系统屏蔽了很多的实现细节，我们引入微服务框架并熟练使用也是要花费巨大的精力的。
治理功能不全。不同于RPC框架，SpringCloud作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。
无法实现真正意义上的语言无关性。提供的框架一般只支持一种或几种语言，要将框架不支持的语言研发的服务也纳入微服务架构中，是比较有难度的。

所以，第一代微服务架构 Service Mesh就产生了，它作为一个基础设施层，能够与业务解耦，主要解决复杂网络拓扑下微服务与微服务之间的通信，其实现形态一般为轻量级网络代理，并与应用以边车代理（SideCar）模式部署，同时对业务应用透明。