1.3　数字化云原生时代来临

企业架构可以助力企业数字化转型的规划和建设，其中企业IT架构是承接企业IT战略、对齐业务架构，以及具体IT项目落地的核心枢纽，让我们一起来看看企业IT架构的演进、云原生的核心技术及企业云原生架构如何助力数字化转型。

1.3.1　企业IT架构的演进

企业IT架构经过长期的发展，涉及企业整体的IT规划，企业IT架构的总体框架如图1-12所示，主要包括IT架构蓝图、IT架构内容规划、IT架构规范、IT架构行业参考、IT架构原则等，同时聚焦于企业应用架构、数据架构和技术架构。

企业IT架构经历了几次比较大的技术演变，对企业应用、数据、技术的选型有着深远的影响。企业IT架构主要经历了如图1-13所示的集中式架构、SOA、微服务架构及云原生架构的演变，在这个过程中，伴随着分布式、服务化、互联网、云计算、大数据、人工智能等技术的变革，企业的业务和技术都得到了质的提升。

1）集中式架构

集中式架构又称单体架构，在互联网和云计算并未大规模兴起时，这个架构十分流行。进入21世纪以来，基于Web应用的B/S架构逐渐取代了基于桌面应用的C/S架构。B/S架构的后端系统大多采用集中式架构。

2）SOA

SOA是分布式架构的代表，阐述了对于复杂的企业IT系统应按照不同的、可重用的粒度划分，将功能相关的一组功能提供者组织在一起为客户提供服务，目的是解决企业内部不同IT资源之间无法互通而导致的信息孤岛问题。

3）微服务架构

微服务架构严格意义上讲是对SOA的进一步抽象总结，突出将服务划分成更细粒度的微服务。各个微服务之间是松耦合的，彼此可以独立升级、部署、扩展和重新启动，并通过标准协议和接口保持互通。

4）云原生架构

云计算改变了传统IT行业的消费和服务模式。云原生架构将充分发挥云计算的技术红利，最大化剥离非业务代码，并提供大量的非功能性需求，让云计算变得标准、简单高效、触手可及。

1.3.2　从集中式架构到SOA

集中式架构分为标准的三层：数据访问层、服务层和Web层。数据访问层用于定义数据访问接口，实现对真实数据库的访问；服务层用于对应用业务逻辑进行处理；Web层用于处理异常、逻辑跳转控制及页面渲染等。服务层是整个系统的核心，它既可以直接提供公开的API，也可以通过Web层提供API，同时服务层可以屏蔽底层实现细节。

集中式架构主要有业务和技术两个层面的问题。

（1）业务层面。大部分企业的信息系统并没有做到这一点——拉通信息系统，重塑组织协同，因为大部分系统都是从外部采购或者由外包公司开发的，由不同的团队进行维护，从而形成“烟囱式”系统，格式不一致，无法拉通和协同。比如，一个传统企业从外部采购了CRM、MES、ERP、HR、OA、PLM、SCM、WMS等系统，但是这些系统各自独立，各有各的数据库，各有各的权限管理。

（2）技术层面。随着X86硬件体系的成熟，很多应用抛弃昂贵、臃肿的大中型机，转向集中式架构。但随着应用规模迅速增长，集中式架构已无法无限制地提升系统的吞吐量，只能通过增加服务器的配置有限地提升系统的处理能力，但会到达垂直伸缩瓶颈。

为了解决集中式架构的问题，分布式架构应运而生。分布式系统指的是多个机器之间通过网络进行交互，从而实现一个共同的目标。利用分布式框架，一个业务可拆分为多个子业务，并部署在不同的服务器上，从而实现功能拆分、模块独立、方便扩展，进而通过集群分担压力并提高效率。在分布式架构中，当系统规模达到一定量级之后，要重点关注高性能、高可用、可扩展、成本、安全等方面。在分布式架构发展初期，诞生了很多典型的技术，如CORBA、EJB、RPC、SOA等。

分布式架构的典型代表是SOA，即面向服务架构。SOA旨在将IT资源整合成基于标准服务且能够重新组合的服务。SOA强调服务化，以接口契约定义彼此的关系，以标准协议确保彼此的相互连接，通过企业服务总线（Enterprise Service Bus，ESB）实现不同系统之间不同接口的调用。

