软件架构如何“以不变应万变”

软件架构的概念最早可以追溯到上个世纪六七十年代，计算机大神 Dijkstra 很早就涉足这一领域，但软件架构真正流行却是从上世纪 90 年代开始。对技术人而言，架构是再常见不过的词汇量，但如果去让他们深入解释架构，就会发现大多数人都无法清楚描述。翻开维基百科软件架构的定义，我们会发现它的概念也比较模糊。

维基百科：“软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软件组件、组件之间的关系，组件特性以及组件间关系的特性。软件架构可以和建筑物的架构相比拟。软件架构是构建计算机软件，开发系统以及计划进行的基础，可以列出开发团队需要完成的任务。"

对于软件架构，不同的人有不同的理解，而且自其出现后也是引起了不少的争议。今天我们就借着 InfoQ 15 周年的机会盘点一下架构这 15 年来的主要变化。希望可以从架构的演进中获得一些经验和启发，给大家带来不一样的思考。

过去十几年，随着互联网发展以及业务的多样化，系统的架构也在不断发生变化，总体上来说大体经历了从单体应用架构 - 垂直应用架构 - 分布式架构 -SOA 架构 - 微服务架构的演变，当前各大企业都在朝着数字化转型和云原生方向前进。本文结合采访嘉宾的经验仅从业务和架构设计两个视角解析架构过去十五年的演进变化，如果你有不同意见，欢迎留言讨论。

"业务驱动与基础设施的进化推动架构发展”

“架构要解决业务需求的问题，业务需求的变化驱动着架构的进化”。谭待在采访时说道。从互联网的角度出发，结合业务的主要变化，国内软件架构这 15 年的发展大致可以分为三个阶段。

第一阶段，互联网正式爆发。这一阶段的特点是网页与用户数据的迅速增多，无论是当时流行的搜索引擎、社交网络，还是工业、电商等行业，互联网的爆发带来的数据量是传统的单机和简单的架构模式无法支持的，传统的架构也无法解决相应的业务问题。

因此，软件架构就慢慢从原来的单机系统演变成分布式系统以解决新业务形态带来的问题，诸如在架构层面考虑容错、负载均衡等问题。同时需要注意的是，也正是这个时候开启了后来所谓的大数据时代。

第二阶段，移动互联网的兴起。移动互联网兴起之后，互联网业务的形式又随之发生了比较大的变化。PC 互联网时代比较典型的一个例子就是搜索引擎，搜索引擎对时效性要求并不是特别高，对用户来说只要能找到所需要的内容即可，不追求实时在线，这个时候架构更多解决的是吞吐量大的问题。移动时代则不同，推荐、个性化服务已经成为更主流的方式，业务的场景也变成了对实时性要求非常高的情况。

这一阶段架构方面主要的变化就是计算从以前的批量计算变成了流式计算，数据处理从离线变成实时，比较典型的例子就是 Hadoop 到 Spark，再到后面 Flink 的变化。这其中的变化就涵盖了系统架构对用户数据的处理、文档数据的处理、推荐、广告算法等等，这个时期业务对架构的范式要求更高。另外，这一时期硬件等基础设施的大幅提升与大规模的应用，也对架构的演进起到了非常大的推动作用。

第三阶段，云原生时代。也就是当下，企业上云对许多公司来说已经变成一种默认行为。这个时候业务架构就需要基于云原生进行改造，如何基于云组件做适配，如何合理使用云的弹性、计算存储分离等功能也变的至关重要。如果继续使用老的业务架构跑在云上，那无异于“拉着马车跑在高速公路上”。

云原生出现之后还衍生了一个有趣的现象，在云原生到来之前，企业软件架构与互联网软件架构是分离的，现在这两者已经开始慢慢交融在一起。传统的厂商需要进行数字化转型，其面临的业务需要互联网化，要解决高并发、大吞吐等问题，势必要采用互联网架构。互联网公司经过多年的发展壮大，内部运营管理上也会面临传统企业的问题，比如如何解决开发效率，如何解决新老系统并存，如何进行数据打通等等。

总的来说，业务场景的需求变化驱动着架构的演进。PC 互联网时代、移动互联网时代、云原生时代（数字化转型时代）的业务需求是不同的，也就对不同时期的架构提出了更多的要求。另外软硬件等基础设施的创新和开源价值的体现等也都对架构的演进起到了非常大的助推作用。

