抛开微服务架构，先看看下面几个问题的解决思路：

  • 如果某个系统需要伸缩扩容，我们通常会购买新的服务器，多部署几套副本实例来分担压力；
  • 如果某个系统需要解决负载均衡的问题，我们通常会布置负载均衡服务器，并选择恰当的均衡算法来分流；
  • 如果需要解决安全传输的问题，我们通常会布置TLS传输链路，配置好CA证书，以保证通讯不被窃听篡改；
  • 如果需要解决服务发现的问题，我们通常会设置DNS服务器，让服务访问依赖稳定的记录名而不是易改变的IP地址等等

从上面的几个问题，我们就可以发现这些问题已经大多都有了专职的基础设施来帮助解决了，那为什么微服务还必须在应用层面上去解决这问题呢？

原因就在于：因为硬件构成的基础设施，跟不上软件构成应用服务的灵活性。

既然软件可以通过命令就可以拆分出不同的服务，那么硬件不可以吗？这就到云原生的时代，微服务时代所取得的成就，本身就离不开以Docker为代表的早期容器化技术的巨大贡献。

近些年蓬勃发展的Kubernetes，可以说是开启了下一个软件架构发展的新纪元。对比下Spring Cloud中提供的应用层面的解决方案，Kubernetes也从基础设施层面给出它的解决方案，而且还是一条全新的、前途更加广阔的解题思路。虽然这一切看起来都很美好，但是从功能灵活性的特点上来，Kubernetes还不如Spring Cloud方案。因为从基础设施层面上很精细化解决一些边缘化的问题（比如做服务熔断）。因为基础设施针对的是整个容器做整体的管理，它的粒度相对来说比较粗犷。

所以微服务的基础设施再次进化，就引出了叫做服务网格的”边车代理模式“。

边车代理模式

微服务基础设施会由系统自动地在服务的资源容器（指Kubernetes的Pod）中注入一个通讯代理服务器（相当于那个挎斗），用类似网络安全里中间人攻击的方式进行流量劫持，在应用毫无感知的情况下，悄悄接管掉应用的所有对外通讯。 这个代理除了会实现正常的服务调用以外（称为数据平面通讯），同时还接受来自控制器的指令（称为控制平面通讯），根据控制平面中的配置，分析数据平面通讯的内容，以实现熔断、认证、度量、监控、负载均衡等各种附加功能。 这样，就实现了既不需要在应用层面附带额外的代码，也提供了几乎不亚于应用代码的精细管理能力的目的。

代表性技术：Istio、Envoy

新技术发展时间比较短，还没有完全成熟起来。但未来可期

思考题

分布式架构发展到服务网格后，真的是到达“最好的时代”了吗？软件架构的发展不太可能真的就此止步，你认为今天的云原生还有哪些主要矛盾，下一次软件架构的进化将会主要解决什么问题？