成本最低、最快上云｜SOFA Mesh 助力银行上云实战案例分享

原创于 2024-07-23 20:15:29 发布 · 901 阅读

9 ·

CC 4.0 BY-SA版权

王程铭（呈铭）

蚂蚁集团技术工程师，MOSN 开发者，Apache Dubbo Committer，SOFAStack Member

专注 RPC、Service Mesh 和云原生等领域。

本文 4675 字，预计阅读 10 分钟

🗂️ SOFA Mesh 简介

“

什么是服务网格

Service Mesh，在国内译作服务网格，是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明；包括在连接层面上的支持、安全、控制、无侵入以及可观察性等业界比较认可的通用能力。

“

服务网格能带来什么收益？

在基础架构和应用层做到解耦，能帮助降低基础架构升级跟运维的成本。
客户侧、企业级等实际场景中，包括框架在内有着很多异构语言，通过服务网格可以实现统一的服务治理。
应用之间通讯做到连接层的安全加密。
可观测性支持。Sidecar 可以在每笔调用中生成一些可观测的报告和事件，或可观测数据。
兼容异构运行时的不同架构的应用。
支持整体的单元化容灾。企业可自行构建单元化能力，在我们的 Sidecar 技术组件上实现。

☁️ 银行核心系统上云-问题与挑战

“

某城商行当前技术现状

当前，某城商行正处于从传统技术架构向微服务架构过度的演进中，在 IAAS 层中对物理机、ECS 以及异构云容器进行混用。在这基础层之上，他们的业务场景包含单体的应用、Spring Cloud 应用以及 SOFA 应用，甚至一些魔改的、非标准体系当中的版本。比如他们用 Spring Cloud 框架做了一些魔改，包括 resttemplate 调用等。

机构技术栈如此复杂，运维同学苦恼于没有统一的服务治理能力和可观测平台，并且所有的能力都参差不齐。面对这种情况，选用 Service Mesh 这种新的架构去解决以上问题，是成本最低、最快上云的途径。

“

某城商行云上云下通信现状

当前现状如上图，可以看出：

云上采用微服务架构，应用间采用 SOFA RPC 通讯。
云下采用 SOA 架构，应用间通过 ESB 以 TCP+JSON 格式通信。
云上云下的通讯因为报文协议的不同，内联网关将云上的微服务接口映射成 ESB 的 JSON 对云下发布，将云下的 JSON 报文映射成微服务接口对云上发布，在调用过程中内联网关进行协议报文的转换。

“

当前存在的挑战

当前的架构带来了以下三点挑战：

云上云下通信严重依赖内联网关，新增服务需要重启内联网关。
云上云下没有统一的服务治理平台。
稳态系统（如理财系统）上云需要改造成技术栈，成本极高。客户需要对技术或业务架构进行拆分或者重构、中间件改造以及容器化改造；同时还需要围绕运维管理、风险管理、资源管理等展开云上优化和适配工作。

🎢 银行核心系统上云-整体架构设计

“

为什么要去 ESB：ESB VS Mesh 功能对比

通过下图 ESB 与 Mesh 的功能对比，可以看出，Mesh 目前的能力已经覆盖了 ESB 所具有的功能。

“

核心上云架构设计

整体思路如下：

在服务元数据平台中集中管理服务声明、契约、字段映射、协议声明等。
MOSN 负责实现注册中心 pub/sub、服务治理、协议编解码、协议转换、字段映射等。
业务应用只需要在服务元数据平台做好服务声明和契约定义即可，代码 0 修改。

“

服务元数据平台

元数据平台是未来平替 ESB 而存在的，在元数据平台上可以管理应用信息、服务信息、契约定义等等。因为传统应用中不存在注册中心，都是通过 ESB + F5 进行调用，所以有了元数据平台，在传统应用上云的场景中就可以轻松地管理服务之间的发布和订阅关系、管理契约信息等。

“

异构系统通信

我们会通过协议转换插件来轻松实现异构系统的通信，即使是不了解 MOSN 的同学也可以轻松上手。下面以 SOFA 的 bolt 协议调用 ESB 的 JsonTcp 协议为例，来看看如何实现异构系统通信：

首先，需要在服务元数据平台录入服务以及契约信息。
之后，MOSN 会代理 JsonTcp 的应用向注册中心 pub 服务。
这样，SOFA 应用就可以调用到 JsonTcp 提供的服务实现异构语言的通信。

具体的实现逻辑如下：

