2022年云原生架构趋势解读

软件架构发展至今，经历了从单体架构、垂直架构、SOA 架构到现在的以微服务、服务网格等云原生技术为主的演变过程，云原生技术发展势不可挡，老生常谈的“云原生”将依然会是未来的热门话题。而且随着数字化转型加速，企业对于云的使用将会达到新的水平，云原生架构和云原生应用也将会持续迭代演进。

那么在云原生等技术的加持下，2022 年的架构领域有哪些值得关注的趋势？云原生如何撑起架构的未来？本文转载自 InfoQ 架构头条，阿里云 MSE 负责人李艳林（彦林）、阿里云高级技术专家李云（至简）一起做客 InfoQ 视频号，分享云原生架构领域最新趋势。

01 软件架构演进过程

InfoQ：软件架构经历了从单体架构到 SOA 架构再到后面以微服务云原生为代表的架构形态，中间有哪些关键的节点？

至简： 讲今天的云原生我觉得我们还是需要回顾一下历史，去了解一下它是怎么一回事。

• 2000 年的时候，还没有虚拟化的概念，大家看到的都是物理机；

• 2001 年 VMware 横空出世，不过这个时候交付的还是一个虚拟机；

• 之后 2006 年亚马逊推出 IaaS（基础设施即服务）平台 AWS，这个时候的思路已经是把 CAPEX（资金投入成本） 变成 OPEX（运营成本）。就是我不需要再买一大堆机器，而是用到了再去云上买；

• 2009 年 Heroku 提出 PaaS，这个时候不再是用虚拟机来交付，变成了 Buildpacks，也开始了有了容器化的概念，还有 12 要素应用程序的一套规则；

• 2010 年，出现了 OpenStack，它其实是通过开源的方式来做 IaaS，目的是跟 AWS 做竞争，它构建的 building block 还是一个 VM；

• 2013 年，Docker 的出现带来了比较大的变化，这个时候交付就变成了容器。

今天讲的 Cloud Native 最早由 Pivotal 提出，后来由 2015 年成立的 CNCF（Cloud Native Computing Foundation）进行了定义。

其实整个过程中我们能很明显的看到一些变化，从大型机、Server 到 VM、Buildpacks，再到容器，隔离的单元也是越来越小，从很重很大到后面通过微服务软件架构把它变得很小。这中间最重要的目的是为了做解耦。大家可能对 Cloud Native 有很多想法，但我觉得关键的一点就是 Cloud Native 的核心是什么，从我自己的认知来看，我觉得所有的软件都有一条至理名言，我们叫做分而治之，也可以叫做解耦，或者高内聚低耦合。通过不断的解耦变成微服务，让整个交互更加敏捷。而不是像以前单体应用耦合在一起，很难协同，很难交付。

Cloud Native 还有一个重要的要素就是 no lock-in，即避免技术锁定。从 CNCF 定义标准说起，CNCF 不会直接说某个东西是一个标准，他们会认为这个东西是一个关键的组件，并表示这个组件是被广泛采纳的，也是我们 CNCF 认可的。这样的话就会有更多的人去用，也知道这个软件会有长期的维护，自然而然它就会标准化，而这种标准化带来的好处就是 no lock-in，我觉得可以从不同的维度去理解它。

从厂商的角度来讲，你可以灵活的选择不同的云供应商；另一种就是对于工程师讲，你在 A 公司的平台上做业务开发，很有可能离开 A 公司后就没有办法施展了，no lock-in 带来的好处就是不会把员工锁定在一家技术公司，只要你掌握的是 Cloud Native 技术，你所从事的岗位就可以在人才市场上做流通。

彦林： 刚才至简是从整个软件行业的角度去讲的，我从产业角度简单说一下我的理解。

