下一代软件架构，如何构建微服务核心能力

作者：李艳林

本文整理自阿里云微服务负责人李艳林在 2023 云栖《下一代软件架构，如何构建微服务核心能力》的分享。

随着数字化进程的加速，各种架构设计思想风起云涌，进入百家争鸣时代，微服务架构，云原生架构，Serverless 架构，事件驱动架构，中台架构，容灾架构，到底哪种思潮代表未来呢？

架构趋势

未来的架构趋势是什么呢？为什么说微服务架构是下一代软件架构呢？

主流架构趋势

每一种架构都有时代的挑战和选择，没有最好的架构，只有更适合的架构。

WEB 1.0 时代，更多的是信息的呈现，系统相对简单，早期一般购买物理机，采用经典的 LAMP 单体架构快速构建一个网站，业务复杂可以采用 MVP 思想进行分层化解。

WEB 2.0 时代，交互复杂，互联网/移动互联网蓬勃发展，互联网充斥着快鱼吃慢鱼的故事，因此化解复杂系统的快速迭代的架构就是下一代架构。在基础设施这层采用云计算底座能够快速交付资源，采用微服务架构充分提升研发效率，解决复杂系统的研发效率问题；采用中台架构，解决复杂系统重复建设和基础服务能力沉淀问题。

随着线上、线下的加速融合，稳定性要求越来越高，因此高可用成为每家企业必须重视的话题。如果在云上，云厂商会解决容灾问题，如果自建 IDC，可以采用混合云架构解决基础设施容灾问题；在应用架构层面，同城多活是解决应用容灾的通用方案；在业务架构层面，异地多活是解决业务容灾的最佳实践。

随着数字化加深，整个时代架构会逐渐右移动，可见微服务会是下一代软件架构，会逐渐成为时代的主角。

云原生微服务

微服务架构在释放研发效率同时导致运维成本上升，但是 K8s 彻底解决了运维问题，让微服务迈过技术成熟度拐点，并且随着云原生架构加速演进，充分释放云的红利。

微服务价值凸显

下图是展示单体和微服务架构选型的图，横坐标代表系统复杂度，纵坐标代表效率，绿色曲线代表单体应用，蓝色曲线代表微服务；当系统复杂度（超过 10 个子系统或者人员）上升，采用微服务架构会比单体架构效率更高。

随着 WEB 2.0 加速渗透，系统能力和复杂度逐渐上升，越来越多的企业达到这个拐点；再伴随着开源和云计算的推进，微服务成本从百万级下降到千级，使用门槛大幅降低，导致拐点左移，目前市场上能看到，3 个子系统就开始采用微服务架构；随着算力成本的不断下降，人力成本的不断上升，采用微服务架构的公司投入产出比会越来越高，加速企业创新和迭代速度。

微服务行业趋势

微服务市场每年保持 18% 以上增长，可见其爆发力之强；Gartner 报告显示，微服务进入稳步爬升初期，这意味着技术成熟、标准，加速渗透各行各业；CSDN 开发者报告则显示，58% 用户关注微服务架构，可见开发者将大规模越迁到微服务时代。

微服务挑战 & 解法

虽然大家都知道微服务是下一代架构，但是对微服务的实施难点有所忌惮，对解法是否优雅有所怀疑，下面我将详细介绍一下我们的思考。

微服务主要挑战

从单体演进到微服务后，会大幅提升业务研发效率，但是也会带来架构的复杂性，开发需要先解决 RPC 调用复杂问题，发布解决变更有损可用性问题，出故障需要解决登陆很多机器解决才可定位的问题，面对黑客需要解决安全问题。这就是微服务核心的四个挑战，下面我们将逐步分享我们的解法。

微服务框架挑战

微服务框架核心要解决的是，如何像单体一样开发微服务应用，屏蔽分布式系统复杂度和多语言差异。2011 年阿里开源 Dubbo 框架，由于简单易用的优势快速成为国内首选，但是存在着序列化协议语言相关性高，多语言发展缓慢，重 SDK 模式、升级困难等问题。

为了解决重 SDK 问题，我们引入了 Agent 的技术（Java 字节码增强），尽可能把复杂的治理功能下沉到 Agent 中，大幅缓解 SDK 生命周期管理问题，但是依然没有解决多语言问题。

