构建未来

构建未来 - 云原生应用

引言

云原生应用已成为软件行业的最大趋势之一，它改变了我们对开发、部署和运维软件产品的思考方式。
每个行业的组织都希望保持竞争力，领导者意识到必须保持至少两种技术配置，最基本的是，在支持产品和服务创新的同时，保持始终在线（业务性需求）；另一个配置必须具有前瞻性，以应对快速变化的技术和拥抱新技术（技术性需求），这其中包括 CI/CD、容器化和微服务。当下迫切需要确保适当数量的基础架构，以管理不可预期的使用量和地域分布。在许多公司里，都有一种强烈的紧迫感，要么快速响应，要么被市场淘汰。
随着架构师和工程师寻求利用云计算，云原生体系结构主要有下列驱动原因：

• 弹性
  假设用户的部署环境和网络是常驻的，这是有风险的，它们最终将发生变化，而且实际上也会发生变化。用户的核心应用程序可能不会收到任何警告以适当平稳关机，因此，至关重要的是为故障而设计，并假设依赖的服务随时可能不可用
• 自发现
  支持应用程序的服务必须易于找到，并且可由其他服务访问，通常服务需要可以动态扩展和更改地址。因此，软件必须具有能够轻松发现其他组件和服务的位置，并与之通信的能力。
• 可扩展性
  尽管用户可以在云系统中管理应用程序，但是如果这些应用程序无法水平扩展，则它们将无法发挥云原生架构的效率。稳健、可靠的云原生计算是由健全的云原生架构驱动的。

为了更好地为未来做准备，重要的是深刻了解这种不断发展的技术趋势，在这本书中，我们将研究云原生架构，回顾云原生应用开发的兴起，并将探讨整个软件生态系统中云原生的未来。
尽管传统的消费者可能永远不会理解云原生架构，但它在创新型公司中不断取得进展，并继续发挥更大的影响力，而且现在已经有一个完善的行业组织，即云原生计算基金会。在线零售、投资银行、银行和各种消费行业等各行各业都将云原生架构视为业务战略的主要基础。了解这一新技术运动非常重要。

什么是云原生架构

我们先给云原生架构下一个定义：

云原生体系架构是一个模型，利用云计算能力，在平台上构建和运行应用程序，而底层基础依赖无关。

采用云原生架构不仅仅是将一些服务负载转移到共有云供应商，这是一种构建基础架构、开发应用程序和构建团队的全新方法。
更详细地说，使用云原生架构的应用程序广泛使用了微服务，通常，云原生应用程序是容器化的，并在容器编排平台上运行，如 Kubernetes。
云原生架构包含四个主要方面：微服务、DevOps、容器化和持续交付。

微服务

在云计算中，这是一个子架构，其中应用程序由大量的小服务集合构成，每个小服务都执行非常特定的功能。通常，微服务作为实现特定业务或技术能力的独立流程运行，微服务间通过 API 或者消息队列进行通信。好的设计原则要求微服务容易部署，方便升级，可伸缩，可以自重启。每个微服务应独立于其他服务，并且不依赖调用它的服务。这种高弹性的体系结构允许对应用程序频繁实时更新，而不会影响到终端用户。

DevOps

DevOps 是软件开发人员和IT运维人员紧密协作的产物。与传统团队不同，对于云原生 DevOps 团队而言，这些应用程序会高度利用云计算技术的弹性和适应性，目标是持续不断地交付出满足客户要求和期望的高质量软件。在最好的团队中，DevOps 是一种文化，它要求以高度一致性来构建、测试和发布软件。

持续集成和交付

持续交付（CD）是敏捷开发的一种实践，该实践要求可以自动地将小批更新的软件通过流水线最终交付到生产环境。CD 通常需要与持续集成（CI） 流程结合使用，才能更显高效，它要求开发人员每天多次将新代码集成到公共库中。在构建过程中，会验证新提交的代码，这使团队可以更快得发现的问题作出响应。CI / CD 的主要目标是使软件版本达到平稳和无错误的可靠性，使用 Jenkins 或 CircleCI 之类的平台，许多已经建立了成熟 CD 流水线的组织，都可以以较低的风险频繁交付产品，并从终端用户那里获得快速反馈。

容器化

本质上，容器是一个软件包，其中包含了应用程序运行所需的一切。例如，许多简单的容器由应用程序服务器，虚拟机环境（VM）和应用程序本身组成。容器可以在虚拟化环境中运行，同时将驻留在其环境中的应用程序隔离出来。这种体系结构的主要优点包括环境独立性和高度可移植性，和容易在多个环境（开发、测试或生产）之间移动同一个容器。如果用户的应用程序具有水平可伸缩的设计，那么可以启动一个容器的多个实例以适应额外的用户需求，同时在需求减少时，也可以自动终止这些实例。
Docker是现在最为广泛应用的容器，与虚拟机相比，容器提供了更高的效率和性能，使用 OS 级虚拟化，单个操作系统实例可以动态支持多个隔离的容器，每个容器都有其自己不同的，可写的文件系统和资源配置文件。虚拟化技术可与容器编排技术结合使用，以实现高度的灵活性和响应能力。动态创建和终止容器只需要少量开销，容器是部署微服务的绝佳方式。

