22个2022年软件开发的趋势预测及其解读

发布时间：2025-11-05 13:32:07 来源：创站工坊 作者：系统运维

Md Kamaruzzaman 是个年 Medium 的一位科技博文作者，更新频率比我强不了多少，软件但他对软件开发行业的趋读认识比我要强太多，毕竟专业出身的势预差距摆在这儿。Kamaruzzaman 个人介绍是测及一位解决方案架构师，同时也是其解一位科技作者、全栈开发，个年专注在云和大数据方向，软件base 德国。趋读

很有意思的势预一个事情是，研发同学往往并不直接与客户打交道，测及多数市场动向和认知观察也往往来自于市场部门或开发者关系，其解但技术发展的个年趋势往往却与商业化直接挂钩，这就导致了一个很有意思的软件现象，即——运营/市场拿着研发一半的趋读工资，却还要时刻掌握市场动向，行业脉搏，用工程师能听懂的语言反哺给研发，最终保证技术发展、产品迭代的路线不至于出现大的纰漏。服务器租用

这对于做开发者社区的同学来说，是先天的弊病和必须的要求，也是开发者运营同学实现个人品牌能力和增值的一大出路。所以，其实各个行业都类似，愿意保持思考，持续学习的人，总是可以跑赢很多人，研发同理。

废话不多说，切入今天的正题。

同往年一样，第一条预测依旧跟云有关，今年在基础设施这个关键词前面多出了一个集中式（Centralized）的前缀，这跟当前云计算行业的下沉还是有关系的，如果关注互联网行业比较多的人，高防服务器可能会觉得分布式云是现在的发展趋势，但其实对于正在数字化转型的非互联网行业而言，集中式的基础设施仍旧是第一选择。

2022 年，仍旧会是公有云快速发展的一年，Gartner 预测 2022 年公有云的收入将增长 16%，在互联网以外的各个行业，金融、政务、出行、工业、民生等多个行业，公有云都会得到有效的利用。所以如果你是非互联网企业的决策者或从业者，现在开始认真关注云计算还来得及。

边缘计算开始被广泛关注，大概也就是最近两年的事情，企商汇我看了一下 2019 年做的那篇趋势预测里，其实没有写边缘计算，但 2021 年的版本里已经有了。跟公有云希望将存储、计算能力和 AI/ML 集中在一个中心位置（可用区域）的特点不同，边缘计算本身是一种去中心化的方式，它希望将存储、计算能力和 AI/ML 部署在靠近用户的地方。低延迟场景(游戏)、低网络带宽(离岸站点)、无网络、监管要求、实时用例(联网车辆)、智能设备(物联网)这些都是需要边缘计算的场景。

再加上 5G 和 Web 3 等关键技术的兴起，边缘计算在 2022 及以后得到广泛采用是很合理的预判。事实上最近两年各大云厂商已经在开始有意识地推边缘计算的能力和产品了，我印象中国内几大云厂商都有相关的案例，比如我之前采访过的华为云的 KubeEdge。

Kamaruzzaman 提到了一项比较关键的动议—— “State of the Edge” ，旨在标准化边缘计算技术。“标准化”这个词是我特别敏感的一个点，因为从商业化的角度看，在没有实现事实标准之前，商业化的拓展往往是杂乱无序或者说没有核心优势的，而形成事实上或人为认定的标准以后，商业化的动向才能更为明朗。毕竟三流企业做产品，一流企业做标准。

阻碍企业上云的一大绊脚石，就是厂商锁定的问题。毕竟云厂商在商业信誉这块上，总是或多或少存在一些黑历史，要么硬盘坏了，要么剽合作伙伴方案，要么抄开源项目代码。你把企业安身立命的核心资产、数据都放在某一家云上，且不说安全的问题，以后要想迁移都是个麻烦。

所以多云、混合云的发展趋势是实实在在肉眼可见的，Kamaruzzaman 提到了很多致力于提供云服务中立性的 API 服务，比如 MinIO（兼容 S3）、Aviatrix（云原生网络）、Volterra（分布式云服务）、LightOS（云原生存储）等。

还有一点比较有意思的是，Google 正在致力于将他们的流行服务，比如 Big Query 引入到其公有云竞争对手 AWS、Azure 里，但这种现象在国内的云计算行业是否有类似案例或者说未来会不会有类似案例，我个人表示怀疑……

如果要对现代 IT 产业的关键技术做个排名，容器毫无疑问将占据一席之地。在容器化技术的普及化中，K8s 发挥了巨大的作用。背靠大厂（Google）、足够努力、精心设计、快速迭代，才有了今天成为事实标准的 K8s。

