1　什么是云原生

1.1　云原生起源

云原生是一种软件开发方法，它充分利用了云计算，使用开源软件技术栈将应用程序部署为微服务。通常，云原生应用程序构建为在Docker容器中运行的一组微服务，在Kubernetes中编排，并使用DevOps和Git Ops工作流进行管理和部署。使用Docker容器的优点是能够将执行所需的所有软件及环境配置打包到一个可执行包中。容器在虚拟化环境中运行，从而将包含的应用程序与其环境隔离。

——维基百科“Cloud Native”

信息技术的发展日新月异，过去几十年，企业IT架构经历了单体架构、分布式架构和云计算架构3个阶段的技术演进。尤其是云计算技术的发展，让企业的整个IT基础设施以及应用运行模式发生了革命性的改变。云时代的第一个十年，作为技术的创新探索先锋，互联网公司引领了云计算技术的发展趋势，大多数互联网应用从诞生之初就生长在云端。随着云计算技术的成熟，以及以移动互联网为特点的创新业务的驱动，很多传统行业（如金融、零售、能源、制造以及政务等领域）的企业和机构也逐渐将各自的业务从互联网数据中心（Internet Data Center，IDC）机房迁移至云上，充分利用云的弹性优势，实现系统的动态伸缩与业务的创新。

企业应用上云，也经历了从云托管到云原生的架构演进过程。上云初始阶段，多数企业仅仅是把应用从传统的IDC机房搬迁到云上的虚拟机，这是云托管模式，或者叫作基础设施即服务（Infrastructure as a Service，IaaS）上云。但要真正用好云，不仅是基础设施和平台的升级，应用也需要摒弃传统的设计方法，从架构设计、开发方式到部署维护的整个软件生命周期管理，都要基于云的特点进行重构，从而构建“原生为云”而设计的应用，这样才能在云上以最优的架构、最佳的模式运行，并充分利用和发挥云平台的弹性以及分布式优势。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。作为诞生于云计算时代的新技术理念，云原生拥有传统IT无法比拟的优势，可帮助企业高效享受云的弹性和灵活性，以服务化的形态获取各种资源，降低大规模分布式高并发的技术门槛，从而实现快速开发、平滑迁移、稳定可靠、运维简便的应用构建模式。云原生已经成为云时代的新技术标准。

云原生的概念最早是谁提出的，业界并没有统一的说法。比较有影响力的是Pivotal（Spring开源产品的母公司）的技术产品经理 Matt Stine，他在2015年发表的电子书Migrating to Cloud Native Application Architectures（《迁移到云原生应用架构》）中，提出了将传统的单体应用和面向服务的架构（Service-Oriented Architecture，SOA）应用迁移到云原生架构所需的文化、组织和技术变革。Matt Stine认为云原生是一组思想集合和最佳实践，包括敏捷基础设施（agile infrastructure）、微服务（microservice）、DevOps、持续交付（continuous delivery）等，主要涵盖如下重要的内容。

（1）十二要素应用程序：云原生应用程序架构模式的集合。

（2）微服务：独立部署的服务，每个服务只做一件事情。

（3）敏捷基础设施：快速、可重复和一致地提供应用环境和后台服务的平台。

（4）基于应用程序接口（Application Programming Interface，API）的协作：发布和版本化的API，允许在云原生应用程序架构中的服务之间进行交互。

（5）抗压性：系统具备良好的健壮性，能够抵抗外界非预期的流量冲击。

从狭义上来讲，云原生包含以容器、微服务、持续集成和持续发布（Continuous Integration/ Continuous Delivery，CI/CD）为代表的云原生技术，使用一种全新的方式来构建、部署、运维应用。它不但可以很好地支持互联网应用，也在深刻影响着新的IT技术架构和应用架构。

从广义上来讲，云原生完全基于分布式云架构来设计开发应用系统，是全面使用云服务的构建软件。随着云计算技术的不断发展和丰富，很多用户对云的使用，不再是早期简单地租用云厂商基础设施（计算、存储、网络）等IaaS资源。

云原生是当前炙手可热且不断发展的技术方向，其定义也会在日后不断演进。据IDC的市场研究数据和报告，截至2019年，超过三成的企业使用了包含 Docker 在内的容器技术，50%以上的企业认为运维自动化和弹性扩容是容器技术的主要应用场景。Gartner报告指出，到2022年，75%的全球化企业将在生产环境中使用云原生的容器化应用。

2　企业为什么需要云原生

