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

《Service Mesh 在超大规模场景下的落地挑战.docx》由会员分享，可在线阅读，更多相关《Service Mesh 在超大规模场景下的落地挑战.docx（16页珍藏版）》请在优知文库上搜索。

1、随着微服务软件架构在互联网企业的广泛实践，新一代微服务软件架构技术悄然兴起，ServiceMesh便是其中之一。根据1.inkerdCEOWillianMorgan对SerViCeMeSh的定义，SerViCeMeSh是一层处理服务间通信的基础设施。云原生应用有着复杂的服务拓扑，ServiceMesh保证请求可以在这些拓扑中安全且可靠地穿梭，对整个服务网络进行观测和高效查错，以及通过灵活的流量治理能力为新功能上线提供高效的验证手段。在实际应用当中，SerViCeMeSh通常是由一系列轻量级的网络代理（又被称为Sidecar）组成的，它们部署在应用进程的边上且对应用进程完全无感。国内Servic

2、eMesh早期实践基本分为先建设数据层后建设控制层和同时建设两类，从后续发展看，随着对服务运营能力要求的提高，控制层会越来越重要。在实际落地方面，众多企业都在积极探索ServiceMesh在大规模场景下的应用。分布式应用架构在阿里巴巴的现状阿里巴巴围绕电商业务构建了庞大的微服务软件架构应用生态，包括了天猫、淘宝、菜鸟、高德等。其次，整个微服务体系是通过DubboRPC连接在一起，MetaQ用于服务之间的异步解耦。目前阿里巴巴主要的技术栈还是Java,围绕Java构建了相当健全的微服务治理能力，其他技术栈的微服务治理能力相对弱很多。在服务可见性这块，阿里巴巴是完全没有隔离的。DUbbORPC仍是

3、接口级服务发现，1个应用如果提供10个接口，那么就会有10个服务是可以被发现的，如果这个应用有n台机器，那么10个服务就会产生10*n个服务端点元信息,这种重复数据导致规模问题被放大。另外一点值得跟大家分享的是，目前阿里巴巴也正经历着应用的SDK升级之痛,SDK中包含了中间件和应用层的一些公共模块，由中间件统一以PandOra包的形式交付给业务方使用。在应用数非常庞大的情形下，SDK升级是一份相当繁重的工作，甚至涉及到集团层面的大协同。为此，我们希望通过SerViCeMeSh先将中间件的那些能力下沉到SideCar,将这块升级工作从PandOra中剥离出来，借助ServiceMesh的流量无损

4、热升级能力让业务对中间件升级完全无感。ServiceMesh面临的挑战ServiceMesh面临的第一个挑战就是新技术如何平滑演进。ServiceMesh在大规模场景下的落地在业界的案例还相当少，根源在于该技术本身还没有完全成熟。在技术走向成熟的持续迭代过程中，如何平滑演进是一个很有挑战的任务。挑战在于需要以终为始地规范技术架构的演进，一步一步地向终态架构演进。第二个挑战是发展的过程中如何协调好技术和业务的平衡。技术团队希望快速迭代向前发展兑现价值，而业务团队每年有自己的业务目标，如何协调好两者的发展关系是个不小的挑战。代表新技术的团队其发展思路通常会更激进，而业务团队会因为“稳定压倒一切”而

5、偏保守，短期内调和好这一矛盾或许需要自顶向下的决策力量，否则业务挑战年年有而可能挤压技术的发展空间，导致技术发展缓慢而无法更好地服务于业务的发展。第三个挑战是技术向前演进时如何处置历史包袱。每一次技术的演进都意味着对原有技术体系的升级，这就不可避免地需要处置过往累积下来的技术债。新技术发展的难点往往不在于其“新”，而在于包袱太重而导致新技术演进困难，很可能因为演进太慢而严重影响了新技术的发展。第四个挑战就是克服超大规模所带来的问题。前面讲到的Dubbo因为是接口级服务发现，使得服务发现的数据规模非常大，给控制平面的端点数据推送能力带去了巨大挑战。最后一个挑战是SideCar的规模化运维。在超大