虽然SOA相比集中式架构有了质的改变，但还是无法支撑业务的快速创新。同时，SOA也带来了额外的技术复杂度，如在CAP定理中，互联网应用往往偏向可用性而舍弃强一致性，通过最终一致性来实现。另外，ESB的交换方式本质上并没有打通数据孤岛，数据在各个系统还是有孤立、重复的情况。

1.3.3　从SOA到微服务架构

2014年，微服务概念被Martin提出，进而开始广泛流传。从本质上来看，微服务既是SOA的进阶和升级，也是SOA的进一步抽象总结，尝试通过更细的服务粒度来解决SOA带来的问题。另外，随着互联网的飞速发展，人们发现在SOA中常使用的传统IOE架构已经不能满足海量业务规模的并发要求，于是产生了Spring Cloud、Dubbo等微服务框架。

微服务是指将大型复杂软件应用拆分成多个简单应用，每个简单应用描述一项小业务，并进而拆分为更细粒度的微型服务，每个服务独立运行，服务之间采用RESTful API等轻量级通信机制。服务可以使用不同的开发语言和数据存储技术。微服务的核心是消除单点。各个微服务之间是松耦合的，可以独立升级、部署、扩展和重新启动，并通过接口契约、标准协议等保持彼此互通，从而实现频繁更新而不会对最终用户产生任何影响。

相比集中式架构，微服务架构有很多优势，如交付速度更快、故障隔离范围在更细粒度的进程级别，可用性由于服务的有效隔离粒度而更高，架构持续研究更简单、技术栈更灵活、可扩展性更强、可重用性更高、对业务的响应更快。

当然，由于服务拆分导致要维护的微服务数量增多，微服务也带来了一些弊端，如资源成本增加、运维复杂度提高、对开发人员的技能要求和对团队组织结构的要求提高。在服务治理和运维方面，微服务需要更加关注配置管理、服务发现、负载均衡、弹性扩缩容、分布式调用链路、日志监控、自愈恢复等技术细节。

1.3.4　从分布式架构到云原生架构

分布式系统带来的运维和管理成本、开发和部署周期等，促使云计算逐步普及。云计算改变了传统IT行业的消费和服务模式，实现了从产品向服务的转变，并通过互联网自助式方式，提高了效率和敏捷度。云计算的具体应用模式主要有SaaS（软件即服务）、PaaS（平台即服务）及IaaS（基础设施即服务）。如今，云计算已经是国内外互联网“大厂”的必争之地，Amazon AWS、Microsoft Azure、阿里云、腾讯云、华为云、金山云、百度云、京东云等纷纷涉足云计算。

云计算已经进入高速发展阶段，云计算是云原生等创新技术的重要载体和试验场。在数字经济浪潮中，传统行业的数字化转型，已成为云原生产业发展的强劲驱动力。笔者在阿里云做云原生解决方案架构师的时候，经常遇到客户问什么是云原生？对企业有什么好处？怎样结合云原生进行架构设计？总体而言，云原生能够帮助我们实现业务应用与基础设施的解耦，因此其被看作新一代云计算的“操作系统”。

云原生的概念由Paul Fremantle于2010年在一篇博客中提出，他的目的是构建一种符合云计算特性的标准来指导云计算应用的编写。2015年，Matt Stine在《迁移到云原生应用架构》中推广了云原生概念，提出了符合云原生架构的几个特征：“12要素”、微服务、自服务、基于API协作、抗脆弱性。2015年，云原生计算基金会（Cloud Native Computing Foundation，CNCF）成立，其把云原生定义为容器化封装+自动化管理+面向微服务；2018年，CNCF对云原生的定义增加了Service Mesh和声明式API。

不同的组织对云原生的定义有所不同，即使同一组织在不同时期对其定义也不同，目前云原生还没有标准定义。云原生从字面上看是Cloud+Native，即云计算+土生土长，也就是让我们的业务“土生土长在云上”。首先，从Cloud的角度来理解，云本质可以看作一种提供稳定计算存储资源的对象，而云资源的一些基本属性，如虚拟化、弹性扩展、高可用等赋予了云原生“云”的含义。然后，从Native的角度来理解，就是需要让我们的应用在最初的时候就基于云的特点来设计，云原生应用和传统在云上运行的应用有所不同，传统业务属于“外来人口”，而在上云“落户”的过程中，并不是简单地部署到云上就万事大吉了，设计模式、架构思想、研发体系、组织文化等都需要按照云原生来进行变革。比如，云是一种分布式架构，我们的应用也要基于分布式架构，而微服务、Service Mesh或者Serverless这种将服务或函数拆分成一个个模块的松耦合系统提供了这样的机制。同时，这位“土著居民”的生命周期，从设计、开发、部署到运维都应该是基于云的理念来实现的，需要容器或者DevOps来实现。另外，针对多种云端，云原生应用也可以进行很好的连接。