云的核心理念是弹性，站在云的视角，过去我们常以虚拟化作为云平台和与客户系统交互的界面，为企业带来灵活性的同时也带来了一定的管理复杂度。容器的出现，在虚拟化的基础上向上封装了一层，逐步成为云平台和与客户系统交互的新界面之一，应用的构建、分发和交付得以在这个层面上实现标准化，大幅降低了企业 IT 实施和运维成本，提升了业务创新的效率。从技术发展的角度看：开源让云计算变得越来越标准化，容器已经成为企业应用分发和交付的标准，可以将应用与底层运行环境解耦；Kubernetes成为资源调度和编排的标准，屏蔽了底层架构的差异性，帮助应用平滑运行在不同的基础设施上；在此基础上建立上层应用抽象（如微服务和服务网格），逐步形成应用架构现代化演进的标准，开发者只需要关注自身的业务逻辑，无须关注底层实现。云原生正在通过方法论、工具集和理念重塑整个软件技术栈和生命周期，帮助企业和开发者在云上构建和运行可弹性扩展、容错性好、易于管理、便于观察的系统。有了诸多标准化的产品技术，企业上云的拐点已经到来，云原生已经成为释放云价值的最短路径之一。

云并非把原先在物理服务器上运行的东西放到虚拟机里运行，真正的云化不仅是基础设施和平台的事情，应用也要改变传统的做法，实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术等都要做出改变，真正发挥云的弹性、动态调度、自动伸缩等一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多，如容器技术、微服务、可持续交付、DevOps等。

1．业务复杂需要云原生

PC的普及，改变了人们加工处理个人数据的方式；移动互联网的普及，改变了人们获取信息的方式；即将到来的万物互联的时代，改变了人们与周围世界的交互方式。随着业务的发展，企业IT架构也随之发生巨大变化，而业务又深度依赖IT能力。

IT系统让人们的工作和生活越来越简单便捷的同时，其自身的架构却变得越来越复杂。随着技术的发展，业务规模的暴增，商业模式的创新，企业的应用系统也经历了单体应用、应用分层、分布式应用、云应用等不同应用形态。原来一个系统由一个团队就可以开发维护，慢慢发展到一个系统由数十个应用构成，需要几十个团队相互协作，甚至像淘宝、天猫这样的巨型系统，需要上千个应用，由几百个团队开发维护。微服务架构能够解决大型分布式系统的团队协作问题，每个团队独立负责一个或者若干个服务，团队对于所负责的服务拥有绝对的决策权，以减少组织的技术决策成本。服务之间通过契约化的接口以缩小沟通范围，只要接口不变，就无须关注外部的变化，从而减少组织的技术沟通成本。

在微服务架构中，应用的数量大幅增加，性能、一致性等问题越来越严重，架构变得越来越复杂，大量服务的治理也变得充满挑战，如何处理和解决这些问题？正如人类社会发展伴随着技术革命与社会大分工一样，云原生技术的出现解耦了很多复杂性，这是IT技术的进步。

（1）以Docker为代表的容器技术实现了应用与运行环境的解耦，众多业务应用负载可以被容器化，而且应用容器化满足了敏捷、可迁移、标准化的需求。

（2）Kubernetes的出现实现了资源编排调度与底层基础设施的解耦，应用和资源的管控也开始得心应手，容器编排实现资源编排、高效调度。

（3）以Istio为代表的服务网格技术实现了服务实现与服务治理能力的解耦。

业务的发展能驱动技术的进步，技术的进步又反哺业务创新。云原生概念及技术提出几年以来，得到众多软件厂商以及云厂商的参与支持，他们也在纷纷贡献自己的产品与技术，绝大多数云厂商提供了容器、Kubernetes编排管理的OpenAPI、软件开发工具包（Software Development Kit，SDK）等丰富的开发工具，实现第三方被集成，为云的生态伙伴提供更多的可能性。这样的技术分层推动了社会分工，极大促进了云原生技术和云原生生态的发展。

2．业务创新需要云原生

互联网（尤其移动互联网）的蓬勃发展提高了业务的推广速度，云产品以及服务大幅降低了海量数据与高并发的技术门槛，二者共同作用，使业务的创新速度达到了前所未有的程度。每天有无数的新App产生。一个App从最初上线到日活跃用户过十万、百万、千万，可能只需要短短几个月的时间。我们正处在一个业务快速增长的时代，产品既需要更快的交付速度以便验证业务可行性，又需要更好的用户体验以便在众多的App中脱颖而出。这也是传统企业竞争不过互联网公司的原因。其中一个重要的因素是产品的进化速度太慢，不能根据用户的反馈快速迭代。当某个功能用户使用频率比较高时，产品的发展方向可能会随时发生转变，需要不断在市场中调整和演进产品的发展路线。万众创业的时代机会转瞬即逝，如果不能在第一时间抓住市场的热点，企业很快就会被市场淘汰。有研究数据表明：中国互联网企业的平均生命周期普遍在3～5年。“3年”成为划分一个企业生命周期的分界线。

