认识达内从这里开始

我们在前几期的文章中给大家简单介绍了微服务架构开发的一些基础知识等内容，而本文我们就通过案例分析来学习一下，微服务架构发展经历了哪些阶段。

1、简单服务通信模块

这是初的模样，开发人员开始的时候想象的两个服务间简单的通信模式

2、原始通信时代

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

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

3、TCP时代

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

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

4、SpringCloud/RPC

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

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

5、二代微服务

为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的通用开发框架出现了。

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

6、ServiceMesh

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

侵入性强。想要集成SDK的能力，除了需要添加相关依赖，业务层中入侵的代码、注解、配置，与治理层界限不清晰。

升级成本高。每次升级都需要业务应用修改SDK版本，重新进行功能回归测试，并对每一台服务进行部署上线，与快速迭代开发相悖。

版本碎片化严重。由于升级成本高，而中间件版本更新快，导致线上不同服务引用的SDK版本不统一、能力参差不齐，造成很难统一治理。

中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着"枷锁”前行，无法实现快速迭代。

内容多、门槛高。依赖组件多，学习成本高，即使通用分布式系统屏蔽了很多的实现细节，我们引入微服务框架并熟练使用也是要花费巨大的精力的。

7、二代ServiceMesh

一代ServiceMesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，我们称之为控制面(controlplane)。

控制面和所有的数据面(dataplane，即代理边车)进行交互，比如策略下发、数据采集等。这就是以Istio为代表的二代ServiceMesh。

ServiceMesh的基础设施层主要分为两部分：控制平面与数据平面。当前流行的开源服务网格Istio和Linkerd都是这种构造。

控制平面的特点：

不直接解析数据包。

与控制平面中的代理通信，下发策略和配置。

负责网络行为的可视化。

通常提供API或者命令行工具可用于配置版本化管理，便于持续集成和部署。

数据平面的特点：

通常是按照无状态目标设计的，但实际上为了提高流量转发性能，需要缓存一些数据，因此无状态也是有争议的。

直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。

对应用来说透明，即可以做到无感知部署。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。