【无标题】

ServiceMesh架构

---

前言

总所周知，Java的技术发展日新月异，每当我们去学习一项新技术时，另一项新技术又如雨后春笋一样拔然而起。在微服务后，ServiceMesh架构进入Java工程师的视野。

当软件架构演进至基于Kubernetes实现的微服务时，已经能够相当充分地享受到虚拟化技术发展的红利，如应用能够灵活地扩容缩容、不再畏惧单个服务的崩溃消亡、立足应用系统更高层来管理和编排各服务之间的版本、交互。可是，单纯的Kubernetes仍然不能解决我们面临的所有分布式技术问题，在此前对基于Kubernetes的架构中“技术组件”的介绍里，笔者已经说明光靠着Kubernetes本身的虚拟化基础设施，难以做到精细化的服务治理，譬如熔断、流控、观测，等等；而即使是那些它可以提供支持的分布式能力，譬如通过DNS与服务来实现的服务发现与负载均衡，也只能说是初步解决了的分布式中如何调用服务的问题而已，只靠DNS难以满足根据不同的配置规则、协议层次、均衡算法等去调节负载均衡的执行过程这类高级的配置需求。Kubernetes提供的虚拟化基础设施是我们尝试从应用中剥离分布式技术代码踏出的第一步，但只从微服务的灵活与可控这一点而言，基于Kubernetes实现的版本其实比上一个Spring Cloud版本里用代码实现的效果（功能强大、灵活程度）是有所倒退的，这也是当时我们未放弃Hystrix、Spring Security OAuth 2等组件的原因。

Kubernetes给予了我们强大的虚拟化基础设施，这是一把好用的锤子，但我们却不必把所有问题都看作钉子，不必只局限于纯粹基础设施的解决方案。现在，基于Kubernetes之上构筑的服务网格（Service Mesh）是目前最先进的架构风格，即通过中间人流量劫持的方式，以介乎于应用和基础设施之间的边车代理（Sidecar）来做到既让用户代码可以专注业务需求，不必关注分布式的技术，又能实现几乎不亚于此前Spring Cloud时代的那种通过代码来解决分布式问题的可配置、安全和可观测性。这一个目标，现在已成为了最热门的服务网格框架Istio的Slogan：Connect, Secure, Control, And Observe Services。

---

一、ServiceMesh架构是什么？

可以将ServiceMesh比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控，同样使用 ServiceMesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud，现在只要交给 ServiceMesh 就可以了。ServiceMesh的出现主要是由于应用虚拟化技术的发展，例如Kubernetes等项目，大大降低了应用的部署和运维复杂度。这样说或许还是一种比较抽象的说法，仔细分析一下：

可观察性

将应用程序分解为多个微服务并不会自动将其转换为独立服务的网络。应用程序仍然像以前一样作为一个单一的、独立的应用程序—它只是变成了“分布式的”。它的各个微服务通常共享相同的代码库，并且是单个架构蓝图的一部分。它们更像是父应用程序的“组件”，而不是跨多个应用程序共享的服务。

因为这样的微服务程序仍然作为一个独立的应用程序，而不是作为独立服务的网络，所以开发团队对它们进行故障排查，就像他们对一个整体进行故障排查一样。当然，调试这样的微服务程序变得更加困难，因为应用程序组件现在是分布式的。这正是为什么工程师非常希望能够跨远程服务追踪请求以进行调试的原因。与这种分布式调试相关的术语通常被称为“可观察性”。

因为服务网格是一个专用的基础设施层，所有的服务间通信都要通过它，所以它在技术堆栈中处于独特的位置，以便在服务调用级别上提供统一的遥测指标。这意味着，无论好坏，服务都被监控为“黑匣子”。服务网格捕获诸如来源、目的地、协议、URL、状态码、延迟、持续时间等线路数据。这本质上等同于web服务器日志可以提供的数据，但是当然，服务网格可以为所有服务捕获这些数据，而不仅仅是单个服务的web层。

一旦捕获，度量(metrics)和日志(logs)将由服务网格的控制平面收集并传递给后端所选择的监控工具。对于严重依赖开源技术的公司来说，Prometheus和Grafana分别是存储和可视化的热门选择。

除了度量服务间的调用之外，一些服务网格还支持请求追踪。通过有效的追踪，工程师能够排除各种问题，如排序问题、服务调用树异常和特定请求的问题等。由于使用了span标识符和转发的上下文标头，服务网格可以进行追踪。当然，要使追踪工作正常，需要修改每个服务，以便在输入时读取追踪头信息，将它们传递给所有相关的执行线程，然后将它们添加到对其他服务的每个请求调用中。

