Service Mesh 在超大规模场景下的落地挑战.docx

随着微服务软件架构在互联网企业的广泛实践，新一代微服务软件架构技术悄然兴起，ServiceMesh便是其中之一。根据1.inkerdCEOWillianMorgan对SerViCeMeSh的定义，SerViCeMeSh是一层处理服务间通信的基础设施。云原生应用有着复杂的服务拓扑，ServiceMesh保证请求可以在这些拓扑中安全且可靠地穿梭，对整个服务网络进行观测和高效查错，以及通过灵活的流量治理能力为新功能上线提供高效的验证手段。在实际应用当中，SerViCeMeSh通常是由一系列轻量级的网络代理（又被称为Sidecar）组成的，它们部署在应用进程的边上且对应用进程完全无感。国内ServiceMesh早期实践基本分为先建设数据层后建设控制层和同时建设两类，从后续发展看，随着对服务运营能力要求的提高，控制层会越来越重要。在实际落地方面，众多企业都在积极探索ServiceMesh在大规模场景下的应用。分布式应用架构在阿里巴巴的现状阿里巴巴围绕电商业务构建了庞大的微服务软件架构应用生态，包括了天猫、淘宝、菜鸟、高德等。其次，整个微服务体系是通过DubboRPC连接在一起，MetaQ用于服务之间的异步解耦。目前阿里巴巴主要的技术栈还是Java,围绕Java构建了相当健全的微服务治理能力，其他技术栈的微服务治理能力相对弱很多。在服务可见性这块，阿里巴巴是完全没有隔离的。DUbbORPC仍是接口级服务发现，1个应用如果提供10个接口，那么就会有10个服务是可以被发现的，如果这个应用有n台机器，那么10个服务就会产生10*n个服务端点元信息,这种重复数据导致规模问题被放大。另外一点值得跟大家分享的是，目前阿里巴巴也正经历着应用的SDK升级之痛,SDK中包含了中间件和应用层的一些公共模块，由中间件统一以PandOra包的形式交付给业务方使用。在应用数非常庞大的情形下，SDK升级是一份相当繁重的工作，甚至涉及到集团层面的大协同。为此，我们希望通过SerViCeMeSh先将中间件的那些能力下沉到SideCar,将这块升级工作从PandOra中剥离出来，借助ServiceMesh的流量无损热升级能力让业务对中间件升级完全无感。ServiceMesh面临的挑战ServiceMesh面临的第一个挑战就是新技术如何平滑演进。ServiceMesh在大规模场景下的落地在业界的案例还相当少，根源在于该技术本身还没有完全成熟。在技术走向成熟的持续迭代过程中，如何平滑演进是一个很有挑战的任务。挑战在于需要以终为始地规范技术架构的演进，一步一步地向终态架构演进。第二个挑战是发展的过程中如何协调好技术和业务的平衡。技术团队希望快速迭代向前发展兑现价值，而业务团队每年有自己的业务目标，如何协调好两者的发展关系是个不小的挑战。代表新技术的团队其发展思路通常会更激进，而业务团队会因为“稳定压倒一切”而偏保守，短期内调和好这一矛盾或许需要自顶向下的决策力量，否则业务挑战年年有而可能挤压技术的发展空间，导致技术发展缓慢而无法更好地服务于业务的发展。第三个挑战是技术向前演进时如何处置历史包袱。每一次技术的演进都意味着对原有技术体系的升级，这就不可避免地需要处置过往累积下来的技术债。新技术发展的难点往往不在于其“新”，而在于包袱太重而导致新技术演进困难，很可能因为演进太慢而严重影响了新技术的发展。第四个挑战就是克服超大规模所带来的问题。前面讲到的Dubbo因为是接口级服务发现，使得服务发现的数据规模非常大，给控制平面的端点数据推送能力带去了巨大挑战。最后一个挑战是SideCar的规模化运维。在超大规模场景下，大量的应用机器意味着有等量的SideCar需要运维，如何在部署、灰度、升级以及保障安全生产是一个很大的挑战。新技术在架构上平滑演进是关键起步三位一体规模化落地新技术的不成熟很可能在相当长的一段时间内是常态，演进的关键在于如何实现新技术架构的平滑演进，避免出现推倒重来这种劳命伤财之事。为此，基于这一考量，我们一共经历了“起步”、“三位一体”和“规模化落地”三大阶段，而每一个阶段采用了不同的软件架构或部署方案。在起步阶段，ISti。控制平面的PilOt组件放在一个单独的容器中，同时当作一个独立的进程和Sidecar部署在一个Pod里。采用这样的方式，使得对开源的Envoy和Pilot可以做最小的改动而加速落地，也方便我们基于开源的版本做能力增强和反哺。这一方案的缺点在于，每个Pod中都包含了一个PilOt进程，增大了应用所在机器上的资源消耗，因在服务规模并不大的情形下资源消耗相对小而可以忽视这一缺点。在三位一体阶段，Pilot进程从业务Pod中抽离了出来变成了一个独立的集群，在Sidecar和Pilot之间仍是xDS协议。这一架构虽节省了应用所在机器的资源消耗，但必须正视规模化落地的问题。xDS中有一个叫EDS(EndpointDiscoveryService)的协议，Pilot通过EDS向SideCar推送服务发现所需使用到的机器IP(又被称之为Endpoint)信息，在阿里的大规模场景下因为有大量的端点需要通过Pilot推送给Sidecar,导致Sidecar的CPU消耗相当大，让人担心业务进程因为SideCar对资源的争抢而受影响。这规模化问题并非在起步阶段的技术方案中不存在，只不过因为那时落地应用的服务规模小而没有成为瓶颈。为了解决规模化落地的问题，我们设计出了规模化落地的技术架构。在这一架构中，虽然还是Sidecar对接Pilot集群，但是Pilot集群只提供xDS中的1.DS/CDS/RDS这些标准的服务，而EDS采用Sidecar直接对接服务注册中心解决。值得强调，虽然SideCar直接对服务接注册中心，但是它仍然沿用了EnVoy里面对EDS所抽象的数据结构和服务模型，只是在数据的获取上对接注册中心来实现。之所以Sidecar直接对接服务注册中心能解决走EDS所存在的规模化问题，根源在于阿里巴巴的服务注册中心具备了增量推送的能力。在这三种架构中，未来的终态一定是采用三位一体的架构，且数据平面和控制平面也一定是并重发展。由于阿里巴巴今天的服务规模非常庞大而没办法一步到位做到三位一-体。通过规模化落地这一过渡方案，仍然有助于我们更好地反哺开源社区，通过尽早大规模落地会让我们清楚地知道开源方案仍存在的问题，从而让我们能为开源方案的完善做出更大的贡献。业务与技术协同发展飞行中更换引擎业务与技术的协同发展首先要回答好一个问题，即新技术带给业务的价值是什么。从业务的角度，采纳新技术最开始考虑的一定是短期价值，然后才是放眼看长远价值。ServiceMesh对于业务所带去的短期价值是：中间件能力下沉，下沉的过程中去除历史包袱轻装上阵。业务对中间件升级无感，中间件资源消耗可量化、优化可度量。从长远来看,完全解决阿里巴巴面临的Pandora/SDK升级之痛是需要相当长的一段时间，而ServiceMesh在流量治理这块的新价值也需要规模化落地达到一定水平后才能兑现，基础技术对业务的价值需要具备长远的眼光。ServiceMesh的长远价值有：业务与基础技术全面解耦，业务更聚集于自身而加速创新，基础技术独立演进而加速迭代。对微服务生态完成标准化、体系化的收口与治理，收敛故障和促进安全生产，加速应用功能正确性的验证效率。为多种编程语言的应用提供微服务治理能力，完善并丰富云原生多编程语言的应用生态。共建全球事实标准，通过阿里云的产品落实客户IT设施的多云和混合云战略，加速中国社会乃至全球的数字化转型。明确了技术的价值之后，业务与技术协同发展接下来的挑战在于，需要技术演进的过程中完全不影响业务，这好比给一架高速运行的飞机换引擎。为此，新技术的落地方案需要考虑对业务无侵入，换句话说规避业务应用新技术的改造成本。为了应用Mesh化时对业务无感，在以RPC流量做Mesh化为切入点的背景下，我们设计了动态流量无损透明拦截的技术方案。上图示例说明了应用mesh化前后的三种状态。在“过去”，流量是直接通过RPCSDK在ProVider和ConSUmer之间互通的，SDK直接跟中间件的服务注册中心、配置中心对接。到了“现在“，SerViCeMeSh直接被插入到了应用和中间件之间，SDK不做任何的变化，但通过iptables将SDK的流量拦截到Sidecar中。由于iptables是否开启和关闭流量拦截是可以通过运维控制台从应用或机器维度进行控制的，这就使得在mesh技术自身出现问题的情形下可以方便禁用，让应用回退到通过SDK直连的方式互通。面向“未来”，当SerViCeMeSh技术完全成熟时，SDK需要从“胖”变“瘦”，那时并不需要SDK中存在下沉到Sidecar的那些能力，从而节约重复功能所导致的资源开销。下图示例说明了打开和关闭流量透明拦截功能的关键流程。其中应用进程中包含了RPCSDK而没有区分表达，TrafficInterceptorPilotAgent和Envoy三个组件在同一个容器中，所有组件共享同一个POd。OneOPSCOre是基于K8s所构建的中心化mesh运维Operator,收到控制台（图中标识为小人的Operator指代）调用开启或关闭流量透明拦截的接口后，通过调用PilOtAgent所提供的接口完成对Pod中应用流量的操作。为了保证打开和关闭透明拦截功能时无业务流量的调用损失，请注意图中红色标识出的二大块流程。开启流量拦截时：PilotAgent将调用RPCSDK的Offline接口（消息2.1.1）,间接完成从服务注册中心对本机做去注册摘除流量；然后调用TraffiCInterCePtOr组件所提供的接口开启流量拦截功能（消息2.1.2）；最后再调用RPCSDK的online接口将本机注册到服务注册中心（消息2.1.3）关闭流量拦截时：PiIotAgent将调用EnVOy的优雅关闭接口（消息4.1.1）,Envoy会在RPCSDK与Envoy建立的连接上透传这一消息（即Envoy会调用RPCSDK的优雅关闭接口，上图并没有表达出），告诉RPCSDK不要再向已建立的这一长连接上发送任何RPC请求；随后PilOtAgent调用TraffiClnterCePtOr接口关闭流量拦截功能（消息4.1.2）；最后，EnVoy的优雅关闭接口被调用时会启动一个延时15秒的定时器，确保RPCSDK与EnVoy间已建立的长连接上还没有完成处理的请求有足够的时间处理完以免出现流量有损，当定时器到期后Envoy会主动关闭与RPCSDK所建立的连接（消息6）。为了让MeSh技术自身的迭代对业务无感，我们设计了流量无损热升级方案，确保Sidecar可以随时对业务无感升级。设计流量无损热升级方案的核心考量是投入产出比，以最小的工程成本构建一个容易做到稳定的技术方案，下图示例了站在Consumer视角（既Consumer侧的Envoy进行升级，Consumer代表流量调用的发起方）所观测到的热升级流程。当EnVOy有一个新版本需要升级时（图中标识为v2）,通过运维控制台可以设置这个新血本的镜像信息，通过C）PenKrUiSe的SidecarSet可以拉到这一镜像并将镜像中的新版本Envoy二进制程序拉起。随后，新版本Envoy会向老版本Envoy（路中标识为Vl）发起热升级流程。热升级大致包含如下几个流程：老版本进程中所有的侦听fd通过进程间通讯的方式交给新版本进程（消息、5.1）,由新版本进程继续在之上进行侦听（消息5.1.1）,换句话说，之后所有在这些被侦听端口上新建的连接都会发生在新版本进程中；老版本进程调用RPCSDK的优雅关闭接口（消息5.3）,告诉RPCSDK不要再已建立的连接上发起新的调用，如果要发起新调用则必须重新建立连接，显然新连接将与新版本进程建立，随后的调用流量将全部进到新版本进程；老版本进程向RPCSDK发起优雅关闭接口调用的同时会建立一个时延15秒的定时器，确保与RPCSDK所建立的连接在这15秒中都处理完，定时器到期后关闭这一连接并退出老版本进程（消息5.4）,从而结束整个热升级流程。下图是从Provider视角（既Provider侧的Envoy进行升级，Provider代表提供相应服务能力的被调用方）所观察到的升级流程。不难看出，红色标识出的部分与前一张图是完全一样的,热升级流程完全无需基于Envoy的ConsumercProvider身份做特殊的处理。毕竟，现实中每个应用大多会同时承担Consumer和Provider两种角色。上图有一个点值得特别指出，Envoy需要实现序号为5.3的优雅关闭消息，并将这一消息透传给RPCSDK（图中并没有表达）。发展新技术是偿还技术债的重要契机不少新技术的出现多少会引发我们的纠结，在新技术所创造的短期价值不那么有吸引力的情形下，似乎旧技术不改变就不会带来风险。但经验表明，不改变的后果是包袱会越积越重，由此所带来的技术债的潜在风险最终都不可忽视。技术债是软件的本质属性，因为无法做到已有架构能一直百分百优雅实现新需求。换句话说，技术债对于一个长期提供服务的软件来说是一直存在的，只不过存在大小之别和何时偿还的问题。阿里巴巴对分布式系统的探索有超过十年的积累，为了做应用的服务化改造提出了HSFRPC开发框架并将之开源为Dubboo基于框架思维所构建的RPC协议为了更好地满足不同业务对服务路由的定制化诉求，提供了通过Groovy脚本进行定制的能力。然而，这种灵活的手段在向SerViCeMeSh这一平台技术演进时将带来流量治理隐患。我们认为，平台思维下构建的SerViCeMeSh得限制过于灵活的定制能力，避免平台出现“窟窿”而无法有效、有力地完成全局最优的治理。为此,我们将去除GroOVy脚本当作是一项技术债加以偿还。Groovy脚本带来的问题主要有两个：过于灵活且导致了开发框架与应用代码的耦合。给流量治理能力下沉留下了潜在隐患。为去除Groovy脚本，我们扩展IStiO的VirtUaISerViCe和DestinationRule,抽象出按应用名、方法和参数路由的能力。下图示例说明了某应用基于应用名做路由在Groovy脚本和ServiceMesh下的具体实现。A>Me配置方案由于单个应用的ServiceMesh化并非一刀切的一次性完成，存在一个应用的部分机器先mesh化做灰度的场景。为此，需要在去Groovy脚本这件事上，让新旧技术方案能同时无缝工作，背后是两种形式的路由表达如何做好同步，背后就涉及控制台收口和格式转化等问题需要妥善解决。系统性解决超大规模问题为了最终解决阿里巴巴在ServiceMesh落地过程中所面临的大规模问题，我们从三个方面着手：SerViCeMeSh技术自身的持续优化。需要从CPU开销、内存占用和时延三大维度进行持续优化，通过软硬件结合等技术手段做到应用SerViCeMeSh化前后零新增成本甚至下降。Dubbo实现应用级服务发现而非接口级。通过应用级服务发现将使得控制平面向数据平面推送的服务元数据有数量级下降，让SerViCeMeSh的控制平面向数据平面推送的数据急剧下降。服务注册数据进行单元封闭并分级治理。动机依然是降低ServiceMesh控制平面向数据平面推送的数据量，通过单元封闭让全局服务元数据通过局部化而减少。这三方面在阿里巴巴分别有相应的团队在探索解决，这里主要分享ServiceMesh技术本身。阿里巴巴对ServiceMesh技术的探索策略是“借力开源，反哺开源"借力''体现于整体技术方案采纳的是开源的IStio（控制平面）+Envoy（数据平面），在工程实践中特别注意自有代码与开源代码做充分的解耦，以及频繁跟进开源社区发布的新版本；“反哺”表在我们积极将性能优化、bugfix等代码提交给开源社区。至今，在IStiO开源社区我们提交了9个PR,解决性能问题和bugfix；在EnVOy开源社区我们提交了14个PR,包含内存开销下降50%的优化、新增对Dubbo和RocketMQ协议的支持等内容。此外,我们曾与Istio社区共同探索实现了EGDS（EndpointGroupDiscoveryService）,作为EDS的增强，但由于Envoy社区担心该feature通用性不足而最终没能接受而完成这次反哺。这一"失败不只体现了我们反哺社区的意愿和热情，也是更好融入开源社区的一次很好的学习机会。在EGDS并不能很好解决在“三位一体”方案下的大规模落地问题的情形下，我们重新调整了落地方案，形成了本文前面所讲到的让Envoy直接对接服务注册中心的“规模化落地”方案。下图展示了两个方案的CPU开销数据比较。图中深蓝色代表的是规模化落地方案，橙色代表的是三位一体的方案，测试数据表明三位一体方案在设定的越大规模压测场景下因服务元数据推送给Envoy所带去的CPU开销是规模化落地方案的三倍。进一步地，我们比对了非Mesh方案和规模化落地mesh方案因服务元数据推送所导致的CPU开销（如下图所示）。数据表明，非MeSh方案（图中橙色表示）因Java进程在数据推送场景下存在GC而使得CPU开销要显著地高于规模化落地Mesh方案（图中深蓝色表示），这是因Envoy采用C+编程语言而获得的优势。后续我们会考虑参与共建Envoy社区所提出的1.EDS协议，让IStio+Envoy的三位一体方案天然地能运用于阿里巴巴的大规模场景。除了CPU开销的优化，我们在内存优化方面也取得了巨大的进展。同样服务规模的情形下，EnVOy的内存开销从之前超过3G优化至500M左右。此外，压测数据表明应用mesh化完成后整体内存开销比mesh化前更低。Sidecar的规模化运维SideCar的规模化运维也是很具挑战的一件事，内容包含SideCar的部署、灰度、升级，以及需要构建相应的监控和报警设施。SideCar的部署、灰度、升级我们全面基于由阿里巴巴开源的OPenKrUiSe中的SidecarSet实现。SideccirSet提供了对Sidecar进行部署、灰度和升级的通用能力，能很好地运用于SerViCeMeSh而省去了重复建设。当然，流量无损热升级这样的能力并非SidecarSet原生提供的，需要从ServiceMesh层面去增强。在Sidecar的运维和流量治理这块,监控和报警全面采用了阿里云上的Prometheus和ARMS两大云产品，一旦当下服务于阿里巴巴内部的ServiceMesh技术将来要通过产品化输送给阿里云上的客户时会更加方便。在运维管控上，我们全新构建了云原生OneoPS运维系统。OneOPS包含控制台和OneOpsCore两大子系统。后者是基于K8s构建的运维Operator,通过CRD的形式暴露给控制台调用接口。OneOPSeOre可以多区域部署，而控制台是全局集中部署的，这样方便运维人员在同一个控制台上能无缝地管理多个区域的ServiceMesho目前OneOps已具备管理包含了SidecarIngreSSGateWay在内的东西南北向流量的能力。总结本文总结了阿里巴巴大规模落地ServiceMesh所面临并克服的技术挑战，希望这些内容对行业同仁在这一技术的探索和学习有所帮助。现阶段，阿里巴巴对于ServiceMesh的探索更多停留于解决历史包袱和完成应用与中间件的解耦，仍没有在服务流量治理方面做出新价值和新体验，期待未来能尽早给大家分享这方面的内容。ServiceMesh是云原生的关键技术，对于阿里巴巴来说，我们笃定这是分布式应用微服务软件架构的未来。正因如此，CTO鲁肃也站台SerViCeMeSh技术，并做出了未来整个经济体全面走Istio+Envoy方案的技术决策。在构建阿里巴巴全球商业操作系统的道路上，SerViCeMeSh是面向未来五年、甚至十年的技术。复杂环境下落地ServiceMesh的挑战与实践在私有云集群环境下建设ServiceMesh,往往需要对现有技术架构做较大范围的改造，同时会面临诸如兼容困难、规模化支撑技术挑战大、推广困境多等一系列复杂性问题。本文会系统性地讲解在在落地SerViCeMeSh过程中，我们面临的一些挑战及实践经验，希望能对大家有所启发或者帮助。一、服务治理建设进展1.1 服务治理发展史首先讲一下OCT0,此前技术团队博客也分享过很多相关的文章，它是标准化的服务治理基础设施，现应用于所有事业线。OCTO的治理生态非常丰富，性能及易用性表现也很优异，可整体概括为3个特征：属于公司级的标准化基础设施。技术栈高度统一，覆盖了公司90%以上的应用，日均调用量达数万亿次。经历过较大规模的技术考验。覆盖数万个服务、数十万个节点。治理能力丰富。协同周边治理生态，实现了SET化、链路级复杂路由、全链路压测、鉴权加密、限流熔断等治理能力。回顾服务治理体系的发展史，历程整体上划分为四个阶段：第一阶段是基础治理能力统一。实现通信框架及注册中心的统一，由统一的治理平台支撑节点管理、流量管理、监控预警等运营能力。第二阶段重点提升性能及易用性。4核4GB环境下使用IKB数据进行echo测试，QPS从2万提升至接近10万，99分位线1ms；也建设了分布式链路追踪、分阶段耗时精细埋点等功能。第三阶段是全方位丰富治理能力。落地了全链路压测平台、性能诊断优化平台、稳定性保障平台、鉴权加密等一系列平台，也实现了链路级别的流量治理，如全链路灰度发布等。第四阶段是建设了跨地域的容灾及扩展能力。在每天数千万订单量级下实现了单元化，也实现了所有PaaS层组件及核心存储系统的打通。WR-泊理能力统一»»-防三金方位的总建健力三fll*tt-命名量务发一It招治戏lfiflv运营平台通信框襄高性能通信低柒转It化分布式!118源踪&路机盗Nia化Uit工具可祝化全集ISASI平台性能优化诊断平台Q定性保平台IK务襄权、me每路皴流量治理SET化架构支撑所育PgSie件打通朗用使平台建设1.2 服务治理体系的困境目前，已具备了较完善的治理体系，但仍有较多的痛点及挑战。大的背景是公司业务蓬勃发展，业务愈发多元化，治理也愈发精细化，这带来了较多新的问题：业务与中间件强耦合，制约彼此迭代。当中间件引入Bug,可能成百上千、甚至数千个业务需要做配合升级，中间件的新特性也依赖业务升级后才能使用，成本很高。中间件版本碎片化严重。发布出去的组件基本托管在业务侧，很难统一进行管控，这也频繁造成业务多类的问题。异构体系融合难。新融入公司的技术体系往往与不兼容，治理体系打通的成本很高，难度也很大。此前，与大众点评打通治理，不包含业务迁移，就历时1年半的时间；近期，摩拜使用的gRPC框架也无法与系统进行通信，但打通迫在眉睫。非JaVa语言治理体系能力弱，多个主流语言无官方SDK。多元业务场景下,未来多语言也是个趋势，比如在机器学习领域，PythOn语言不太可能被其他语言完全代替。二、服务治理体系优化的思路与挑战2.1优化思路总结来看，OCTo在服务层实现了统一抽象来支撑业务发展，但它并未解决这层架构可以独立演进的问题。1.2节中问题1与问题2的本质是“耦合”，问题3与问题4的本质是“缺乏标准服务治理运行时在理想的架构中，异构语言、异构治理体系可以共用统一的标准治理运行时，仅在业务使用的SDK部分有轻微差异。所以，我们整体的优化思路分为三步：隔离解耦，在隔离出的基础设施层建设标准化治理运行时，标准之上建体系。理想架构整体优化思路上述解决方案所对应的新架构模式下，各业务进程会附属一个Proxy进程，SDK发出以及接收的流量均会被附属的Proxy拦截。像限流、路由等治理功能均由ProXy和中心化的控制大脑完成，并由控制面对接所有治理子系统集成。这种模式下SDK很轻薄，异构的语言、异构的治理体系就很容易互通，从而实现了物理解耦，业界将这种模式称为SerViCeMeSh（其中PrOXy被称为数据面、中心化控制大脑被称为控制面）。l皿.1I骄器含翳2.2复杂性挑战在实践中所面临的复杂性划主要包括以下4类：兼容性：技术改造涉及范围较大，一方面需要通过保证现有通信方式及平台使用方式不变，从而来保障业务研发效率，另一方面也要解决运行载体多样性、运维体系兼容等问题。异构性:第一是多语言互通问题；第二是打通治理体系内的众多治理子系统,像服务鉴权、注册中心等系统的存储及发布订阅机制都是不同的；第三是快速打通新融入公司的异构治理体系。大规模支撑：出于性能方面考虑，开源Istio等产品不宜直接应用于大规模的生产环境，控制面需具备百万级链接下高吞吐、低延迟、高精确的系统能力。重交易型业务容错性低：交易型业务场景下，业务对SerViCeMeSh的性能、稳定性往往持怀疑态度；基础架构团队也强调在业务价值导向下，基于实际业务价值进行运营推广，而不是采用从上至下的偏政策性推广方式。三、落地ServiceMesh的解决方案3.1 整体架构采用数据面基于EnVOy二次开发、控制面自研为主、SDK协同升级的方案(内部项目名是OCTOMeSh)。架构简介如下：各语言轻薄的SDK与Proxy通过UDS(1.InixDomainSocket)交互，主要出发点是考虑到相比透明流量劫持，UDS性能与可运维性更好。控制面与ProXy通过双向流通信，控制面与治理生态的多个子系统交互，并将计算处理过的治理数据及策略数据下发给ProXy执行，协同配合完成路由、限流等所有核心治理功能。控制面内部的5个模块都是自研的独立服务。Pilot承载核心治理能力，与PrOXy直接交互。Dispatcher负责屏蔽异构子系统差异。集中式健康检查管理节点状态。ConfigServer管理Mesh体系内相关的策略，并将Pilot有状态的部分尽量迁移出来。监控及巡检系统负责提升稳定性。自研了的MetaServer系统实现Mesh体系内部的节点注册和寻址，通过管理控制面与数据面的链接关系，也实现了按事业群隔离、水平扩展等能力。治建生本作KUISM1FB元敷掘收掘平36务造程阑JVRk（W户MUSrvrMttMetaSfver*tt（自研）«a«RPc««(自研为主)3.2 兼容性解决方案兼容性的目标及特征用一句话来总结就是：业务接入无感知。为此，我们做了以下三件事情：(1)与现有基础设施及治理体系兼容将ServiceMesh与OCTO深度打通，确保各治理子系统的使用方式都不变。运行载体方面，同时支持容器、虚拟机、物理机。打通运维体系，保证服务治理基础设施处于可管理、可监测的状态。(2)协议兼容服务间调用往往是多对多的关系，一般调用端与服务端无法同时升级，为支持MeSh与非MeSh的互通，增强后的协议对业务完全透明。与语义相关的所有内容(比如异常等)，均在SDK与ProXy之间达成共识，保证兼容。无法在控制面及数据面中实现的能力，在SDK中执行并通过上下文传递给ProXy,保障功能完全对齐，当然这种情况应该尽量避免的。(3)Mesh与非Mesh模式的无缝切换基于UDS通信必然需要业务升级一次SDK版本，我们在2020年初时预先发布早做部署，确保当前大部分业务已经升级到新版本,但默认仍是不开启Mesh的状态。在可视化平台上面通过开关操作，几乎无成本实现从Mesh模式与非Mesh模式的切换，并具备实时生效的能力。3.3 异构性解决方案异构性的目标及特征用一句话总结就是：标准化服务治理运行时。具体可拆分为3个子目标：标准化内部6种语言的治理体系。架构层面由控制面统一对接各个治理子系统，屏蔽注册中心、鉴权、限流等系统具体实现机制的异构性。支持摩拜及未来新融入公司的异构治理体系与公司整体的快速融合。针对上述3个子目标，我们所采取的方案如下：将数据面+控制面定义为标准化的服务治理运行时，在标准运行时内打通所有治理能力。建设统一接入中心系统Dispatcher,并由其对接并屏蔽治理子系统的异构性,从而实现外部系统的差异对Pilot透明；下图中Dispatcher与Pilot直接交互，MetaServer的作用是避免广播降低冗余。重构或从零建设SDK,目前使用的6种语言SDK均己落地并使用。异构语言、异构体系均使用增强的统一协议交互，实现互通。通过ServiceMesh实现体系融合的前后对比如下：引入SerViCeMeSh前，单车向公司的流量以及公司向单车的流量，均是由中间的adaptor单点服务承接。除稳定性有较大隐患外，所有交互逻辑均需要开发两份代码，效率较差。引入SerViCeMeSh后，在一套服务治理设施内打通并直接交互，消除了中心adaptor带来的稳定性及研发效率方面的缺陷；此外整个打通在1个月内完成，异构体系融合效率很高。:心所有文互中在一个最基所需交互开发鼻饰凌口代B通过上述方案，针对异构性方面取得了较好的效果：标准化6种语言治理体系，非JaVa语言的核心治理能力基本对齐Java；新语言也很容易融入，提供的官方Python语言、Golang语言的通信框架新版本（依托于OCToMeSh）,开发成本均控制在1个月左右。支持异构治理子系统通过统一接入中心快速融入，架构简洁、扩展性强。支持异构治理体系快速融合并在单车侧落地，异构治理体系打通成本也从1.5年降低到1个月。3.4 规模化解决方案3.4.1 开源Istio问题分析规模化的目标及特征用一句话总结是：具备支撑数万服务、百万节点体量的系统能力，并支持水平扩展。挑战主要有3个：体量是最流行开源产品Istio上限的上千倍。极高的实时性、准确性要求；配置下发错误或丢失会直接引发流量异常。起步较早，业界参考信息很少。经过对IStiO架构进行深入分析，我们发现核心问题聚焦在以下3个瓶颈点:每个控制面实例有ETCD存储系统的全部数据，无法水平扩展。每个Proxy链接相当于独立与ETCD交互,而同一个服务的Proxy请求内容都相同，独立交互有大量的I/O冗余。当ProXy批量发版或网络抖动时，瞬时风暴很容易压垮控制面及ETCDo每个节点都会探活所有其他节点。10万节点规模的集群，1个检测周期有100亿次探活，会引发网络风暴。HCDOIiBirittfffittfllft«9««10w网一：各实例承HCD全徵:无法京早IrjK内二元余祖接依立访网ETCDWT"店.KKKXJK9t.尸U时反）.金-4xk,*b.,擂二、分JI订同、降冗余IOHIM=.中心化健康检查,Proxy万-科三:舞活引夏网传风,P2P*活.个节点赛活所If节直10w9Ttt满育IMig:100亿次集活3.4.2 措施一：横向数据分片针对Istio控制面各实例承载全集群数据的问题，对应的措施是通过横向逻辑数据分片支持扩展性，具体方案设计如下：Proxy启动时会去向MetaServer系统请求需要连接的PilotIP,MetaSerVer将相同服务的ProXy尽量落到同一个控制面节点（内部策略更为复杂，还要考虑地域、负载等情况），这样每个Pilot实例按需加载而不必承载所有数据。控制面节点异常或发布更新时，其所管理的ProXy也会有规律的迁移，恢复后在一定时间后还会接管其负责的ProXy,从而实现了会话粘滞，也就实现逻辑上面的数据分片。通过管理链接关系实现了按事业群隔离、按服务灰度等平台能力，最关键的还是解决了Mesh体系水平扩展的问题。3.4.3 措施二：纵向分层订阅针对IStiO独立管理各Proxy链接的I/O冗余问题，对应的措施是通过分层订阅减少冗余I/O。Proxy不直接与存储等系统对接，而是在中间经过一系列的处理，关键点有两个：关键点1：基于快照缓存+索引的机制来减少ZKWatCher同步。以注册中心为例，常规实现方式下，如果每个ProXy关注100个节点，1万个节点就会注册100万个Wateher,相同服务的PrOXy所关注内容是相同的，另外不同服务PrOXy所关注的也有很多交集，其中包含大量的冗余。分层订阅模式下，ProXy不与注册中心直接交互，通过中间的快照缓存与分层，确保每个PilOt实例中ZK相同路径的监听最多只用Ijwatcher,获取到WatCher通知后，PilOt根据内部的快照缓存+索引向所有关注者分发，大大降低了冗余。关键点2：治理能力层及会话管理层实现了类似于I/O多路复用能力，通过并发提升吞吐。结果方面有效应对了网络抖动或批量发版的瞬间风暴压力，压测单Pilot实例可以承载6万以上的链接，时延TP99线2.3ms、数据零丢失。3.4.4 措施三：集中式健康检测针对大规模集群内指数级膨胀的节点间健康监测次数，对应的措施是摒弃了P2P检测模式，我们参考并优化了Google的TraffiCDreCtOr中心化管理的健康检测模式。这种模式下检测次数大大减少，一个周期内10万节点集群的检测次数,从100亿次下降到10万次。此外，当Pilot感知至IProxy异常时，会立即通知中心化健康检测系统启动检测，而不是等待检测周期窗口的到来，这可以有效提升业务调用的成功率。e9vo3as3.5 交易型场景困境下的解决方案3.5.1 业务属性分析内部业务线较多，包括外卖、配送、酒店、旅游、单车、团购等，其中绝大多数业务都带有交易属性，交易链路上一个流量异常就可能影响到订单。业务系统对新技术领域的探索往往比较慎重，期望在新技术充分验证后再启动试点，所以除小语种及亟待与公司打通的单车业务外，推广的难度是非常大的。此外，基础架构部秉承“以客户为中心”的原则，研发、运维、测试人员均是我们的“客户”,所以技术升级会重点从业务价值入手，并非简单依靠从上至下的政策推动力。所以，我们对外的承诺是：通信足够快、系统足够稳定、接入足够平滑高效。推广困境较大性能损瓢量低性育于一切通信足务快、系统足0、接入足平清育效I3.5.2 精细化运营体系建设针对推广的困境，我们首先做了两件事情：寻找具备强诉求的业务试点，客观来说，技术栈内这类业务数量非常有限。寻求标杆核心业务试点，充分验证后推广给其他业务，但效果并不理想，与业务稳定性的诉求并不匹配。针对上述困境，我们进行深度思考后建立了一个精细化的运营体系：服务接入Mesh前。基于SOA分级将服务划分为非核心与核心两类，先针对非核心服务以及所有服务的线下环境进行重点突破，实现了在广泛的业务场景下，全面且充分的验证系统能力。服务接入Mesh中。运营系统通过校验SDK版本、运行时环境等信息，自动筛选出满足条件的服务，业务同学只需要在平台上做（1）开启开关、（2）选择节点（3）指定MeSh流量比例三个步骤，就完成了到MeSh模式的切换，不需代码改造也不需发布服务，整个过程基本在1分钟左右完成；此外，通过与IM工具深度联动，提升了推广与数据运营的效率。服务接入MeSh后。一方面，业务侧包括架构侧的运营有详细的数据指标做对比参考；另一方面，运营系统支持预先设置稳定性策略并做准实时的检测，当某个接入服务Mesh模式异常时，即时自动切换回非Mesh模式。运营体系具备“接入过程无感”、“精细化流量粒度灰度”、“