后微服务时代-凤凰架构

        第一章第五小节，开篇提出了一个问题，关于微服务中可种需要解决的问题，如注册发现、跟踪治理、负载均衡、传输通信等，这些问题一定要由软件系统自己来解决吗？

        如果不局限于采用软件的方式，这些问题几乎都有对应的硬件解决方案。譬如，某个系统需要伸缩扩容，通常会购买新的服务器，部署若干副本实例来分担压力；如果某个系统需要解决负载均衡问题，通常会布置负载均衡器，选择恰当的均衡算法来分流；如果需要解决传输安全问题，通常会布置TLS传输链路，配置好CA证书以保证通信不被窃听篡改；如果需要解决服务发现问题，通常会设置DNS服务器，让服务访问依赖稳定的记录名而不是易变的IP地址，等等。随着计算机科学多年的发展，这些问题大多有了专职化的基础设施去解决，而在微服务时代，人们之所以选择在软件的代码层面而不是硬件的基础设施层面去解决这些分布式问题，很大程度上是因为由硬件构成的基础设施跟不上由软件构成的应用服务的灵活性的无奈之举。软件可以只使用键盘命令就拆分出不同的服务，只通过拷贝、启动就能够实现伸缩扩容服务，硬件难道就不可以通过键盘命令变出相应的应用服务器、负载均衡器、DNS服务器、网络链路这些设施吗？

       至此，需要提到虚拟化技术和容器化技术了。微服务时代所取得的成就，本身就离不开以Docker为代表的早期容器化技术的巨大贡献。在此之前，笔者从来没有提过“容器”二字，这并不是刻意冷落，而是早期的容器只被简单地视为一种可快速启动的服务运行环境，目的是方便程序的分发部署，在这个阶段，针对单个应用进行封装的容器并未真正解决分布式架构问题。再谈到基础设施，它是针对整个容器管理的，粒度相对粗犷，对单个远程服务很难有效管控。比如，在服务的监控、认证、授权、安全、负载均衡等方面都可能面临细化管理的需求，譬如服务调用时的负载均衡，往往需要根据流量特征，调整负载均衡的层次 、算法等，而DNS虽然能实现一定程度的负载均衡，但通常并不能满足这些额外的需要。

       为了解决这一类问题，虚拟化的基础设施很快完成了第二次进化，引入了今天被称为“服务网格”（Service Mesh）的“边车代理模式”（Sidecar Proxy），如图1-5所示。所谓“边车”是一种带垮斗的三轮摩托车，笔者小时候还算常见，现在基本就只在影视剧中才会看到了。在虚拟化场景中的边车指的是由系统自动在服务容器（通常是指Kubernetes的Pod）中注入一个通信代理服务器，相当于那个挎斗，以类似网络安全里中间人攻击的方式进行流量劫持，在应用毫无感知的情况下，悄然接管应用所有对外通信。这个代理除了实现正常的服务间通信外（称为数据平面通信），还接收来自控制器的指令（称为控制平面通信），根据控制平面中的配置，对数据平面通信的内容进行分析处理，以实现熔断、认证、度量、监控、负载均衡等各种附加功能。通过边车代理模式，便实现了既不需要在应用层面加入额外的处理代码，也提供了几乎不亚于程序代码的精细管理能力。

      未来Kubernetes将会成为服务器端的标准运行环境，如同现在的Linux系统；服务网格也将会成为微服务之间通信交互的主流模式，把“选择什么通信协议”“怎样调度流量”“如何认证授权”之类的技术问题隔离于程序代码之外，取代今天Spring Cloud全家桶中大部分组件的功能。微服务只需要考虑业务本身的逻辑，这才是最理想的智能终端解决方案。

***********************************************************************

【如果文字看累了，可b站搜索“沙皮狗2021”，用听的方式领略知识的魅力】

   传送门 ：https://space.bilibili.com/407643589

***********************************************************************