云原生应用架构 (1)

欢迎访问网易云社区，了解更多网易技术产品运营经验。

1.3 云原生应用架构

云原生（Cloud Native）的概念，由来自 Pivotal 的 Matt Stine 于 2013 年首次提出，被 一直延续使用至今。这个概念是 Matt Stine 根据其多年的架构和咨询经验总结出来的一个 思想集合，并得到了社区的不断完善，内容非常多，包括 DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）和 12 要素（The Twelve-Factor App）等几大主题，不但包括根据业务能力对公司进行文化、组织架构的重 组与建设，也包括方法论与原则，还有具体的操作工具。采用基于云原生的技术和管理方法， 可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。

顾名思义，云原生是面向“云”而设计的应用，因此技术部分依赖于在传统云计算的 3 层概念（基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS））， 例如， 敏捷的不可变基础设施交付类似于 IaaS，用来提供计算网络存储等基础资源，这些资源是 可编程且不可变的，直接通过 API 可以对外提供服务；有些应用通过 PaaS 服务本来就能组 合成不同的业务能力，不一定需要从头开始建设；还有一些软件只需要“云”的资源就能 直接运行起来为云用户提供服务，即 SaaS 能力，用户直接面对的就是原生的应用。

应用基于云服务进行架构设计，对技术人员的要求更高，除了对业务场景的考虑外， 对隔离故障、容错、自动恢复等非功能需求会考虑更多。借助云服务提供的能力也能实现 更优雅的设计，比如弹性资源的需求、跨机房的高可用、11 个 9（99.999999999%）的数据可靠性等特性，基本是云计算服务本身就提供的能力，开发者直接选择对应的服务即可， 一般不需要过多考虑本身机房的问题。如果架构设计本身又能支持多云的设计，可用性会 进一步提高，比如 Netflix 能处理在 AWS 的某个机房无法正常工作的情况，还能为用户提 供服务，这就是“云”带来的魔力，当然，云也会带来更多的隔离等问题。如图 1-4 所示， 目前业界公认的云原生主要包括以下几个层面的内容。 

图 1-4 云原生的内容

敏捷基础设施

正如通过业务代码能够实现产品需求、通过版本化的管理能够保证业务的快速变 更，基于云计算的开发模式也要考虑如何保证基础资源的提供能够根据代码自动实现需求， 并实现记录变更，保证环境的一致性。使用软件工程中的原则、实践和工具来提供基础资 源的生命周期管理，这意味着工作人员可以更频繁地构建更强可控或更稳定的基础设施， 开发人员可以随时拉取一套基础设施来服务于开发、测试、联调和灰度上线等需求。当然， 同时要求业务开发具有较好的架构设计，不需要依赖本地数据进行持久化，所有的资源 都是可以随时拉起，随时释放，同时以 API 的方式提供弹性、按需的计算、存储能力。

技术人员部署服务器、管理服务器模板、更新服务器和定义基础设施的模式都是通过 代码来完成的，并且是自动化的，不能通过手工安装或克隆的方式来管理服务器资源，运 维人员和开发人员一起以资源配置的应用代码为中心，不再是一台台机器。基础设施通过 代码来进行更改、测试，在每次变更后执行测试的自动化流程中，确保能维护稳定的基础 设施服务。

此外，基础设施的范围也会更加广泛，不仅包括机器，还包括不同的机柜或交换机、 同城多机房、异地多机房等，这些内容也会在后续章节中逐一进行部分讨论。

持续交付

为了满足业务需求频繁变动，通过快速迭代，产品能做到随时都能发布的能力，是一 系列的开发实践方法。它分为持续集成、持续部署、持续发布等阶段，用来确保从需求的 提出到设计开发和测试，再到让代码快速、安全地部署到产品环境中。持续集成是指每当 开发人员提交了一次改动，就立刻进行构建、自动化测试，确保业务应用和服务能符合预 期，从而可以确定新代码和原有代码能否正确地集成在一起。持续交付是软件发布的能力， 在持续集成完成之后，能够提供到预发布之类系统上，达到生产环境的条件，持续部署是 指使用完全的自动化过程来把每个变更自动提交到测试环境中，然后将应用安全地部署到 产品环境中，打通开发、测试、生产的各个环节，自动持续、增量地交付产品，也是大量 产品追求的最终目的，当然，在实际运行的过程中，有些产品会增加灰度发布等环境。总 之，它更多是代表一种软件交付的能力，过程示例请参考图 1-5。 