为了解决多语言问题，有两个基本思路，一个是通过 Sidecar 技术，在网络层通用解决一些流量治理问题，但这个思路会引入一个新的依赖，增加复杂度；另外一个思路是发展利于多语言实现的序列化协议，目前主要有 Http + Json 和 gRPC（基于 HTTP2.0）+ PB 两个路径。

我们基于第一性原理判断，最终 RPC 调用类似 HTTP 调用，不应该引入一个 Sidecar 的复杂度，应该按照标准化和轻量化方向演进，因此我们 Dubbo 3.0 推出了 Triple 协议（基于 HTTP / gRPC），解决多语言问题，数据面控制面分离，客户端轻量化。

微服务框架解法

微服务框架主要由三个部分组成，API 层，协议层，治理层；API 层主要解决简单好用问题，Dubbo 的 API 非常适合 Java 开发者，但是早期参照 Java 写的 Golang 版本不适合 Golang 开发者习惯，因此我们推出更适合 Golang 语言的微服务编程 API，并配套升级了官网、文档、示例、脚手架，不断降低复杂度；协议层推出 Triple 协议，解决跨语言调用问题，支持 OT 利于多语言链路追踪；服务治理代码占 Dubbo 一半左右代码，多语言实现难度大，因此我们做了数据面和控制面抽象，将 SDK 轻量化，支持部分治理下沉 Sidecar，方便多语言实现。

微服务可用性挑战

实践数据表明，系统变更会引入 70% 风险。如采用微服务后第一个遇到的是发布流量损失，核心原因是节点下线通过注册中心通知下游有延迟，上有系统不能及时摘除下线节点，导致调用异常；由于应用多，变更时间不同，依赖复杂，会导致变更产生的风险变多。

运行态会引入 10% 左右风险，比例虽小但是风险极大，这类风险主要有三类，一类是被上游系统突发流量和攻击压死，一类是被下游不靠谱依赖拖垮，一类是被运行机器抖动拖死；

因此微服务的可用性挑战，主要解决这些问题。

微服务可用性解法

面对变更态最多的风险，我们核心的思路是可灰度、可观测、可回滚； 通过灰度缩小爆炸半径，观测快速识别问题，回滚来快速解决问题；其中灰度技术要求最高，主要是因为两个原因，一个涉及全链路应用多、规则复杂。阿里内部全产品改造（Dubbo+Nacos/ RocketMQ / 任务调度 / 可观测）所有核心业务升级，消耗大、时间久，不通用，因此我们后来推出 Agent 解决方案，无侵入解决服务治理的问题。

Dubbo 早期预置了一些治理规则 + Groovy 扩展机制，治理规则变化多总得升级，Groovy 不利于多语言实现且不好管控。因此需要在灵活性和复杂性之间做一个平衡，最后我们根据主流流量控制场景将配置模版化，数据面和控制面分离，来解决该问题。

微服务观测挑战

由于微服务系统业务复杂，依赖复杂，链路复杂，导致排查问题增大，尤其涉及多层调用问题排查。如果登陆到一台台机器查日志，这个简直是一个噩梦。

微服务观测解法

微服务观测目前方法论比较充分，通过 Metrics 定性大概是业务问题还是中间件问题，通过 Tracing 定量分析是哪个应用问题，通过 Logging 定位具体根因。OT 标准的出现，加速了技术迭代，解决复杂链路问题，大幅提升分析诊断效率。

微服务安全挑战

为了快速落地微服务，很多公司一个应用挂一个公网 SLB 来发布服务，这样安全攻击面非常大，也增加了管理证书负担，应用内部都有自己的敏感数据，一不小心可能造成致命损失。

微服务安全解法

安全最好的做法就是统一入口，在入口建立安全防线，把风险拒之门外，把敏感数据存放到配置中心加密存储，代码、密文和密钥分别存储，杜绝核心数据泄漏。

微服务演进 & 实践

上面详细介绍了微服务当前的挑战和解法，那面对未来微服务将如何演进，有哪些实践呢？

微服务演进

