微服务1：微服务及其演进史

★ 微服务系列

---

微服务1：微服务及其演进史

微服务2：微服务全景架构 

微服务3：微服务拆分策略

微服务4：服务注册与发现

微服务5：服务注册与发现（实践篇）

1 传统单体系统介绍

---

在很多项目的业务初期阶段，高速迭代上线是首要考虑的事情，对后期的容量预估、可扩展性和系统健壮性、高可用一般没有那么重视。但随着业务的发展，用户量、请求量的暴增，

发现原来的单体系统已经远远不满足需求了，特别是随着互联网整体的高速发展，对系统的要求越来越高。

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

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

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

 

1.1 单体系统的问题

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

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

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

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

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

 

1.2 单体系统的优点

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

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

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

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

 

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

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

 

2 关于微服务

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）模式部署，同时对业务应用透明。

 

 

SideCar将分布式服务的通信抽象为单独一层，需要和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求。

所以在这一层中它能够实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能。

 

如果我们从一个全局视角来看，绿色的为应用服务，蓝色的为SideCar，就会得到如下部署图：

 

如果我们省略去服务，只看Service Mesh的代理边车的网格应该是这样的：

 

流量经过的时候，会先被代理边车所劫持，然后再进入服务，所以它就是一个由若干服务代理所组成的错综复杂的网格。  

3.7 第七阶：第二代Service Mesh

第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，我们称之为控制面（control plane）。

控制面和所有的数据面（data plane，即代理边车）进行交互，比如策略下发、数据采集等。这就是以Istio为代表的第二代Service Mesh。

 

只包含控制面和数据面的 Service Mesh 服务网格全局结构图 如下：

 

从上面的结构图可以看出，Service Mesh 的基础设施层主要分为两部分：控制平面与数据平面。当前流行的开源服务网格 Istio 和 Linkerd 都是这种构造。

控制平面的特点：

• 不直接解析数据包。
• 与控制平面中的代理通信，下发策略和配置。
• 负责网络行为的可视化。
• 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。

数据平面的特点：

• 通常是按照无状态目标设计的，但实际上为了提高流量转发性能，需要缓存一些数据，因此无状态也是有争议的。
• 直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
• 对应用来说透明，即可以做到无感知部署。

到这一步我们大概了解了微服务架构的演进过程，也初步了解Service Mesh技术比较于传统的微服务架构有哪些优势。

• 还没有人评论，欢迎说说您的想法！