但另一方面，随着 K8s 技术的成熟，未来关于 K8s 本身的吸引力会持续减少，这有点类似于跨越鸿沟理论中的技术采用生命周期，K8s 我认为已经到了晚期大众这个阶段。所以 Kamaruzzaman 表示，K8s 已经成为现代软件开发的引擎，但也由于其本身的成熟度而导致进展缓慢。从这个角度看，有点类似于 Java。

Docker 是另一个在容器化历史进程中发挥了关键作用的技术，不幸的是，即便在全盛时期，Docker 也没有找到商业化的终南捷径，加上公司一系列的骚操作，在与 K8s 的正面对决中败下阵来。

2022 年起，Docker 宣布推出新的订阅模式，继续做着商业化的艰难探索。坦白说，这个小标题预测的结论并非定论，更多是 Kamaruzzaman 基于 Docker 的历史功绩提出的美好祝愿，我其实也一样。Docker 是我对开源行业产生浓厚兴趣的开始，希望它能有一个好的未来。​

对初创公司或者中型公司来说，网络安全就像“房间里的大象”，他们可以看到网络安全的需求，却没有足够的资源去实现他。这其实也是公有云能迅速落地下沉的一大原因，初创企业不需要自己去搭建底层的基础设施，也省去了网络安全的防护，只要部署在公有云上就行，其他的事交给云厂商。

可当云厂商遭到网络攻击，或者出现故障时，受到影响的就绝不只是一家公司而已。事实上，2021 年曝出来的云厂商高危漏洞也不在少数，2022 年公有云厂商和 Linux 都要在安全方面更努力地工作。

除了云安全，另一个常见的网络安全来源于开源软件。之前奇安信有过相关数据报告，90%的开源软件存在安全漏洞，这对于在开源软件基础上构建起来的互联网本身就是个令人不寒而栗的问题。幸运的是，高危漏洞的利用没有那么容易。不幸的是，很多世界流行的开源软件，背后的维护者甚至只有两三个人，比如 2021 年最受关注的 log4j 漏洞，影响了全世界近一半的 IT 公司。

我们需要思考一个问题，为什么世界流行的开源项目却得不到应有的收益？为众人抱薪者，不可使其冻毙于风雪。

区块链经常与加密货币联系在一起，每次有人被加密货币嘎了腰子，就有人开始痛骂区块链技术。但从技术上来讲，加密货币只是区块链技术的一个实现方式，却并非区块链的全部或唯一用例。

2021 年区块链一个非常流行的新用例是 NFT（Non-Fungible Tokens），之前勇士队球星库里花了 18 万美元买了一张 NFT 的头像就火出了圈。虽然，我也不懂这玩意儿贵在哪了……

NFT 目前更多用在数字艺术方面，但显然可以期待它未来的使用场景。从这个点延伸出去可以看到，区块链技术正在越来越为人所正视，注意是正视。IDC 预测 2022 年区块链技术的解决方案增长将达到 75%，考虑到目前该项技术的普及程度，我觉得这个数字不算盲目乐观。

区块链一个为人所诟病的点在于能源消耗，在国内双碳政策的前提下，区块链要想获得长远发展，必然还是需要做出一些改变的，像以太坊那样，在 2022 年由能源密集型的 “proof of work” 模型转向绿色的 “proof of stake” 模型。

我之前策划「稀土开发者大会」的时候，用过一句文案叫「机器都在学习，你凭什么例外」。这个点说的就是机器学习，但从实际的行业发展来看，机器学习的应用规模还是受到不小的制约，最大的原因是——搞机器学习的专家太少了。第二个原因是——大多数公司不需要完全的机器学习，有限的使用就够了。

AutoML 就是在有限情况下实现机器学习使用的一种方式。某种意义上，它就相当于低代码/无代码，不同之处在于，低代码/无代码是降低开发的门槛，而 AutoML 是降低机器学习的使用门槛。

我最近在看阿西莫夫的科幻系列，里面提到过的「机器人三大准则」、由机器人协助建立的行星文明等等故事，讲述的就是人工智能的终极目标之一——让 AI 可以和人一样聪明，甚至更聪明。但从 AI 发展的 60 多年历程里，我们离这个目标还差得远。

跟机器学习一样，深度学习在过去十年间获得了大量采用和快速增长，预计在未来仍将如此。人工智能发展的终极目标在肉眼可见的当前触不可及，但让人工智能代理在特定领域协助/增强人类还是问题不大的。

