学习笔记-架构的演进之后微服务-2月day06

引言

回顾之前微服务架构中需要解决的问题，比如注册发现、跟踪治理、负载均衡、传输通讯等，当前针对各各独立的问题的解决方案包括：

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

在微服务时代，我们之所以不得不在应用服务层面，而不是基础设施层面去解决这些分布式问题，完全是因为由硬件构成的基础设施，跟不上由软件构成的应用服务的灵活性。

虚拟化和容器化技术为上述问题提供了解决方案。

Kubernetes

当虚拟化的基础设施，开始从单个服务的容器发展到由多个容器构成的服务集群，以及集群所需的所有通讯、存储设施的时候，软件与硬件的界限就开始模糊了。一旦硬件能够跟得上软件的灵活性，那么这些与业务无关的技术问题，便很可能从软件的层面剥离出来，在硬件的基础设施之内就被悄悄解决掉，让软件可以只专注于业务，真正“围绕业务能力构建”团队与产品。那么原来只能从软件层面解决的分布式架构问题，于是有了另外一种解法：应用代码与基础设施软硬一体，合力应对。

以上正是Kubernetes容器管理系统所带来的容器间网络、服务、负载均衡、配置等虚拟化基础设施。

云原生

云原生时代追求的目标，跟此前微服务时代中追求的目标相比，并没有什么本质的改变，它们都是通过一系列小型服务去构建大型系统。在服务架构演进的历史进程中，“云原生时代”似乎也可以被称为“后微服务时代”。

Kubernetes 成为了容器战争的胜利者，标志着后微服务时代的开端，但 Kubernetes 其实并没有完美地解决全部的分布式问题。因为有一些问题处于应用系统与基础设施的边缘，我们很难能完全在基础设施的层面中，去精细化地解决掉它们。
比如：

• 微服务 A 调用了微服务 B 中发布的两个服务，我们称之为 B1 和 B2，假设 B1 表现正常，但 B2 出现了持续的 500 错，那在达到一定的阈值之后，我们就应该对 B2 进行熔断，以避免产生雪崩效应。如果我们仅在基础设施的层面来做处理，这就会遇到一个两难问题，也就是切断 A 到 B 的网络通路，会影响到 B1 的正常调用，而不切断的话则会持续受到 B2 的错误影响。（主要是因为基础设施是针对整个容器来做整体管理的，它的粒度相对粗犷，无法精确到应用层面。）

实际上，类似的情况不仅仅会在断路器上出现，服务的监控、认证、授权、安全、负载均衡等功能，都有细化管理的需求。比如，服务调用时的负载均衡，往往需要根据流量特征，调整负载均衡的层次、算法等，而 DNS 尽管能实现一定程度的负载均衡，但它通常并不能满足这些额外的需求。

服务网格（Service Mesh）

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

In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between services or microservices, using a proxy. (From Wikipedia)

如边车代理（Sidecar Proxy）流量模式：

虽然，我们很难从概念上，来判定一个与应用系统运行于同一资源容器之内的代理服务，到底应该算是软件，还是算作基础设施，但只要它对应用是透明的，不需要改动任何软件代码就可以实现服务治理，这就足够了。

总结

后微服务时代带来了容器化技术对软件架构、软件开发的改变，提出了通过虚拟化基础设施，来解决分布式问题的办法。服务网格仍然是一个新潮的概念，甚至连 Kubernetes 也还算是个新生事物（如果看开源的日期的话）。未来几年，Kubernetes 将会成为服务器端标准的运行环境，如同在此之前的 Linux 一样；服务网格将会成为微服务之间通讯交互的主流模式，它会把“选择什么通讯协议”“如何做认证授权”之类的技术问题隔离于应用软件之外，取代今天的 Spring Cloud 全家桶中的大部分组件的功能。这是最理想的Smart Endpoints解决方案，微服务只需要考虑业务本身的逻辑就行了。

上帝的归上帝，凯撒的归凯撒，业务与技术完全分离，远程与本地完全透明。

附

此文章为2月Day5学习笔记，内容来源于极客时间《周志明的软件架构课》