产品交付速度的提高不能以降低可用性为代价。我们知道，变更是可用性的“天敌”，以阿里巴巴为例，有统计数据表明，超过50%的线上故障是变更引起的，也正因如此，每逢重要的节假日或者大促活动节点，我们都会进行“封网”，以确保线上系统的稳定和可靠。当然这也是目前技术不够成熟，不得已而为之的折中和让步。就像目前很多传统企业的线上管理策略，提升可用性的一种方法就是少发布、多审核，这显然是和快速试错、快速交付、快速迭代的互联网思想背道而驰的。在传统行业中，企业的应用系统一般是有一个工作时间的，应用的发布和变更会选择在非工作时间进行。但在互联网行业中，尤其在全球化背景下，我们要求应用系统具有7×24小时不间断的在线服务能力，不存在非工作时间，甚至不存在业务低峰期，这就对企业的应用系统运维提出了更高的要求。云计算已经重塑了软件的整个生命周期，从架构设计到开发，再到构建、交付和运维等所有环节。云原生通过一系列产品、工具、方法减少变更导致的可用性问题，而不是因噎废食地控制变更、减少发布次数。

互联网公司经常提到他们每天实现几十次，甚至上百次的发布。为什么频繁发布如此重要？如果你可以每天实现上百次发布，那么你就可以几乎立即从错误的版本中恢复过来；如果你可以立即从错误中恢复过来，那么你就能够承受更多的风险；如果你可以承受更多的风险，那么你就可以做更“疯狂”的试验——这些试验结果可能会成为你接下来的竞争优势。

3．业务不确定性需要云原生

云最主要的特性之一就是弹性，这也是企业应用上云最核心的需求。随着移动互联网的普及，以及网红经济、热门事件营销、秒杀大促等商业模式的推陈出新，企业的业务流量变得无法预估。当然，为了应对突发流量的冲击，企业也可以购买更多更高规格的服务器；但对于绝大部分业务平峰期以及低峰期， CPU都是空闲的，这会让资源使用率指标很低。通过云的弹性伸缩，可以应对业务突发流量的冲击，保证业务的平稳运行，提高资源利用率，降低IT运营成本。

随着企业的应用系统进行分布式改造，应用由一个单体应用被分割为众多的微服务应用，整个应用集群的节点数由原来的数十个快速上升到了数百以至上千个，垂直拆分带来良好隔离性的同时，也使资源的利用率大幅下降。互联网公司通过以下两个开创性的举措来解决这个问题。

（1）不再继续购买更大型的服务器，取而代之的是用大量更便宜机器来水平扩展应用实例。这些机器更容易获得，并且能够快速部署。

（2）将大型服务器虚拟化成几个较小的服务器，并向其部署多个隔离的工作负载，从而改善现有大型服务器的资源利用率。

纵观IT应用服务器的发展历史：大型机→小型机→x86服务器→虚拟机→容器→Serverless，越来越朝着轻量化的方向发展，这也符合云原生敏捷基础设施的策略。轻量化意味着更好的弹性，应用部署时间相应减少：月（大型机）→天（小型机）→小时（x86服务器）→分钟（虚拟机）→秒（容器）→毫秒（Serverless）。极致的弹性是企业解决业务不确定性的有效手段。

云原生的核心技术之一是容器。容器技术的兴起源于2013年开源的Docker。容器的价值可以从下面两个层面阐述。

（1）从应用架构层面，容器技术可以方便地支持微服务架构实现应用的无状态化，更加灵活地应对变化和弹性扩展。在软件生命周期管理方面，容器技术可以帮助把DevOps等最佳实践落地成可运用的标准化工具和框架，大大提升开发效率，加速迭代。DevOps的概念最早起源于2009年的欧洲（更早的20世纪90年代提出的柔性生产模式中也有DevOps的思想），但一直不温不火，直到Docker容器技术的流行，最近几年DevOps才为人们所津津乐道。

