2021 年 7 月 2 日，阿里云用户组（AUG）第一次线下活动在济南召开。阿里云云原生资深专家李国强结合自身微服务领域经验，现场跟数十家山东企业分享了云原生的代表技术之一“微服务”的演进和应用实践。本文根据作者的现场演讲整理而成。

背景

在企业内部分为运维或开发，但最终所有做的事情都是为了解决业务的问题。如果你做一件事情，只有技术目标而没有业务目标，失败是很常见的。

什么样的业务诉求会驱动一个企业去考虑微服务呢？

随着架构的演进，当你的业务越来越复杂，组件越来越多，对于每个业务组件的独立性要求或者技术栈的异构成本越来越高的时候，就会需要去考虑微服务。换言之，如果这个业务是一个比较平稳、没有什么大的挑战，其实不需要去做微服务的改造。

各企业需要结合自己的业务去进行分析是否真的需求微服务。很多企业可能为了沟通，或者架构师、CTO 有自己的诉求，想要这个技术领先去做微服务，最终惨淡收场，其实这种案例是非常多的。微服务的适用性一定是从一个业务驱动的这个角度考虑的，需要考虑的是业务的复杂程度。

比较单体和微服务之间的一个区别，什么情况下需要它，和复杂程度是非常相关的。当你的一个业务的复杂程度比较低，处于单体时代的时候，前端后端数据库都是一体的，需要进行变更时，一个数据包上去，所有的这个业务都上去了。并且，当你的业务足够简单的时候，单体效率一定是最高的。

业务不断往前演进，复杂度越来越高的时候，单方面的发布可能会影响到别人。比如我有一个数据包，里边对应一个模块，在这个模块上线的时候，需要去考虑别的模块怎么上线。业务流量进行扩缩容的时候，需要对整个业务进行沟通，而不是对单个模块进行沟通，你会发现资源浪费会很高。这个时候就会到一些拐点，不管是你的发版或者是你的资源利用率都会出现一些问题，生产效率开始降低。单体应用架构的效率出现的拐点就是客户考虑是否需要微服务架构的一个时间点。

微服务的应用架构

1、应用架构的演进历程

微服务最早的时候其实还是单品为主。现在的微服务对主流的一些技术框架，像 Java 体系的四分之二的 Double 类，其他语言都没有放置。但实际上其他语言都有非常多的微服务框架可以选择，像 PDP 等都会有一些。

之前云栖大会做过一次统计，账号体系在整个后端开发中的地位，50%的投票是 Java 后端开发。但现在企业越来越多元化，之前 Java 占统治的地位已经发生了变化。规模略大的公司基本上都是多元体系，里面有很多种，不同业务线的诉求不一样，可能有的业务线是 Java；有些业务偏前端框架，会用 PAP、PYTHON；还有就是企业的并购，也会带来很多元的体系。

多元数据的解法就是用一个多种的维度方案或是用新的技术形式，再往后就是容器化，微服务带来的很多问题是通过容器来解决的。包括微服务器，有些人可能直接放弃不用了。负责人看到 Double 这个体系，直接用 K8sS Service 去做它的这个运行的暴露单元，好处是和语言无关，什么样的体系里面都可以是一个 K8s Service。但在用了微服务后暴露出来的问题会比较多，我们需要对这么多的业务组件进行治理。

K8s 本身是不强的，就是为了要进一步解决这个问题，引入了更多的网格技术。去年开始越来越多的企业开始做网格网络，这里面就包括用 Service Mesh 这个服务网解决跨语言的调研和服务治理。还有一个更新的叫做 Dapr 的技术解决供应链依赖问题。

可以发现，应用架构的演进是一个业务不断地提出问题，然后产出新框架，新的框架又可能会引入新的问题，不断推动着技术的运行过程。

阿里应用架构演进

