搁浅服务网格体系结构的探索与实践

自2016年进入公众视野以来,Servimesh一直保持着快速发展的状态。目前,Servimesh已成为业界公认的下一代微服务架构,并被CNCF列为构建容错性好、易于管理和观察的云本地应用的关键技术。

2019年底,经过多年的微服架构实践积累,总结和分析现有架构的痛点,并在各个阶段进行思考和评估,莫莫莫正式启动了服务网格落地项目莫阿网格。本文将从原有的微服架构入手,详细描述陌生服务网格架构的探索过程,希望能为业内也关心如何登陆服务网格的技术人员提供参考。

1

搁浅的微服务架构的演进

2013年,Momo服务导向架构团队完成了微服务架构的研发和推广。考虑到当时行业中还没有成熟的开源产品,Momo面向服务架构是自己开发的,并应用于很多业务领域,如附近的动态、直播、即时消息、短视频等。

随着业务的不断增长,农业部已经完成了对自身能力和稳定性的验证。它发布了2000个服务,注册了20000个实例,全天使用3500亿次,QPS在高峰时达到600万次。

发展历史

为了支持大规模商业服务的运营,除了不断完善自身,MOA还需要与其他基础设施产品合作,如监控、异步、配置、日志、分布式跟踪、压力测量等平台和系统。

回顾莫言整个微服系统的发展,2011年仍采用单一应用,2012年开始系统拆分,2013年开发微服框架MOA,2017年实现应用容器化,2020年登陆服务网格架构。

1000.jpg

搁浅的微服务系统的发展

多语言支持

陌生化服务器架构采用多语种架构的PHP API Java后端服务,实现了PHP开发效率和Java高性能的优势。这也使得农业部从一开始就要应对跨语言通话带来的挑战。

该协议的核心部分是Java语言SDK。在微服务系统中,我们进一步引入了以下机制来简化其他语言的SDK开发

能够重用成熟的Redis客户端的Redis GET跨语言传输协议

与普通服务调用方法一致的通过域名访问的地址查询服务查找

由Java开发的MOA代理,以边车模式部署,作为入站代理,支持非Java语言发布服务,并访问整个微服务系统。

整体结构

随着相关基础设施产品和多语言支持机制的集成,MOA 1.0微服务系统具备了相对全面的服务治理能力。

MOA的整体架构如下图所示,其中MOA Watcher是一个集中式健康检测系统,MOA客户端也有自动容错机制。并行调用代理是支持PHP语言实现并行调用的集中流代理。

1000.jpg

2

体系结构难点和服务网格

结构痛点分析

在业务规模不断扩大和微服务架构不断演进的过程中,仍然存在一些无法完全解决的问题。它们可以统一成“服务治理能力滞后”的问题。

非Java应用程序能力落后

在最初的体系结构中采用了许多机制来简化多语言SDK的开发。然而,在中间件团队由Java工程师主导的情况下,SDK在其他语言中的迭代速度仍将远远落后于Java SDK,导致SDK在其他语言中缺少许多关键功能,无法快速完成修复和补充。

Java应用能力落后

Java SDK具有最完善的服务治理能力,但当Java应用程序的数量达到数千个规模时,SDK的升级将成为一项极其困难的任务,使得新开发的功能也无法快速应用于每个应用程序。即使推广集中在一些紧急情况下,依赖和重新发布每个应用程序修订版本的过程也会消耗业务团队和基础架构团队的大量时间和精力,这将对整体业务迭代效率产生负面影响。

滞后问题的危害

服务治理能力的滞后使得整体微服务架构无法实现统一。能力的缺乏会损害应用程序的稳定性,甚至导致失败。当进行重大的结构性变革时,缺乏和无法迅速补充将成为理想计划的障碍,从而迫使选择其他有缺陷的计划。

引入服务网格

服务网格将服务框架的核心逻辑剥离到本地代理进程的方式可以完全解决Java SDK升级和多语言SDK二次开发的问题。然而,是否应该引入这个全新的框架需要对以下问题进行深入和全面的评估:

它是否足够成熟,不会影响稳定性?

有没有其他计划可以达到同样的目标

投资有限且可接受吗

我们真的能解决问题并带来预期的价值吗?

经过仔细考虑,我们决定引入Servimesh来解决原始架构的难点。

观察阶段

对于新的技术方案,我们没有多余的人力去“试着犯错”。在这个阶段,我们首先关注服务网格的发展,同时我们也在等待公司内部一些基础设施的成熟,比如集装箱化部署的应用和日志监控代理方案的改进。

试验阶段

尝试通过其他解决方案解决现有问题。例如,非Java SDK最迫切的需求是流量调度能力。我们尝试采用无流量代理的方案,只将路由机制引入代理。然而,我们发现业务流程和代理之间存在着复杂的交互逻辑,并且不能完全解耦。

评估阶段

对服务网格方案进行综合评估,包括耗时增加呼叫、服务器成本、人工投入等问题。确保计划的成本和影响在可接受的范围内。

初始阶段

在当前的业务规模下,提高业务团队的开发效率和减轻业务团队的负担是基础设施部门的主要工作目标。当我们决定引入服务网格解决方案时,保持服务治理能力的高速迭代和将业务团队从SDK升级中解放出来是最重要的价值。

3

服务网格体系结构的陌生化实践

行业方案研究

Istio

