随着微服务架构在互联网企业的广泛实践，新一代微服务开发技术悄然兴起， Service Mesh 便是其中之一。根据 Linkerd CEO Willian Morgan 对 Service Mesh 的定义：Service Mesh 是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，Service Mesh 通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。
这个定义听起来有点绕，如何简单定义一下 Service Mesh 呢？ 美团点评基础架构团队技术专家郭继东认为 Service Mesh 属于受中心化管控的服务间通信基础设施层，将业务与基础设施进一步解耦的新一代云原生微服务架构模式，其最关键的部分是将非业务的功能下沉到通用的基础设施层，是推进云原生体系具备高度移植性、易用性及弹性能力建设的关键一环。
Service Mesh 的适用场景
针对 Service Mesh 的理念及产品有很多，不同产品解决的问题及建设目标也会有所差异，但总体而言，郭继东认为 Service Mesh 主要是用来解决以下问题的：
将基础设施与业务隔离开促进彼此迭代效率的提升；
Kubernetes 在应用生命周期管理方面很成熟，但尚不具备在服务流量粒度进行调度及管理的能力，Service Mesh 可以填补这个空白并协同组建云原生的微服务治理体系；
提升基础设施及应用的可靠性、易用性、可伸缩性。
如果企业开始实践 Service Mesh，那么会给企业各部门人员带来哪些变化呢？郭继东表示：“对业务开发人员而言，Service Mesh 会带来更全面、灵活的服务运营支撑能力，协助他们更好的应对服务化或微服务带来的复杂性；对架构师而言，Service Mesh 会为他们的技术决策提供更多的选择和更少的约束，这得益于 Service Mesh 促进基础设施的简化与全方位运营能力的提升；对运维人员而言，Service Mesh 解耦了研发与运维，运维人员可以更加专注底层设施能力的建设和运维效率的提升，如减少对 Nginx、LVS 等各类复杂配置的维护成本等。”
当然，在企业所有人员中，基础研发同学是最需要重点关注 Service Mesh 的，因为基础架构可以基于 Service Mesh 扩大微服务治理的功能及语言覆盖范围，这非常有益于技术标准化；Service Mesh 会为工程效率团队带来新的思路和方向，使得包含构建、测试、发布的流水线更高效和可靠；RPC 及 Http 外的基础设施如存储、MQ 团队也可以积极关注业界动态并积极探索，Service Mesh 是一种架构模式，未来应用场景很可能并不局限于服务间通信，而是覆盖更多类型的网络通信设施。
美团点评的 Service Mesh 实践
美团点评的 Service Mesh 建设开始于 2018 年底，在 2019 年 5 月底进行了线上少量业务的试点。据了解，美团点评内部的 Java 语言栈服务治理体系相对完善和统一，承载了上万应用日均万亿级的调用，覆盖了公司 90% 以上的服务，在治理能力方面，路由策略比 Istio 更为精细，也有完善的分布式链路追踪系统、立体化监控系统、全链路压测系统等设施。但美团点评的微服务治理也存在一些局限，那就是除了 Java，其它语言对应的治理体系相对薄弱。
基于这样的微服务治理现状，美团点评的 Service Mesh 实践主要是与 OCTO 系统进行深度打通，通过 Service Mesh 将现有的治理能力开放给基础设施薄弱的语言栈、通过解耦业务与基础设施进一步提升业务迭代效率、支持新合并的异构技术栈公司更便捷融入美团点评现有治理体系，同时也在尝试通过中心化能力实现全局最优治理。
在技术选型方面，美团点评在尽量保持现有体系的架构下，通过自研技术持续演进，数据层是基于 Envoy 进行了二次开发，而控制层则是进行了完全自研。为什么会是这样的技术选型呢？郭继东表示主要是出于三个方面的考虑：“一是因为 Envoy 已经几乎成为数据面的事实标准，其 xDS 模型和 IO 模型可以满足 sidecar 的需求；二是 Istio 的 API 尚不稳定，美团点评的初期目标是对齐现有全部的治理能力，Istio 现有能力及扩展性不能很好的支撑；三是美团点评现有的治理体系较为完善且各个系统都经历了真实业务场景的充分考验，Istio 深度依赖的 Kubernetes 及 Etcd 现支撑的集群规模并不能满足当前的需求。”
郭继东把美团点评的 OCTO-Mesh 建设分为了四个阶段：
第一阶段：实现了 OCTO-Mesh 的数据面与控制面的 MVP 版本，整体打通 Service Mesh 与 OCTO，进行小范围试点，验证可行性；
第二阶段：全面对齐 OCTO 现有的治理能力，并在多种语言业务应用试点，具备新融入公司快速切换技术栈能力；
第三阶段：实现 OCTO-Mesh 对业务接入透明，具备极高的稳定性支撑核心业务高效运营，实现全局中心化更灵活治理能力建设三个目标，在这个前提下核心业务广泛接入 OCTO-Mesh；
第四阶段：分布式应用完全不感知服务发现、路由、集群容错、安全等问题，但这需要 OCTO-Mesh 协同其他基础设施共同演进才有可能达到。
据郭继东介绍美团点评的 OCTO-Mesh 仍处于探索阶段，在整个建设过程中的难点集中在与现有体系的兼容性和稳定性这两个方面。
兼容性遇到的问题及解决方法
问题一：Envoy 的 xDS 并不能支撑 OCTO 精细复杂的路由策略，众多核心治理能力 Istio 也尚不具备，业务切换成本高。
解决方法：增强 xDS 语义并增加多项自定义 DS，提升灵活性的同时自研对齐现有功能，升级一次组件版本便做到无感知升级。
问题二：绝大部分治理子系统的存储及架构呈现异构特性且并不绑定 Kubernetes 与 Etcd。
解决方法：我们在控制层做了架构统一工作，通过统一接入中心使得各异构系统或平台可以快速接入并在数据面逐渐丰富能力，进而实现服务注册、服务发现、路由、负载均衡、安全控制、全链路压测、分布式链路追踪、限流、断路器、故障演练等能力打通和在 Mesh 体系的落地。
问题三：性能与协议兼容性。
解决方法：为了兼顾性能与协议兼容性，美团点评摒弃了 iptables 方案，而是将 SDK 与 Sidecar 间的通信统一改为 UNIX Domain Socket，并升级了公司通用的协议，提升性能的同时解决 Mesh 模式和非 Mesh 模式应用通信的兼容问题。
稳定性方面遇到的问题及解决方法
问题一：OCTO 承载着万级应用的日均超万亿调用量，这个量级下参考 Istio 模式会对控制面及后端协作的命名服务等系统造成巨大压力，同时较难水平扩展。
解决方法：我们设计了超大规模服务注册发现应对机制及多级缓存机制解决大规模集群场景下对协作系统的压力。
问题二：Istio、Kubernetes 在大规模集群的能力尚有所欠缺。
解决方法：基于独立的第三方服务用于管理控制面节点的服务注册与发现，通过数据面与控制面间连接的“会话粘滞”等手段来解决 Istio 在大规模集群能力上的乏力。
问题三：技术栈大范围升级的同时需要保证业务稳定性。
解决方法：建设了完善的实时 Mesh 与非 Mesh 模式切换能力，优先保证业务稳定性。
“通过 OCTO-Mesh 建设整体提升了美团点评的研发效率，并降低了企业成本，治理能力层面能够更好的支撑多元语言栈的技术选型，促进基础设施标准化。”郭继东表示：“对技术团队而言，OCTO-Mesh 可以带来更灵活运营能力及更高的研发效率，例如过去需要发布才能使用的特性，现在只需 OCTO-Mesh 升级即可使用，过去分散化架构无法实现的功能，现在可以在中心化架构体系实现。除此之外，服务治理的覆盖率也更广泛，异构技术栈、非 Java 应用都可以接入美团点评的技术体系。”
Service Mesh 的技术选型
Service Mesn 最早是由开发 Linkerd 的 Buoyant 公司提出，并在内部使用。2016 年 9 月 29 日，Service Mesh 第一次被公开使用。2017 年，随着 Linkerd 的传入，Service Mesh 才进入国内技术社区的视野… 可以说，Service Mesh 在整个技术领域还是一个“新兵”，企业实践也基本处于初级阶段。
什么样的企业应用场景适合使用 Service Mesh 呢？郭继东认为以下三种场景比较合适：
业务部署在主流公有云上的企业，可以大胆尝试 Service Mesh，依托于大厂的技术沉淀和稳定性保障能力，往往投入低的同时也能提升研发及运营效率。
私有云基础设施建设处于早期阶段，这类企业往往体量不大，建议立足于开源项目完善整个治理体系建设，注重社区亲和性。
私有云基础设施完备且有独立自研能力的企业，可以基于开源项目二次开发或自研为主，同时考虑和业界规范的兼容性，长久的收益是兼得 Service Mesh 和微服务治理体系的优势，但这个周期往往较长，对技术决策的把控要求也很高。
在技术选型方面，目前业界主流的 Service Mesh 框架主要有三个，分别是 Istio、Linkerd 和 Linkerd 2（原为 Conduit），这三种框架各有利弊，可根据具体情况来选择。
Istio 是由 Google、IBM 和 Lyft 发起的开源的服务网格项目，虽然尚未加入 CNCF，但在业界受众最多，也被认为最有前景的 Service Mesh 产品，大有成为事实标准的趋势。Istio 功能丰富强大，xDS 协议及 Mixer 设计优秀，但其仍处于早期版本，距离成熟还有很长的路要走，此外性能也是 Istio 被诟病的最主要问题。
Linkerd 是由 Buoyant 2016 年推出的，用 Scala 语言实现的开源项目。最大的优势是支持主机或虚拟机共享实例部署，不与 Kubernetes 绑定对使用环境约束较小，资源占用也会小些，同时较为成熟稳定。但共享实例异常时对所有服务都会造成影响，在微服务模式下影响更大，另外 Scala 并不适合做基础组件，吃内存严重和 GC 问题对吞吐量和性能都很不友好。
Linkerd 2，即原来的 Conduit，数据层面使用 Rust 语言实现，控制层面使用 Golang 实现。Linkerd 2 的配置较 Istio 更简单，整体性能及资源占用情况也都比 Istio 更好，但 Rust 语言生态很不完善受众也较小，国内基本呈现观望态度。
当然，Service Mesh 实践并非只有益处，肯定也存在风险。在郭继东看来，虽然不同企业容器化和 Service Mesh 技术选型会有一定的差异，但是这些风险都应该重视起来，并且在大规模落地前，一定要进行充分的容灾切换能力建设及实操演练：
技术栈大范围调整带来的稳定性风险都是最大的挑战，夸张点说，这就好比给行进中的高铁换轮子；
Service Mesh 体系所有的流量都穿过 Sidecar，在其余设施不变的情况下，性能损耗是不可避免的，如果是服务容量接近瓶颈的系统可能会造成雪崩。
Service Mesh 技术栈是非常复杂的，任何一个小功能（如路由、安全等）的异常都可能会造成严重的服务中断。
Service Mesh 的应用难点
目前国内企业较为完善的治理系统基本都是重度依托于微服务框架的。在这种情况下，应用 Service Mesh 势必需要做出较大改动，至少需要将服务发现、路由等功能迁移到 Sidecar 中。
如果是基础架构不完善的企业，尤其是服务化和容器化不完善，在实践过程中会有很大阻力。郭继东并不建议这类企业贸然应用 Service Mesh：“Istio 虽有成为事实标准的趋势，但国内以蚂蚁金服、华为、腾讯为代表的探索路径差异非常大，说明技术体系仍不成熟。企业想拥抱 Service Mesh，往往需要深度自研或二次改造，这就会带来不可预期的问题，风险把控往往比基础能力完善要难的多，而且切换 Service Mesh 技术栈的挑战不见得比从 0 到 1 引入 Service Mesh 的挑战小。另外，Istio 的 API 尚不算稳定，尤其是对第三方系统的适配能力并不强，并且 Service Mesh 竞品（Linkerd/Linkerd2、Envoy）同时进入 CNCF，这说明了新生事物的不确定性，标准化之路可能还很遥远，大量的投入可能会付诸东流。”
如果是基础架构较为完善的企业，凭借扎实的技术沉淀大可一试，但郭继东表示这类企业仍需把控好技术方向及技术决策，深度调研结合技术栈现状。
另外，如果企业是在原有技术栈的基础上引入 Service Mesh，从实际的应用实践情况来看，往往会存在以下 4 种问题：
标准的不确定性引发重复建设的风险；
Service Mesh 模式在业务每次远程调用增加 1 跳至 2 跳时，会带来性能损耗，一条实际的调用链路可能包含多次远程调用，性能损耗会被明显放大；
与基础技术体系融合的难度很大，国内众多企业的服务通信框架及治理系统技术栈往往不是云原生优先支持的 gRPC 和 HTTP，在 RPC 框架不兼容的背景下改造成本和挑战非常大；
基础设施与业务解耦带来的复杂性对运营系统的易用性和 Service Mesh 的稳定性要求极高，否则排查问题时很可能会面临根本无从下手的情况。
国内 Service Mesh 早期实践基本分为先建设数据层后建设控制层和同时建设两类，从后续发展看，随着对服务运营能力的要求的提高，控制层会越来越重要。在实际落地方面，众多企业都在积极探索私有云建设，也有很多通过 Service Mesh 提供治理能力的案例。在现有开源产品方面，郭继东认为未来发展趋势会逐渐平缓，但 Service Mesh 势必会和更多种类的云原生系统深度集成。
采访嘉宾
郭继东，美团点评基础架构团队技术专家，先后深度参与了美团点评服务治理系统 OCTO 的演进与 Service Mesh 的探索与落地。目前专注于服务架构、大规模分布式服务治理、Service Mesh、性能优化等方向。致力于为多元业务提供标准化、高可用、高可靠的服务治理解决方案。曾就职于百度凤巢商业平台部，拥有丰富的高可用架构设计经验。
今年 10 月，郭继东老师将在 QCon 上海 2019分享美团点评深度结合 OCTO 与 Service Mesh 打造下一代分布式服务治理系统 OCTO-Mesh 的探索之路，讲述 Service Mesh 在产品化过程可能面临的挑战及对应的架构演进及实践，敬请关注。
评论