展望架构的2023：Serverless 兴起，下一代微服务的雏形和标准化开始呈现

作者：褚杏娟

2022 年，架构领域发生了哪些值得关注的事情？一位架构师必备哪些技能？2023年哪些架构趋势需要掌握？Nacos 和 MSE 创始人、阿里云高级技术专家彦林做客 InfoQ 直播间，为我们带来 2023 年的架构师发展指南。

Question：今天的主题是 2022 年架构发展的亮点，以及架构师成长的路径。我们请到了老朋友彦林，先请彦林给大家打招呼。

彦林：我是来自阿里云的彦林，很荣幸有机会跟大家一起聊聊今年架构的一些趋势。我从事软件开发 10 多年，赶上了在阿里做百万实例架构的演进历程，包括最近 3 年帮助阿里云从自建 IDC 全部搬到了公有云。我也有幸参与到阿里巴巴中间件产品的开源，随着开源的影响力越做越大，我们也把开源的一些技术解决方案，使用产品化的模式，通过阿里云以云产品的形式对外输出。

目前我主要在阿里云负责微服务产品相关的开发工作，也非常高兴跟大家聊一聊技术架构的趋势演进。

详解架构技术发展

Question：今年架构领域有哪些比较重要的进展和亮点？

彦林：我经常跟客户聊架构选型相关的事情，今天以我的视角讲讲我对架构演进的理解。大家都会讲到不同类型的架构，比如单体架构、微服务架构、Serverless 架构以及低代码等等，在不同的场景怎么去选型？哪些场景适合哪些领域？现在每个领域的业务成熟度是什么情况？

面对这几个问题，我们会简单进行分解。首先，单体架构现在基本成熟了，各个语言包括 Java、Golang 做单体开发都比较成熟。所以在过去一年 Java 做了一些变化，为了更好地适应云原生，它会通过 GraalVM 技术、Spring 3.0 等关键大版本的发布，让 Java 变得更轻量、启动速度更快。其他的语言比如 Go，天然就是云原生的语言，所以它在做单体分布式开发的时候，整个启动速度都比较快，相对会比较成熟一些。

第二是微服务。微服务在过去一年发生了一些变化。在最早的时候，一些互联网大厂在使用微服务，但是去年看到各行各业开始更加深入地去使用微服务。疫情给整个社会数字化进程带来了一些推动，包括数字化系统的迭代在变快、复杂度在变高，因此微服务加速渗透到了各行各业。在微服务架构的选型过程中我们也可以看到，由于 Spring Cloud 成熟度已经很高、Spring Boot 3.0 最新的架构往前演进，Java 在解决云原生应用的一些启动速度和加载速度问题。

我们还看到另外一个非常有意思的现象：大家都在往 Go 语言发力。微服务在 Go 语言的发展趋势在变快，这标志着今天 Go 语言在做微服务分布式开发上进入了一个爆发阶段。

最早以阿里为代表的一些互联网企业，采用 Java 较多，但是随着传统厂商慢慢进入数字化演进过程，他们就从 C++、 PHP 开始向 Go 转型，而且转得速度在变快，包括阿里微服务在这方面也做了一些布局，这是今天后端开发方面的一些变化。

在前端，Node.js 现在也越来越成熟。一般在架构简单的时候，可能采用前端网关直接挂后端应用的方式。随着客户规模变大，就会用 Node.js 做代理层，这样有利于前后端的分离，让前端的整个迭代速度更快。在阿里内部分中台、后台、前台分三层，后台应用需要稳定性，中台需要支撑效率的可复用性，前台需要业务跑得足够快，这方面微服务也比较成熟了。

最后讲两个技术趋势。

第一，Serverless。2022 年可以被认为是 Serverless 元年。阿里云在 2022 年 11 月份的云栖大会上发布 Serverless 战略，介绍了一系列 Serverless 产品，从整个计算、存储、网络，到上层的函数计算、Serverless 应用引擎等产品，到数据库的 Serverless 化，演进速度都在持续加快，2023 年将持续高速增长。

在 Serverless 架构方向引导之下，事件驱动也在慢慢变成主流。一个个函数之间通过事件驱动模式进行解耦，架构的容错率会非常好。我们可以看到一些新兴的中小型业务、偏前台的业务，包括计算型的任务，都大规模采用了 Serverless 架构。

