云原生应用讲解系列一

某一天，在办公室，你在做“下一件大事”

你的手机响了。是你友好的招聘者——一天给你打两次电话谈新工作的人。

但这次不同了：创业、股权和充足的资金。

一提到云和尖端技术，你就会被推到边缘。

快进几周，你现在是一个新员工在设计一个主要的电子商务应用程序的设计会议。你将与领先的电子商务网站竞争。

你将如何建造它？

如果您遵循过去15年的指导，您很可能会构建如图1.1所示的系统。

传统单体设计

构建一个包含所有域逻辑的大型核心应用程序。它包括标识、目录、排序等模块。核心应用程序与大型关系数据库通信。核心通过一个HTML接口公开功能。

祝贺你，你刚刚创建了一个单片应用程序。

不是所有的都是坏的。巨石提供了一些独特的优势。例如，他们很容易。。。

• 建造
• 测试
• 部署
• 故障排除
• 规模

今天存在的许多成功的应用程序都是以巨石的形式创建的。该应用程序是一个热门，并继续发展，一个又一个迭代，增加更多的功能。

然而，在某个时刻，你开始感到不舒服。您发现自己正在失去对应用程序的控制。随着时间的推移，这种感觉变得更加强烈，你最终进入一种被称为恐惧周期的状态。

• 这个应用程序变得极其复杂，以至于没有一个人能理解它。
• 你害怕做出改变——每一个改变都会产生意想不到的、代价高昂的副作用。
• 新特性/修复变得棘手、耗时，而且实施起来成本高昂。
• 每个版本都尽可能小，并且需要完整部署整个应用程序。
• 一个不稳定的组件会使整个系统崩溃。
• 新技术和框架不是一个选择。
• 实施敏捷交付方法是很困难的。
• 随着代码基础的不断恶化和无休止的“特殊情况”，体系结构的侵蚀开始出现
• 顾问让你重写。

许多组织通过采用云原生方法来构建系统，解决了单一的恐惧周期。下图显示了应用云本地技术和实践构建的相同系统。

云原生设计

请注意应用程序是如何在一组小型独立的微服务之间进行分解的。每个服务都是自包含的，并封装了自己的代码、数据和依赖关系。每个都部署在软件容器中，并由容器编排器管理。每个服务都拥有自己的数据存储，而不是一个大型关系数据库，数据存储的类型根据数据需要而有所不同。请注意，有些服务是如何依赖关系数据库的，而另一些服务是如何依赖NoSQL数据库的。一个服务将其状态存储在分布式缓存中。请注意，所有流量都是如何通过负责将流量定向到核心后端服务并强制执行许多横切关注点的API网关服务路由的。最重要的是，应用程序充分利用了现代云平台中的可伸缩性、可用性和可恢复性特性。

云原生计算

我们刚刚用了“云原生”这个词。你的第一个想法可能是，“这到底是什么意思？”另一个由软件供应商炮制的行业流行语是“推销更多的东西？”

幸运的是，这是远远不同的。

在很短的时间内，云原生已经成为软件行业的一个驱动趋势。这是一种考虑构建大型复杂系统的新方法，一种充分利用现代软件开发实践、技术和云基础设施的方法。这种方法改变了设计、实现、部署和操作系统的方式。

与推动我们行业的持续炒作不同，cloud native是真实存在的。以云原生计算基金会（CNCF）为例，它是一个由300多家大公司组成的财团，拥有一个宪章，旨在让云原生计算在技术和云栈中无处不在。作为最具影响力的开放源码组织之一，它托管了GitHub中许多增长最快的开放源码项目。它们包括Kubernetes, Prometheus, Helm, Envoy和gRPC等项目。

云原生到底是什么？

停止你的工作，给你的十个同事发短信。让他们定义术语“云原生”。很有可能你会得到十个不同的答案。

cloudnative就是要改变构建关键业务系统的思维方式。

云原生系统被设计为支持快速变化、大规模和弹性。

云原生计算基金会提供了一个官方定义：

云原生技术使组织能够在现代、动态的环境（如公共、私有和混合云）中构建和运行可伸缩的应用程序。容器、服务网格、微服务、不可变的基础设施和声明性api就是这种方法的例子。