云原生技术和产品体系分为两个层面，如图1-14所示。其一是Cloud Hosting部分，即生长于云，也就是将系统和应用部署在云上，比如通过云计算的计算、存储、网络等服务，围绕基础设施的成本和性能、应用架构的稳定性、开发运维的效率等，让系统更加易于运维、成本最小化性能发挥到极致。其二是Cloud Native部分，即云原生技术和产品，需要基于云原生的相关技术对业务和系统进行改造，这些技术和产品包括容器服务、微服务治理、Service Mesh、Serverless、DevOps、数据库、消息、中间件等开放标准的原生产品服务，让系统更加弹性、可靠、松耦合、易于管理和观测，充分发挥云计算的优势。

关于云原生架构的定义，阿里云在2020年发布的《云原生架构白皮书》中给出了比较明确的定义：云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性。

云原生架构可以带给IT架构非常多的好处，主要体现在以下几个方面。

（1）降低开发复杂度和运维工作量。云原生把三方软硬件的能力升级为服务，使得业务代码的开发人员不需要掌握复杂的分布式或者底层网络技术。比如，Serverless和Service Mesh将大量分布式和服务治理的技术细节下沉，让企业更加关注业务本身，提升研发效率。

（2）提供大量非功能特性。让云原生来提供非功能特性，如高可用能力、可扩展能力、容灾能力、易用性、可测试性、安全特性等能力。

（3）自动化的软件交付。云原生采用容器等技术，通过标准的方式对软件打包，容器及相关技术可以屏蔽不同环境间的差异，进而基于容器做标准化的软件交付，提升资源利用率，提供统一的基础设施，如操作系统、容器、Kubernetes。

1.3.5　云原生的核心技术

云原生的核心技术包括容器、微服务、Serverless、Service Mesh、DevOps等。

1）容器

作为标准化软件单元，容器将应用及其依赖项打包，使应用不再受环境限制，进而可以在不同环境间快速、可靠地运行。容器的核心技术是Docker和Kubernetes。Docker基于操作系统虚拟化技术，能够共享操作系统内核，几乎无资源损耗，并且能快速启动，提升系统的应用部署密度，同时通过Docker镜像解耦应用与运行环境。Kubernetes凭借优秀的开放性、可扩展性、可移植性及活跃开发者社区，成为容器编排、分布式资源调度的事实标准，助力应用一致地运行在多种云环境中。

2）微服务

微服务也是云原生的核心技术，从云原生架构和技术演化角度，微服务经历了四代演化。第一代，自行解决上下游寻址、通信及容错等问题。第二代，引入服务注册中心来完成服务的自动注册和发现。第三代，到了Service Mesh，微服务基础能力演化成为一个独立进程——Sidecar，其功能包括服务发现、调用容错及丰富的服务治理功能，如权重路由、流量重放等。第四代，开始尝试Serverless，微服务进一步由一个应用简化为微逻辑，被下沉到Sidecar中的能力越来越丰富，如资源绑定、链路追踪、事务管理、安全等。

3）Serverless

Serverless属于无服务器架构，让用户无须关心程序运行环境、操作系统、网络配置、资源及容量，只要将精力聚焦在业务逻辑和技术上即可。从架构抽象上看，Serverless让技术能力更加下沉，将部署这个动作从运维中取消。Serverless有BaaS和FaaS两种形态。BaaS是后端即服务，如存储、数据库、中间件、大数据、AI等领域全托管的云形态服务；FaaS是功能即服务，它把应用逻辑拆分成多个函数，每个函数通过事件驱动的方式来触发执行。Serverless函数编程是事件驱动方式，与传统编程方式有所不同；另外，Serverless的成功案例、行业标准、初次访问性能、开发调试等目前还不太完善。不过，伯克利（加利福尼亚大学伯克利分校）曾大胆预言：Serverless计算将会成为云时代默认的计算范式，将会取代Serverful计算模式，接入更多的支撑服务，更加安全和易用。

