现在越来越多的大型组织正在过渡到更加自组织的团队结构。在架构下，如何保证服务之间必要的一致性和兼容性？为了确保服务之间的有效协作，即使是自组织微服务也需要与某些组织标准保持一致。服务网格(SERVICEMESH)在服务发现、安全、跟踪、监控和故障处理方面提供一致性，而无需API网关或ESB等共享资产。服务网格化的典型实现由轻量级反向代理进程组成，这些进程可以与每个服务进程一起部署在单独的容器中。反向代理与服务注册中心、身份提供者、日志聚合器等进行通信。通过此代理的共享实现（而不是共享运行时实例），我们获得了服务互操作性和可观察性。一段时间以来，我们一直提倡一种去中心化的微服务管理方法，我们很高兴看到一致的服务网格化模式的出现。随着linkerd和Istio等开源项目的成熟，服务网格化将变得更容易实现。新瓶旧酒还是积累？对于持续关注云服务架构设计最新发展趋势的同学来说，在刚刚过去的2017年，最火的词莫过于CNCF，它是一个专注于“云原生”（CloudNative）的基金会，由众多奋战在云服务领域的公司建立。云服务一线（包括谷歌、AWS、阿里云等），旨在推动云原生架构的标准化和最佳实践的普及。最近，“云原生”和“微服务”也推出了很多相关技术。随着Kubernetes、Docker等容器管理工具的普及，我们也看到在容器内部，微服务、服务的架构设计也发生了一些变化，其中“ServiceMesh”成为关注的焦点。那么这些变化是新瓶装旧酒，还是日积月累？我们不妨从一个比较熟悉的架构——“网关”（Gateway）说起。Gateway的作用作为微服务工具链中的老将，“Gateway”的引入为微服务API提供了统一的入口和平台，不同的服务可以统一管理。使用网关架构可以减少很多企业的重复开发。甚至一些通用的逻辑也可以通过网关来承载（比如Zuul、Enovy、OpenResty等）。不管初衷如何，随着时间的推移，这些网关的功能越来越多。网关可以负责解决不同服务的服务注册发现、负载均衡、配额流控、监控日志、缓存加速、配置分离、安全管控等。、后续审核等问题。这一系列的功能大致可以分为两类：“数据平面”和“控制平面”。数据平面（DataPlane）负责数据包粒度的筛选和处理：路由转发负载均衡安全通信缓存加速Authentication认证日志审计健康检查熔断限流控制平面（ControlPlane）负责统筹规划和服务粒度管理：注册、发现、配置、管控、弹性伸缩、统筹、遥测、容错、自愈策略、证书颁发执行等一系列功能是网关面临的问题域。了解了问题域之后，让我们回到本文的主题：继承了“网关”（Gateway）衣钵的“微网关”（MicroGateway）和“服务网格”（ServiceMesh），究竟是什么？什么是MicroGateway？随着微服务的普及，传统的中心化网关越来越重。由于与中心化节点通信，带来大量的网络、IO开销和单点问题，往往不能满足我们对实时性和高可用的要求。要求。此外，日益增长的自治需求与原有的中心化微服务治理方式也存在诸多冲突。因此，可以本地化和分布式适应微服务的微网关（MicroGateways）逐渐兴起。什么是服务网格？服务网格（ServiceMesh）是为确保安全、快速和可靠的“服务到服务”通信而创建的基础设施层。它不同于应用层和通信层。一个新的云原生上下文中的抽象层。如果你正在构建云原生应用，在微服务拓扑越来越复杂的今天，服务网格层的提出可以帮助开发者将服务的交互通信问题与微服务内部的业务问题隔离开来，专注于自己的领域.演进的微网关和服务网格当我们了解了微网关和服务网格的作用后，我们可以一步步看一下微网关和服务网格架构是如何设计的。1.低侵入组件（Low-InvasiveComponent）最初的服务间互访，往往因为业务还不明确，给标准化带来障碍。因此，我们经常会看到领域专家提供一些低侵入性的组件，为服务开发者提供抽象的规范，使他们能够轻松获得定制能力。组件可以更好的规范问题，尽可能将组件封装成简单的接口。早期的服务发现通常以这种方式实现。例如Eureka套件通过引入Client获得了完整的上报、监控、熔断等能力。我们在一些IAM（IdentityAccessManagement）服务设计中采用了这种模型，为各种业务服务提供一致的认证和鉴权接口，由领域专家驱动，设计标准化的调用模式。由于这类组件尽可能设计成低侵入式的接口，微服务团队也可以根据不同的场景选择是否使用该组件提供的功能，比如在开发环境中简单的关闭鉴权通过添加特性工具到配置文件认证功能加速开发进程。2.反向代理（ReverseProxy）随着服务成熟度的提高，我们可以找到一些通用的非业务相关的逻辑，可以从原有的服务中分离出来，通过反向代理进行过滤。反向代理可以在微服务处理请求的前后端链接上添加通用逻辑，比如apigee提供的API代理包，通过反向代理的方式在原服务上添加PreFlow和PostFlow，解决请求前后的常见问题lifecycle，比如Checkingquota和recordcallfrequency，添加和消费HttpHeaders比如CORS，这些功能和传统的Filter模型有些类似，但是可以独立部署。反向代理可以从这些常见细节中提供更高的可用性和免费的微服务开发人员。3.SidecarPattern准确的说，SidecarPattern本身并不是微网关或服务网格技术所特有的，它只是软件模块的一种特定的共生关系。Sidecar模式可以是反向代理或作为服务存在。作为反向代理的Sidecar进程，可以过滤请求和返回内容，实现安全通信、鉴权认证、服务端/客户端负载均衡、自动路由等功能。作为服务使用的sidecar进程可以为主服务提供额外的能力，实现分布式缓存同步、配置文件拉取、日志收集等功能。sidecar模式常见于分布式缓存和安全基础设施网关。通过与微服务进程一起启停的服务或容器，可以更方便的与微服务一起调度，享受微服务管理平台自身提供的服务发现和注册。、配置和扩容。通过共享生命周期，在简单部署和灵活应用之间找到平衡点。在微服务框架Jhipster提供的基础能力中，我们可以通过注解直接使用Hazelcast的分布式缓存，这是通过Sidecar模式实现的。有了共生的分布式缓存实例后，可以轻松实现服务接口的缓存，并将缓存本身的同步策略等分布式问题封装在Sidecar进程中，免去开发者花费大量时间关于重新开发和调试。Sidecar也可以用来实现OAuth等安全相关的守护服务，帮助微服务处理业务边界之外的特殊问题。4.原生基础设施（NativeInfrastructure）服务网格化带来的最大差异是原生不敏感。通过sidecar模式部署的反向代理，结合一些容器系统级的配置，更彻底的解决微服务。数据平面和管理平面之间能力的一致性。服务网格框架Istio提供了Istio-Initializer和istioctl工具。您可以在Kubernetes容器准备过程中注入所需的配置和Envoy容器，将SidecarProxy和SidecarService注册为容器集群中的原生服务。您可以在享受弹性部署的同时，享受数据面和控制面协同提供的标准化能力。无痛添加Istio提供的特性，如iptables代理转发、双向TLS认证、限流策略、日志收集等。我们在设计服务网格层时也可以考虑使用更多原生的服务组织和部署策略，比如注册微服务容器作为系统服务，通过控制流编排容器，尽可能与微服务共享生命周期和运行环境。提高可用性和性能等等。从现在开始，拥抱微服务的云原生生态既是新瓶陈酒，也是长期积累。云原生趋势下的微服务也在不断进化，逐渐成为我们原本希望的“会呼吸”的模样。我们建议大家在一些适用场景，尤其是微服务架构设计中，考虑使用微网关与服务进行网格化，总结最佳实践与我们交流。让我们共同期待云原生生态中的微服务，为数字时代提供更多想象空间。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