JsonTcp 的服务注册信息由 MOSN 推送到注册中心。服务注册信息的数据，既可以直接在服务元数据平台上新增，也可以来源自 ESB 控制台。ESB 控制台通过调用服务元数据平台的接口，或以文件导入导出的方式，同步到服务元数据平台。服务元数据平台通过 drm，按照应用维度推送到各个 Sidecar，最终由 Sidecar 进行服务 pub。
SOFA 应用通过注册中心 sub 到的 JsonTcp 的地址，其实是 Sidecar 的端口（Sidecar 做服务 pub 时做了端口替换），因此会将请求发给 Sidecar。Sidecar 将 SOFA 应用发过来的 Hessian 格式的 bolt 协议请求，经过协议转换，转换为 JsonTcp 能够识别的 JSON 格式的 TCP 请求。具体的过程如下图：

在 Hessian 序列化和反序列化时，需要接口契约，字段映射时需要映射规则。因此契约和字段映射规则需要提前下发到 Sidecar。同样，契约和字段映射规则可以在服务元数据平台定义，也可以从 ESB 控制台，通过调用接口或者导入导出的方式进行同步。

“

流量劫持方案

SOFA Mesh 支持 iptables 的流量拦截模式，也支持 SDK 流量拦截的模式。通常来说微服务体系下推荐 SDK 拦截模式，传统应用下推荐使用 iptables 的拦截模式（当然也要接受附带的性能损耗）^[1]。

SDK 流量劫持模式

适用场景：使用 Spring Cloud、Dubbo、SOFA 框架的应用，都可以使用该种方案进行接入。

优点：

性能较高，应用到 MOSN 代理都是 pod 内的本地调用。
实现原理简单，蚂蚁内部大部分 SOFA 应用都使用该种方式接入 Mesh。
当客户使用的是 SOFA 框架时，已经内置了该 SDK 能力，可以无修改接入 SOFA Mesh。

透明劫持模式

适用场景：未使用微服务框架的应用及非 Java 语言（如 Python、Ruby 等）的应用，同时应用未接入注册中心。

优点：

应用不需要改代码，只需要一点配置，即可以享受微服务框架带来的红利。
可以把传统应用纳管到全行级的微服务体系中，尤其是一些改不动的“老应用”。
外部金融客户正在大面积微服务化，很多历史遗留应用改不动也不想改。这种方式接入成本更低，用户接受度更高。
在行里传统应用上云的场景下，我们可以使用透明劫持的模式。只需要用户在 Meshserver 控制台，配置透明劫持规则，声明服务注册、订阅配置即可。

透明劫持配置：

注册配置：

订阅配置：

通过声明式注册订阅配置，可以让 MOSN 完成服务的注册和订阅。其次，通过对请求的透明劫持，可以把应用流量纳管进 MOSN 中，从而无侵入地让传统应用接入 SOFA Mesh，享受微服务框架带来的服务治理红利。配置后流程如下：

用户在控制台配置透明劫持规则，主要针对 Client 应用内代码中配置的请求方端口号来进行劫持。其次用户还需要声明 MOSN 代理注册订阅的服务名及端口号。
当 MOSN 注入时，注入规则中会有相关透明劫持的配置信息及服务注册订阅的配置信息。
MOSN 启动时根据透明劫持信息会生成对应 iptables 规则，如针对 9080 端口的流量进行拦截，并转发到 MOSN 进行处理。
MOSN 启动时也会根据用户配置的注册订阅配置，去注册中心进行服务的注册订阅。
应用依然使用代码中原本的配置，向 app:9080 起 http 请求，该请求将会命中透明劫持规则，转发给 Client MOSN，MOSN 内部会进行一系列处理，如服务治理、路由、负载均衡等，最终把该请求发往 Server MOSN。
Server MOSN 保存有 Server 应用注册时监听的端口，从而会把请求转发到本地的 Server 应用，完成一次 RPC 调用。

“

静态路由

核心上云的过程中并不是一次性全部切流的，而是先部分上云，待稳定之后再陆续全都搬到云上。那么在这个过程中，就会出现同时调用云下和云上的场景。但是云下的传统应用又是没有注册中心的，往往都是通过 ESB 来路由的，那么之后我们就需要静态路由的方式来实现。

我们会优先通过服务 id 进行寻址👉如果没有成功，再判断是否存在静态路由👉如果存在则交给 ESB 处理（当然静态路由也是在服务员数据平台配置的）。

“

自定义日志设计

MOSN 可以接管业务应用的流量，自然也可以处理一些自定义日志。而且 MOSN 不区分语言，无论是 Java、C++ 还是 Python 都可以无缝支持，只需要一个插件就可以轻松实现，且插件可以存在于 Client 或者 Server 侧。

MOSN 已经留下了口子：如果我们期望在 Client 侧打印自定义日志，只需要实现 OnRecieve 方法；如果我们期望在 Server 侧打印自定义日志，只需要实现 Appand 方法。

符合行内规范的日志举例如下：