图 1-5 持续交付流程

DevOps

DevOps 如果从字面上来理解只是 Dev（开发人员）+Ops（运维人员），实际上，它是 一组过程、方法与系统的统称，其概念从 2009 年首次提出发展到现在，内容也非常丰富， 有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面。首先，组织架 构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部 门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。其次，自动化是指 所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自 动化才有可能完成快速迭代。再次，DevOps 的出现是由于软件行业日益清晰地认识到，为 了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。总之，如图 1-6 所示， DevOps 强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命 周期管理，从而更快、更频繁地交付更稳定的软件。 

图 1-6 DevOps 强调组织的沟通与协作

微服务

随着企业的业务发展，传统业务架构面临着很多问题。其一，单体架构在需求越来越 多的时候无法满足其变更要求，开发人员对大量代码的变更会越来越困难，同时也无法很 好地评估风险，所以迭代速度慢；其二，系统经常会因为某处业务的瓶颈导致整个业务瘫痪，架构无法扩展，木桶效应严重，无法满足业务的可用性要求；最后，整体组织效率低 下，无法很好地利用资源，存在大量的浪费。因此，组织迫切需要进行变革。随着大量 开源技术的成熟和云计算的发展，服务化的改造应运而生，不同的架构设计风格随之涌 现，最有代表性的是 Netflix 公司，它是国外最早基于云进行服务化架构改造的公司，2008 年因为全站瘫痪被迫停业 3 天后，它痛下决心改造，经过将近 10 年的努力，实现了从单架 构到微服务全球化的变迁，满足了业务的千倍增长（如图 1-7 所示）， 并产生了一系列的最 佳实践。

图 1-7 Netflix 微服务化支撑业务千倍增长

随着微服务化架构的优势展现和快速发展，2013 年，Martin Flower 对微服务概念进行 了比较系统的理论阐述，总结了相关的技术特征。首先，微服务是一种架构风格，也是 一种服务；其次，微服务的颗粒比较小，一个大型复杂软件应用由多个微服务组成，比 如 Netflix 目前由 500 多个的微服务组成；最后，它采用 UNIX 设计的哲学，每种服务只做 一件事，是一种松耦合的能够被独立开发和部署的无状态化服务（独立扩展、升级和可替 换）。微服务架构如图 1-8 所示。

图 1-8 微服务架构示例

由微服务的定义分析可知，一个微服务基本是一个能独立发布的应用服务，因此可以 作为独立组件升级、灰度或复用等，对整个大应用的影响也较小，每个服务可以由专门的 组织来单独完成，依赖方只要定好输入和输出口即可完全开发，甚至整个团队的组织架构 也会更精简，因此沟通成本低、效率高。根据业务的需求，不同的服务可以根据业务特性 进行不同的技术选型，是计算密集型还是 I/O 密集型应用都可以依赖不同的语言编程模型， 各团队可以根据本身的特色独自运作。服务在压力较大时，也可以有更多容错或限流服务。

微服务架构确实有很多吸引人的地方，然而它的引入也是有成本的，它并不是银弹， 使用它会引入更多技术挑战，比如性能延迟、分布式事务、集成测试、故障诊断等方面， 企业需要根据业务的不同的阶段进行合理的引入，不能完全为了微服务而“微服务”，本书 第 5 章也会对如何解决这些问题提供不同的方案。

文章节选自《云原生应用架构实践》 网易云基础服务架构团队 著

网易云计算基础服务深度整合了 IaaS、PaaS 及容器技术，提供弹性计算、DevOps 工具链及微服务基础设施等服务，帮助企业解决 IT、架构及运维等问题，使企业更聚焦于业务，是新一代的云计算平台。点击可免费试用。