展望架构的 2022：热度居高不下的云原生，如何撑起架构的未来
软件架构发展至今，经历了从单体架构、垂直架构、SOA 架构到现在的以微服务、服务网格等云原生技术为主的演变过程，云原生技术发展势不可挡，老生常谈的“云原生”将依然会是未来的热门话题。而且随着数字化转型加速，企业对于云的使用将会达到新的水平，云原生架构和云原生应用也将会持续迭代演进。
那么在云原生等技术的加持下，2022 年的架构领域有哪些值得关注的趋势？云原生如何撑起架构的未来？本期直播，阿里云 MSE 负责人李艳林（彦林）、阿里云高级技术专家李云（至简）一起做客 InfoQ 视频号，为你带来云原生架构领域最新趋势解读。以下根据直播内容整理，InfoQ 做了不改变原意的编辑，完整内容可查看回放视频（https://www.infoq.cn/video/hf6vJTe3tiulDq5zhhfP）。
至简：讲今天的云原生我觉得我们还是需要回顾一下历史，去了解一下它是怎么一回事。
2000 年的时候，还没有虚拟化的概念，大家看到的都是物理机；
2001 年 VMware 横空出世，不过这个时候交付的还是一个虚拟机；
之后 2006 年亚马逊推出 IaaS（基础设施即服务）平台 AWS，这个时候的思路已经是把 CAPEX（资金投入成本） 变成 OPEX（运营成本）。就是我不需要再买一大堆机器，而是用到了再去云上买；
2009 年 Heroku 提出 PaaS，这个时候不再是用虚拟机来交付，变成了 Buildpacks，也开始了有了容器化的概念，还有 12 要素应用程序的一套规则；
2010 年，出现了 OpenStack，它其实是通过开源的方式来做 IaaS，目的是跟 AWS 做竞争，它构建的 building block 还是一个 VM；
2013 年，Docker 的出现带来了比较大的变化，这个时候交付就变成了容器。
今天讲的 Cloud Native 其实是 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 年左右的时候，按照刚至简说的，通用化和标准化这个事情基本上在逐渐的形成，在 15 年之后，行业中的关于各种各种的容器化，比如 Docker、K8s 包括 Spring Cloud 都是在这个时代陆续的产生，大概是这么一个情况。
至简：我觉得今天来看的话，可以说云原生架构已经被业界被行业广泛接受。
以 Service Mesh 为例，服务网格现在都在逐步的接受。讲云原生架构之所以拿 Service Mesh 来举例，是因为云原生整体的概念已经被广泛接受，比如像云原生下的 K8s 毫无疑问已经是一统江湖的局面，而相比之下 Service Mesh 是偏晚的。像 Service Mesh 曾经被质疑的问题比如性能等，到今天已经都已被逐步接受。
从这个层面就可以看出来，大家对整个云原生架构的接受度已经很高了。今天很多企业考虑的问题是我如何去落地云原生这个技术。我觉得云原生不管是理念也好设计模式也好，它是一个组合在一块的。我不会简单的说云原生发展到整个历程的 50% 或者 60%，不会用这个思维去看待它，而是说我们能不能先上到云原生，随着云原生技术的演进，我也能跟着这个节奏去往前走。
我觉得好的地方是整个大众对云原生技术有很好的认知和理解，然后云原生整体趋势也是乐观和蓬勃发展的。
彦林：我讲一下我对这个事情的理解，首先从软件技术上分层去讲的话，今年大家可以看到，包括阿里云和其他所有的云都在讲容器 Anywhere，其实容器已经慢慢成为一种基础设施，随着未来三到五年的发展，保有容器的量可能比单独跑在 ECS 上的要多。从容器角度来看，基本上已经要成为新一代的一个基础设施。
从微服务角度去看，因为我们最近在做两年规划，大家应该也看到了一些关键的数据，比如中国程序员的平均工资多少多少，平均工资那就是人力成本，其实已经远远高于 IT 的算力成本资源成本。容器更多解决的是资源调度成本、运维成本，微服务更多解决的是研发成本、协同成本。因为大家在一个代码上去共建人太多的话，效率是非常低的。所以第一个面临的问题就是人力与效率越来越重要，而且随着整个行业竞争的加剧，你跑得快就有优势，跑慢了就会错过这个机遇，互联网行业就是“快鱼吃慢鱼”。
我在关注的数据中还有一个比较新的事情是整个程序员的年龄分布，90 后已经成为构建数字化经济的核心中坚力量，他们的协作模式和工作风格与老成员已经不太一样了。他们喜欢更敏捷更独立的协作模式，微服务其实就是更符合他们的一个协作模式。
目前从整个行业来看的话，微服务已经成为一种主流的选择。而且我们从另外的两个数据也可以看到，第一个就是从整个行业看微服务每年有差不多 20% 以上的一个增长，就是说整个行业每年有数万家企业在做整个微服务的一个改造，第二个就是除了互联网公司进行容器化和微服务改造，许多传统行业，比如零售、医疗、金融等等，陆续开始进行数字化升级，微服务在整个行业也有了更广发的一个演进。
从另外一个技术角度来看，不管是单体应用、微服务，还有未来的服务网格、Serverless 等，都有自己的应用场景，今天可能是因为人力成本的提升，整体年轻化对协作要求更自由、更独立，容器跟微服务在这个大趋势下越来越重要了。
彦林：落地案例其实非常多，我简单举几个可以对外讲的例子吧。
来电科技在前几年就完成了整个云原生的技术改造，容器化、微服务都做了，在研发效率、资源利用率上都得到了比较大的提升。现在他们已经走到了云原生的第二个阶段，当下比较大的问题是服务治理，比如优雅上下线、无损下线，同时也会面临高可用的问题，比如它实际场景，线上线下融合，对线上稳定性有更高的要求，就需要一套高可用体系，包括限流、降级、熔断、回滚、全链路灰度。他们目前是已经走到了这个阶段，在服务治理上也是比较高的一个层次，代表了一些传统企业和互联网有交集的一个案例。
另一个就是斯凯奇，他们也赶上了数字化转型，他们知道数字化经济在国内已经是势不可挡的趋势， 不加入这个趋势就可能会被淘汰。他也联系我们准备做整个中台系统，差不多几个月的时间里快速复用阿里中台技术架构，构建他的整个零售系统，当然在这个过程中也遇到了一些问题。就是做微服务系统的时候，之前他的整个系统有 POS 机、Web、App 多端接入，包括有一些传统架构，一部分是新的微服务架构，这个过程中，通过新的云原生网关解决了内网到外网的安全问题，比如证书管理、Web 防护、安全认证等。
另外斯凯奇也会做大促，峰值是平时的好几倍，他们复用了阿里整个三季度的高可用体系，从入口到后端，做了一个端对端全链路的限流降级熔断的机制，保证整个交易过程中的高可用。也通过整个全链路压测系统去演练，提前一个月就演练成功，支撑了整个斯凯奇在双 11 当天交易的电商系统。
几个月的时间能打造这样的一个系统，这就是整个云原生给大家带来的一个红利，我就简单分享这两个案例。
至简：我简单补充一下，今天讲云原生架构的落地不是很小的数字了，已经是成千上万的概念。
如果你经常关注整个行业，就可以看到，几乎有一点名气的互联网大厂，都不是说在探索了，已经是深度用了，我认为在这点上是没有任何疑问的。
至简：我认为我们在面对新技术的时候，“新”不是最大的问题。
我恰恰认为每个新技术的出现，伴随着的是会让我们重新去审视每个企业在发展过程中留下来的技术债务。包括我们之前在集团内部做 Service Mesh 落地，我感受最痛的不是这个技术新不新，你不能把它做出来，而是你要花大量的精力和时间先去把把历史包袱和适配处理好。
所以在落地的过程中，我看到的一个最大的痛点其实还是改造的成本，包括以前的架构搬到云原生上来，可能要做服务的拆分等。因为云原生架构不是简单的说你把它搬到容器上这个事情解决了，而是说我们要借这个过程，该做微服务化的做微服务化，至少在效率上我们要有所体现。
彦林：我讲一下我在实践中的一些具体感受，首先大家对新技术要抱一个开放的态度。举个例子，不管是微服务还是容器的改造，它改变的不仅仅是软件的架构，还有组织的架构。比如我们把阿里的软件架构输出到一些传统企业时发现，阿里整个组织都是扁平的，微服务也是扁平的分布式的，所以大家协同效率比较高，是敏捷开发模式。但是很多组织还是金字塔的形式，跨部门协作效率会比较低。当然随着软件架构的改变，组织架构也会随着软件架构去改变，这个大家可以慢慢体会。
然后当大家解决心态问题迈出第一步之后，确实会陆续面对一些问题，因为软件行业没有银弹，没有万能的架构，比如微服务架构它确实是超过 10 个人的团队，超过 5 个子系统才会在整个生产力上有更大的优势。大家在做微服务本身改造的过程中更多的问题是我的系统拆到什么力度？我认为“一主一备”是比较合适的一个区间，拆的太细会带来更多的协同成本跟运维成本。当然也不是说拆的细了就是方式不行，有一些业务场景偏离线计算型的，它更轻就可以拆的更细，这个就需要有经验的专家去做领域的切分。
具体说微服务拆分，我当时遇到的第一个问题就是定位，微服务之后你会发现日志跑到十几台机器中去了，查看所有日志代价是非常大的，出问题的诊断代价也是非常大。现在行业链路追踪，包括 APM，还有监控报警就是解这个领域的问题。
另外我们看到一个数据，就是容器里 70% 都非常容易的去实施微服务，为什么呢？因为微服务之后，你应用的部署更细更多，运维成本会上升。容器很大部分通过自动化的模式解决了运维成本，起到了就是相辅相成的结果。通过容器的一个演进，解决了微服务拆分之后的一个部署成本的问题。
从整体上来看，我能慢慢感受到的是，现在整个容器跟微服务的使用的门槛已经比之前低多了。今天通过开源和云计算的发展，降低了这些技术的门槛，剩下的可能更多的是决策者在寻找合适的时机。比如我知道业务要爆发性增长了，复杂度变高了，我要做云原生架构的演进，把问题解决掉，大概是这样。
至简：在我们看来云原生很重要的一个驱动力就是防止锁定，也是企业比较在意和希望有一个标准化的东西。
多云的话，对于我们当前的客户，对于管理多云会有一些挑战。我觉得这会是一个过程，从最开始大家讲要上云原生，到多云、混合云，我觉得毫无疑问的是云原生有一个特别关键的点，它是让开发者越来越方便使用这个技术，它是以开发者为中心的角度去做的，所以未来肯定是会有相关的技术和产品陆续出来，包括现在已经有一些了。
另外，我理解短期内大家可能会觉得没有那么好用，但是我认为这个会越来越好用，这肯定是各个云厂商都会去重点关注的，因为我们发展的重点还是看我们能解决客户的哪些痛点，帮助客户更好地发展他的业务。
彦林：多云这个可能不同的厂商有不同的叫法，比如跨云、混合云，我们这边更多的强调分布式云。我能感受到的是，行业里为什么选择多云，大家有不同的理念。
海外的情况可能是有一些高可用的需求，国内就是大家希望有更便宜的资源，打价格战。海外就是希望利用每家云的优势，比如 AI 大数据谷歌云强一点，传统 IDC 领域 AWS 强一点，这样就可以混合去使用，在线业务在 AWS，离线的放在谷歌，诸如此类，配合使用。
我举这个例子就是说，对于大部分的厂商，跨云一定是有成本的。国内部分企业可能希望选择多家云厂商，谈一些折扣，但带来的结果是，跨云之后的运维复杂度上升和管理成本上升，我了解到的国内互联网行业在这方面投入了比较大的人力去抹平。
至简：架构究竟是什么我觉得我们需要先捋一捋，我理解的架构是由三个要素组成的，核心就是概念，第二个是概念跟概念之间的关系，在概念和关系之上施加的第三个要素就是约束。
云原生的出现其实讲的是一种架构的实践，这种实践它是基于我们过去所看到的面临的问题，重新回顾和反思，把之前的概念打破、拆分，再重新去塑造这个概念，最后形成了今天所讲的 Best Practices（最佳实践），包括很多设计模式比如 Sidecar、Operator 等等。
如果说未来五年完全没有新的架构理念出来也不太可能，但是颠覆性的，我个人认为不太会。如果要颠覆云原生架构，首先云原生技术需要应用到一定程度，然后遇到了还有更极致的追求的状况。至于变化，有新的概念提出来是很正常的，行业的发展就是不断的有人塑造概念，这恰恰是技术发展的现象和自然而然的一个状态。
彦林：除非量子计算发声，我认为这个时代来临之前分布式时代会长期的存在。然后在长期存在的分布式时代里，我们能感受到一些趋势在发生。
因为有了容器，有了微服务，业务变成无状态了，今天整个灵活调度的弹性能力做到极致的话，未来 Serverless 是有可能的。从我们今年的技术架构中间件客户端轻量化，业务侧会 Serverless 化的去演进，因为业务现在是越来越无状态了。随着底层基础设施的完备，弹性能力的具备，有往上去演进的可能性，但从我们今年角度就是说偏前端比如离线计算的一些任务 Serverless 会比较容易。我相信随着基础技术的不断突破，包括硬件加速的技术等，我相信包括很多大厂对 Serverless 都有布局，之前大家谈 Serverless 都是说应用架构，现在比如消息存储都有对应的 Serverless 产品，所以 Serverless 可能就是未来的一个技术思想。
另外，我能感受到的是容器以下，更多的是关心 DevOps，解决运维效率，云原生前半场解决 Ops 的问题，就是运维的问题，未来更多的是解决 Dev 的问题，就是怎么让研发效率更高，开发迭代更快。当然在这个过程中，中间件包括微服务可能更多的解决默认的安全可信和稳定性问题。
至简：其实架构师领域有很多东西可以讲的，我先说一下我的想法，简单分享几点，彦林可以做补充。
首先做架构师第一点就是对技术要有追求，需要在技术上有一些积累，对软件设计的追求，也就是我们讲的《架构之美》。
第二点就是懂得切换视角，站在不同的角度去看待事情。我做架构师最大的感受就是，如何站在用户、客户或者说使用者的角度去看待我们正在做的事情。当你站在使用者用户或者客户角度去看事情的时候，会发现完全不一样的东西。
从我自己在过去一年做商业化这件事情上来讲，是有蛮大一个感触的。无论是开发交付给客户用一个产品，还是做一个哪怕是内部的一个模块，你如何站到对方的角度去看，切换视角，你会发现我们熟悉的一个术语，我们关心的内容，客户或者用户并不这么想。然后就容易陷入一种情况，就是我认知的东西是对的，但实际上当我们如果跳出来去站到客户的角度去看的时候，发现想法完全不一样。
我个人觉得比较重要的就是思维的不断升级，从关注个人，到关注的是更大的团队、组织，是一个不断突破的过程，做一个好的架构师，要有持续抽象能力，需要很务实，需要有商务思维。我认为是认知不断升级的过程，越往高处走，会发现技术只是一部分，但是我要强调的是不要认为技术不重要，恰恰是把基础技术打扎实了，才能有自信往前去突破。
彦林：刚才至简讲的很好，切换视角是很多人从程序员变成架构师或者是 PD、领导者的时候，都绕不过的一个坎儿。然后我补充以下我这边的几个想法，我经常面试，所以会结合这个来讲一下我比较关心的几个事情。
首先，就基础技术或者软件开发来说，我比较喜欢有好奇心的人，对技术感兴趣，就能不断把技术作深，反之做技术就容易浮在表面，很难有长期的技术沉淀。好奇心驱动，才能在软件技术行业深耕发展，走的更远。
第二，就是工作中主动担当。我也经常跟团队的同学讲，你搞不定我帮你一起做。在这个过程中，你可以得到更多的资源和帮助，获得更快的成长。很多的成长都是往高区域跳一下，挑战一下更有难度的事情，这样才能不断锻炼自己，站在更高层面思考问题。
第三，就是思考维度。刚才至简提到了用户视角和技术视角，还有一个视角也比较重要，就是全局观。
举例来说，比如刚入职的员工看问题、拆解问题，不会想特别多，能把 10 个问题拆解成 5 个需求，5 个问题就已经上了一个层级，能从这 5 个需求中找出不合理的同时避开，这就有了产品的思维，再平衡排期把剩余合理需求做完就锻炼了投入产出比与优先级思维。而当你完整做完一整个产品的时候，你会不断跟前后端、运营等做协同，协同的过程中能力就会慢慢锻炼出来。同理，再往上走就是更多的周边资源协同的能力等等。
简单总结一下，入职 2-3 年，核心技术的深度积累是非常重要的，有了深度才能走的更远；技术扎实之后，第二点就是培养产品思维，产品思维很重要，不要只是做技术；具备产品思维之后，第三个要做的就是上下游人的协同，做做架构师需要跟多个角色打交道才能把事情做好；等到协同做好了要解决的问题就是领导力与规划未来的能力，这个要求就会比较高了。
嘉宾介绍：
李云（花名：至简），阿里云服务网格混合云产品技术负责人。2018 年开始在阿里集团带领团队从事服务网格技术的发展与建设工作，在 QCon 做过多次云原生与服务网格的技术分享。
李艳林（花名：彦林），Nacos PMC，阿里云 MSE 产品创始人，阿里云软负载团队负责人。
《中国卓越技术团队访谈录》是 InfoQ 打造的重磅内容产品，为了能进一步了解读者的实际需求和喜好，持续为大家生产有价值、具备启发性的内容，我们发起了本次调查，真诚邀请广大社区读者参与问卷。同时，如果你希望 InfoQ 关注并采访你所在的技术团队，也可以通过本问卷报名，报名选项在问卷底部。
点击【阅读原文】，即刻参与有奖问卷调查，还有机会获得精美礼品。
如对本次调研有任何疑问或建议，欢迎联系微信 13512772438。
点个在看少个 bug 👇
相关内容
微信扫码咨询专知VIP会员