目前,最具影响力的开源产品Istio提供了一套完整而具体的解决方案,包括代理流量的数据平面和管理代理层的各种控制平面组件。几乎所有公司的着陆计划都会参考Istio的设计。然而,Istio仍然是高速进化的产物。由于与一些k8s机制的绑定和性能瓶颈,许多公司没有直接使用Istio。

1000.jpg

蚂蚁金融

蚂蚁金服选择使用go语言自行开发数据飞机产品SOFA MOSN,并在过去一年中完成了大规模着陆实践验证。平滑升级机制取得了非常理想的效果,值得数据层追求。自主开发的控制平面SOFA网格目前正在与Istio合并。

1000.jpg

美团

美国代表团基于Istio的数据平面产品特使已经第二次开发,以支持与现有内部系统的集成和对现有服务的访问。AMC的原始服务框架产品OCTO具有非常完善的服务治理功能,这部分经验已经应用到自主开发的控制平面上。

1000.jpg

搁浅方案的选择

从各公司的计划来看,有使用开源产品、二次开发和自我研究的案例。如果要构建一个全新的应用程序,采用开源产品方案并持续跟踪社区是一个理想的选择。Mo Mo Mo的当前目标是将现有服务升级到服务网格体系结构。最后,对数据平面和控制平面都采用了自主研究方案,并使用Java语言开发了数据平面代理流量代理。在方案选择过程中,我们主要考虑以下三个因素

与现有架构的兼容性

MOA框架使用私有协议,而不是标准的HTTP和gRPC协议。直接使用开源数据平面产品需要更多的适应和修改。同时访问其他内部系统也需要大量的修改。

现阶段的关键要求

当前体系结构的难点是SDK升级和跨语言,而不是缺少控制平面功能。开源控制平面产品的直接引入将大大增加方案的复杂性,而社区控制平面产品仍在逐步完善的过程中。

技术储备和主要因素

出于技术储备和人才储备等原因,我们暂时不想在技术系统中引入围棋语言。Java语言是公司中开发服务器最成熟的应用程序。自主学习MOA框架积累了丰富的经验。

整体结构

目前,我们关注的核心利益都是由数据平面产生的,所以总体规划将集中在数据平面代理的建设上。在控制平面方案中,增加了一个轻量级的导频代理来将数据平面代理从其他内部系统中分离出来。控制平面优先采用Istio标准协议(如xDS、MCP等。)来实现组件之间的通信,这提供了逐渐靠近社区的可能性。下图显示了基于服务网格的MOA 2.0的整体架构

1000.jpg

数据平面架构方案

数据平面是与业务流程直接交互的级别,它与业务团队的直观体验和应用程序的整体稳定性相关。在设计数据平面方案时,我们主要关注三个方面:平滑升级、代理容灾和代理性能。

平稳升级

为了在没有业务团队参与的情况下实现代理迭代升级过程,该过程必须对业务开发人员不敏感,并且需要满足“平滑升级”过程

业务流程不会重新启动

业务流程的流量保持不变

传统的流量交换方案需要一个新的代理IP或端口和一个复杂的流量调度过程来实现业务流程的流量保持不变。我们选择了一个更具商业意识的“FD迁移方案”。通过调用Linux操作系统的sendmsg/recvmsg接口,旧进程可以将其持有的连接的FD(文件描述符)发送到新进程,新进程可以将接收到的FD恢复到该连接并继续读写操作。

Java的JDK本身并不公开操作系统的底层接口,需要通过JNI调用。Java的网络框架Netty已经实现了相关接口的封装。基于Netty提供的Java API,可以开发相关的功能开发迁移机制。

1000.jpg

代理容灾

随着数据平面转发流量的引入,整体架构将变得更加复杂。在为代理设计容灾方案时,遵循的原则很简单,并且依赖尽可能少的资源。

对于大多数服务类型的应用程序,代理代理的传出流量由传入流量生成。此时,可以利用微服务系统原有的健康检测机制进行容灾,当代理异常时,可以删除实例流量,使整个服务不再受异常代理的影响。

对于少数代理仅代理流量的情况,当代理异常时,SDK可以将流量切换到该应用程序的其他代理。因为同一应用程序中的代理具有相同的配置、资源和身份验证要求,所以该切换过程具有最低的切换成本和最高的稳定性。

1000.jpg

代理性能

在影响代理流量代理性能的诸多因素中,通信协议是最关键的环节之一。MOA的原始协议不支持可扩展报头字段。转发请求时,它需要解码整个请求的字节数据,以获得路由信息,如服务名。在这种情况下,需要添加新的传输协议,以避免在转发请求时解析请求体的开销。同时,新协议需要针对原有的Redis GET协议不支持单连接并行处理请求的问题,优化连接重用,从而优化代理转发性能。

1000.jpg

4

观点

陌生人服务网格架构实践仍处于初级阶段。目前,数据平面的研发已经完成,在线服务的灰度验证已经逐步开始。接下来,我们将进一步完成控制平面的建设,完善数据平面的功能,解决网上业务大规模推广中遇到的问题。我们计划在每个阶段分享我们的经验和见解,并与业界进行广泛交流。请期待未来不断更新的内容。

作者简介

陌生的中间件架构师高飞航在微服务、多房间架构和中间件产品领域进行了深入研究。目前,他专注于服务网格、云起源等技术方向。

莫莫基础平台团队继续为基础中间件招募高级架构师和高级Java工程师。该团队致力于为公司和子公司提供完整的基础设施能力交付,包括微服务治理平台、配置中心、监控平台、消息传递平台、存储中间件、即时消息通用解决方案等技术领域。