需要指出的是，收集数据仅仅是解决微服务应用程序中可观察性问题的一部分。收集和存储度量需要额外能力的机制的补充，借此来分析数据，然后通过作用于警报、实例自动伸缩或者应用程序的一个操作模式断路器来发挥这些数据的作用。

流量控制

当涉及到满足服务级别目标(如延迟和正常运行时间)时，管理服务之间通信的能力是至关重要的。这是因为它允许运营团队实现像circuit breaking或backpressure这样的操作模式，以补偿行为不佳的服务。

服务网格可以提供这种类型的流量控制。因为它们的主要功能是管理服务间通信，所以它们能够相当容易地提供这些特性。然而，由于它们的设计目的是有效地将来源请求调用连接到其最优目标服务实例，所以这些流量控制特性是面向目的地的。换句话说，服务网格适合在一些目的地实例之间平衡单个请求调用，而不合适来控制来源为多个而目的地为一个的流量，或控制整个服务架构的流量。

服务网格通过其控制平面提供对服务间调用的控制，控制平面最终实现组成其数据平面的代理的配置。尽管具体功能可能因服务网格的不同而有所不同，但大多数支持智能配置，即延迟感知负载均衡(也称为“智能路由”)和基于请求属性的路由规则。由于服务网格控制从第4层扩展到第5层及以上，有些还为开发团队提供了实现弹性模式(如重试、超时和截止时间)的能力，以及更高级的模式(如断路、金丝雀发布和A/B发布)。

例如，使用超时，开发人员可以限制微服务等待另一个服务完成请求所需的时间。如果这被证明是一个太粗糙的阈值，超时作为替代可以用来启动断路器。当断路器以这种方式“跳闸”时，它将保持“打开”一段时间，直到服务网格再次认为该服务可用为止。这样，下游客户端就不会受到上游服务过于缓慢的影响，反过来，服务也不会因积压的请求而过载。或者，如果特定客户端的请求行为从服务级别来看，威胁到向相同共享服务发出请求的其他客户端，那么开发人员可以限制高容量客户端的速率，这样其他客户端就不会被淹没。最后，服务网格可以通过强制执行配额来帮助控制流量。例如，运维人员可以根据请求向客户端收费，或者希望在给定的时间范围内限制客户端请求。

安全

在某种程度上，单一应用程序受其单地址空间的保护。然而，一旦单一应用程序被分解为多个微服务，网络就会成为一个重要的攻击面。更多的服务意味着更多的网络流量，这对黑客来说意味着更多的机会来攻击信息流。这就是为什么服务要网格化，因为网格提供了保护网络调用的能力(和基础设施)。

服务网格的安全相关的好处体现在以下三个核心领域:

服务的认证。
服务间通讯的加密。
安全相关策略的强制执行。
例如，Istio为开发人员提供了一个证书授权来管理密钥和证书。使用Istio，您可以为每个服务生成证书，并透明地管理这些证书的分发、轮换和撤销。有了这些功能，服务可以彼此进行身份验证并实现适当的访问控制。通常，这以白名单和黑名单的形式出现，因此服务网格知道是否接受传入的请求。在加密方面，服务网格可以使用相互传输层安全协议(mTLS)锁定数据平面通信，从而使服务到服务的通信更加安全。最后，一些服务网格能够执行适用于特定pod、特定命名空间或特定服务的各种安全策略。

二、实战

Bookstore采用基于Istio的服务网格架构。

1.技术组件

配置中心：通过Kubernetes的ConfigMap来管理。
服务发现：通过Kubernetes的Service来管理，由于已经不再引入Spring Cloud Feign了，所以在OpenFeign中，直接使用短服务名进行访问。
负载均衡：未注入边车代理时，依赖KubeDNS实现基础的负载均衡，一旦有了Envoy的支持，就可以配置丰富的代理规则和策略。
服务网关：依靠Istio Ingress Gateway来实现，已经移除了Kubernetes版本中保留的Zuul网关。
服务容错：依靠Envoy来实现，已经移除了Kubernetes版本中保留的Hystrix。
认证授权：依靠Istio的安全机制来实现，实质上已经不再依赖Spring Security进行ACL控制，但Spring Security OAuth 2仍然以第三方JWT授权中心的角色存在，为系统提供终端用户认证，为服务网格提供令牌生成、公钥JWKS等支持。

2.项目地址

https://github.com/fenixsoft/servicemesh_arch_istio

---

总结

推荐一套学习serviceMesh方案：https://www.infoq.cn/article/x7msfGEOZ9iRzmB50Koq