6、规模场景下，大量的应用机器意味着有等量的SideCar需要运维，如何在部署、灰度、升级以及保障安全生产是一个很大的挑战。新技术在架构上平滑演进是关键起步三位一体规模化落地新技术的不成熟很可能在相当长的一段时间内是常态，演进的关键在于如何实现新技术架构的平滑演进，避免出现推倒重来这种劳命伤财之事。为此，基于这一考量，我们一共经历了“起步”、“三位一体”和“规模化落地”三大阶段，而每一个阶段采用了不同的软件架构或部署方案。在起步阶段，ISti。控制平面的PilOt组件放在一个单独的容器中，同时当作一个独立的进程和Sidecar部署在一个Pod里。采用这样的方式，使得对开源的Envoy和Pilot可

7、以做最小的改动而加速落地，也方便我们基于开源的版本做能力增强和反哺。这一方案的缺点在于，每个Pod中都包含了一个PilOt进程，增大了应用所在机器上的资源消耗，因在服务规模并不大的情形下资源消耗相对小而可以忽视这一缺点。在三位一体阶段，Pilot进程从业务Pod中抽离了出来变成了一个独立的集群，在Sidecar和Pilot之间仍是xDS协议。这一架构虽节省了应用所在机器的资源消耗，但必须正视规模化落地的问题。xDS中有一个叫EDS(EndpointDiscoveryService)的协议，Pilot通过EDS向SideCar推送服务发现所需使用到的机器IP(又被称之为Endpoint)信息，在

8、阿里的大规模场景下因为有大量的端点需要通过Pilot推送给Sidecar,导致Sidecar的CPU消耗相当大，让人担心业务进程因为SideCar对资源的争抢而受影响。这规模化问题并非在起步阶段的技术方案中不存在，只不过因为那时落地应用的服务规模小而没有成为瓶颈。为了解决规模化落地的问题，我们设计出了规模化落地的技术架构。在这一架构中，虽然还是Sidecar对接Pilot集群，但是Pilot集群只提供xDS中的1.DS/CDS/RDS这些标准的服务，而EDS采用Sidecar直接对接服务注册中心解决。值得强调，虽然SideCar直接对服务接注册中心，但是它仍然沿用了EnVoy里面对EDS所抽象

9、的数据结构和服务模型，只是在数据的获取上对接注册中心来实现。之所以Sidecar直接对接服务注册中心能解决走EDS所存在的规模化问题，根源在于阿里巴巴的服务注册中心具备了增量推送的能力。在这三种架构中，未来的终态一定是采用三位一体的架构，且数据平面和控制平面也一定是并重发展。由于阿里巴巴今天的服务规模非常庞大而没办法一步到位做到三位一-体。通过规模化落地这一过渡方案，仍然有助于我们更好地反哺开源社区，通过尽早大规模落地会让我们清楚地知道开源方案仍存在的问题，从而让我们能为开源方案的完善做出更大的贡献。业务与技术协同发展飞行中更换引擎业务与技术的协同发展首先要回答好一个问题，即新技术带给业务的价

10、值是什么。从业务的角度，采纳新技术最开始考虑的一定是短期价值，然后才是放眼看长远价值。ServiceMesh对于业务所带去的短期价值是：中间件能力下沉，下沉的过程中去除历史包袱轻装上阵。业务对中间件升级无感，中间件资源消耗可量化、优化可度量。从长远来看,完全解决阿里巴巴面临的Pandora/SDK升级之痛是需要相当长的一段时间，而ServiceMesh在流量治理这块的新价值也需要规模化落地达到一定水平后才能兑现，基础技术对业务的价值需要具备长远的眼光。ServiceMesh的长远价值有：业务与基础技术全面解耦，业务更聚集于自身而加速创新，基础技术独立演进而加速迭代。对微服务生态完成标准化、体系