（2）从基础架构层面，容器技术带来的可移植性，可以帮助开发者和企业更便捷地上云和迁云，让应用在自有数据中心和云端实现动态迁移。随着容器技术和云计算的计算、存储、网络的进一步融合，更快速地推动从传统以基础设施为中心，向以应用为中心的IT架构转变。

容器解决了应用与运行环境的解耦，把运行环境也作为一种资源支持可编程式的管理；Kubernetes的出现则让资源的动态编排与管理变得更加简单，充分满足业务不确定对资源的弹性要求。

综上所述，云原生不是一个产品，而是一套技术体系和一套方法论。企业数字化转型是思想先行，从内到外的整体变革，更确切地说，它是一种文化，更是一种潮流，是企业云计算战略的必然导向。

3　云原生的设计原则

顾名思义，云原生是面向“云”而设计的应用，但要给云原生下一个明确的定义很难，所有的架构的目标都是解决特定的业务场景。一方面，业务场景千变万化，而每个人的技术背景不同，站的角度不同，所理解和设计的系统架构也就各不相同。另一方面，架构总是不断演进的，新的技术层出不穷，因此云原生的落地形式与能力边界也在不断演进中。

换一个思路，云原生所倡导的思想与设计原则，或许能更好地让大家理解什么是云原生，云原生具体解决哪一类问题。

1．去中心化原则

中心化意味着单点，为了具备良好的线性扩展能力，分布式系统要求去中心化，避免单点故障。对于系统的服务能力，随着资源加入，微服务的性能和容量能够呈线性扩展。在微服务场景下，每个服务可以独立采用自己的技术方案或技术栈，每个微服务应用独立部署，服务之间进程隔离，每个服务都有独立的数据库，一个服务实例的失效不会导致大规模的故障。这也是微服务架构和SOA非常重要的区别之一。SOA一般有一个中心化的企业服务总线（Enterprise Service Bus，ESB）负责所有服务的注册发现以及调用路由；微服务架构虽然也有一个服务注册中心，但服务注册中心只负责应用启动或者状态变更时做服务推送，真正在运行过程中微服务之间的相互调用都是点对点直接调用，即运行时是去中心化的。

另外，从研发流程的角度来说，去中心化意味着关注点分离。云原生对开发团队一个很重要的要求是独立自主，每个服务由独立的团队负责开发运维，所有者的团队对服务具有决策权，可以自主选择技术栈以及研发进度，服务之间只要接口不变，外部就不必对其过度关注，更容易实现关注点分离。

2．松耦合原则

（1）实现的松耦合：这是基本的松耦合，即服务消费端不需要依赖服务契约的某个特定实现，这样服务提供端的内部变更就不会影响消费端，而且消费端未来还可以自由切换到该契约的其他服务提供方。

（2）时间的松耦合：典型的是异步消息队列系统，由于有中介者（broker），因此生产者和消费者不必在同一时间都保持可用性以及相同的吞吐量，而且生产者也不需要马上等到回复。

（3）位置的松耦合：典型的是服务注册中心，消费端完全不需要直接知道提供服务端的具体位置，而都通过注册中心查找服务来访问。

（4）版本的松耦合：消费端不需要依赖服务契约的某个特定版本来工作，这就要求服务的契约在升级时要尽可能地提供向下兼容性。

3．面向失败设计原则

为了保证系统的健壮性，软件设计领域中一个很重要的原则是，所有的外部输入和外部依赖都是不可信的，系统间依赖的调用随时可能会失败，也包括硬件基础设施服务随时可能死机，还有后端有状态服务的系统能力可能有瓶颈。总之在发生异常时能够快速失败，然后快速恢复，以保证业务永远在线，不能让业务半死不活地僵持着。

面向失败设计（design for failure），意味着所有的外部调用都有容错处理，我们希望失败的结果是我们可预期的、经过设计的。在微服务架构场景中，当服务数量越来越多，依赖越来越复杂时，出现问题的概率也就越大，问题定位也会越来越困难，这时再用传统的解决办法将是一个灾难。传统的方法通常是通过重试、补偿等手段尽可能避免失败，微服务架构下由于存在更多的远程调用，任何外部依赖都有可能失效或延迟，这是潜在的故障和瓶颈。故障总是无法避免的，设计的目标是预测和解决这些故障。因此在设计服务时，应充分考虑异常情况，从使用者的角度出发，能够容忍故障的发生，最小化故障的影响范围。系统架构设计时需要考虑到应用系统的每一个层面，包括硬件和软件是可能出现故障的，并据此在应用系统架构设计上消除单一故障点，从而实现高可用性（High Availability，HA）的系统架构。