整个阿里巴巴内部是完全走过一遍上述流程的，因为业务的快速增长，对技术团队也在不断地进行挑战。PHP 是世界上最好最早的语言，淘宝商城其实就是用的 PHP。但是后来业务发展，淘宝的体量越来越快后，不但不能够支撑这个业务，PHP 本身的扩展能力也撑不住了。

2009 年，阿里先做了分布式业务。阿里正式地从单体变成了分布式业务，那时候体量已经比较大，还没有双十一，但已经促成了阿里内部去做自己的分布式框架。除了会有分布式的服务框架，还有一些分布式的数据库和分布式的相应规定，在内部称为三辆马车，这也是从单体变成分布式框架时，必须要解决的三件事。

到 2011 年时，阿里开始探索容器化，先做了 T4 项目，是对于容器化的技术实现，最后变成 Pouch 的容器化的实现，它也是符合容器标准的容器化的实现。这体现出针对微服务后带来的运维挑战，容器是一个非常好的解决方案。

再往后到 2013 年，整个 Oracle 包括小型机在阿里下线，全部变成自己的开源的技术栈。2015 年开始，阿里全面拥抱云原生技术，包括容器技术的对外开放等业务，整个体系逐步深化。2016 年到 2019 年间，阿里做了云原生上云，包含已经全面拥抱的 K8s 体系，以及微服务的改造、治理等。

到现在这段时间，我们做的事情是图上画的最后一个阶段：基于网格进一步对服务点的支持，多语言越来越常见。阿里有很多业务是从外部合并进来的，阿里原来的整套技术战略全部都是 Java，对外部合并进来的用户非常不友好，因为他们不可能全部配好重启，不得不去适配 Java。所以，近来我们在做的事情就是基于网格的新一代微服务架构做演进，会有一些技术让微服务的框架本身对于多元的支持变得更好，包括治理也可以去解耦，这也是成本较高的一个原因。

2、Apache Dubbo 3.0

Dubbo 3.0 在 6 月底已经发布了最新版，这其实是一个很坎坷的项目。2008 年的时候 Dubbo 在内部正式发布，2011 年正式开源。以前，Dubbo 和 HMPK 在阿里内部都有，但阿里希望技术上是统一的，不希望有两套技术，两边不互通。这是两个技术栈，所以进行了一次 PK，Apache Dubbo 胜出，所以阿里内部目前全是 Apache Dubbo。现在这也是国内最火的 Apache 框架。中间有段时间，阿里内部投入比较少。到 2017 年时，我们中间件团队再次去做商业化，重启整个 Dubbo 开源，才让 Apache 从完整的一个项目到前几天时完成了发布。

这个项目是非常活跃的，现在的贡献和使用率都非常高。Dubbo 3.0 里其实做了很多事去拥抱最新的一些理念，比如对 Service Mesh 的支持，它的协议也和 GRP 做了更好的兼容，做了一系列全新的服务发现模式。现在国内用得比较多的还是 2.7、2.6 的版本，3.0 发布之后，很多企业一旦用起来都比较喜欢。当时还没发布时，社区里就有一个用户在拿 3.0 开始测试了。

3、Spring Cloud Alibaba

另一个不得不夸奖的是 Cloud 体系，它和 Java 的微服务这两个体系目前还是最流行的。Spring Cloud 体系的优点是组件非常丰富。Dubbo 这两年在从 IPC 框架往主流服务器去引擎，而 Spring Cloud 诞生之初就是要把微服务数据相关部门支持起来。

随后，阿里巴巴做了 Spring Cloud Alibaba，阿里开源一系列的中间件，包括 Double 注册中心、配置中心、限流交易规律以及事务，去帮助用户解决刚才讲到的微服体系中各种各样的问题。

微服务是一整个体系，而不仅仅是简单的调用框架。微服务在大家使用的落地过程中碰到的问题，阿里非常重视。它把其中一些重要的点进行开源，同时通过与阿里云结合做 SDK 的分装，把这两部分合在一起。主要目的之一是帮助用户去使用 Spring Cloud 体系，另一个目的是帮助用户在阿里云上更好地运行 Spring Cloud。所以，这是阿里巴巴的 Cloud。