现在的云原生技术，包括软件架构的形态跟互联网 1.0、2.0、3.0 是有很大关系的。最早互联网 1.0 时代都是静态页面，这个时候多数网站承载的内容比较简单，单体应用基本上加 CDN 就能解决；随着互联网进入 2.0，各种门户网站、Web 应用涌现出来了，也开始有交互了，更多的交互、更多的渲染对技术的整体要求变高了，单体应用已经不能满足日益复杂的业务需求，软件变得复杂，场景变得复杂，人力协同数字化程度变得越来越高，这个时候就进入了 SOA 和微服务的时代；之后整个产业又发生了一个比较大的变革，就是移动互联网，第三个时代的到来对实时性提出了更高的要求，包括“主动获取、被动推送”。信息的获取量、实时渲染量更大，整个 IT 系统在这个阶段也是爆发性的增长，对数字化系统要求更高。

随着整个云计算的发展，其实更多的随着云的发展，在 2015 年左右的时候，按照刚至简说的，通用化和标准化这个事情基本上在逐渐的形成，在 2015 年之后，行业中的关于各种的容器化，比如 Docker、K8s 包括 Spring Cloud 都是在这个时代陆续的产生，大概是这么一个情况。

InfoQ：经历了这么多年软件行业和产业的变化，云原生架构现在发展到了一个什么样的阶段呢？

至简： 我觉得今天来看的话，可以说云原生架构已经被各行各业广泛接受。

以 Service Mesh 为例，服务网格现的接受度在过去一年有很大的增长。讲云原生架构之所以拿 Service Mesh 来举例，是因为云原生整体的概念已经被广泛接受，比如像云原生下的 K8s 毫无疑问已经是一统江湖的局面，而相比之下 Service Mesh 是偏晚的。Service Mesh 曾经被质疑的问题比如性能等，到今天已被逐步接受，接受并非代表性能问题被完全解决，而是大家知道如何扬长避短地用好。

今天很多企业考虑的问题是我如何去落地云原生这个技术。我觉得云原生不管是理念也好、设计模式也好，它是一个组合在一块的。我不会简单的说云原生发展到整个历程的 50% 或 60%，不会用这个思维去看待它，而是说我们能不能先上到云原生，随着云原生技术的演进，我也能跟着这个节奏去往前走。

我觉得好的地方是整个大众对云原生技术有很好的认知和理解，然后云原生整体趋势也是乐观和蓬勃发展的。

彦林： 我讲一下我对这个事情的理解，首先从软件技术上分层去讲的话，今年大家可以看到，包括阿里云和其他所有的云都在讲容器 Anywhere，其实容器已经成为了一种基础设施，随着未来三到五年的发展，保有容器的量可能比单独跑在 ECS 上的要多。

从微服务角度去看，因为我们最近在做两年规划，大家应该也看到了一些关键的数据，比如中国程序员的平均工资多少，平均工资那就是人力成本，其实已经远远高于 IT 的算力成本和资源成本。容器更多解决的是资源调度成本、运维成本，微服务更多解决的是研发成本、协同成本。因为大家在一个代码上去共建人太多的话，效率是非常低的。所以第一个面临的问题就是人力与效率越来越重要，而且随着整个行业竞争的加剧，你跑得快就有优势，跑慢了就会错过这个机遇，互联网行业就是“快鱼吃慢鱼”。

我在关注的数据中还有一个比较新的事情是整个程序员的年龄分布，90 后已经成为构建数字化经济的核心中坚力量，他们的协作模式和工作风格与老成员已经不太一样了。他们喜欢更敏捷更独立的协作模式，微服务其实就是更符合他们的一个协作模式。

目前从整个行业来看的话，微服务已经成为一种主流的选择。而且我们从另外的两个数据也可以看到：第一个就是从整个行业看微服务每年有差不多 20% 以上的增长，就是说整个行业每年有数万家企业在做微服务的改造；第二个就是除了互联网公司进行容器化和微服务改造，许多传统行业，比如零售、医疗、金融等等，陆续开始进行数字化升级，微服务在整个社会有了更广泛的运用空间。

从另外一个技术角度来看，不管是单体应用、微服务，还有未来的服务网格、Serverless 等，都有自己的应用场景，今天可能是因为人力成本的提升，整体年轻化对协作要求更自由、更独立，容器跟微服务在这个大趋势下越来越重要了。

InfoQ：刚才我们聊的过程中也看到了不少观众表示受认可的情况，也提到了一些落地的案例，两位老师有没有相关落地案例分享？

