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

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

彦林：我是来自阿里云的彦林，很荣幸有机会跟大家一起聊聊今年架构的一些趋势。我从事软件开发 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，代码变得很复杂了。第三个原因是扩展性不足，性能无法满足要求，比如做大型运营活动时，单体无法满足需求，企业就需要做一些分布式的改造，把主链路和分支链路分开，做更好的扩展性和弹性。

微服务：真的被滥用了？

主持人：您在去年的分享中谈到，微服务每年有差不多 20% 以上的增长。今年，微服务的增长趋势如何？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

社区：性能上升了，对于复杂业务，Go 相比 Java 开发维护效率会下降吗？

彦林：会有一些代价，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；对一些大型的比如阿里巴巴大型交易系统 Serverless 是不适用的。所以这些技术有各自的适用场景，存在互补关系，而不是互斥关系。

最新经典文章，欢迎关注公众号

原文链接：
https://www.infoq.cn/article/UCaTitOegreb3NGiX24m

感谢分享