云原生应用讲解

Posted 2021-04-23 IT大咖说

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生应用讲解相关的知识，希望对你有一定的参考价值。

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

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

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

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

你将如何建造它？

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

云原生应用讲解

传统单体设计

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

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

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

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

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

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

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

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

云原生应用讲解

云原生设计

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

◆ 云原生计算

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

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

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

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

◆ 云原生到底是什么？

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

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

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

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

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

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

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

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

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

公司	经验
Netflix	在生产中提供了600多项服务。每天部署一百次。
Uber	有1000多个生产服务。每周部署几千次。
微信	在生产中有3000多个服务。每天部署1000次。

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

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

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

◆ 云

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

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

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

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

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

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

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

◆ 现代设计

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

◆ 十二因素应用

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

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

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

	因素	解释
1	代码库	每个微服务的单一代码库，存储在自己的存储库中。通过版本控制跟踪，它可以部署到多个环境（QA、暂存、生产）。
2	依赖项	每个微服务都隔离并打包了自己的依赖项，在不影响整个系统的情况下接受更改。
3	配置	配置信息从微服务中移出，并通过代码外部的配置管理工具进行外部化。相同的部署可以在应用了正确配置的环境中传播。
4	支持服务	辅助资源（数据存储、缓存、消息代理）应该通过可寻址的URL公开。这样做可以将资源与应用程序分离，使其能够互换。
5	构建、发布、运行	每个发行版都必须在构建、发行和运行阶段之间实施严格的分离。每一个都应该标记一个唯一的ID，并支持回滚功能。现代CI/CD系统有助于实现这一原则。
6	进程	每个微服务都应该在自己的进程中执行，与其他正在运行的服务隔离开来。将所需状态外部化到备份服务（如分布式缓存或数据存储）。
7	端口绑定	每个微服务都应该是独立的，其接口和功能在自己的端口上公开。这样做提供了与其他微服务的隔离。
8	并发	服务跨大量相同的小进程（副本）扩展，而不是在功能最强大的计算机上扩展单个大型实例。
9	可处置性	服务实例应该是一次性的，有利于快速启动，以增加可伸缩性机会，并使系统处于正确的状态。Docker容器和orchestrator本身就满足了这个要求。
10	开发/生产校验	使整个应用程序生命周期中的环境尽可能相似，避免昂贵的快捷方式。在这里，通过促进相同的执行环境，采用容器可以做出很大的贡献。
11	日志	将微服务生成的日志视为事件流。使用事件聚合器处理它们，并将数据传播到数据挖掘/日志管理工具，如Azure Monitor或Splunk，最终进行长期存档。
12	管理流程	作为一次性流程运行管理任务。任务可以包括数据清理和对报表进行分析。执行这些任务的工具应该从生产环境中调用，但要与应用程序分开。

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

	新要素	解释
13	API优先	让一切都成为服务。假设您的代码将由前端客户端、网关或其他服务使用。
14	遥测	在工作站上，您可以深入了解应用程序及其行为。在云中，你没有。确保你的设计包括监视、特定领域和健康/系统数据的收集。
15	身份验证/授权	从一开始就实现身份。考虑一下公共云中可用的RBAC（基于角色的访问控制）特性。