4．无状态化原则

云原生的应用服务设计尽可能是无状态的，使得业务天生具有扩展性，在业务流量高峰和低峰时期，依赖云的特性自动弹性扩容、缩容，满足业务需求。无状态指的是服务在处理请求时，不依赖除请求本身以外的其他内容，也不会有除响应请求之外的额外操作。这样如果要实现无状态服务的并行横向扩展，只需要对服务节点进行并行扩展，在服务之上添加一个负载均衡。

将“有状态”的业务处理过程改造成“无状态”的过程，思路比较简单，主要有以下两种手段。

（1）状态分离：服务端所有的状态信息统一保存在外部独立的分布式存储中（如缓存、消息队列、数据库）。

（2）请求附带全部状态信息：将状态信息前置，丰富请求的入参，将需要处理的数据尽可能都通过上游的客户端放到入参中传过来。

5．不变性原则

容器技术带来的最大优势，是通过镜像实现了可编程式的运行环境定义，从而实现了应用与运行环境的解耦。作为一种服务（IaaS），云原生基础设施提供可编程式的需求描述，并实现记录版本变更，保证环境的一致性。使用软件工程中的原则、实践和工具来加强基础设施服务的生命周期管理，这意味着开发人员可以更频繁地构建更强可控或更稳定的基础设施。对资源调度而言，我们希望所有的服务（包括环境）无差异化配置，实现标准化可迁移，而不希望在部署任何服务的过程中还需要手动操作，因为手动操作是无法批量化、自动化执行的，也是不容易回溯的。

实现不变性原则的前提是，基础设施中的每个服务、组件都可以自动安装、部署，不需要人工干预。所有的资源都可以随时拉起、随时释放，同时以API的方式提供弹性、按需的计算、存储能力。每个服务或者组件在安装部署完成后将不会发生更改，如果要更改，就丢弃老的服务或组件，并重新部署一个服务或组件。另外，为了提升可用性，我们应该尽量减少故障修复时间，要知道替换的速度远远快于修复的速度。

6．自动化驱动原则

为了满足业务需求的频繁变动，通过快速迭代，产品能做到随时可发布，这是一系列开发实践方法。自动化驱动分为持续集成、持续部署、持续交付等阶段，用来确保需求的提出、设计开发测试，再到代码快速、安全地部署到生产环境中。持续集成是指每当开发人员提交了一次改动，就立刻进行构建、自动化测试，确保业务应用和服务均能符合预期，从而可以确定新代码和原有代码能否正确地集成在一起。持续部署是指使用完全的自动化过程把每个变更自动提交到测试环境中，触发自动化测试用例，测试验证通过后将应用安全地部署到生产环境中，打通开发、测试、生产等各个环节。持续交付是软件发布的能力，在持续集成完成后，能够提供到预发布之类的环境上，满足生产环境的条件。

应用系统的部署与运维的成本会随着服务的增多呈指数级增长，每个服务都需要部署、监控、日志分析等运维工作，成本会显著升高。在服务划分之前，应该首先构建自动化的工具及环境，开发、测试人员应该以自动化为驱动力，简化服务在创建、开发、测试、部署、运维上的重复性工作，尽可能通过自动化工具完成所有重复的工作。当提交代码后，自动化的工具链自动编译、构建、测试、集成。开发人员持续优化代码，当满足上线要求时，自动化部署到生产环境中。这种自动化的方式能够实现更可靠的操作，既避免了人为失误，又避免了微服务数量增多带来的开发、运维、管理的复杂化。

云原生架构设计你需要有这样一本书：

1.基于作者在阿里公司多年的大型项目架构设计实践经验，介绍云原生相关技术及产品
2.内容深入浅出，既有方法论详述也有技术原理深入分析
3.理论与实践并重，深入阐述云原生架构设计
4.紧贴技术趋势，把握主流技术发展

内容简介
《企业级云原生架构：技术、服务与实践》较为全面、系统地介绍了云原生架构相关的方法论与技术产品，并结合作者多年的大型项目建设实施经验，阐述了分布式环境下面向云原生的架构设计最佳实践。本书主要分为4个部分，分别是云原生概述、云原生技术、云原生服务、云原生架构实践。本书兼顾理论、技术与实践，对从事相关行业的读者具有很好的学习指导意义。

《企业级云原生架构：技术、服务与实践》面向的读者对象为互联网行业的业务咨询师、系统架构师，以及相关领域的技术开发人员。