第二，低代码。低代码现在每年的增长速度有 40%，速度很快。阿里最早推出的产品叫宜搭，基于行业性的解决方案，具备行业属性、业务属性，现在也比较成熟。

从技术上来说，低代码是一个趋势。举例来说，它会通过一些图形化的拖拉拽，将模块进行组装，对于业务比较简单的场景，开发效率还是比较高的。低代码和无代码这种拼装的模式，可以让更多的人参与设计数字化的建设过程。阿里在微服务上也做了一些事情，比如开源了云原生应用脚手架（https://start.aliyun.com/），能够帮助开发者快速拖拉拽，把一个依赖包快速组建起来，这也是低代码的一种模式。

相信随着整个技术基础架构中间件稳定成熟之后，在 IaaS、PaaS 之上，基于更高层的低代码会成为未来的趋势。从业务方面说，各个行业的 SaaS 会成为一个趋势。

微服务：真的被滥用了？

*Question：微服务每年有差不多 20% 以上的增长。今年，微服务的增长趋势如何？

彦林：从三方报告、阿里、官网以及 Star 上的数字来看，今年的增长速度是 15% 左右，比去年同比增长速度稍微慢了一点点，和疫情有很大的关系，但其实绝对数字差不多。在中国，每年采用微服务架构的有几十万家企业，虽然增速变慢了，但是每年采用微服务架构的绝对数字依然非常大。另外，整个技术热度也在持续上升。

Question：今年有一个争议点，马斯克接手推特之后，吐槽过推特的微服务架构，说运行要调用 1200 多个 RPC，但其实真正需要的微服务不到 20%。其实像 GitHub 前 CTO 也提到过微服务滥用的问题。这就会引发大家一个思考，今年的微服务真的在被滥用吗，您怎么看？

彦林：从我们的角度看，无论是微服务还是单体应用，都是一个技术选型。随着公司业务的发展、需求不断增多，业务变得更复杂，我认为更多是管理和产品的问题，不是技术的问题，我们要把技术和业务分开。

“什么时候采用微服务”是技术人要回答的，比如企业只有一个业务系统，其实是不需要上微服务的。那一个公司几十号人、几十个子系统，还要单体应用吗？效率能解决吗？架构其实是一个拆分，服务规模大了后架构师在做架构的时候，就会从两个方向来解决业务的复杂性问题。

针对有几十个研发同学、几十个子系统的情况，就需要做一些分支，这个时候用微服务的投入产出比会比较高。单体到微服务有一个交叉的技术曲线，可能是 10 个应用、10 个子系统，达到拐点之后采用微服务确实效率比较高。但在没有达到拐点时，提前采用微服务可能会发现一些问题，随着业务规模增大，微服务后面才慢慢释放红利，这是一个技术选择问题。

总的来说，没有最好的，只有最合适的。当系统的复杂度达到 10 个研发、10 个子系统以上，可能就适合用微服务了；当达到 100 个研发、100 个子系统以上，可能就要把公共服务抽成一些中台服务去做，这是架构师基本的服务化、分层设计理念。用这样的理念设计后，我们的组织架构也随着技术架构去调整，让业务尽可能跑得快。

Question：传统项目准备使用微服务，在转型时主要从几方面去转？

彦林：互联网的第一波，包括云的第一波、数字化的第一波已经过去了，第二波就是传统客户包括政企。大部分客户会问，CTO 应该怎么决策？最佳的解决方案是：第一，新老架构前面都加一层网关，用网关将老的服务路由到老的单体架构上面，新的架构采用微服务，让新的业务先跑到新的架构上，老的架构慢慢往前演进，这是一个长期的过程。

第二，新老架构之间也可以通过网关进行代理。有许多厂商向传统公司提供服务，多个服务之间怎么进行快速组装、相互调用健全，怎么组装更高级、更丰富的上层服务？都是通过网关快速做 API 的聚合与整理等，这都是这些传统企业的诉求。通过网关可以把新老系统、多个 ISV 系统全部互联互通，这是做现代化架构演进或者云原生架构演进最快的模式，让新的架构、新的模式讲清价值、慢慢迭代，把老的架构进行收敛。这就是我们现在看到最好的一种模式。

