3.7 企业架构与云原生的关系
随着互联网技术的高速发展，虚拟化技术、云计算等得到了发展和推进，容器化技术、敏捷交付、精益工程等也快速发展，DevOps、微服务、云原生等也渐渐被人们所知晓。云原生以应用为中心，让应用得以最大限度享受云计算的红利。企业架构也要与时俱进，在面向市场、面向用户的同时，拥抱云原生等新技术。
云原生架构将云应用中的非业务代码部分进行最大化剥离，从而让云设施接管应用中原有的大量非功能特性，使业务在不再受非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。云原生包括基于云原生技术的一组架构原则和设计模式的集合，如“12要素”、服务化治理原则、弹性可扩展原则、服务无状态原则、可观测和监控原则、高可用稳定原则、自动化交付原则和零信任安全原则等。这里我们重点看一下企业架构与云原生之间的关系。
3.7.1 云原生与企业战略的关系
架构必须服务于企业战略，云原生架构也不例外。云原生架构和以往的架构升级不同，云原生架构不仅是技术升级，更是对企业核心业务流程的重构。企业的定位无论是建立新型的业务战略，还是通过技术创新提升企业的IT战略，技术的核心竞争力都是非常重要的，特别是对于高科技的互联网公司，事实上即使是传统企业也会从新技术中获得大量红利，达到更广泛、更高效地互动连接。在数字化转型的过程中，越来越多的企业将IT战略作为企业战略中的重要角色，促使技术赋能业务创新，CTO、CIO、CDO等岗位也体现了技术在企业战略中的重要位置。
3.7.2 云原生与业务架构的关系
业务架构将企业的业务能力通过场景、流程、服务进行管理，实现的一个重要的方式是采用编排思想，比如业务能力是一些对外流程的编排，流程是活动及服务的编排，解决方案是产品级别的编排，产品是功能层面的编排。这种编排思想在云原生架构中非常重要，比如云原生应用是对应用服务的编排、Kubernetes是对容器资源的编排、Service Mesh是对微服务的编排、IaaS是对基础资源的编排。在Kubernetes中，一切皆资源，如机器、存储、计算、服务，而这些资源的组合依赖编排。这种编排云原生“与生俱来”，对应的编排很自然地从业务能力传递到云原生的具体技术细节，并通过一些自动化的调度和协调能力，通过系统很好地固化下来。传统模式下技术赋能业务的流程比较长，比如技术选型、POC测试、试点和推广；而当大量使用云服务后，由于更快地连接和试错，以及统一平台和技术依赖的优势，让业务得以更快地试错和创新。
3.7.3 云原生与应用架构的关系
云原生通过应用平台来提供企业架构涉及的相关应用系统的快速研发和交付。云原生为应用架构提供应用生命周期的管理能力。云原生应用平台可以由多个组成部分共同完成，如CaaS（容器、Kubernetes等），aPaaS（Service Mesh、CI/CD等）、BaaS（中间件、数据库等云托管服务）、FaaS（Serverless、Function、Trigger等）；同时，涉及维护这个应用平台必要的能力组件，如监控报警、日志诊断、配置执行、质量安全、资源管控等。云原生应用平台本质上是连接应用架构与交付落地的纽带，聚焦在如何合理设计和实现，进而顺利交付和运维。云原生应用平台将应用和运行环境解耦，避免静态环境信息，具备可观测性及自包含性，同时可以结合低代码技术，帮助企业快速完成应用的搭建。
3.7.4 云原生与数据架构的关系
数据是企业架构的核心，当然在云原生中也不例外，云原生数据管控如图3-12所示。比如，DaaS提供数据分析、大数据等能力云上托管；Kubernetes的面向终态就像一个黑盒，通过可观测的状态来判断是否达到终态，过程是否完善、是否健康。这个过程通过执行、日志、配置、状态的数据管控，达到可驱动、可记录、可控制、可观测，从而基于云原生的数据驱动方式，为数据架构提供强大的数据支撑和分析能力。
图3-12 云原生数据管控
3.7.5 云原生与技术架构的关系
数字化业务对技术架构的主要诉求是业务连续性和业务快速上线。这些能力诉求被云原生架构转化在技术、产品、工具、流程等多个层面。云原生的核心技术包括容器、微服务、Serverless、Service Mesh、DevOps，还包括与基础设施相关的编排、监控、日志、网络，与容器和Kubernetes相关的CaaS，与中间件相关的存储、消息、配置、文件，与应用PaaS相关的模板、编程、状态协调、开发框架，以及BaaS、FaaS、DaaS等其他相关领域的技术。技术层面随着这样的趋势，计算单元的粒度越来越细，模块化程度越来越高，自动化运维程度越来越高，弹性效率越来越高，故障恢复能力越来越高。相关数据显示，通过采用容器技术可以降低30%以上的运维支出，同时可以通过DevOps、IaC、GitOps、OAM等提高云原生系统的运维效率。此外，云原生也吸引了很多技术开发者，CNCF 2020年发布的《云原生开发状态报告》显示，全球约有470万名云原生开发者，占全部后端开发者的36%。
3.7.6 云原生与项目管理的关系
在云原生架构中，应用的粒度越拆越细，更多技术上的代码都下沉到底层基础设施。云原生追求的是更敏捷和更稳定的应用运行时技术。从项目的维度来看，企业需要管理好云原生不同层面的生命周期，如解决方案、产品、应用、服务、Pod等（见图3-13），以及支持的中间件、aPaaS、FaaS等服务的生命周期，同时需要处理好各种配置的依赖关系。对于DevOps、CI/CD流程，项目管理需要清晰地定义云原生应用从研发、测试、发布、运维、运营整个交付流程，标准化定义涉及的参与角色、度量指标、成熟度模型、API规范等，探索如何更好地进行团队合作和持续迭代。
图3-13 云原生项目生命周期管理
此外，项目管理需要关注研发模式的变化。在传统研发模式中，开发人员需要关注各种软件开发工具包（SDK）、非功能性组件、各类运维事件。在采用云原生技术之后，大大简化了研发过程，比如通过新的语言协议或其他更友好的方式对基础设施、运维、托管等进行简化。这种简化促使项目管理需要注重代码审核、开发规范及编程文化等。
3.7.7 云原生与运营治理的关系
运营治理中强调的治理框架、成熟度模型、组织适配、原则规范、架构演技等对于云原生架构也十分重要。云原生改变了应用研发的模式，也带来了技术上的变革，促使我们需要考虑更多的运营治理的原则和方法。这里我们简要总结一下云原生架构经典的设计原则——“12要素”原则。
（1）基准代码：一份基准代码（Codebase）、多份部署（Deploy）。
（2）依赖：显式声明依赖关系。
（3）配置：在环境中存储配置。
（4）后端服务：把后端服务当作附加资源。
（5）构建、发布、运行：严格分离构建、发布和运行。
（6）进程：以一个或多个无状态进程运行应用。
（7）端口绑定：通过端口绑定提供服务。
（8）并发：通过进程模型进行扩展。
（9）易处理：快速启动和优雅终止，最大化健壮性。
（10）开发环境与线上环境等价：尽可能保持开发、预发布、线上环境相同。
（11）日志：把日志当作事件流。
（12）管理进程：把后台管理当作一次性进程运行。
在这些原则中，一个核心的运营治理思想是应用服务治理能力与业务逻辑解耦，解除之间的绑定，通过标准化的平台、服务、应用协议，将业务和技术的耦合进行有效的分离，并通过云原生容器、微服务、Service Mesh、Serverless等得以实现，如服务通信、服务发现、流量转移、流量熔断和限流等，还可以通过日志监控等手段进行全链路追踪。这些代码库被构建在应用程序之外，通过云原生应用平台来加以管理。