彦林： 落地案例其实非常多，我简单举几个可以对外讲的例子吧。

来电科技在前几年就完成了整个云原生的技术改造，容器化、微服务都做了，在研发效率、资源利用率上都得到了比较大的提升。现在他们已经走到了云原生的第二个阶段，当下比较大的问题是服务治理，比如优雅上下线、无损下线，同时也会面临高可用的问题，比如它实际场景，线上线下融合，对线上稳定性有更高的要求，就需要一套高可用体系，包括限流、降级、熔断、回滚、全链路灰度。他们目前是已经走到了这个阶段，在服务治理上也是比较高的一个层次，代表了一些传统企业和互联网有交集的一个案例。

另一个就是斯凯奇，他们也赶上了数字化转型，知道数字化经济在国内已经是势不可挡的趋势， 不加入这个趋势就可能会被淘汰。他也联系我们准备做整个中台系统，差不多几个月的时间里快速复用阿里中台技术架构，构建他的整个零售系统，当然在这个过程中也遇到了一些问题。就是做微服务系统的时候，之前他的整个系统有 POS 机、Web、App 多端接入，包括有一些传统架构，一部分是新的微服务架构，这个过程中，通过新的云原生网关解决了内网到外网的安全问题，比如证书管理、Web 防护、安全认证等。

另外斯凯奇也会做大促，峰值是平时的好几倍，他们复用了阿里的高可用体系，从入口到后端，做了一个端对端全链路的限流降级熔断的机制，保证整个交易过程中的高可用。也通过整个全链路压测系统去演练，提前一个月就演练成功，支撑了整个斯凯奇在双 11 当天交易的电商系统。

几个月的时间能打造这样的一个系统，这就是整个云原生给大家带来的一个红利，我就简单分享这两个案例。

至简： 我简单补充一下，今天讲云原生架构的落地不是很小的数字了，已经是成千上万的概念。

如果你经常关注整个行业，就可以看到，几乎有一点名气的互联网大厂，都不是说在探索了，已经是深度用了，我认为在这点上是没有任何疑问的。

InfoQ：在这个过程中或者说新技术的落地和应用会遇到什么问题，又该如何面对？

至简： 我们在面对新技术的时候，“新”不是最大的问题。

我恰恰认为每个新技术的出现，伴随着的是会让我们重新去审视每个企业在发展过程中留下来的技术债务。包括之前在阿里集团内部做 Service Mesh 落地，我感受最痛的不是这个技术新不新、或你不能把它做出来，而是你要花大量的精力和时间先去把把历史包袱处理好。

所以在落地的过程中，我看到的一个最大的痛点其实还是改造的成本，包括以前的架构搬到云原生上来，可能要做服务的拆分等。因为云原生架构不是简单的说你把它搬到容器上这个事情解决了，而是说我们要借这个契机，该做微服务化的做微服务化，至少在效率上我们要有所体现。

彦林： 我讲一下我在实践中的一些具体感受，首先大家对新技术要抱一个开放的态度。举个例子，不管是微服务还是容器的改造，它改变的不仅仅是软件的架构，还有组织的架构。比如我们把阿里的软件架构输出到一些传统企业时发现，阿里整个组织都是扁平的，微服务也是扁平的分布式的，所以大家协同效率比较高，是敏捷开发模式。但是很多组织还是金字塔的形式，跨部门协作效率会比较低。当然随着软件架构的改变，组织架构也会随着软件架构去改变，这个大家可以慢慢体会。

然后当大家解决心态问题迈出第一步之后，确实会陆续面对一些问题，因为软件行业没有银弹，没有万能的架构，比如微服务架构它确实是超过 10 个人的团队，超过 5 个子系统才会在整个生产力上有更大的优势。大家在做微服务本身改造的过程中更多的问题是我的系统拆到什么力度？我认为“一主一备”是比较合适的一个区间，拆得太细会带来更多的协同成本跟运维成本。当然也不是说拆得细了就一定不行，有一些业务场景偏离线计算型的，它更轻就可以拆得更细，这个就需要有经验的专家去做领域的切分。

