【图文详解】更强大的微服务架构——SeviceMesh ！
本周和大家聊聊架构进化史-大家可文末扫码加入
随着互联网持续高歌猛进，相关技术名词也是层出不穷，ServiceMesh服务网格这两年尤为火爆，然而很少有讲清楚的文章。笔者这里用心整理了一篇文章，用11张图演绎ServiceMesh的进化历程，由浅入深，老少咸宜，欢迎拍砖！
万丈高楼平地起，要理解高端ServiceMesh，得先从单体应用架构开始。在没有那么多架构概念的“远古”年代，一个网站项目的全部功能都是在一个进程的，一个B/S应用架构应该是这样的：
当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡，架构就变成这样了：
后面发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体响应，然后架构就变成：
然而上面3种架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本缺点：
· 代码臃肿，应用启动时间长；（代码超过1G的项目都有！）
· 回归测试周期长，修复一个小bug都需要完整的回归测试；
· 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；
· 伸缩困难，单体应用扩展性能时只能整个应用进行扩展；
· 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码管理复杂度急剧增加。
这个时候微服务诞生了，微服务架构将单体应用拆解成多个小粒度的微服务 (micro-service)，通过HTTP API来组装对外提供服务。由于每个微服务足够小且功能内聚，因此能很好地解决以往单体应用的开发与发布困难的问题。
微服务架构的核心是为了解决应用微服务化之后的服务治理问题。一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：
解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：
以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：
上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：
· 通过熔断、限流等机制保证高可用；
· 微服务之间调用的负载均衡；
· 分布式事务（2PC、3PC、TCC等）；
· 服务调用链跟踪等。
随着业务的发展和微服务化的深入，微服务架构里面的各种服务治理反而会成为前进的桎梏，因为技术门槛太高，大量企业无法推进下去。于是Service Mesh诞生了！以Linkerd，Envoy，Ngixmesh为代表的代理模式（边车模式）应运而生，这就是第一代Service Mesh，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求。
如果我们从一个全局视角来看，就会得到如下部署图：
如果我们暂时略去服务，只看Service Mesh的单机组件组成的网络：
何为Service Mesh服务网格？这会儿大家应该理解了！
然后为了提供统一的上层运维入口，Service Mesh演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。
只看单机代理组件(数据面板)和控制面板的Service Mesh全局部署视图如下：
至此，11张图见证了单体架构到微服务到服务网格的变迁，展示了Service Mesh到底是什么，以及是如何一步步演化到今天这样一个形态。这两年还有很多热门的技术名词如中台、Severless、Faas、CloudNative，让996的程序员们各种懵。技术演进浩浩荡荡，顺之者昌逆之者亡，追逐高薪，必须直面！本周三(9号).NET社区邀请了重磅大咖(本文贡献者之一)，在线分享《这些年的互联网架构进化史》，欢迎大家扫码进交流社群！
扫码即可加入 添加微信 zhaoxiNET007