2024-07-12T01:55:16.149Z        INFO    {"Input":"status:su,usrNm:sampleUsrNm-su,","InvokeInfo":{"traceId":"ac1100021720749306358100131","spanId":"","serviceDesc":"","appSide":"consumer","callerTime":"2024-07-12 01:55:15","callerHostName":"","methodName":"execute","callerAppName":"http-app","className":"com.facade.springcloud.UserAddService","timeSpan":""},"RequestHead":{"txnDt":"20240510","cnsmrChnlTpCd":"888","rfnc24HourFlagp":"0","aplTimestamp":"2024-05-10+17:30:26.000913","orgId":"087190007","eventNo":"a-consm24051017265814623221","txnTlrId":"TKTO0001","cnsmrSysId":"000033","cnsmrSeqNo":"a-consm24051017265814623221","txnChnlTp":"888","lglPrsnCd":"9999","txnTm":"17:26:58","origIttAplNo":"000033"}}
2024-07-12T01:55:38.115Z        INFO    {"Output":"userId:SOFA provider success\n{\"abc_def\":\"1234\"},","InvokeInfo":{"traceId":"ac1100021720749306358100131","spanId":"","serviceDesc":"","appSide":"consumer","callerTime":"2024-07-12 01:55:32","callerHostName":"","methodName":"","callerAppName":"http-app","className":"","timeSpan":""},"ResponseHead":{"txnTlrId":"tsxn0030303","svcSplrSeqNo":"boltApp24071209551945461210","txnDealTp":"0","txnSt":"0","retCd":"000000","cnsmrSeqNo":"","tlrPwsd":"","retMsg":"交易处理成功","orgId":"0800001","eventNo":""},"Exceptional":"false"}

“

发布平台对接

通常行方会有自己的 DevOps 平台，那么在注入 Mesh 时，会选择优先兼容行方的 DevOps 平台。SOFA Mesh 也是支持的，并且同时支持虚拟机和容器两个场景。

以虚拟机场景为例，通常只需要对接接口即可。其中有两个比较重要的角色是 operator 和 Sidecar agent，其中 Sidecar agent 负责虚拟机场景下 Sidecar 生命周期管理；operator 负责 Sidecar 的注入。整体对接方案如下：

而容器场景中，我们通常使用云效，只需要在云效打开开关就可以实现 Sidecar 的注入。

🔭 总结与展望

以上，我们总结了在某城市商业银行实施 Service Mesh 的实践经验，证明了 Service Mesh 是实现银行核心系统快速且低成本上云的关键技术。

其核心优势及成果概括如下：

高效上云路径：Service Mesh 通过将复杂性下沉至 Sidecar 代理层，提供了一种加速银行核心系统上云的高效方式，同时降低了转型成本。
协议互通简化：Sidecar 自动处理不同服务间的协议转换，确保通信链路简洁高效，应用层无需关注底层协议差异，提升了系统的互操作性。
架构灵活性增强：通过去 ESB 和内联网关的依赖，实现了架构的优化和简化。
经济高效的扩展：新增服务间通信链路变得简便，仅需声明服务契约，无需承担额外的硬件或运维成本，促进了成本效益。
加速传统应用云端迁移：接入 Service Mesh 后，应用自动获得服务发现、服务治理、安全通信等关键能力，极大降低了传统系统上云的技术障碍。
无侵入性升级：该方案对现有业务代码无任何修改要求，仅需在 Mesh 控制台上进行服务声明和服务契约配置，保证了业务连续性和低风险迁移。

未来我们还将持续在以下方面进行探索和实践：

智能化运维与自愈能力：随着 AI 和大数据技术的融合，Service Mesh 有望集成更智能的监控、故障预测及自我修复功能，减少人工干预，提高系统的稳定性和可用性。
安全性的持续增强：安全始终是金融行业最为关注的要点。未来，Service Mesh 将在数据加密、访问控制、身份验证等方面进一步加强，引入更精细的策略管理和自动化安全响应机制，为银行核心业务提供全方位的安全防护。
全面微服务化与 DevOps 融合：Service Mesh 将成为推动银行 IT 架构全面微服务化的重要基石。结合持续集成/持续部署(CI/CD)流程，将进一步缩短软件交付周期，提升开发效率和业务响应速度，促进 DevOps 文化的深入发展。
多云与混合云策略的支持：随着银行业务的全球化布局，多云和混合云环境成为趋势。Service Mesh 将提供更加灵活的跨云服务发现、流量管理和一致性保障能力，支持业务在不同云平台之间的无缝迁移和扩展。
服务网格标准化与生态融合：随着 Istio、Envoy 等开源项目的发展，Service Mesh 的标准和生态系统将更加成熟。这将促进不同服务网格产品间的互操作性，降低技术锁定风险，银行可以更自由地选择和集成最佳工具与服务。
边缘计算与分布式架构的深入整合：面对物联网(IoT)和 5G 时代的数据爆炸，Service Mesh 将更好地与边缘计算相结合，优化数据处理和传输效率，为银行提供更即时、低延迟的服务体验。