上面我们从业务的角度盘点了架构的一个大概演进史，过去十几年，软件架构发生了非常大的变化。从互联网到移动互联网再到云原生，这个过程对软件架构的影响是巨大的，尤其是云的出现，它不再需要我们去构建基础设施，这几个阶段都改变了软件架构也改变了我们如何去构建软件。但是，尽管软件架构的形态发生了明显的变化，其实软件架构本身的目的却从未改变。

回到文章开头我们提到的关于软件架构定义的争议，蔡超认为，软件架构从出现到定位一直是一个颇具争议的词，目前唯一能够明确的只有它的目标。软件架构的目标则是，第一，加快软件发布；第二，减少整个软件生命周期（设计，实现，持续迭代、线上发布维护等）中的资源投入，包括人力资源、软硬件资源等。

同时，如同 10 多年前，处理好业务复杂性的业务领域建模，实现系统非功能性需求的架构领域的设计模式 / 风格（如：micro-kernel, whiteboard，pipe-filter 等模式）至今也同样还是架构师的必备知识，不同可能只是他们基于不同基础设施的具体实现方式。十年前我们做架构一样会考虑可维护性、可扩展性、高可伸缩性，可扩展性，现如今依然需要考虑这些。关于研发团队组织结构，诞生于 1964 年的康威定律现在依然在指导我们进行软件开发团队组织结构建设 -- 让团队结构与系统结构相匹配（如：与微服务匹配的 two-pizza team）。这些从未改变的东西恰恰是架构领域非常重要的内容。

提到微服务最近几年的一些变化，第一个比较重要的点就是微服务会促进大家逐渐去用更加高效的语言。以 Golang 举例来说，Golang 特别适合在云原生场景下使用，一方面 Golang 没有 Java 那么重的启动的依赖，另一方面容器也提供了一套相对统一的执行环境，这种场景下是没有必要再去使用字节码的。而 Golang 的广泛应用也解决了一些开发效率上的问题。

第二点就是在多运行时、Service Mesh 上的一些改变，做业务和基础设施的解耦，这给基础设施提供了更大的发展空间，对于业务和技术能力的迭代都有着非常重要的价值。第三点比较大的变化就是构建可观测性，比如 Tracing 或者 OpenTelemetry。

而说到挑战，诚然服务治理、弹性伸缩等等确实是微服务所遇到的挑战，但微服务最大的挑战却并不在技术上，用采访专家的话说“微服务最大的挑战是大家没有意识到微服务的挑战有多大”。除了技术，企业和程序员正确使用微服务架构，本身就是微服务最大的挑战。第一，你需要正确使用场景，真正了解微服务带来的复杂性，了解服务划分会带来的问题；第二，微服务对于组织结构也有一定的要求，它要求自治的团队，如果你是强耦合的组织结构，那么首先就不符合康威定律，组织结构和系统架构就有着巨大的冲突。所以正确理解微服务的理念，正确使用微服务，是企业目前最大的挑战。

解决认知挑战后，在技术上，企业针对微服务应主要在这些方向投入，主要有几个部分，首先就是构建各类平台化能力，包括调度的能力、服务治理的能力；第二，尝试对成本优化进行更深入的研究；第三，在多运行时架构上持续投入。微服务未来的研发重点：微服务的各类能力规范化（RFC）、多运行时、成本优化：各类深度技术应用；开发效率：Rust wasm 等；智能化流量治理等。

展望架构的未来，还是需要关心整个行业业务发展的情况，企业和架构师必须知道未来要解决的问题是什么？业务层面会产生什么变化？这些变化会对底层架构带来什么影响？

云原生技术的发展势不可挡，势必会成为未来的热门话题。随着数字化转型加速，企业对于云的使用也将会达到新的水平，云原生架构和云原生应用也将会持续迭代演进。

三年前 IDC 做过一份预测，他们发布的《数字化世界 -- 从边缘到核心》白皮书以及《IDC：2025 年中国将拥有全球最大的数据圈》白皮书有这样一项结果。人类每一年新创造的数据都超过了过去千年的总和，到 2025 年数据将达到惊人的 175ZB，中国数据圈将增至 48.6ZB，占全球 27.8％，成为全球最大数据圈，而且这种增长没有显现出任何缓和的趋势。越来越多的数据，使用方式的不同，规范使用和隐私管理，边缘需求等等都会给架构带来更大的挑战。