旅程：我们如何使用云原生应用程序

在过去十年间，现代软件开发一直在放弃使用内部物理机部署服务，而是使用云计算基础架构。最初出现云计算时，许多 IT 部门仅试图将其系统转移到云中，而不对应用程序体系结构进行任何更改，只需将多层应用程序从本地物理机上迁移到虚拟化云环境即可。随着时间流逝，云系统工程师在云平台和基础架构方面进行了许多创新的改进，这些举措催生了一些工程趋势，沿用至今日。其中趋势之一就是从单体应用系统向微服务体系架构的转变，这使我们今天看到的云原生运动蓬勃发展。
投入云原生运动可以获得互惠，希望高效地使用云资源影响这云原生体系结构，更好的结构又进一步提高了效率。总体而言，这种高效表现为更好的客户服务以及更快的产品和服务开发。
除了上面提到的云原生特性外，以下是一些目前正在影响云原生架构的主流软件开发趋势。

Restful 风格 API

基于 Restful 风格的 API 提供了可伸缩并且可靠的通信，这种方法在很大程度上依赖于存在已久的 Internet 协议，基础结构和完善定义的标准。

状态隔离

无状态组件更易于水平扩展（向上或向下），尽管有状态的组件并不是完全需要避免，但应将其减少到最少。

松耦合

在松耦合的情况下，服务大多通过事件或者数据组合。更具体地说，事件交互依赖于消息系统，例如 AMQP 标准；数据交互通常依赖于可伸缩的，满足最终一致性的存储解决方案，通常是 NoSQL 数据库。

弹性平台

弹性意味着系统可以通过实时自动配置来适应工作负载变化，诸如 Kubernetes，Swarm 或 Mesos 之类的弹性平台通常被视为广义弹性基础架构的关键统一中间件，这些平台极大地扩展和最大化了资源共享。它们还提高了标准化部署单元中，基础计算、存储和网络资源的利用率。

云建模语言

现代云计算在提供服务时支持高度的自动化，云服务用户可以动态地获取用于部署云服务程序的服务。专门的云建模语言寻求提供灵活的方法来管理不断增长的云计算功能。这些新语言旨在支持不同场景，例如将现有应用程序迁移到云，云应用程序开发和优化。

serverless 化

这是一种云应用程序架构，在很大程度上依赖于外部第三方服务。这些基于事件触发的小型功能集合称为 Fass（功能即服务）。Faas 使用分时策略在弹性平台内实现资源共享最大化。

微服务：云原生设计的核心

在过去15年中，使用各种类型的面向服务的架构（SOA）构建了许多业务应用程序，最终孕育了云原生架构的兴起。面向服务的计算是用于管理复杂分布式系统和集成不同的软件应用程序的计算范例。本质上，一项服务通过通信机制为其他服务提供功能。重要的是，SOA 服务设计将其接口与核心实现分离开来，并通过专用的工作流语言协调所有服务之间的动作。
从历史上看，许多技术人员一直乐观地认为，这些面向服务的应用程序只需适度地重新配置，就可以重新部署到云环境中，许多人称此类应用为云友好型应用。但是，云系统工程师并不这么认为，尽管常规的 SOA 应用程序由分布式服务组成，但是它们的部署方式不是分布式的。从部署的角度来看，此类分布式应用实际上还是单体应用。
问题在于，对应用程序的任何更新或者服务版本升级都需要重新部署一整个应用，在许多情况下，其结果会导致线上服务长时间不可用。
这些遗留的单体应用伸缩性有限，无法处理实时的负载变化，对于某些操作（比如凌晨运行的批处理任务），此类体系结构是胜任的，但是对于工作日的自然流量，这类系统会遇到瓶颈。
为了摆脱这些约束和限制，架构师必须朝着微服务架构迈进，这是云原生计算的主要特征。

向更大弹性的演进

云计算支持云原生架构，高级系统工程师利用这几年时间，已经更好地理解了，并可以利用现代计算技术的弹性潜力来充分支持云原生应用。时至今日，许多创新的系统设计专门针对云基础架构，它们直接支持水平可伸缩性，这对于云基础架构至关重要。这些系统使用容器、微服务和 serverless 架构，大大提高了基础计算架构的利用率，现在，这种架构通常称为云原生。
与传统架构相比，云基础架构和平台必须具有高度的弹性。弹性是系统根据负载变化，实时自动配置和终止资源的能力，缺乏必要的弹性，云计算通常是行不通的，不论在成本上还是运营上。
下图描述了过去十年中一直在发展的明确趋势，虚拟化使整合大量裸机机器和增加物理机利用率成为可能，而且它构成了云技术的技术中坚力量。但是，虽然虚拟机的资源占用量较小，VM的镜像依旧很大。