深度学习的轮子有很多，但你基本上可以只看这两个：Google 的 TensorFlow，Meta 的 PyTorch。

TensorFlow 在其 2.0 版本中进行了自我更新，并引入了动态图形、Python 友好和许多其他变化。它还提供了 Tensorflow.js 以在浏览器中使用 AI 库。其另一个创新是 Tensorflow Lite，它提供了在移动和 Web 上部署 Tensorflow 的功能。Tensorflow 还发布了 Tensorflow Extended (TFX)，这是一个用于部署生产 ML 管道的端到端平台。

PyTorch 是另一个主要的人工智能库，它引入了动态图形和 Python，对开发人员也更友好。它还发布了 PyTorch Mobile，支持在 Android/iOS 设备上使用 PyTorch。它通过 PyTorch Profiler 为开发人员提供了更多的友好性来调试大型 AI 模型。

从 Stack Overflow 的调查数据来看，TensorFlow 继续保持统治地位似乎并没有什么悬念。

过去几年间，数据库领域的一个趋势就是用一种特定的数据库去匹配特定的用例，比如：

这种方法的一个缺点是，我们经常需要为一个应用程序使用多个数据库。现在有一个新的趋势，即每个数据库将提供一个以上的模型并服务于一个以上的用例。PostgreSQL (Multi-Model)、Azure CosmosDB (Multi-Model, Multi-purpose)、SingleStore (OLAP 和 OLTP)是这些数据库的先驱。

Kamaruzzaman 介绍道，Apache Spark 几乎已经取代 Hadoop 生态系统成为默认的数据密集型计算框架。Spark 还使用相同的 API 提供接近实时的流处理。

另一个获得很多关注的开源框架是 Apache Beam，其提供了一个统一的编程模型来定义和执行数据处理管道：批处理和流处理。这个背后的身影少不了 GCP、Azure 和 AWS。

所以如果你不想用云，或许只有 Spark 一个选择。

这个点的意思跟上一条颇为类似，简单来说就是，实时流计算这里，除了 Flink 啥都不推荐。即便要在公有云上用，也建议用 Flink，感觉无脑上就行了。话说回来，确实在这个领域里我目前也没见过有能跟 Flink 掰掰手腕的轮子。

几年前，可观测性只对大型企业至关重要。然而，伴随着云本地开发和微服务架构的迅速崛起，可观测性对整个现代软件开发都至关重要。除了传统的日志记录、监控、跟踪，还需要 K8s 集群的遥测、拓扑数据等等。

其实 DevOps 这种理念一直处在持续的发展中，当它跟 AI 结合时就变成了 AIOps，当它强调安全时，就有了 DevSecOps，轮子的实现有各种形态，归根结底还是看需求是什么。

低代码/无代码（Low Code/No Code，简称 LCNC）旨在降低开发 Web/移动应用的障碍，而无需开发人员（或少量开发人员）。在未来的几年里，我们仍然需要开发人员来开发应用程序。但也有很多用例表明，低代码/无代码框架/工具确实可以显著加快应用程序开发。

整个 2021 年称之为低代码元年都不为过，这一年光是我见过的低代码创业公司就不下三五家，一场关于低代码是否业界毒瘤的争论更是引爆了行业沸点。预计 2022 年，这些场景下会有更多低代码/无代码的身影：

目前主流的后端架构有三种选择：单体、微服务和 Serverless，三者各有优势、劣势和适用的场景。对于微服务而言，其是云原生场景下绝佳的架构选择，从企业发展角度来看，不论是上云后的改造，还是云原生的架构设计，都以微服务为首选。

前端领域的程序复杂性往往受到轻视，而微前端的思想内核跟微服务是一样的，都是为了解决复杂性而生，化整为零。因此可以畅想的是，微前端也会是未来前端开发的首选架构模型，另一个好消息是，主流的 JS 框架都支持微前端。

软件开发本身很有意思的一个地方在于，开发人员不喜欢做那些乏味的、可预测的、重复的脏活累活，所以各种轮子应运而生。研发们享受的是创作解决问题的解决方案，而非享受问题。人工智能在实现终极目标之前，更多的价值往往就体现在这些地方上，比如使用 GPT-3 和 NLP 库自动地完成这些任务。

另外就是去年刚推出的一些自动生成代码的工具，比如 GitHub 的 Copilot。很多人喜欢玩梗说，AI 已经可以自己写代码，自己 Debug 了，程序员还有人要吗？但实际上目前 AI 的能力仍旧是狭义层面的，但如果你只能、只会做脏活累活，那你确实比较危险，不是吗？

