蚂蚁金服 Service Mesh 落地实践与挑战，附全套PPT下载

本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。分享基于 Service Mesh 的理念，结合蚂蚁金服内部实际场景，将中间件、数据层、安全层等能力从应用中剥离出来后下沉至独立的 Sidecar SOFAMosn 中，结合 Kubernetes 运维体系，提供应用无感知的情况下升级基础设施层能力的案例。

本次分享将从以如下次序展开进行：

蚂蚁金服当前的服务化现状

在看蚂蚁金服的服务化架构之前我们先从一个简单的服务化调用示例说起，下图是 SOFARPC 基本原理：

图1. SOFARPC 基本原理

我们从上图可以看出，构建一个服务化框架需要有服务注册中心，有服务定义，调用方和服务提供方使用相同的服务定义来互相通讯。通过服务注册中心，调用方可以直接订阅到服务提供方的地址，采用点对点的方式直接发起请求。客户端内可实现服务发现、路由寻址、负载均衡、限流熔断等能力来增强服务通讯能力。通过我们开源的 SOFARPC、SOFARegistry、SOFABoot，用户已经可以直接构建起微服务体系，助力业务发展。

蚂蚁金服发展至今，双 11 系统需要应对的交易洪峰逐年递增：

图2. 历年双 11 交易额与峰值数据

每秒 26.5 万笔交易是 2017 年双 11 的峰值数据，这个数据背后有非常复杂的架构支持，LDC 单元化架构是蚂蚁金服沉淀多年的核心架构，依靠这个架构实现每年峰值交易量飞速增长下系统依然能平滑渡过。我们来简要看下 LDC 架构：

图3. LDC 架构示例

上图摘自 金融级分布式架构 中的 素描单元化 一文，这里不详细展开。LDC 的单元化架构给应用的服务化带来更多的规范与抽象，服务路由中需要考虑单元间的调用，跨机房调用等更多场景。这里主要希望表达的是 LDC 架构给 RPC 调用带来更高的复杂度。

服务化痛点

中间件版本升级

在上面介绍背景时，有介绍到目前 LDC 架构下服务调用的复杂度，这些复杂度目前是直接体现在应用的代码中。对于业务同学来讲，一个应用的关注重点是如何实现业务逻辑，至于高可用、容灾等能力更多是整体架构层面会考虑的点。应用内通过引入 RPC 的 jar 包即可获得 LDC 架构下服务调用各种能力的支撑，带来便利的同时也可以看到这种模式的缺点：

图4. APP 业务与 SDK 组成部分

应用内除业务