容器技术的出现是为了改善和简化标准化部署，同时还提供了VM利用率。但是，这也需要权衡取舍，尽管容器可以快速扩展，但是它们始终处于打开状态，并且总是消耗大量资源，为此，FaaS 技术应运而生，并使其可以在专用容器平台上分时使用容器。现在可以采用纯 FaaS 架构来部署任何细粒度的服务。这种分时功能在同一个硬件上是完全可行的，因此 FaaS 可以支持从零进行缩放，这大大提高了资源效率，成本上也是可控的。最近技术已经革新到可以在云中复杂编排资源阵列，并且在相同的物理基础架构上运行更多的负载。

serverless 架构

微服务架构提供了现代解决方案，与单体应用不同，可以规模化扩展计算资源。但是，任何微服务架构都面临着其他挑战，例如部署所有微服务，在云环境运行他们以及根据需要扩展它们。
这孕育了云计算生态系统中的 serverless 架构和 FaaS 平台，其中最著名的是 AWS Lambda，但是还有其他许多类似的服务，包括 Azure Functions、Google Cloud Functions、OpenWhisk Functions 和 Spring Cloud Functions。所有商业平台似乎都遵循相同的基本原理，提供细粒度的服务（每个服务通常仅包含一个无状态功能），这些服务根据每个请求或每个 API 调用运行时消耗模型计费。
serverless 设计支持事件驱动的应用程序，其中轻量级进程会响应事件而触发，它比微服务体系结构更复杂，并且有助于创建各种服务。这种细粒度的服务有时被称为纳米服务，易于部署并且可自动扩展，如果运用得当，对减少运营和基础架构成本有很大的潜力。

云原生架构结合微服务和 serverless 设计

微服务可以以多种方式部署，它们通常与 serverless 体系结构结合在一起，可以驻留在容器中，也可以使用 PaaS 构建。微服务的好处是适用于本地应用程序开发，但是，在云环境中（利用容器或 serverless 架构），可以更加清楚地看到微服务的巨大优势。
微服务和 serverless function 之间的区别在于微服务体积更大，包含更多的功能。通常函数是一小段代码，可以直接响应事件来执行单个动作，在许多情况下，微服务可能等效于 serverless function，或者说微服务类似于 serverless function 的集合。
serverless 微服务驻留在 serverless 基础架构中，并且仅在应用程序进行调用是操作。serverless 计算提供商提供了服务的访问权限，订阅者可以编写和部署可交互的代码，而无需考虑基础架构。大多数服务商提供自动缩放以支持流量波动。这些服务通常按量计费，因此不需要保留未被充分利用的固定容量，从而降低成本。

云原生运动的驱动原因

云原生应用	传统企业应用
高预期性	不可预期、缺乏弹性
按量生产	产能过剩、浪费
协同合作	职责壁垒
持续集成、持续发布	瀑布模型
自动的，系统级的可伸缩性	手动的，有限制的伸缩
操作系统无关行	操作系统依赖
松耦合	紧耦合
恢复迅速	恢复缓慢

云原生架构的好处

云原生应用程序是专门为云模型而构建的，这些程序由小型和专业的功能团队，以快速地节奏构建和部署到易于扩展并且硬件解耦的平台上，从而为组织提供了更大的敏捷性、灵活性和可移植性。
云原生架构提供了众多好处。

竞争优势

云原生架构折射出了计算架构应如何影响业务目标，企业级的思想已经发生了很大的改变，之前仅注重降低成本，现在是需要打造促进业务增长的引擎，在这个不断发展的软件时代，只有那些能够响应当前客户需求，并且可以快速交付应用程序的组织才能取得成功。

增加灵活性

尽管云提供商以合理的价格提供了非常好用的服务，但大多数仍不愿意只选择一种基础架构，灵活性很重要，因为依赖单个供应商会带来很大风险。提供灵活性，并且还保留了快速采用新技术的能力，使开发人员可以选择最适合需求的工具。

专注于弹性

当传统基础架构出现故障时，服务可能会遭受损失，在云原生环境中，团队可以集中精力进行构建，以恢复故障或解决性能缓慢，云原生架构使系统设计在可能发生任何异常情况的环境中仍可以保持在线状态。

使运营与业务占率保持一致