这些技术使得松散耦合的系统具有弹性、可管理性和可观察性。与强大的自动化相结合，他们允许工程师以最小的工作量频繁地和可预见地进行高影响的更改。

应用程序变得越来越复杂，用户的要求也越来越高。用户期望快速响应、创新功能和零停机时间。性能问题、反复出现的错误和无法快速移动已不再是可接受的。他们很容易就会转移到你的竞争对手那里。

Cloud native是关于速度和敏捷性的。业务系统正在从支持业务能力演变为加速业务速度和增长的战略转型武器。必须立即将想法推向市场。

下面是一些已经实现了这些技术的公司。想想他们实现的速度、敏捷性和可伸缩性。

如你所见，Netflix、Uber和微信公开了由数百个独立微服务组成的系统。这种架构风格使他们能够快速响应市场条件。它们可以即时更新活动的复杂应用程序的小区域，并根据需要单独扩展这些区域。

CloudNative的速度和敏捷性来自许多因素。最重要的是云基础设施。下图所示的另外五个基础支柱也为云本地系统提供了基础。

让我们花点时间来更好地理解每一个模块的意义。

云

云本地系统充分利用了云服务模型。

这些系统旨在在动态虚拟化云环境中蓬勃发展，广泛使用平台即服务（PaaS）计算基础设施和托管服务。他们将底层基础设施视为一次性的—在几分钟内调配完毕，并通过自动化按需调整大小、扩展、移动或销毁。

考虑一下被广泛接受的DevOps关于宠物和牛的概念。在传统的数据中心中，服务器被当作宠物：一台物理机器，被赋予一个有意义的名字，并受到照顾。您可以通过向同一台机器添加更多资源来进行扩展（扩展）。如果服务器生病，您可以护理它恢复健康。如果服务器不可用，每个人都会注意到。

牛的服务模式不同。将每个实例设置为虚拟机或容器。它们是相同的，并分配了一个系统标识符，如Service-01、Service-02等等。您可以通过创建更多的对象来进行缩放（向外缩放）。当一个人不在时，没有人会注意到。

牛模型包含不变的基础设施。服务器未修复或修改。如果一个失败或需要更新，它将被销毁，并提供一个新的-所有这些都是通过自动化完成的。

云原生系统采用了牛服务模型。随着基础设施的扩展，它们将继续运行，而与它们运行的机器无关。

Azure云平台支持这种具有自动伸缩、自我修复和监视功能的高弹性基础设施。

现代设计

你将如何设计一个云本地应用程序？你的架构是什么样的？您将遵循哪些原则、模式和最佳实践？哪些基础设施和运营问题将是重要的？

十二因素应用

构建基于云的应用程序的一种被广泛接受的方法是十二要素应用程序。它描述了开发人员在构建针对现代云环境优化的应用程序时遵循的一组原则和实践。特别注意跨环境的可移植性和声明式自动化。

虽然适用于任何基于Web的应用程序，许多从业者认为十二因素作为建立云本地应用程序的坚实基础。基于这些原则构建的系统可以快速部署和扩展，并添加功能以快速响应市场变化。

下表重点介绍了十二因素法：

此外，当今云应用程序设计还有另外三个因素。

关键设计考虑

除了十二要素方法提供的指导之外，在构建分布式系统时，还必须做出几个关键的设计决策。

沟通

前端客户端应用程序将如何与后端核心服务通信？你允许直接沟通吗？或者，您是否可以使用提供灵活性、控制和安全性的网关外观来抽象后端服务？

后端核心服务将如何相互通信？您是否允许直接的HTTP调用导致耦合并影响性能和敏捷性？或者您是否可以考虑使用队列和主题技术来解耦消息传递？

弹性

微服务体系结构将您的系统从进程内网络通信转移到进程外网络通信。在分布式体系结构中，当服务B不响应来自服务a的网络调用时会发生什么？或者，当服务C暂时不可用并且其他调用它的服务被阻塞时会发生什么？

分布式数据

按照设计，每个微服务都封装了自己的数据，通过其公共接口公开操作。如果是这样，如何跨多个服务查询数据或实现事务？

身份

您的服务将如何识别谁正在访问它以及他们拥有哪些权限？