一个架构师在 2023 年需要掌握哪些“必杀技”？

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

目前我主要在阿里云负责微服务产品相关的开发工作，希望后面有更多机会交流。今天晚上主要跟大家聊一聊技术架构的一些趋势。

彦林：我在阿里云每天见非常多的客户，经常跟客户聊架构选型相关的事情，今天以我的视角带大家做一个简单的回顾。一般找我们聊架构，大家都会讲到不同类型的架构，比如单体架构、微服务架构、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 的产品，从整个计算、存储、网络，到上层的 FC 产品，一直到数据库的 Serverless，演进速度都在持续加快，相信在 2023 年速度会更快。

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

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

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

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

彦林：重构不是按照时间决定的。重构的第一个原因是迭代效率变低了，比如代码的研发效率越来越低，严重阻碍了它的迭代速度。第二个原因是稳定性，比如开发者修改一 Bug 引出了多个新 Bug，代码变得很复杂了。第三个原因是扩展性不足，性能无法满足要求，比如做大型运营活动时，单体无法满足需求，企业就需要做一些分布式的改造，把主链路和分支链路分开，做更好的扩展性和弹性。

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

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

“什么时候采用微服务”是技术人要回答的，比如企业只有一个业务系统，其实是不需要上微服务的。那一个公司几十号人、几十个子系统，还要单体应用吗？效率能解决吗？架构其实是一个拆分，服务规模大了后架构师在做架构的时候，就会向两个方向去解决业务的复杂性问题。针对有几十个研发同学、几十个子系统的情况，就需要做一些分支，这个时候用微服务的投入产出比会比较高。单体到微服务有一个交叉的技术曲线，可能是 10 个应用、10 个子系统，达到拐点之后采用微服务确实效率比较高。但在没有达到拐点时，提前采用微服务可能会发现一些问题，随着业务规模增大，微服务后面才可以慢慢释放红利，这是一个技术选择问题。

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

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

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

彦林：从理论上来说大家应该都是一样的，但是当组织离核心业务、权力机构远的时候，很多的组织效能会做一些弱化的事情。我认为更多的是组织的问题，技术的问题并不大。马斯克只是说了一个现象，被一些人拿出来做新闻热点炒作而已。

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

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

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

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

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

容器和微服务搭配使用的原因在于：第一，一个巨大的单体应用没有调度空间，只有把资源打碎、拆分之后，才可以充分使用资源池，即业务拆分合理之后，能够让开发者更好地调度、提高资金利用率，这是微服务对容器的一个好处；第二，使用微服务后，运维可能会从早期的 1 人运维变成 10 人运维，成本会上升。而容器能帮助微服务解决运维的问题，让每个开发有工具自己写代码自己运维，把整个生命周期管理起来。因此，容器帮助微服务解决了最核心的运维痛点。

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

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

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

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

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

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

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

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

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

彦林：会有一些代价，Go 偏系统一些,Java 偏业务一些。根据不同分层选择合适的。

彦林：在微服务领域也会发生很大的变化。比如大家可能觉得微服务很先进，云原生现在虽然讲得很火，一些掌握先进技术的大公司、掌握话语权的人在使用，但今年全世界的采用率可能也就 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 语言作为微服务或者云原生的一个主导语言，未来会得到很好的发展。

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

彦林：在互联网中，虽然我们也叫技术专家，但实际上是架构师。举例来说，有人盖房、有人设计图纸，架构师是设计图纸的，对于一家网站来说是设计网站骨骼架构的。做架构师要有设计架构的能力、画图的能力，比其他所有技术实践的人要先行一步。

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

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

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

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

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

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

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

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

彦林：一般只有大厂有质量工程师角色，核心协同开发、测试、安全做好产品或者版本质量，宣传质量文化。

彦林：因为后端技术架构更复杂，能更全局的技术架构。

彦林：不一定很强， 但是需要有一定的技术积累，不然比较难与程序员对话。

彦林：积累深度可以看一些 paper、专利行业的动向，这在子领域里会有很多上下游的竞对、海外竞对的分析；积累广度可以看 InfoQ 以及海外架构师等最顶级的技术媒体信息，也可以看大厂分享的公众号，因为大厂有很多场景，并会根据它的场景做很多技术分享。

之后大家也可以去逛一逛线下的技术 Meetup 以及行业的论坛、分享会等等，参与开源共建，相当于跟全世界一流的工程师一起工作。在和别人沟通的过程中，也能了解到好的技术以及别人在思考哪些事情，这也是学习技术先进性、前瞻性的一个很好的模式。在参加各种论坛、与开发者相互碰撞的过程中，可以很好地帮助你进行架构规划。比如和大厂的人沟通，你可以了解他们怎么一步步走过来的，还可以根据自己公司的发展情况一步步向前演进。如果你已经在大厂，就可以深入想一些比如如何代表中国的技术，在今天的开源、技术影响力、先进性工具上，给世界做一些贡献，打造一些世界性的产品等问题。

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

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

如果你对本文感兴趣，欢迎在文末留言，或加入 InfoQ 写作平台话题讨论。后续，迷你书、专题将集合发布于 InfoQ 官网，登录 InfoQ 官网注册并将 InfoQ 添加进收藏夹，精彩不错过。更多内容可点击查看系列专题文章。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！