11、化的收口与治理，收敛故障和促进安全生产，加速应用功能正确性的验证效率。为多种编程语言的应用提供微服务治理能力，完善并丰富云原生多编程语言的应用生态。共建全球事实标准，通过阿里云的产品落实客户IT设施的多云和混合云战略，加速中国社会乃至全球的数字化转型。明确了技术的价值之后，业务与技术协同发展接下来的挑战在于，需要技术演进的过程中完全不影响业务，这好比给一架高速运行的飞机换引擎。为此，新技术的落地方案需要考虑对业务无侵入，换句话说规避业务应用新技术的改造成本。为了应用Mesh化时对业务无感，在以RPC流量做Mesh化为切入点的背景下，我们设计了动态流量无损透明拦截的技术方案。上图示例说明了应用m

12、esh化前后的三种状态。在“过去”，流量是直接通过RPCSDK在ProVider和ConSUmer之间互通的，SDK直接跟中间件的服务注册中心、配置中心对接。到了“现在“，SerViCeMeSh直接被插入到了应用和中间件之间，SDK不做任何的变化，但通过iptables将SDK的流量拦截到Sidecar中。由于iptables是否开启和关闭流量拦截是可以通过运维控制台从应用或机器维度进行控制的，这就使得在mesh技术自身出现问题的情形下可以方便禁用，让应用回退到通过SDK直连的方式互通。面向“未来”，当SerViCeMeSh技术完全成熟时，SDK需要从“胖”变“瘦”，那时并不需要SDK中存在下

13、沉到Sidecar的那些能力，从而节约重复功能所导致的资源开销。下图示例说明了打开和关闭流量透明拦截功能的关键流程。其中应用进程中包含了RPCSDK而没有区分表达，TrafficInterceptorPilotAgent和Envoy三个组件在同一个容器中，所有组件共享同一个POd。OneOPSCOre是基于K8s所构建的中心化mesh运维Operator,收到控制台（图中标识为小人的Operator指代）调用开启或关闭流量透明拦截的接口后，通过调用PilOtAgent所提供的接口完成对Pod中应用流量的操作。为了保证打开和关闭透明拦截功能时无业务流量的调用损失，请注意图中红色标识出的二大块流程

14、。开启流量拦截时：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请求；

15、随后PilOtAgent调用TraffiClnterCePtOr接口关闭流量拦截功能（消息4.1.2）；最后，EnVoy的优雅关闭接口被调用时会启动一个延时15秒的定时器，确保RPCSDK与EnVoy间已建立的长连接上还没有完成处理的请求有足够的时间处理完以免出现流量有损，当定时器到期后Envoy会主动关闭与RPCSDK所建立的连接（消息6）。为了让MeSh技术自身的迭代对业务无感，我们设计了流量无损热升级方案，确保Sidecar可以随时对业务无感升级。设计流量无损热升级方案的核心考量是投入产出比，以最小的工程成本构建一个容易做到稳定的技术方案，下图示例了站在Consumer视角（既Consu

16、mer侧的Envoy进行升级，Consumer代表流量调用的发起方）所观测到的热升级流程。当EnVOy有一个新版本需要升级时（图中标识为v2）,通过运维控制台可以设置这个新血本的镜像信息，通过C）PenKrUiSe的SidecarSet可以拉到这一镜像并将镜像中的新版本Envoy二进制程序拉起。随后，新版本Envoy会向老版本Envoy（路中标识为Vl）发起热升级流程。热升级大致包含如下几个流程：老版本进程中所有的侦听fd通过进程间通讯的方式交给新版本进程（消息、5.1）,由新版本进程继续在之上进行侦听（消息5.1.1）,换句话说，之后所有在这些被侦听端口上新建的连接都会发生在新版本进程中；老版本进程调用RPCSDK的优雅关闭接口（消息5.3）,告诉RPCSDK不要再已建立的连接上发起新的调用，如果要发起新调用则必须重新建立连接，显然新连接将与新版本进程建立，随后的调用流量将全部进到新版本进程；老版本进程向R