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


总的来说,业务场景的需求变化驱动着架构的演进 。PC 互联网时代、移动互联网时代、云原生时代(数字化转型时代)的业务需求是不同的,也就对不同时期的架构提出了更多的要求 。另外软硬件等基础设施的创新和开源价值的体现等也都对架构的演进起到了非常大的助推作用 。
以不变应万变
上面我们从业务的角度盘点了架构的一个大概演进史,过去十几年,软件架构发生了非常大的变化 。从互联网到移动互联网再到云原生,这个过程对软件架构的影响是巨大的,尤其是云的出现,它不再需要我们去构建基础设施,这几个阶段都改变了软件架构也改变了我们如何去构建软件 。但是,尽管软件架构的形态发生了明显的变化,其实软件架构本身的目的却从未改变 。
回到文章开头我们提到的关于软件架构定义的争议,蔡超认为,软件架构从出现到定位一直是一个颇具争议的词,目前唯一能够明确的只有它的目标 。软件架构的目标则是,第一,加快软件发布;第二,减少整个软件生命周期(设计,实现,持续迭代、线上发布维护等)中的资源投入,包括人力资源、软硬件资源等 。
同时,如同 10 多年前,处理好业务复杂性的业务领域建模,实现系统非功能性需求的架构领域的设计模式 / 风格(如:micro-kernel, whiteboard,pipe-filter 等模式)至今也同样还是架构师的必备知识,不同可能只是他们基于不同基础设施的具体实现方式 。十年前我们做架构一样会考虑可维护性、可扩展性、高可伸缩性,可扩展性,现如今依然需要考虑这些 。关于研发团队组织结构,诞生于 1964 年的康威定律现在依然在指导我们进行软件开发团队组织结构建设 -- 让团队结构与系统结构相匹配(如:与微服务匹配的 two-pizza team) 。这些从未改变的东西恰恰是架构领域非常重要的内容 。
微服务的突破、挑战与未来
提到微服务最近几年的一些变化,第一个比较重要的点就是微服务会促进大家逐渐去用更加高效的语言 。以 Golang 举例来说,Golang 特别适合在云原生场景下使用,一方面 Golang 没有 JAVA 那么重的启动的依赖,另一方面容器也提供了一套相对统一的执行环境,这种场景下是没有必要再去使用字节码的 。而 Golang 的广泛应用也解决了一些开发效率上的问题 。
第二点就是在多运行时、Service Mesh 上的一些改变,做业务和基础设施的解耦,这给基础设施提供了更大的发展空间,对于业务和技术能力的迭代都有着非常重要的价值 。第三点比较大的变化就是构建可观测性,比如 Tracing 或者 OpenTelemetry 。
而说到挑战,诚然服务治理、弹性伸缩等等确实是微服务所遇到的挑战,但微服务最大的挑战却并不在技术上,用采访专家的话说“微服务最大的挑战是大家没有意识到微服务的挑战有多大” 。除了技术,企业和程序员正确使用微服务架构,本身就是微服务最大的挑战 。第一,你需要正确使用场景,真正了解微服务带来的复杂性,了解服务划分会带来的问题;第二,微服务对于组织结构也有一定的要求,它要求自治的团队,如果你是强耦合的组织结构,那么首先就不符合康威定律,组织结构和系统架构就有着巨大的冲突 。所以正确理解微服务的理念,正确使用微服务,是企业目前最大的挑战 。
解决认知挑战后,在技术上,企业针对微服务应主要在这些方向投入,主要有几个部分,首先就是构建各类平台化能力,包括调度的能力、服务治理的能力;第二,尝试对成本优化进行更深入的研究;第三,在多运行时架构上持续投入 。微服务未来的研发重点:微服务的各类能力规范化(RFC)、多运行时、成本优化:各类深度技术应用;开发效率:Rust wasm 等;智能化流量治理等 。
2回顾当下,展望未来
展望架构的未来,还是需要关心整个行业业务发展的情况,企业和架构师必须知道未来要解决的问题是什么?业务层面会产生什么变化?这些变化会对底层架构带来什么影响?
云原生技术的发展势不可挡,势必会成为未来的热门话题 。随着数字化转型加速,企业对于云的使用也将会达到新的水平,云原生架构和云原生应用也将会持续迭代演进 。
三年前 IDC 做过一份预测,他们发布的《数字化世界 -- 从边缘到核心》白皮书以及《IDC:2025 年中国将拥有全球最大的数据圈》白皮书有这样一项结果 。人类每一年新创造的数据都超过了过去千年的总和,到 2025 年数据将达到惊人的 175ZB,中国数据圈将增至 48.6ZB,占全球 27.8%,成为全球最大数据圈,而且这种增长没有显现出任何缓和的趋势 。越来越多的数据,使用方式的不同,规范使用和隐私管理,边缘需求等等都会给架构带来更大的挑战 。


推荐阅读