未来微服务会沿着易用、标准化、语言无关、可扩展、可持续架构演进； 微服务框架解决易用性和多语言问题，控制面解决标准化和可扩展问题，可持续架构是从小到大可以持续演进，而不是第一天就搞一个巨复杂架构。小的时候可以 Dubbo+Nacos 快速开始，遇到安全问题上云原生网关 Higress，遇到稳定性问题上服务治理，遇到一致性问题引入 Seata（启动贡献 Apache 社区），一步步持续生长。

微服务框架演进

对于 OPS 同学，掌握 K8s + Terraform 就可以高效的运维；面对开发者，我们通过 Spring-Cloud-Alibaba 帮助开发者解决微服务开发效率问题。未来，我们将扩大范围，做开发者和阿里云的链接，通过 Spring 注解快速使用阿里云主流云产品，大幅提升开发者效率。

服务治理演进

Istio 体系主要解决流量治理问题，抽象度高但是复杂，然而对于微服务，我们更多需要的是服务治理，因此我们会通过 OpenSerGo 来推动服务治理的规范和标准制定，简化服务治理使用门槛。

网关演进

WEB 1.0 主要采用 SLB / ALB + ECS + 单体架构，支撑简单的信息系统。

WEB 2.0 主要采用云原生网关 + 容器 + 微服务架构，支撑复杂交互系统；从单体到微服务，SLB / 微服务网关彼此不能互通，从微服务到 ACK，微服务网关和 Ingress 网关彼此不能互通，导致在架构演进中会出现流量网关、微服务网关、安全网关多层叠罗汉现象，带来运维和部署复杂度提升。因此，我们推出云原生网关 Higress，将三层网关合一，基于 Ingress 标准整合微服务和安全网关能力，提供服务治理差异化竞争力，相比 Nginx 生态网关，Higress 采用 Envoy 内核，从规则、路由、证书、插件实现全部热更新，避免链接抖动带来的用户中断和体验下降。

未来云计算发展有两个主导力量，一个是 Serverless，把算力发挥到极致；一个是 AI，把数据挖掘到极致。

面对 Serverless 时代，网关需要突破自适应能力（流量来后端服务没有拉起 Hold 流量，后端服务拉齐转发下去），目前 MSE Higress  +  ASK / SAE 已经全部跑通，阿里云 FC / SAE 会内置 Higress。

面对 AI 时代，网关需要双向流传输性能和链接稳定性有很高要求，协议上需要支持 SSE/WebSocket 等双向流协议，需要热更新能力保证链接稳定，目前通义系列和 PAI 等开始集成 Higress。

微服务企业级实践

阿里微服务体系通过 10+ 年的双十一洪峰考验，以及云上成千上万家企业的打磨，构建了默认安全、默认高可用的差异化竞争力。今年 MSE 4.0 全面 Serverless 化，推出了行业首个云原生网关/注册配置中心 Serverless 版本，从低运维到免运维，无需关心容量，无需关心版本升级，按量付费低于自建成本，真正做到像水电一样使用微服务。

微服务高可用实践

我们根据双十一压测场景，简单介绍一下微服务高可用体系。首先，我们通过 PTS 模拟客户压测，在 MSE 云原生网关入口做路由级流量防护，在应用侧通过服务治理做服务级流量防护，通过 ARMS 做全链路观测，通过指标驱动容器弹性伸缩，从而轻松应对流量洪峰。

微服务容灾实践

解决完单集群高可用问题，我们需要解决多 AZ 容灾问题，进一步提升微服务高可用体系。下面有两个可用区，每个可用区有一个 K8s 集群，通过 ACK One 轻松管理两个集群。面对入口流量我们有两个选择，一个选择是一个网关集群，聚合两个 K8s 服务，可以通过网关灵活切换不同可用区容量；一个是选择两个网关集群，通过上层 DNS 切换流量，这样架构简单，但是切流实时性无法保障。

微服务 Serverless 实践

如果我们真的想像用水电一样使用云服务，未来 Serverless 一定是关键方向，让用户能够聚焦业务开发，让云逐渐带大家走到自动挡，自动驾驶时代。目前在云上可以通过 SAE + MSE 体验 Serverless 的优势，加速推进 Serverless 进程，进一步释放云计算红利。