Question：马斯克说推特在一些国外地区会比在美国的运营速度要慢很多，产生速度差异的原因是什么？

彦林：从理论上来说大家应该都是一样的，但是当组织离核心业务、权力机构远的时候，很多的组织效能会做一些弱化的事情。我认为更多的是组织的问题，技术的问题并不大。

其实我们也能感觉到，技术和产品有时候有一些博弈，产品总想让技术多做需求，但是需求越多系统就越复杂，随之依赖越多、链路越长，风险也就越大。

我记得阿里巴巴在 2012 年左右，其实链路也很长、很复杂，所以我们当时抓体验，所有的请求要在一秒钟之内做完。为此，架构做了很多改变，比如分布式架构分为核心链路和非核心链路，核心链路我们用 RPC 微服务同步解决，非核心业务通过异步发消息去解决、通过事件去解决。这样做稳定性、扩展性会有大幅提升。

Question：微服务的注册中心跟 K8S 云原生是不是有些冲突？

彦林：这个问题非常专业。其实没有冲突的，有一些交集。因为容器和微服务是正交关系。注册中心是微服务的存储，etcd 是 K8S 的存储，是分层的。

云原生架构：容器和微服务搭配提效

Question：云原生架构的技术体系是怎样构成的，怎样才算是云原生架构？

彦林：最早提出云原生概念的是一家小公司，他们以 Spring Cloud 为理念去宣传了云原生技术。在之后 3-5 年的发展过程中，CNCF 重新定义了云原生，大家有了主流的认知，即采用了容器、微服务和不可变基础设施这些关键技术栈的，我们就认为是一个云原生架构。

在做架构演进和变化的过程中，为什么采用云原生架构？云的本质是弹性，每个公司都有低峰和高峰，怎么更好地利用云的弹性、让自己的资源成本和研发效率得到进一步提升才是本质问题。云原生架构比如微服务，解决的核心问题是研发效率问题，因为业务规模上去，复杂度提升，所以需要微服务这样解耦的方式去解决研发效率问题。容器解决的是运维效率，它可以让运维效率得到空前释放，使运维从体力活变成了技术活。

容器和微服务搭配使用的原因在于：第一，一个巨大的单体应用没有调度空间，只有把资源打碎、拆分之后，才可以充分使用资源池，即业务拆分合理之后，能够让开发者更好地调度、提高资金利用率，这是微服务对容器的一个好处；

第二，使用微服务后，运维可能会从早期的 1 人运维变成 10 人运维，成本会上升。而容器能帮助微服务解决运维的问题，让每个开发有工具自己写代码自己运维，把整个生命周期管理起来。因此，容器帮助微服务解决了最核心的运维痛点。

总的来说，容器和微服务做搭配，一个解决运维效率，一个解决研发效率。容器帮助微服务解决了最大的运维痛点；微服务把资源打碎，让容器充分地进行资源调度，提高整个资源利用率，所以它们是相辅相成的技术。

Question：云原生网关很热，能展开聊下选型么？

彦林：传统的网关在云原生时代确实遇到了一些挑战，这些挑战在于传统的网关包括最早的单体架构，在不用容器的时候，它的调度和发布都不频繁，因此发布过程中有一些流量的损失问题，但也不大；老的业务，不是端到端的业务、视频的业务，对稳定性要求也不是特别高。

但随着数字化深入，云原生技术的采用就会引发一些问题。第一，对整个连接的稳定性、规则热更新有实时的要求，对网络稳定性的要求会更高。第二，云原生背后隐藏了一个标准化的事情。在云原生时代，未来网关的 API 标准到底是什么？其实 K8S 通过 Ingress 的 API 定义了网关的标准，这就解决了技术选型的一个痛点。第三，多语言的扩展性。传统的网关在语言扩展性以及热更新上有很大区别，所以面对未来的云原生网关，必须解决掉这些问题。

我们认为，云原生网关可能是代表下一代网关的技术。不仅阿里巴巴开源 Higress 进入这个领域，CNCF、APISIX 等都在加速这个过程的发生，如雨后春笋般地进入云原生网关领域。大家也意识到今天在微服务里，网关是非常重要的角色。云原生网关已经形成了一个技术热点，相信在 2023 年会得到高速发展。

