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