大部分的用户知道的 Nacos、Sentinel 等中间件，实际上和云的一些产品间有非常好的基础。我们也会和其他公司去联合开发，不断地演进项目。因为在阿里，我们会认为开源和商业化是同样重要的，一个团队既需要承担开源项目，也需要承担商业化的服务。

微服务不是免费的午餐

1、微服务会带来复杂度的提升

微服务不是免费的，它会带来很大的复杂度提升，包括服务框架的选型、注册中心的稳定性等。当一个客户足够大的时候，他会面临一个很大的问题，就是注册中心的稳定性可能会成为一个业务的瓶颈，包括应用的监控、统一的配置管理、任务调度等一系列的东西都会成微服务落地过程中需要考虑的问题。

在这个过程中，对整个企业挑战还是比较大的，不是每个企业都有能力去把整个微服务的开发组件全部自己运维起来。这一大堆组件如果全部靠自己运维起来，要求还是比较高的。所以，在里面更多地是希望企业更关注业务的一些相对偏运维的事情，云厂商才可能通过用其他方式进行解决，或者是如果企业足够强大，也可以去通过开源自建的方式去解决。

2、软件架构诉求与基础设施能力间存在“步调差 ”

刚才讲到 Spring Cloud、 Dubbo 挺好用，但实际上也存在问题，即 SDK 的升级会变得非常困难，因为这个升级对业务没有任何价值，业务方不愿意去配合。很多时候都是系统来说 2.6 有 bug，需要升一下 2.7 版本。这个时候就需要推动业务方去做，因为他把 SDK 引用进去了，引了之后如果有 bug 或者做一个增强，都需要在 SDK 做，这时业务方往往是不愿意的。在阿里内部这个问题也同样存在。

实际上这涉及到一个比较大的话题，即业务开发人员和基础设施的运维人员的边界在哪。SDK 这件事情到底属于业务人员还是属于基础知识，这个问题问起来很抽象，是大家的一个责任边界的问题。业务开发人员认为 SDK 是运维测试的，因为我只要接口，剩下更新、治理、工程上和业务开发没关系。运维人员又不得不让研发人员去配合业务研发，这是模糊的边界，必然会发生冲突。

所以从云的角度或从计算的角度出发，我们在探讨所谓的软件架构速度和基础设施能力丰富度的问题时，能不能把业务和完成业务没有那么相关的所有能力都下降到基础设施的运维团队，这是一直在思考的一个问题。在演练中经历过几代：

• 第一代是云计算。它把基础设施的这个东西从业务侧翻下来，业务人员就不需要再去关心基础资源。

• 第二个是容器和推广安全。运维这件事情变得更简单后，开发人员就不会关心这一层了，但是 SDK 侵入这件事对于业务开发员来讲，就是一个侵略。

• 剥离的问题也是在 Service Mesh 这个技术上来做的。它把所有运行态的治理能力、流量管理能力全部从用户侧、开发测的 SDK 过滤出来，而不再需要去做 SDK 的生产。这个也就意味着用了 Service Mesh 之后，用户是不需要做语言绑定，也就解决了刚才说的那个模糊地带很难解决的问题。这个可能对于现在在用 Spring Cloud 的企业都可以考虑，这个东西会不会成为替代掉现在任何一个单语言的微服务框架技术。

• 再往后讲其实还有一种依赖。比如当你需要一个中间件时，你一定要去做选型，这需要业务开发人员的配合。单独的一个理念就是我能让你把这个中间件下沉到基础设施。到这时所有的业务开发人员真的只需要关心业务代码，所有的这些基础设施就全部下载下来，是不断地去让基础设施能力更加丰富，来满足上层业务这样一个自主发展趋势。

3、Service Mesh 的剥离了服务和流量治理能力