Question：IaaS、PaaS 和 SaaS 的商业模式哪个更好？

彦林：当前来看，IaaS 是技术门槛最高、投入产出比最高模式，需要规模化；PaaS 是技术门槛居中、投入产出比中等模式，需要可复制、解决服务效率问题；SaaS 目前核心是看业务领域创新，如果能搞出类似钉钉的 SaaS 平台，价值是巨大的。未来机会在 SaaS。

”降本增效“对架构有影响吗？

Question：今年各大厂奉行的宗旨是降本增效，这种内部政策导向的变化会对企业在架构选择上产生什么影响吗？

彦林：其实有影响，包括正向和负向的。如果一个企业真的运营不下去了就不会再为未来投资，如果要投资未来，技术架构就要演进，公司基本上都是要降本增效。采用云原生架构之后，复杂性略有上升，但是多家数据也表明成本至少下降 30%。因为容器解决了成本效率、运维效率的问题，微服务解决了研发效率问题。

但是最近我在想一个事情，云不断地把算力成本降下来了，但是人力成本却一直在提升。很多人可能在关心资源成本，但其实大部分公司现在应该更关心研发效率、研发成本，因为人力成本在不断提升，算力成本在不断下降，杠杆的拐点已经到来了，这就是为什么越来越多的人采用微服务的原因。首先，云原生架构能降本，这是一个事实；第二，提升人的效率其实也就是降低人力成本。

Question：云原生虽然降低了成本，但是却提高了复杂度，我们应该怎么去平衡？

彦林：这其实很简单。我们要相信后浪能推倒前浪，现在的新人很多都对云原生有了解，新人的学习能力和知识储备都是够的。而对于我们这些老程序员来说，不跟上时代确实会有压力。技术虽然有门槛，但是通过 2-3 个月的学习，突破技术门槛和拐点之后，就能柳暗花明，充分利用工具的优势。

当然，比如在做一些变革和技术架构升级时，一定会有很多人阻碍你，因为大家都喜欢不变。但是这也意味着不能带来任何变化，为了做降本增效、技术架构先进性就必须要变，而在变的过程中自然有一些人会感到不适，但这都是短暂的，当你迈过拐点、享受到红利之后，就自然而然地会加入到推动技术浪潮的过程中。

架构下一年发展趋势

Question：下一年架构领域可能会有什么趋势？

彦林：在微服务领域也会发生很大的变化。比如大家可能觉得微服务很先进，云原生现在虽然讲得很火，一些掌握先进技术的大公司、掌握话语权的人在使用，但今年全世界的采用率可能也就 5% 左右，普及度远远不够，这是一个现状。

标准化上，我们可以看到云从 IaaS 到 PaaS，再到容器（当时定义为 CaaS Container as a Service）、微服务都在做这件事。海外也有一些公司比如 Google，也想通过服务网格去定义微服务的标准，但目前大家得到的一致结论是，它不是未来的标准，未来微服务的标准还在定义的过程中。

整个行业在一起定义下一代的微服务体系。相信在 2023 年，下一代微服务的雏形和标准化会慢慢开始呈现。我认为 2023 年不仅是 Serverless 的元年，也可能是下一代微服务到来的前夕。

另外说到云原生网关，其实云原生网关是阿里巴巴在 2022 年提出的，也快速得到了行业上下游的响应，因为相对于传统的流量网关、微服务网关、API 网关，云原生网关定义了一个新的领域，是一个新的、云时代定义的下代网关雏形。其实阿里在 2018 年就有了云原生网关的雏形，我们经过 3 年的打磨才有的一个雏形。阿里做网关做了十几年，云原生网关领域也做了 3、4 年，基于之前的积累，我们才去尝试定义云原生网关领域，帮助传统企业在云原生时代做架构的演进，也帮助选型微服务及云原生架构的客户更好地享受云原生的红利。我相信在微服务领域，统一控制面、标准化和云原生网关会得到空前的发展。

另外，Serverless 目前是阿里云的战略级项目，今天它的标杆和可复制的场景已经非常多了。所以，事件驱动加上 Serverless 的架构，会在未来一年得到非常好的发展。

