编辑｜辛晓亮
本文是“2021 InfoQ 年度技术盘点与展望”系列文章之一，由 InfoQ 编辑部制作呈现，重点聚焦架构领域在 2021 年的重要进展、动态，希望能帮助你准确把握 2021 年架构领域的核心发展脉络，在行业内始终保持足够的技术敏锐度。 “InfoQ 年度技术盘点与展望”是 InfoQ 全年最重要的内容选题之一，将涵盖架构、AI、大数据、大前端、云计算、数据库、中间件、操作系统、开源、编程语言十大领域，后续将聚合延展成专题、迷你书、直播周、合集页面，在 InfoQ 媒体矩阵陆续放出，欢迎大家持续关注。 特此感谢成国柱、李云、田靖、翁扬慧、杨皓然（按姓名首字母排序）对本文的贡献，他们的真知灼见，是本文能与大家见面的关键。
过去几年，随着互联网发展以及业务的多样化，系统的架构也在不断发生变化。总体上来说经历了单体应用架构 - 垂直应用架构 - 分布式架构 -SOA 架构 - 微服务架构的演变。当下头部互联网企业已经在向服务网格类的云原生架构演进。今天借着这个机会，我们盘点一下 2021 年架构领域的各项技术。区别于云原生盘点，本文试图从架构的角度出发，挖掘出不同的内容，希望可以给你提供帮助。
重点技术演进盘点
架构领域涵盖的技术类别较多，本文选择了 2021 年比较突出的几个领域如微服务、服务网格、Serverless、低代码、多云架构等，并以此展开年度回顾和趋势展望。篇幅有限，本文未提及的技术并非不重要，如果你对其他相关技术感兴趣欢迎留言告诉我们。
微服务 & 服务网格（Service Mesh）：羽翼渐丰，成熟完善
微服务生态图（图源：Chris Richardson Consulting, Inc.）
如果要总结 2021 年的服务网格的话，那就是技术日趋成熟，生态逐步完善，市场更加理性，回归价值本身。
一项新技术的发展基本都是会符合技术成熟度曲线（The Hype Cycle）规律的，服务网格也不例外。服务网格概念最早从 2017 年被提出，2018 年正式爆发，进入服务网格技术元年，之后随着众多云厂商纷纷入局，服务网格也达到了成熟度曲线的期望顶峰点。
随后的的两年时间里，服务网格在设计过程中算是颇为曲折，但也不乏突破创新。从早期废弃 Mixer，到回归单体架构设计调整，以及后来对 Web Assembly 技术的支持等等，都算是有一些比较大的变化调整或者是创新突破。
在刚过去的 2021 年，虽说服务网格仍被 Gartner 评定为处于技术发展的早期采纳阶段，但无论是商业还是技术都取得了长足的发展。
从商业的视角：
- 国外的专业提供服务网格产品与服务的 Solo 公司披露客户数出现强劲增长的态势（500% 季度比增长），并获得 C 轮 1.35 亿美元的融资；
- 另一个国外的专业提供服务网格产品与服务的 Tetrate 公司收获了 B 轮 4000 万美元的融资；
- 阿里云服务网格 ASM 产品的公有云客户数较前一年增长 250%，客户数出现跃变式增长；
- 国内专业提供服务网格产品与服务的初创公司 Flomesh 获得 pre-A 轮数千万人民币的融资。
从技术的视角，Istio 继续引领全球服务网格的发展。在 2021 年 9 月 CNCF 的一项终端用户调查的结果显示， 采纳了 Istio 的用户数大约是采纳了 Linkerd 的 3 倍。
图源：cncf.io
以刚才提到的目前主流的服务网格技术选型 Istio 为例，无论是开源社区还是众多云厂商都在围绕网格技术做持续优化。相比以往大刀阔斧的进行架构调整、技术突破等，过去的一年里似乎更加“务实”，解决的都是一些真真实实业务侧的落地问题，比如性能优化、虚拟机支持、多集群和多网格支持等等。
在 2021 年，服务网格 Istio 并没有特别大的或者突破性的调整，更多是关注于技术本身的优化，聚焦于解决实际生产中的落地问题。例如通过完善对虚拟机的支持来扩大基础设施的适配范围，通过引入智能 DNS 代理来解决大规模服务场景下的 iptable 性能瓶颈，还有完善对多控制平面的支持，完善在生产中的运维操作等等，都是一些相对比较实实在在的优化。这也是一项新技术在经历期望膨胀之后，回落到低谷，又重新进入一个稳定的爬坡期，是一个良性的过程，也代表服务网格技术正变得越来越成熟稳定。
其次，可以看到的是围绕服务网格的开源技术生态正在完善，围绕 Istio 衍生的周边开源生态有向上发展的趋势且不乏很多创新。这里面主要分为两类，一类是将现有技术或者产品融入服务网格生态，比如为服务网格提供一种新的数据面技术支持等；另外一类是在服务网格落地过程中为了解决问题衍生出来的工具或者扩展支持，比如配置优化、协议支持等。
eBPF 技术也更加完善，可以在内核层面优化来提升服务网格性能以及可观测性，各类服务网格数据面的开源替换方案，或者是基于 Istio 控制面构建的云原生网关等等，刚才提到的还有用于解决服务网格生产落地中的一些扩展性、易用性等问题的开源项目，比如定位于服务网格智能管理器的 Slime 项目，它可以解决大规模服务场景下的配置性能问题，以及能力扩展问题；用于管理 Istio 七层负载的 Aeraki，提供了一种非侵入式的协议扩展解决方案等等。这些都是建立在服务网格 Istio 之上的，也都是服务网格技术日趋成熟的一种体现。
上面提到了 2021 年服务网格无论从商业还是技术都获得了长足的发展。Istio 继续引领行业的发展，除了易用性获得了巨大改善，还向业界展示了基于 gRPC 的无代理解决方案，清晰地描绘了未来服务网格的终极形态。
“架构不是一蹴而就，而是慢慢演进”，受访专家提到，微服务架构目前已经发展到第三代，即将微服务的基础能力从服务框架演进成一个独立进程 Sidecar，实现云原生微服务架构。被业界称为“下一代微服务架构”的服务网格，经历了前两年的“火热”，在 2021 年大家对于网格的看法更趋于理性，回归到了技术是用于解决问题的本质。通过服务网格能解决什么问题？现有业务想上服务网格还需要解决什么问题？上了服务网格之后会有什么新的问题？这些问题是需要大家进行理性思考的。好在这些问题，不同的云厂商分别都有丰富的经验沉淀和成熟的技术方案，可以值得关注。
受访专家表示，在 2022 年，企业对于服务网格的态度不再是“技术是否成熟”，而是“我们应以怎样的路径落地”。在落地的道路上，技术债才是企业面临的最大障碍。技术浪潮除了带来红利，还创造了让企业正视技术债的重大机会。技术债是技术发展的自然产物，技术进步与发展的一个表征是，我们用新的思维、站到新的高度去解决过去、现在和不久的将来的问题。
Serverless：仰望星空，脚踏实地
“2021 年的 Serverless 可以用仰望星空，脚踏实地来形容”，受访专家总结道。
落地可以说是 Serverless 2021 年发展的关键词。Serverless 可以帮助开发者省掉基础设施运维等很多杂事，但在什么场景下使用 Serverless，如何把 Serverless 应用的开发部署集成到现有的开发运维流程中，如何调试、诊断 Serverless 应用等等，仍是困然多数开发者的主要问题。
因此，在 2021 年各个云服务商，都在不断拓展 Serverless 产品线的能力。在 Web 应用，微服务，事件处理，批处理任务等场景，Serverless 正在成为最流行的架构。
一方面是因为 Serverless 编程模型变得更加通用，例如 Google Cloud Run、AWS App Runner、阿里云函数计算 /Serverless 应用引擎等产品支持实例并行处理多个请求，容器镜像等功能，Web 应用或者基于 Spring、Dubbo 等流行框架的微服务应用基本上不需要改造就能直接运行到 Serverless 平台上；另一方面，Serverless 平台在工具链，可观测等方面的长足进步，让开发者能用更习惯的方式开发和运维 Serverless 应用。
在落地场景上，以阿里为例，高德出行通过 Serverless 架构实现的 API 后端服务，支撑了十一出行高峰 50 万 TPS 的流量；公有云上的南瓜电影使用 Serverless 应用引擎，7 天完成了微服务的 Serverless 化；网易云音乐使用函数计算的极致弹性能力，让音频算法在业务上的落地速度提升了 10 倍。这几个头部厂商的成功案例，证明了 Serverless 的价值。
此外，2021 年云服务商产品体系 Serverless 化的趋势也越来越明显，不仅有 AWS App Runner、Azure Container Apps 这些计算领域的产品，还包含大数据领域的 AWS Redshift Serverless、AWS EMR Serverless、AWS MSK Serverless，机器学习领域的 AWS Sagemaker Serverless 等产品。全产品体系的 Serverless 化，体现了云厂商将 Serverless 视作云未来的坚实承诺。
2021 年的 Serverless 还有一个值得关注的点，就是开源开放。2019 年 CloudEvents 1.0 标准正式发布，为不同供应商的事件互通奠定了基础，2021 年 Serverless Workflow 标准按计划将推出 1.0 RC 版本，意味着在工作流领域很快也将出现正式的标准。2021 年 11 月， Knative 正式发布了 1.0 版本，达到了生产环境可用的能力。Serverless 开放标准和开源软件的成熟，对消除 Serverless 的 vendor lock-in 有重要意义。
关联阅读：
从实践出发，解锁 Serverless 的不同面 （https://www.infoq.cn/article/ThI2lzLS6F7f0R79A5hZ）
Serverless 的承诺都兑现了吗？ （https://www.infoq.cn/article/MLKyYvB6dhjMeMB9WZtj）
低代码：垂直发展，更获认可
低代码平台这一概念最早由 Forrester Research 在 2014 年提出，Gartner 用基于 aPaaS 的高生产力平台（hpaPaaS）来命名这一类别。随着西门子收购 Mendix、Outsystems 融资，低代码平台正式进入大众视野，国内低代码市场也进入快速发展期。
说到 2021 年国内低代码市场的变化，受访专家表示，主要有以下两个方面。
接受度提高
第一点也是最大的变化接受程度上的改变。就是随着业务多元化，尤其是遇到需要快速上线的业务，低代码可以在末端交付上显著提升效率，行业内对低代码的接受程度提升很高，对低代码的快速业务能力也表示认可。
另外，不仅是企业、市场对低代码的接受度变高，做低代码平台的开发人员也形成了共识。以前的程序员认为低代码是自己的死对头，两者是水火不相容的关系。慢慢的程序员圈也逐步接受一个概念，就是低代码可以释放程序员工作的能量。程序员接触核心开发，把简单或者固化的业务交给低代码平台去开发，并通过低代码平台交付给业务部门，提高业务响应效率。
垂直发展
第二个比较大的变化就是低代码逐步从通用化平台向垂直方向演进和发展。
低代码的特点就是必须做约束和抽象规范才能达到高效的目的，这些都是带有垂直行业属性的。纯通用的低代码平台效率不会太高。同样，纯低代码平台也无法满足企业的需要，广义的低代码又在覆盖更多的业务，开发人群范围也在扩大，这些问题不是纯低代码平台可以解决的。
所以低代码必须像垂直领域发展，以更好的实现业务。另外提升效率和降低成本的核心就是复用，低代码从以前的纯技术组件级复用，到纯业务组件复用，也在逐步往垂直方向发展。
几个月前，Gartner 发布了《2021 年企业低代码应用平台魔力象限》，报告从多个维度对全球知名厂商进行了严格评选。
- OutSystems、Mendix、微软、Salesforce、ServiceNow 被评为行业领导者；
- Appian、Oracle 和 Pega 被评为挑战者；
- Creatio、Kintone、Newgen 和 Quickbase 被评为利基市场参与者。
根据 Gartner 的预测，“到 2023 年，超过 70% 的企业将采用低代码（LCAP）作为他们发展战略的关键目标之一。"同时，到 2025 年，整体 LCAP（低代码开发平台）市场规模将达到 290 亿美元，年复合增长率超过 20%。尽管低代码已成为行业热点并且获得了足够的认可，不过整体来看，目前国内低代码仍处于发展早期，市场还有很大的潜力等待企业去挖掘。
值得关注的技术
混沌工程（Chaos Engineering）
今年 11 月 11 日，在混沌工程实验室主办的“混沌工程与系统稳定性主题沙龙”上，中国信通院解读了国内首个《中国混沌工程调查报告》。
报告主要指出：
- 国内软件系统稳定性有较大可提升空间，企业期待构建完成、可度量的系统稳定性保障体系；
- 混沌工程是提升产品可用性的有效手段，是建立稳定性的技术核心；
- 混沌工程应用目前成熟度较低，在企业内普及与渗透偏低。
随后今年 12 月 21 日举办的数据安全产业峰会上，中国信通院发布了《混沌工程实践指南（2021 年）》，首次提出混沌工程实践体系，混沌工程的重要性不言而喻。阿里巴巴开源 ChaosBlade、PingCAP 开源 Chaos Mesh，字节腾讯亚马逊等企业也在混沌工程上有深度实践，从几年前的被人质疑，到今年越来越多的落地实践，混沌工程证明了自己的价值。
混沌工程演进时间线（图源：亚马逊云科技博客）
混沌工程重要事件参考：
- 2010 年，Netflix 开发 Chaos Monkey 项目并向社区开源；
- 2015 年，Netflix 正式提出混沌工程原则；
- 2016 年，混沌工程开始出现商业化产品。
多云架构
数字化加速了企业上云的过程，另外随着企业业务的多元化，多云也成为必然的趋势。
多云架构主要有以下优点
- 灾难恢复与故障转移：企业使用一个云平台管理所有资源存在较大风险，使用多云架构，在一个云出现故障时，还有其他云可以承担工作负载，也便于快速恢复；
- 避免供应商锁定：多云可以让企业探索不同的供应商，从不同云平台选择服务，定制符合企业目标的基础设施；
- 数据主权：欧盟以及多个国家都通过了法律，对数据存储的位置和方式进行监管，受约束的公司可以采用多云的方式确保数据符合监管要求；
- 降低成本：将工作负载分布在多个云平台之间进行合理的规划，可以有效降低总体成本。
不过多云不是万能的，目前仍存在较大的部署挑战。复杂的环境，成本管理，数据隐私和保护，数据控制访问与跟踪等等都是企业面对的，也是云厂商要解决的问题，所以是否选择多云架构的形式还是要基于公司业务的现状。
展望未来
云原生技术的发展势不可挡，老生常谈的“云原生”将依然会是未来的热门话题。随着数字化转 型加速，企业对于云的使用将会达到新的水平，云原生架构和云原生应用也将会持续迭代演进。
Serverless
在云原生第一阶段，云赋能开发者随时使用海量的算力，支撑了移动互联网等产业的兴起。当下，我们已经进入了云原生第二阶段，云的使命是重塑云原生应用的开发运维模式，帮助开发者获得前所未有的敏捷性和创新能力。
2022 年，开发者将越来越多的听到现代应用（modern application）的概念。现代应用是在应用架构，开发流程，可观测性，安全性等方面采用新的理念，实现安全且快速的软件开发方式。
现代应用的核心是采用微服务和事件驱动的松耦合架构，微服务和事件驱动架构的概念并不新鲜，但很多开发者想要很好的落地仍然面临很大的挑战，最主要的原因是这类将应用拆分为细粒度、松耦合的方式对基础设施的运维带来了很大的挑战。
因此云服务商需要提供越来越多的全托管产品，让开发者基于全托管服务以搭积木的方式实现应用，最终应用的运维演变成 Serverless 模式，即不再管理基础设施，从而大幅降低开发运维的复杂度。
DevOps
DevOps 是实践现代应用的关键。无论是云厂商还是开源社区，都围绕 DevOps 提供了大量的软件。在 2022 年，受访专家认为将会涌现出越来越多工具，帮助开发者整合应用开发、部署、运维、监控等各个环节的工具，实现清晰流畅的软件交付工作流程。
诸如 Backstage.io 这样的开源软件，让开发者能够轻松的访问共享的软件开发组件，API 文档，以及模板化的工作流，整个团队以一致的方式构建和部署应用，对于提升软件交付的速度和质量非常有价值。
服务网格 & 云原生架构
从目标上看，服务网格试图将服务间的通信及治理下沉到基础设施以达到业务开发和运维解耦，而随着多运行时概念的提出，又试图通过抽象和隔离上层应用开发中的运行时依赖，来进一步解耦开发设计和技术能力的底层实现。
受访专家表示，或许云原生应用开发的愿景是试图通过一层标准化的 API 抽象定义，使得用户可以基于不同语言开发云原生应用，屏蔽外部的基础技术依赖，以及底层的运行环境。从而不被厂商和平台限制，实现跨云跨平台的可移植性。
此外设计和想法都具有一定的前瞻性，站在新业务的角度，大胆进行新技术的尝试，新架构的设计，是一种不错的探索，试错成本也相对较小。而现实中更多的是面临大量历史存量业务，改造难，迁移难，是很多业务方面临最头疼的问题。
这些问题导致企业在云原生架构的前进道路上步伐沉重，受访专家提到，面向多技术栈、多语言、多协议的 "混合应用架构治理" 是需要重点关注和解决的难题。好在目前已有不少厂商在做相关产品的落地设计。
写在最后
回顾这一年，架构领域并没有像其他领域有特别多的重大新闻事件，但是各项技术也都有长足的发展。服务网格日趋成熟完善，Serverless 落地实践场景越来越多，低代码平台更受认可，云原生架构也初具规模。放眼更长远的未来，新技术创新和旧技术淘汰是必然趋势，服务网格也好，Serverless 也罢，都是云原生技术浪潮中的重要组成部分，或许有一天，这些技术将进一步相互组合使用，从而真正意义上，让用户只关注业务逻辑的设计和开发，实现 “Write Once, Run Anywhere” 的终极目标。
采访嘉宾介绍（按姓名首字母排序）：
成国柱，字节跳动 架构 / 服务框架团队负责人； 李云（花名：至简），阿里云高级技术专家，服务网格专有云负责人； 田靖，华为技术专家； 翁扬慧，网易数帆云原生团队，资深技术专家； 杨皓然（花名：不瞋），阿里云资深技术专家，阿里云 Serverless 负责人。
如果你对架构的发展有其他观察和看法，欢迎在文末留言，或加入 InfoQ 写作平台话题讨论。
