本文来自微信公众号“twt企业IT社区”，作者/汪照辉，中国银河证券架构师，专注于容器云、微服务、DevOps、数据治理、数字化转型等领域，对相关技术有独特的理解和见解。擅长于软件规划和设计，提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等内容，受到了广泛关注和肯定。
近期NVIDIA发布了新一代架构的GPU Blackwell，采用多芯片封装设计，同样的模型训练所需GPU数量和能耗约只是原来的25%。大模型的应用促使企业采购大量的GPU服务器，但也对传统数据中心的电力、制冷等带来挑战。需求驱动新技术的创新和应用，新技术应用也会带来新的问题，又驱动新的技术和方法来解决出现的问题，从而形成循环螺旋向前发展的趋势。在数字化时代，面对敏捷响应、业务转型等众多目标要求，认识并深刻理解IT架构的演进方向和趋势，知其然并知其所以然，是企业数字化生产力转型的关键。
随着IT技术的创新和发展，逐步地能满足不同的业务场景需求，也驱动着IT架构不断地演进中，因此IT系统的更新和迭代是一种常态。
IT系统初期架构
信息化初期，受限于当时的软硬件技术，只能采用简单的信息系统代替人工完成计算、存储等能力。信息系统的所有功能代码部署在一台服务器中，就是最早的单体系统架构。单体架构指的是IT系统的部署架构，单体架构的应用程序的业务逻辑往往紧密耦合，系统的所有功能必须部署为一个单元，难以拆分，导致了高度耦合的体系结构。随着时间和功能的累积，单体系统功能往往会越积越多，成为难以修改和变更的单体巨石应用。
随着硬件、软件和网络等技术的发展，出现了一个server并行支持多个client访问的Client/Server架构模式，这是初始的二层分布式模式。软件研发人员将前端功能和数据存储分离，形成前端+数据库的二层模式，满足不同用户根据授权从多个客户端访问同一个功能的需求。随着互联网技术的出现和应用，一个浏览器就可以访问互联网上的内容，称为B/S架构模式。虽然B/S模式下的Server端可能也分离出并访问数据库，但从互联网整体模式上，WebServer和数据库是运行在数据中心的机器上，而用户接口运行在用户的浏览器上，因此还是看作是二层架构。随着软件高级开发语言能力的增强和软件研发框架的出现和增多，软件系统的层次演进为三层架构或多层架构。表示层使用php、jsp、asp、javascript、html等实现，应用逻辑层封装在应用层，数据库访问封装在数据层，Java的MVC等是非常典型的三层架构框架。初期IT系统需求相对简单，只侧重一个单点领域功能，比如财务管理等，几乎所有功能堆积在一起，基本上没有架构的概念，至多实现代码或函数的复用，随着系统需求的扩展和复杂度增加，逐步进行了架构分层、模块分解等。随着系统建设数量越来越多，系统间共享成为迫切需求。
共享复用驱动集成
IT技术和软件系统的出现驱动每家公司都逐步建设了众多的单体系统，比如说人力、财务、办公、客户管理、供应商管理等，解决了企业单点的效率问题。但随着时间的推移，单体系统建设的越来越多，企业业务流程可能会涉及散落于各个单体系统中的数据，系统之间数据的共享需求越来越多，由于这些系统可能不同的厂商提供的，从而也带来了架构不同、开发语言不同、数据结构不同、技术路线不同等众多异构系统间数据共享难题，系统与系统之间彼此隔离，数据形成孤岛。早期的二层或三层架构等理论上是一种分布式单体架构，虽然进行了分层，却依然是紧耦合的。另外，供应商往往为了突出自己的系统功能支持多个场景，不断增加和扩展系统功能边界，都希望自己提供的系统尽可能多的满足客户需求，从而也造成多个系统都有类似的功能。不但造成重复建设，也使系统之间的集成和共享复杂化。
为了实现这些单体竖井系统之间的数据共享和功能复用，不得不去做系统集成。系统间数据共享需求驱动了系统间的集成，驱动从DBLink到EAI、消息集成、SOA服务化等多种集成方式的出现和发展。不过系统集成是一种加层补丁方式，如ESB，会导致整个业务链路加长，性能和效率降低。
复用和敏捷变更驱动系统分解和组件重构
随着使用的深入以及系统集成需求，企业往往会提出一些定制化的需求，从而使系统的版本不断迭代，功能越来越多。随着功能的增多，系统越来越复杂，变更迭代的难度越来越大，变更速度就越来越低，早期的系统往往没有规划组件架构关系，彼此之间是紧耦合的，牵一发动全身，某一个点的更新可能会影响到其他功能的正常运行，也就导致开发人员不敢轻易变更。特别在开发人员变化之后，后续的开发人员对前期代码的不熟悉，很容易导致系统的重大异常或数据错误，从而带来损失。
为了解决重复建设的问题，将一些共用的能力或模块分离出来实现复用。复用有很多层次，比如说代码复用、函数复用、类复用、服务复用、组件复用、平台复用等等，不同的发展阶段复用的层次也不一样。最初通常通过代码复制实现代码复用或者定义函数来实现代码的复用；在面向对象编程后更多采用类、包/组件复用的方式；系统集成越来越多的使用组件复用和服务化服务复用等。比如将消息处理分解为一个消息中间件工具，日志处理分解为日志中间件工具等。这也促使单体系统的分解，单体系统架构逐步分拆为分布式架构，最终成为当前的分布式微服务架构。当然也是基于技术的创新和发展能够支持分布式的系统交互。在一台服务器无法再纵向扩展支撑越来越多的业务请求时，就需要解析单体架构为分布式架构，将功能模块进行分解，逐步沉淀为一个个组件或工具，比如日志平台、权限认证平台、基础设施平台等。
资源复用驱动资源池化、云化和基础设施融合
为了充分利用资源，提升资源利用率，存储资源池、网格计算、并行计算、虚拟化等技术的发展，使计算、存储、网络等能够统一管理和分配调度。互联网的巨大需求也使通过网络提供各种服务的云计算迅猛发展。虚拟化和云计算使应用所需的计算、存储、网络等资源更容易提供，在这个过程中存储资源池、虚拟化、超融合、多云管理等也逐步实现了基础设施资源的融合，从而从基础设施资源层屏蔽了异构基础设施资源细节，提供标准化的基础设施资源服务。这也使当前的平台工程成为可能。
随着云计算分层服务能力的完善，应用和基础设施完全分离，甚至多家云厂商提供了无服务器Serverless架构模式，云成为企业业务应用系统研发和部署运行的底座。不过Serverless往往受限于云厂商所提供的框架和能力，而微服务粒度的敏捷迭代、可复用的服务化架构基于云平台的自动化构建和部署运行受到了更多企业的关注和应用。基于云底座研发和部署微服务架构的应用，实现自动化的部署和运行运维管理等能力，从而也促进了云原生体系的构建和应用。
企业级复用驱动“中台架构”出现
随着企业规模的增长，为了实现企业级功能和数据复用，国内厂商提出了“中台”的概念。但“中台”没有明确合适的可复用粒度，使“大中台”过于笨重，导致不得不“拆中台”。中台架构的核心在于定义可共享复用的粒度。共享和复用有不同的粒度，粒度过小则难以管理，比如函数级的粒度，会导致量过大而难以管理；粒度过大，则增加额外的对接和封装工作量，比如以整个系统或工具为粒度，都需要基于该系统或工具的接口或API进行额外的对接，而且一旦版本或工具变更，所有的工作都需要重新做一遍。
以抽象、提取可共享可复用的企业级微服务作为中台层，支撑这些服务的平台和工具作为后台层，中台层的微服务来自于后台的工具和平台能力的抽象和沉淀，而不是直接依赖于后台工具和平台的API。简单的说，就是需要在后台平台和工具之上封装一层微服务作为企业级可复用中台层。这样，即便后台工具版本变更或工具替换，也可以不影响前台的业务应用。这就明确中台的可复用粒度和可复用服务来源。中台架构尝试以连通、融合企业内各业务条线的数据和基础设施能力，形成联动，从而减少重复建设、提升响应能力。服务化和中台融合，从而可以实现以微服务粒度为单位的企业级复用能力，也因此可以以PaaS平台为依托，支撑云原生可复用中台微服务的部署、运行、高可用、可观测性、韧性等。云原生容器提供了一致性环境、弹性伸缩、轻量、无状态等特性，契合微服务的敏捷变更需求，从而也促进了云原生架构的进一步应用和发展。
云化驱动云原生的出现和应用
云计算提供了敏捷的、自服务的、不变的基础设施等内容，使业务应用上云逐渐成为一种共识，但不进行云原生架构重构而直接上云可能是危险的。传统业务应用架构无法在云上进行弹性扩展和敏捷响应，无法有效利用云计算的特性赋能企业，所以这需要对传统架构的业务系统进行分布式微服务分拆重构，部署运行在容器平台之中，使用DevOps思想通过CI、CD等提升持续交付效率，等等。使应用从一开始被创建就具备云的特性，为云而生，它是为了充分利用云计算的分布式和弹性扩展等特征，使其具备或适应云上部署运行的要求，或者直接用云的思想、方法、工具在云中创建，天生具备云的特性。所以云原生可以认为是一种基于云来构建和运行云应用程序的方法论和技术体系，使用云原生技术和方法论来构建和运行管理云上应用。
架构演进趋势
从单体架构到云原生，IT架构从出现到现在一直是不断的分解过程中，分解的越来越细，但彼此之间却又不断地集成、融合。因为分解的越来越细，使相互之间的依赖加深。如果架构定义不好，往往导致影响面巨大的事故，比如多个大厂的持续故障就是在于整体架构存在局限。IT系统在不断分解融合的过程中，需要越来越关注架构的设计和健壮性。
架构演进趋势和社会化分工发展趋势是一致的。专业化分工提升效率，但也彼此依赖加深，但一体化融合的架构是不可逆的，就像全球化，虽然不少人反全球化，但总的来说，全球化更符合大多人的利益，更符合资源的最大化配置。因此，对于一家企业来说，需要考虑企业级的一体化融合架构。我以前也提到过，我们都习惯于做加层，导致整个系统的架构体系越来越复杂，系统中的垃圾也越来越多。一个应用动不动就是几个G，可能不必要的组件就占了一大部分。这也导致了额外的风险和潜在故障。多一个组件就多一个故障点，复杂度就增加一分，因此，在考虑企业级一体化架构时，需要尽可能消除不必要的组件，简化组件功能，使每个组件成为一个自治的单体，同时又是整个体系的一部分。每个组件的故障不应影响和导致其他组件不可用。每个组件都是可替代的。
总的来说，科技在不断的进步，促进了业务的创新和发展以及社会的发展，而系统架构也在持续的演进，但总的趋势和方向趋同于人类社会的发展趋势。