编程语言上，目前来看 Go 语言真的挺有希望。我们拜访很多大客户，Golang CPU 的利用率能比企业 Java 高一倍，这个数字还是比较可观的。Go 语言作为微服务或者云原生的一个主导语言，未来会得到很好的发展。

Question：微服务和 Serverless 会有冲突吗？

彦林：单体应用、微服务和 Serverless 其实不是互斥关系，它们都有各自的场景。单体应用是相对通用的一个技术架构，微服务经过多年发展目前得到了行业的广泛认识，只是说有一个拐点决定了哪个时候采用它最好。Serverless 是一个架构选型，它是一个新技术，有它的适用场景。比如偏前端、简单一点的比如小程序，偏计算性的任务适合跑 Serverless；所以这些技术有各自的适用场景，存在互补关系，而不是互斥关系。

职业成长

Question：有观点认为，架构师关注技术的广度比深度更重要，您如何看待这种说法？

彦林：从整个学习习惯或规律上来看，一般都是先有深度再有广度。只要深入地把一个技术、一个语言、一个架构吃透，做其他的很多事情都会触类旁通。如果做任何事情都蜻蜓点水，就很难把一个事情做深。我建议工作的前三年一定要把技术的基础先打牢，这对架构师的成长会比较好。在早期可能 80% 是深度、20% 是广度，随着技术成长足够了，这个比例再不断去调整。另外，对技术的热情也一定要有。

Question：架构师是一个长期主义的事情，不可能在 1-2 年就完成一个蜕变？

彦林：是的。架构师是站在开发、产品、运营、技术等最前面的人，对人的综合素质要求比较高，一般在阿里内部架构师的是点线面体的发展规律。

第一，最早进入这个领域之时，最基本的要求是“见问题解问题”，掌握一门好的语言，能修复 Bug，但是到后面大家的发展方向、成长速度会不一样。

第二，从点到线。这对开发的抽象能力是一种考验。当每天面对很多问题的时候，能不能把问题抽象成需求，横向拉通所有问题做一层抽象，这很考验架构师的思考问题的能力。

第三，从线到面。比如把所有的需求聚集成了 10 个需求，再从整个产品角度，把需求砍下 4-5 个，要知道做什么不做什么，有产品视角。

第四，从面到体。当技术问题解决完之后，要考虑哪个投入产出比比较高，怎么拉通研发团队的前端、后端、产品、技术、运营，做一个很好的技术排期，最快拿到技术结果。这里就涉及到人的协同与沟通，但并不是说沟通能力好就能当架构师，还要懂得画图纸。其实还是要以产品为核心去和上下游沟通，因为用技术语言无法和运营、产品对话，也无法和客户去对话，至少要能抽象到产品，用产品的语言才能和客户对话。

走到“体”这一步后，解决技术、产品、协同以及人等问题的能力基本上会得到一个全面的提升，至少需要 5 年的积累。所以大家不要急，一步一个脚印往前走，只要你有这样的技术情怀和追求，一定可以搞定。

我认为有技术情怀的人才能当架构师，因为我发现很多人随着工作时间增多，慢慢地淡化技术变成了管理者，变成了 PM，这就会有问题。因为如果你画的图纸不合理，最主营的技术业务不行，就会把所有的人拖下水，这就很危险。

Question：如何理解 Serverless、低代码等对架构的影响，它们会降低对架构师的要求吗？

彦林：我认为是不会的。现在有 10 种技术选型，最早大家写代码的时候有 20 种设计模式，你只有充分掌握哪个工具适合哪种场景，才能画出最好的图纸、做出最适合的架构，只不过早期没有这些技术和工具时，做架构需要更多的思考。而今天在市面上有很多主流选择，在选择过程中，如何根据自己的业务选择最好的架构和技术，这对架构师是一个考验。

另外，很多人做技术架构师、业务架构师，要对业务很熟悉。微服务的主要挑战不是技术有多难，而是你的业务拆分是否合理。很多人做了微服务之后拆分不合理，就会导致代价变大。所以，对领域模型要有更好地了解，有架构师底蕴，理解业务模型、技术模型，这样的人才能做好一个架构师。