我刚入行那会儿，Python 还没今天这么火，那个时候大家讨论的是 Java 和 C 语言，甚至 Go 语言在中国的热度感觉都不比 Python 差。可一瞬之间，Python 就在 TIOBE 编程语言排行榜上干到了第一名：

Python 具有简洁、解释性、动态、门槛低等特性（然而我却没学会，从入门到放弃），这些在 Python 之禅里都有很直观的体现，更关键的是，Python 并不仅仅局限在软件开发行业里，很多做数据、图表的行业同样可以用 Python 实现很多工作。加上数据科学的火热，Python 的火爆不难理解。2021 年 Python 的登顶不会是昙花一现，悬念或许在于，以后谁会把它顶下来？我个人期待 Rust。

主流的企业级编程语言，很长一段时间里代名词就是 Java。Java 的语言设计，JVM 的强大，共同构筑了 Java 生态。但在云原生兴起以来，Java 其实受到了非常大的挑战。我年前发过一条朋友圈专门聊过这个话题：

目前看有两个技术趋势会对 Java 造成比较大的影响，一个是云原生，一个是 Serverless。造成影响的原因跟 Java 语言的特性有关，这门语言设计就是为了大型应用复杂场景，而云，尤其是 Serverless，更加适合轻量化、业务逻辑简单的应用。话说回来，其实制约云原生和 Serverless 发展的，也恰恰是在大型应用复杂场景下的管理问题、安全问题。

一个好消息是：Java 社区一直在持续地迭代创新，保证 Java 的生命力。比如 GraalVM 等现代化的特性，在 Java 近几年保持周期发布的当下，凭借现代化特性的更新和严格且无与伦比的向后兼容性，你可以不用再问 Java 老矣，尚能饭否。而是，接着奏乐，接着舞！

前端三大框架早已是耳熟能详的存在：来自 Meta 的 React，来自 Google 的 Angular 和来自尤雨溪的 Vue。Kamaruzzaman 给出 React 和 Angular 会在企业中得到更多重用，而非 Vue 的原因是：前两者背靠两大企业，而 Vue 过于依赖尤雨溪，且提到了 Vue 的安全考虑。

我不知道这个安全考虑指的是软件方面的安全，还是地缘方面的安全，这里不做评价。但我想提的是，如果 Vue 在过于依赖尤雨溪的情况下，仍旧做到了如此流行，岂非更加说明 Vue 的牛逼所在？你觉得呢？

Spring MVC/Spring Boot 是 Java 里最主要的服务器端框架，它遇到的问题跟 Java 遇到的问题是伴生问题，因为 Java 受到了云原生趋势的挑战，导致了它的问题。在 Redhat 推出 Quarkus 后，云原生开发的首选框架易主，因为后者使用了 GraalVM 而非传统的 OpenJDK。终于，Spring 也声明了将发布 Spring Native，同样使用 GraalVM 进行云原生开发。

2022 年如果开发云原生 Java 应用程序，可以考虑使用 Java 原生框架。如果场景仍旧是单体 Java 应用开发，继续使用传统框架亦无不可。

移动应用开发一直是个庞大的市场，并且仍将持续膨胀下去。目前主流的移动应用开发有四种模式：原生开发、跨平台开发、混合开发和云开发。

原生开发和跨平台开发是应用最广的开发模式，前者提供了最大的灵活性，后者提供了“Write once，Run everywhere”的诱人可能。

去年写过一篇苹果发布会的文章 苹果：没想到吧，我自己做了“小程序” ，里面借着苹果生态分析了一下原生开发的发展，重点在于其软硬件的协同。Kamaruzzaman 预测 2022 年原生开发将占据主流，重点在于跨平台开发不如原生灵活。未来如何，且走且看。

现代软件开发通常是 API 驱动的开发:grin:，API 轮子可以说是多如牛毛，但知名度最高的也就这三个了：REST、gRPC 和 GraphQL。

这三个主流 API 技术，一个最古老，同时也是最成熟、最广泛使用（REST）；一个由 Google 创建，在服务和服务通信方面更快更高效（gRPC）；一个由 Meta 开发，以为特定的用例定义数据结构的形状，并在一次访问中获取所有数据。

这简直是完美体现软件开发没有银弹一词的场景，各有各的擅长，也各有各的弊病，企业按需使用，每个轮子都有前景。我们都有光明的未来！

相关文章