具体说微服务拆分，我当时遇到的第一个问题就是定位，微服务之后你会发现日志跑到十几台机器中去了，查看所有日志代价是非常大的，出问题的诊断代价也是非常大。现在行业链路追踪，包括 APM，还有监控报警就是解这个领域的问题。

另外我们看到一个数据，就是容器里 70% 都非常容易的去实施微服务，为什么呢？因为微服务之后，你应用的部署更细更多，运维成本会上升。容器很大部分通过自动化的模式解决了运维成本，实现了相辅相成的效果。通过容器的演进，解决了微服务拆分之后的一个部署成本的问题。

从整体上来看，我能慢慢感受到的是，现在整个容器跟微服务的使用的门槛已经比之前低多了。今天通过开源和云计算的发展，降低了这些技术的门槛，剩下的可能更多的是决策者在寻找合适的时机。比如我知道业务要爆发性增长了，复杂度变高了，我要做云原生架构的演进，把问题解决掉，大概是这样。

02 未来架构趋势展望

InfoQ：可以简单聊聊多云架构是怎么回事吗？

至简： 在我们看来云原生很重要的一个驱动力就是防止锁定，也是企业比较在意和希望有一个标准化的东西。

多云的话，当前的客户管理多云会有一些挑战。我觉得这会是一个过程，从最开始大家讲要上云原生，到多云、混合云，这两者毫无疑问是云原生的关键内容，也会让开发者越来越方便使用这一技术，它是以开发者为中心的角度去做的，所以未来肯定是会有相关的技术和产品陆续出来，包括现在已经有一些了。

另外，我理解短期内大家可能会觉得没有那么好用，但是我认为这个会越来越好用，这肯定是各个云厂商都会去重点关注的，因为我们发展的重点还是看我们能解决客户的哪些痛点，帮助客户更好地发展他的业务。

彦林： 多云这个可能不同的厂商有不同的叫法，比如跨云、混合云，我们这边更多的强调分布式云。我能感受到的是，行业里为什么选择多云，大家有不同的理念。

海外的情况可能是有一些高可用的需求，国内就是大家希望有更便宜的资源，打价格战。海外就是希望利用每家云的优势，比如 AI 大数据谷歌云强一点，传统 IDC 领域 AWS 强一点，这样就可以混合去使用，在线业务在 AWS，离线的放在谷歌，诸如此类，配合使用。

我举这个例子就是说，对于大部分的厂商跨云一定是有成本的。国内部分企业可能希望选择多家云厂商，谈一些折扣，但带来的结果是，跨云之后的运维复杂度上升和管理成本上升，我了解到的国内互联网行业在这方面投入了比较大的人力去抹平。

InfoQ：我们之前收集了一些社区问题，想问一下未来五年软件架构会出现什么样的新形态？

至简： 架构究竟是什么我觉得我们需要先捋一捋，我理解的架构是由三个要素组成的，核心就是概念，第二个是概念跟概念之间的关系，在概念和关系之上施加的第三个要素就是约束。

云原生的出现其实讲的是一种架构的实践，这种实践它是基于我们过去所看到的和面临的问题，重新回顾和反思，把之前的概念打破、拆分，再重新去塑造这个概念，最后形成了今天所讲的 Best Practices（最佳实践），包括很多设计模式比如 Sidecar、Operator 等等。

如果说未来五年完全没有新的架构理念出来也不太可能，但是颠覆性的，我个人认为不太会。如果要颠覆云原生架构，首先云原生技术需要应用到一定程度，然后遇到了还有更极致的追求的状况。至于变化，有新的概念提出来是很正常的，行业的发展就是不断的有人塑造概念，这恰恰是技术发展的现象和自然而然的一个状态。

彦林： 除非量子计算发声，我认为这个时代来临之前分布式时代会长期的存在。然后在长期存在的分布式时代里，我们能感受到一些趋势在发生。