通过使 IT 流程和交付操作自动化，技术团队与业务优先项紧密结合，公司可以变得更加精简，当所有员工都可以专注于自动化以取代效率低下的管理任务时，就可以减轻由于人为错误而导致的故障风险。我们可以在所有层推进自动化升级和运维发布，这可以有效消除停机时间和运维人员进行手动干预，虽然云原生架构有很多好处，但从业人员也面临着许多挑战，接下来我们探讨一下。

向云原生架构迈进的挑战

一些从业人员犯的一个巨大错误是将旧的本地应用直接迁移到云中。将旧版应用程序迁移到云基础架构不会从云原生功能中得到任何好处。相反，最好将遗留应用分解或重构为云原生架构，或者在新的云原生环境开发新的云原生应用程序。
展望未来，放弃新的开发范式和方法将变得越来越重要。瀑布模型实际上已过时，经典敏捷也有不足。要享受云计算的好处，必须采用新的云原生应用程序开发方法，其中包括通过实施现代 DevOps 和 CI/CD 方法、最小化可行产品（MVP）开发、快速迭代、多变量测试以及跨组织边界的紧密集成。
云原生设计、开发和部署涉及很多方面，其中包括虚拟化、容器化、容器编排、微服务架构、基础架构服务、自动化和实时监控。拥抱这些需要吸收新的方法，同时摒弃旧的习惯，保持适当的热度，稳步前行，才能抵达成功。

对从业者的影响

这里简要概述一下有关云原生从业者的一些关键见解。所有这些点都极大地影响了从业人员构建完全针对云计算而设计的云原生架构的方式。

• 更喜欢迁移平台，而不是应用；
• 希望有多个平台选项；
• 首选声明式和自动调整的方式，而不是基于工作流的方式进行编排部署；
• 注重实用的解决方案，而不是全功能覆盖云平台。

从业人员注意事项

分布式计算并不简单，仅仅要使微服务之间互相通信这点就很复杂，容器技术用户面临的挑战是运行微服务的容器具有网络 IP 地址，这个地址需要统一管理。为了在微服务架构上构建云原生应用程序，其他容器需要互相的 IP 地址才能通信。
为了支持联网，每个微服务容器必须提供网络安全性、防火墙、消息队列、负载平衡和其他基本网络服务。将这些全都管理起来是云原生计算发展的下一个主要挑战。而且，云优先架构中的网络因素通常很脆弱，在云计算中建立健壮的网络连接这个问题尚未解决，因此构建云原生体系结构使其具有弹性至关重要。
云原生架构严重依赖微服务，然而，尽管有众多好处，但是微服务并不能解决所有问题，在缓解单体应用问题的同时，微服务提出了一些全新的挑战，它提供的敏捷性和开发速度是以增加管理复杂性作为代价的。这需要增加操作的复杂性，与单体应用相比，需要更多的活动部件。
采用微服务架构可能会增加运营开销，仅仅全面部署微服务就需要消耗大量资源，在创建基础架构也需要付出更多努力。大多数服务都需要建立集群-同时兼顾弹性和故障转移。一个典型的系统具有数十个或更多独立组件

云原生将如何影响整个生态系统

云原生现在尚不是主要的软件开发范式，但不会等太久了。在 Cloud Foundry 的最新调查中，大约600个 IT 决策中游超过75%的人正在使用或者准备使用 PaaS 平台，72%的人正在使用或者准备使用容器，46%的企业正在使用或准备使用 serverless。
我们现处的世界中有很多平台服务，因此，毫不奇怪，在使用了各种工具和平台之后，技术决策者会继续寻找一套可以协同工作的技术。它们会寻求与现有平台良好集成的技术，从而满足当前需求，同时也期望可以适应未来的需求。
超过一半的受访者表示，它们的公司一边构建云原生应用，一边重构现有应用程序，仅仅过了几个月，这项调查结果就提高了9个百分点。

新云原生应用开发的兴起

公司究竟如何使用云原生技术？的确，许多人已经在使用它来重构遗留应用程序。但也正在改变，如今，许多云原生从业人员表明它们主要是在构建新的原生应用程序，很少有开发使用该技术来重构旧的应用程序，许多公司正在更广泛地在 PaaS 上进行部署。

最短时间在应用内验证你的想法

云原生架构的最大优势是什么？用户可以在最短的时间内，完成从对产品的构思到发布上线，没有其他应用程序开发范式比这更有效。
云原生架构所涉及的不只是使应用程序在云计算环境中运行，它在如何设计基础架构，以及如何围绕微服务设计应用程序的方式上发生了重大改变。并且，如果对基础架构进行根本性的修改，需要一个专门针对云原生操作而构建的新工具集。
所有这些努力共同创造了巨大的动力 - 发布更快、应用程序更具扩展性，云原生架构需要付出很多，但在日益激烈的云计算世界中都是值得的。