除此之外，现阶段业务上超大流量的上涨对计算资源的消耗也是巨大的，扩展虽然没有问题，但扩展的过程会带来非常大的损耗，另外业务与基础设施解耦带来的问题切分、信任等等也是架构目前遇到的主要挑战。

除了技术上的挑战，企业遇到的问题同样不可忽视。数字化给传统企业带来了无限的能量，在企业都进行数字化转型的大背景下，做好传统企业架构和所谓的互联网架构的融合至关重要，这就需要考虑多个层面的问题。

首先，企业对外的业务如何通过互联网数字化等方式做得更好，在面临大规模高并发的秒杀活动等业务时如何处理。如何利用互联网架构解决实时性、大规模、高并发的问题。其次，企业对内需要使用数字化提升效率，打通各种老系统，数字化自己的内部人才，将传统与互联网和云更好的融合。

除此之外，软硬件关注基础设施层面的创新也至关重要，正所谓”巧妇难为无米之炊“，基础设施如果不具备条件，业务需求也就无法实现。在云原生时代，基于云的基础设施设计新的架构就是重中之重，如何将云的基础特性更好地释放，将弹性扩缩容，成本优化、可观测性等等处理好都是需要重点关注的。此外，在业务变多系统架构变得复杂的同时利用类似低代码或者新的 aPaaS 等技术将效率提高，更快的完成交付。最后就是企业需要在系统增多之后，重点关注系统治理、微服务治理和技术债务等问题。

成为优秀的架构师是每个技术人的初级梦想，面对挑战，如何在未来的云原生时代中屹立不倒，除了需要过硬的基础技术，其他能力也不可或缺，关于架构师的成长蔡超老师总结了以下几点经验。

第一，坚持编码。架构师也是程序员，代码是软件的最终实现形态，停止编程会逐渐让你忘记作为程序员的感受，更重要的是忘记其中的“痛”，从而容易产生一些不切实际的设计。大家可能听说过在 Amazon，高级副总裁级别的 Distinguish Engineer（如：James Gosling，Java 之父），他们每年的编码量也非常大，常在 10 万行以上。

第二，坚持学习。对于 IT 人而言忙碌已成为了习惯，加班常被挂在嘴边。“996”工作制似乎也变成了公司高效的标志。而事实上过度忙碌会导致你没有时间学习和更新自己的知识，进而逐渐落后。

另外，除了要勇于去关注技术上新的变化，同时还要有更多思考的角度，重点思考那些历经多年真正不变的技术和理念。

篇幅有限，更多建议推荐阅读：一位架构师的感悟：过度忙碌使你落后（https://www.infoq.cn/article/dyceqhlrbgzkzdvk3esd）

推荐书籍：
《Pattern Oriented Software Architecture》
《Patterns of Enterprise Application Architecture》
《Design Pattern》
《The Design of Design》

架构设计是一个企业的重中之重，云原生时代与数字化转型的到来，给架构提出了更高的要求，如何正确使用相关技术，帮助企业在云原生数字化转型时代站稳脚跟释放更多的能量是当前的巨大挑战。毫无疑问，软件领域发展至今仍有大把机会等待着程序员与架构师去开疆扩土。同样的，无论技术如何演进变化，无论我们使用何种架构和技术，初心不可变，我们最终的目的是为了简单高效的实现业务需求，以需求为核心找到适合自己和企业的技术才是最明智的选择。

嘉宾介绍：（按姓名首字母排序）

蔡超：Mobvista 副总裁兼首席架构师。拥有超过 15 年的软件开发经验，其中 9 年任世界级 IT 公司软件架构师 / 首席软件架构师。

成国柱：字节跳动 架构 / 服务框架团队负责人。

谭待：火山引擎总经理，在云计算和搜索引擎领域有十几年研发经验。2007 年至 2019 年期间就职于百度，曾担任百度搜索和基础架构首席架构师。2020 年加入字节跳动，领导火山引擎开拓企业级市场。

参考链接：

https://zh.m.wikipedia.org/zh/%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84

https://www.infoq.cn/article/dyceqhlrbgzkzdvk3esd

https://www.infoq.cn/article/r9vtub0robioghjeu5ti

https://www.infoq.cn/article/Cx1Mokk6WCFIeduMedFw

点击【阅读原文】送祝福进群解锁超多福利~