Service Mesh 就是服务治理、流量治理框架。在原有的设计里，它属于业务的一部分，上面是业务代码，下面是这些能力。Service Mesh 能做的最重要的一件事，就是把这些能力剥离到 Istio 里来，业务带中就是纯业务功能，边界很清晰，服务治理、流量治理框架由运维团队来服务。

上层所有的语言和下层所有的基础设施，通过一层层统一的接口进行抽象。不管用 Rock MQ 还是 Rabbit MQ，对上层业务是无感的，它会给上层业务一个统一抽象的 API ，而且是 HTTP 或者 gRPC 这样的一个企业的 API 。开发人员不再关心底下到底是什么，进一步地让开发人员和下面进行解耦。

目标理想架构

最后真正理想的框架是什么样的呢？开发人员和业务人员边界到底在哪呢？我们画了一个理想的框架。

• 对上层来讲的话，我们会期望不同的业务单元可以选择不同的语言和框架。比如说有的是单体，有的是 Spring Cloud 或者 Dubbo，从调用层面来讲，完全是互通的，可以接入 Service Mesh 的技术，或者现有的这个框架

• 对于中间的容器服务，会让业务不再感知具体的中间件。

• 再往下是容器服务，作为整个位置的一个支撑。

• 右边是它的支撑体系，如微服务会带来一些复杂性，需要通过可观测性监控你的 Devops 的流程 CICD 或者安全性支撑。

这时候就可以让你的业务开发人员用他喜欢的语言去开发他想的业务，而不再关心这些所有的基础设施团队需要去解决的问题，这其实也是从应用框架或微服务上来讲的最终目标。

微服务化实践案例

1、微服务引擎（MSE）

我们去做微服务时会碰到一些问题，有一种解决方式是进行全国自建，这对于一些企业来说工作量比较大。阿里云会把其中一些共性的东西变成产品来提供。比如说你去搭建一个微服务，你需要配置功能、网关、治理能力，阿里云会用一个产品的形态直接给到你，不用自己建了。就好像我原来是自建的，现在是影响他启动的数据不一样，那对于你原来是自建的 Nacos，现在就是一个云产品的提供。

2、畅捷通

另外有一个案例，畅捷通是用友的一个全资子公司，这个客户专门做小微企业的财务系统。它全面上到阿里云，把自己的财务系统全部变成 SaaS 化的模式交付。大家都知道传统的财务系统 ERP 等都是偏单体的架构，畅捷通的整个财务系统也经历了从虚机到 K8s 的转变。一开始，是从虚机跑了微服务，后来从虚机转到了 K8s。整体来看，在云上的规模非常大，也服务了非常多的客户。

从容器化到微服务这样一个过程，它基本上也是这个难题，希望提升系统微服务治理能力和监控能力，在新业务快速上线、频繁的版本迭代中确保系统的稳定健壮。它一开始用了阿里云的一些项目，后来想把它变成 Spring Cloud，现在是两个结合在一起使用。

3、阿里云服务网格 ASM

服务网格这个产品技术大概是在去年发布用于生产，但实际上真正在生产上落地的企业还在不断地去尝试。阿里云也一样，通过一个产品去降低用户使用 Service Mesh，因为 Mesh 这件事情对于很多企业来讲只是个技术概念，企业要的是一种多元微服务的能力，而 ASM 服务网的产品会帮助用户去做服务网的一个落地。

4、商米科技通过 Service Mesh 完成微服务化

上海的商品科技是做各种物联网设备的，它碰到的问题是内部技术框架和语言体系比较复杂，各种各样的语言和服务都遇到了困难。它希望对这些业务能够进行一个统一的流量管理，包括发布时的流量管理，所以它最终选择用 Service Mesh 这个技术去解决多元微服务。从这些业务价值的数据可以看出，比如更新迭代、异常排查、控制面资源成本都有了较大的优化。

以上就是关于微服务的演进和实践分享，希望有带给大家一些微服务的体系的梳理。