4）Service Mesh

Service Mesh是在微服务架构之上发展起来的技术，目的是将微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。这样一来，开发者不用关注微服务相关治理问题，从而可以聚焦业务逻辑本身，提升应用开发效率和业务创新能力。Mesh化架构是把中间件框架从业务进程中分离，让中间件与业务代码进一步解耦，从而使得中间件升级对业务进程不会造成影响。实施Mesh化架构后，大量分布式架构模式，如熔断、限流、降级、重试等都由Mesh进程完成，因此业务代码的制品中即使不包含这些三方软件包，也能获得更好的安全性，同时可以对流量控制、环境隔离、自动化测试等提供有力的支持。

5）DevOps

DevOps（英文Development和Operations的组合词）是一组过程、方法与系统的统称，是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或实践。Gartner对DevOps的定义：这是一种使用敏捷方法、协作和自动化交付解决方案的业务驱动方法，为云原生提供持续交付能力。在云原生架构中，强调应用研发运维生命周期的全方位管理，包括业务需求、架构设计、开发测试、发布上线、运维保障等，突出基础设施的资源规划、系统应用的开发框架规范、代码管理规范及持续集成交付的自动化和健壮性。云原生技术极大地简化了软件部署和运维，比如容器技术和Kubernetes服务编排技术的结合，解决了应用部署自动化、标准化、配置化问题。微服务通过拆解服务，降低了服务间的耦合性，提高了部署灵活性。Service Mesh让中间件的升级和应用系统的升级解耦。Serverless具有运维自动化、按需加载、弹性伸缩、敏捷部署等特点。同时，DevOps通过IaC（Infrastructure as Code，基础设施即代码）、GitOps、OAM（Open Application Model，开放应用模型）等多种方式提高云原生应用生命周期的运维效率。

1.3.6　企业云原生架构助力数字化转型

数字化转型的蓬勃发展给云计算带来巨大的机会，同时促使云原生作为云计算的服务新界面进入快速发展阶段，进而赋予企业新的增长机遇。就像集装箱加速贸易全球化进程一样，云原生技术正在助力云计算普及和企业数字化转型。全面使用云计算服务和云原生技术落地系统架构的时代已经到来。作为释放云计算技术红利的新方式，云原生架构如果结合企业架构的特点，从方法和理论、工具集、技术最佳实践角度出发，重塑和升级整个企业架构，改变企业的IT根基，则能助力企业的数字化转型。

图1-15所示为云原生架构与企业架构相结合的基本框架。从图1-15中可以看出，整个企业架构以典型的框架为基本内容，如战略规划、规范原则、业务需求、组织结构等，从而驱动业务架构和IT架构。云原生架构主要对应IT架构部分，包括应用架构、数据架构及技术架构。而云原生IT架构核心与云原生技术和产品、云原生关键设计点、云原生典型技术能力、云原生技术最佳实践紧密相连，进而通过云原生架构治理完成整个闭环。其中，一些需要特别关注的设计细节如下所述。

（1）云原生技术和产品：涉及云原生特色的技术和产品，如容器、微服务、Service Mesh、Serverless、DevOps等。

（2）云原生关键设计点：体现云原生架构设计方面的核心能力，包括服务化、可扩展性、无服务器能力、监控能力、高可用能力等。

（3）云原生典型技术能力：包括云原生典型的技术细节，如流量调度、配置管理、服务治理、日志监控、安全生产、异步通信等。

（4）云原生技术最佳实践：包括云原生特有的一些最佳实践，如高可用性、可扩展性、性能优化、容灾、秒杀、压测等。

（5）云原生架构治理：涉及架构持续演进迭代，如相关运营指标、决策权机制、组织架构优化、基于云原生的架构迭代目标、选取云原生技术、架构评审和风险控制等。

云原生架构生于云、长于云，是云计算的“下一站”，可以让开发者更加聚焦业务实现。云原生架构的未来也将更加易于操控、开放、无边界、无服务、安全。我们有理由相信，结合企业架构和云原生技术，将极大地助力企业实现数字化转型。本书的后面章节也将对相关内容逐步展开介绍，让我们继续探索数字化转型架构之道。