因为有了容器，有了微服务，业务变成无状态了，今天整个灵活调度的弹性能力做到极致的话，未来 Serverless 是有可能的。从我们今年的技术架构中间件客户端轻量化，业务侧会 Serverless 化的去演进，因为业务现在是越来越无状态了。随着底层基础设施的完备，弹性能力的具备，有往上去演进的可能性，但从我们今年角度就是说偏前端比如离线计算的一些任务 Serverless 会比较容易。我相信随着基础技术的不断突破，包括硬件加速的技术等，包括很多大厂对 Serverless 都有布局，之前大家谈 Serverless 都是说应用架构，现在比如消息存储都有对应的 Serverless 产品，所以 Serverless 可能就是未来的一个技术思想。

另外，我能感受到的是容器以下，更多的是关心 DevOps，解决运维效率，云原生前半场解决 Ops 的问题，就是运维的问题，未来更多的是解决 Dev 的问题，就是怎么让研发效率更高，开发迭代更快。当然在这个过程中，中间件包括微服务可能更多的解决默认的安全可信和稳定性问题。

03 架构师成长经验分享

InfoQ：不少程序员在从普通开发者转向架构师的时候会遇到一些瓶颈，两位老师有什么架构师成长上的经验可以分享给大家吗？

至简： 其实架构师领域有很多东西可以讲的，我先说一下我的想法，简单分享几点，彦林可以做补充。

首先做架构师第一点就是对技术要有追求，需要在技术上有一些积累，对软件设计的追求，也就是我们讲的《架构之美》。

第二点就是懂得切换视角，站在不同的角度去看待事情。我做架构师最大的感受就是，如何站在用户、客户或者说使用者的角度去看待我们正在做的事情。当你站在用户或者客户角度去看事情的时候，会发现完全不一样的东西。

从我自己在过去一年做商业化这件事情上来讲，是有蛮大一个感触的。无论是开发交付给客户用一个产品，还是做内部的一个模块，如何站到对方的角度去看，会发现我们熟悉的一个技术术语觉得很自然和简单，但客户或用户并不这么认为。

我个人觉得比较重要的就是思维的不断升级，从关注个人，到关注的是更大的团队、组织，是一个不断突破的过程。做一个好的架构师，要有持续抽象能力，需要很务实，需要有产品思维和商务思维。认知越往高处走，会发现技术只是一部分，但是我要强调的是不要认为技术不重要，恰恰是把基础技术打扎实了，才能有自信往前去突破。

彦林： 刚才至简讲的很好，切换视角是很多人从程序员变成架构师或者是 PD、领导者的时候，都绕不过的一个坎儿。然后我补充以下我这边的几个想法，我经常面试，所以会结合这个来讲一下我比较关心的几个事情。

首先，就基础技术或者软件开发来说，我比较喜欢有好奇心的人，对技术感兴趣，就能不断把技术做深，反之做技术就容易浮在表面，很难有长期的技术沉淀。有好奇心驱动，才能深耕发展和走得更远。

第二，就是工作中主动担当。我也经常跟团队的同学讲，你搞不定我帮你一起做。在这个过程中，你可以得到更多的资源和帮助，获得更快的成长。很多的成长都是往高区域跳一下，挑战一下更有难度的事情，这样才能不断锻炼自己，站在更高层面思考问题。

第三，就是思考维度。刚才至简提到了用户视角和技术视角，还有一个视角也比较重要，就是全局观。

举例来说，比如刚入职的员工看问题、拆解问题，不会想特别多，能把 10 个问题拆解成 5 个需求，5 个问题就已经上了一个层级，能从这 5 个需求中找出不合理的同时避开，这就有了产品的思维，再平衡排期把剩余合理需求做完就锻炼了投入产出比与优先级思维。而当你完整做完一整个产品的时候，你会不断跟前后端、运营等做协同，协同的过程中能力就会慢慢锻炼出来。同理，再往上走就是更多的周边资源协同的能力等等。

简单总结一下，入职 2-3 年，核心技术的深度积累是非常重要的，有了深度才能走的更远；技术扎实之后，第二点就是培养产品思维，产品思维很重要，不要只是做技术；具备产品思维之后，第三个要做的就是上下游人的协同，做做架构师需要跟多个角色打交道才能把事情做好；等到协同做好了要解决的问题就是领导力与规划未来的能力，这个要求就会比较高了。