现在越来越多的大型组织在向更加自组织的团队结构转型，这些团队拥有并运营自己的微服务，但他们如何在不依赖集中式托管的基础架构下，确保服务之间必要的一致性与兼容性呢?为了确保服务之间的有效协作，即使是自组织的微服务也需要与一些组织标准对齐。服务啮合(SERVICE MESH)在服务发现、安全、跟踪、监控与故障处理方面提供了一致性，且不需要像API网关或ESB这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程，这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现(而非共享的运行时实例)，我们可以获得服务的互操作性和可观测性。一段时间以来，我们一直主张去中心化的微服务管理方法，也很高兴看到服务啮合这种一致性模式的出现。随着linkerd和Istio等开源项目的成熟，服务啮合的实现将更加容易。
新瓶旧酒还是厚积薄发?
对于持续关注云服务架构设计***发展趋势的同学来说，刚过去的2017年，最火的词莫过于CNCF了，这是一个专注于“云原生”(Cloud Native)的基金会，由众多战斗在云服务一线的公司(包括了谷歌、AWS、阿里云等等)组建而来，旨在推进云原生的架构标准化与***实践的普及。
最近，“云原生”(Cloud Native)和 “微服务”(Microservices)也引出了许多相关的技术，随着 Kubernetes、Docker 等一众容器管理工具的普及，我们也看到在容器的内部，微服务的架构设计也发生着一些变化，其中“服务啮合”(Service Mesh)就成为了大家关注的热点。
那么这些变化到底是新瓶旧酒，还是厚积薄发?我们不妨先从一个更耳熟能详的架构——“网关”(Gateway)谈起。
网关(Gateway)的作用
作为微服务工具链中的元老，“网关”(Gateway) 的引入为微服务API提供统一的入口和平台，不同的服务可以得到一致的管理。使用网关的架构可以减少企业大量的重复开发。甚至有一些通用的逻辑也可以使用网关来承载(如Zuul、Enovy、OpenResty等)。
不论初心为何，这些网关们随着时光流转，功能也变得越来越丰富，网关可以负责解决不同服务的服务注册发现、负载均衡、配额流控、监控日志、缓存加速、配置分离、安全管控、跟踪审计等问题。这一系列的功能，我们可以大致分为两类：“数据面”和“控制面”。
数据面(Data Plane)负责在数据包粒度上进行筛选和处理：
- 路由转发
- 负载均衡
- 安全通信
- 缓存加速
- 认证鉴权
- 日志审计
- 健康检查
- 熔断限流
控制面(Control Plane)负责在服务粒度上进行统筹和管理：
- 注册发现
- 配置管控
- 弹性伸缩
- 统筹遥测
- 容错自愈
- 策略执行
- 证书签发
这一系列的功能，就是网关面临的问题域。在了解问题域之后，让我们回归本篇的主题：继承了“网关”(Gateway)衣钵的“微网关”(MicroGateway)和“服务啮合”(Service Mesh)，它们到底是什么?
什么是微网关?
随着微服务的普及，传统的中心化网关变得越来越厚重，由于与中心化节点通信，带来了大量网络、IO开销以及单点问题，往往无法满足我们对于实时性、高可用的要求。另外越来越多的自治化需求，与原有集权式微服务治理方法之间，也产生出许多冲突矛盾。因此，与微服务化相适应的，可以本地化、分布式部署的微网关(MicroGateway)也逐渐涌现出来。
什么是服务啮合?
服务啮合(Service Mesh)是一种为了保证“服务到服务”的安全、快速和可靠的通信而产生的基础架构层，区别于应用层、通信层的一种新的云原生上下文内的抽象层。如果你正在构建云原生的应用程序，在微服务拓扑结构日益复杂的今天，服务啮合层的提出，可以帮助开发者将服务的交互通信问题与微服务内部的业务问题隔离开来，专注于各自的领域。
演进中的微网关与服务啮合
当我们了解到微网关与服务啮合的作用之后，就可以一起来看一下微网关与服务啮合架构是如何一步步设计出来的。
1. 低侵入性组件(Low-Invasive Component)
最初的服务间互访，常常由于业务尚不清晰，给标准化带来了障碍。因此我们常常见到一些由领域专家提供的低侵入性的组件，为服务的开发者提供抽象的规范，使其能轻松获得定制化能力。
组件可以更好地规范问题，并且尽可能地将组件封装为简单的接口，早期的服务发现常常通过该类方式实现，例如 Eureka 套件通过引入 Client 来获得完整的如报告、监控、熔断等能力。
我们在一些 IAM (Identity Access Management)的服务设计中采用了这种模式，为各个业务服务提供了一致的认证鉴权接口，由领域专家驱动，设计规范化的调用模式。由于该类组件尽可能设计为低侵入性的接口，因此微服务团队也可以更加便利地根据不同场景取舍是否使用该组件提供的功能，例如通过配置文件加 feature toogle 简单地在开发环境中关闭认证鉴权的功能，以加快开发进程。
2. 反向代理(Reverse Proxy)
随着服务成熟度的提高，我们可以发现一些常见的非业务强相关的逻辑，可以从原有的服务中剥离出来，通过反向代理统一进行过滤处理。
反向代理，可以为微服务处理请求的前后环节增添通用逻辑，例如 apigee 提供的 API proxy 封装，通过反向代理模式为原有的服务添加 PreFlow、PostFlow，解决请求生命周期前后常见的问题，例如检查配额和记录调用频度，对 CORS 等 Http Header 的添加和消费，这些功能有些类似于传统的 Filter 模型，但是却可以独立部署。
反向代理可以提供更高的可用性，并帮助微服务开发者从这些常见细节中解脱出来。
3. 侧车模式(Sidecar Pattern)
准确来说，侧车模式(Sidecar Pattern)本身并非微网关或者服务啮合技术独有，它只是一种特定的软件模块共生关系。侧车模式可以是一个反向代理，也可以作为一个服务存在。
作为反向代理使用的Sidecar进程可以过滤请求与返回内容，实现如安全通信、认证鉴权、服务端/客户端负载均衡、自动路由等功能。
作为服务使用的Sidecar进程可以为主服务提供额外能力，实现分布式缓存同步、配置文件拉取、日志搜集等功能。
侧车模式常见于分布式缓存和安全基础设施网关，通过与微服务进程共同启停的服务或容器，可以更方便地与微服务一并调度，享受微服务管理平台本身提供的服务发现、注册、配置、扩容能力。通过共享生命周期，在简单部署和灵活应用中寻找一个平衡。
我们在微服务框架 Jhipster 提供的基础能力中，可以直接通过注解使用 Hazelcast 的分布式缓存，正是通过 Sidecar 模式实现的，拥有共生的分布式缓存实例后，可轻松实现服务接口的缓存，而分布式缓存自身的同步策略等问题都被封装在 Sidecar 进程中，无需开发者花费大量时间重新开发和调试。Sidecar也可以用于实现例如OAuth等安全相关的守护服务，帮助微服务处理业务界限外的专项问题。
4. 原生的基础设施(Native Infrastructure)
服务啮合带来的***的不同就是原生无感知，通过侧车模式部署的反向代理，与一些容器系统级的配置结合，更彻底地解决微服务在数据面与管理面的能力一致性问题。
服务啮合框架 Istio 提供了 Istio-Initializer 和 istioctl 工具，你可以在Kubernetes的容器整备过程中，注入所需的配置和 Envoy 容器，将Sidecar Proxy、Sidecar Service注册为容器集群中的原生服务，可以在享受弹性部署的同时，享受数据面和控制面协同提供的标准化能力。无痛地加入Istio提供的功能，如 iptables 代理转发、双向TLS认证、限流策略、日志收集等等。
我们在设计服务啮合层时也可以考虑使用更原生的服务组织与部署策略，例如将微服务容器注册为系统服务、通过控制流对容器进行编排、尽可能与微服务共享生命周期和运行环境来提高可用性与性能等等。
从现在开始，拥抱微服务的云原生生态
既是新瓶旧酒，又是厚积薄发，云原生趋势下的微服务也在不断的演进，逐渐变成我们最初希望的“会呼吸”的模样。我们建议您考虑在一些适用的场景，尤其是微服务化的架构设计中，考虑使用微网关与服务啮合，并总结***实践与我们交流。
让我们一起期待云原生生态下的微服务，为数字化时代提供更多的想象力。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
