Cloud Native架构应用

世界各地的许多组织已经认识到云计算的威力，并正在向云本地cloud-native架构过渡，以便跟上创新步伐，以快速高效的方式提供数字服务。

随着云计算利用率的提高，预计到2020年，超过32%的新企业应用程序将是cloud-native云本地应用程序。这并不奇怪，因为利用云计算的强大功能，企业可以开发和部署易于扩展、更具弹性的应用程序，而成本仅为成本的一小部分。

openlegacy通过依赖容器、微服务和云计算能力，组织可以节省大量的时间和金钱，否则他们将花费在创建本地解决方案上。

什么是cloud-native云本地架构？

云本地架构是专门为在云中存在和运行而构建的系统或架构。与遗留系统相比，云本机架构的主要优势在于其灵活性。遗留系统依赖于不与新系统和创新集成的硬件和软件，而云本地架构不受这些需求的限制。

云本地架构不是构建在本地物理服务器上，而是部署在云平台上，并利用分布式系统的云哲学。这使得云本地架构能够充分利用分布式系统的最新和最佳技术。它们是专门为利用云的多功能性和可伸缩性而设计的。

cloud-native云本地应用程序

理解云本机架构的最好方法是仔细研究云本机应用程序。云本地应用程序的构建方法与单一应用程序完全不同。云原生应用程序不是作为一个整体开发和部署应用程序，而是基于自包含和独立部署的微服务。

微服务是云本地应用架构的核心。它们本质上是小型的、自给自足的迷你程序，每个程序都有自己的数据存储和应用程序逻辑，用于执行单个业务功能。

如果你想了解更多关于微服务的信息，这里有一篇详细的文章，解释什么是微服务，它们是如何工作的，以及接受微服务和基于微服务的API的主要业务好处是什么。

微服务是松散耦合的，设计用于容器内的编排。容器允许使用任何工具集（Kubernetes、OpenShift）快速轻松地部署到任何云平台（私有云、公共云或混合云）。

微服务背后的主要思想是实现灵活性和可伸缩性，支持DevOps，并大幅提高部署速度，同时降低成本。

灵活性和可扩展性

微服务的独立性使组织能够采用相当灵活的方法在云中创建应用程序。由于微服务是自包含的，开发人员总是可以根据特定微服务的业务能力和所需功能来选择最佳工具。

换句话说，他们可以选择最合适的数据存储，并使用对他们所从事的特定微服务最有意义的编程语言。这意味着开发人员不致力于一种技术，也不受其功能的限制。

随着创新和新技术的引入，开发人员可以轻松地利用它们，而不必担心一个微服务中的更改将如何影响整个应用程序。他们可以更新和扩展单个微服务，也可以删除现有的和添加新的微服务，而无需在推出新版本时中断应用程序或使其暂时不可用。

DevOps和敏捷框架

微服务非常适合采用DevOps和CI/CD（持续集成/持续交付）的敏捷组织。正如我们提到的，微服务是自包含的，这意味着它们是可独立测试和可部署的单元。

微服务和云本机架构使多个跨职能的开发团队能够同时开发应用程序的不同功能。它们还使组织能够在整个开发生命周期中接受不断变化的需求，并快速有效地响应客户反馈。

使用微服务，应用程序被分解成更小、更易于管理的单元，这些单元可以独立开发、测试和部署。这与敏捷框架和DevOps寻求实现的目标完全一致。

部署速度

对于单片应用程序，开发人员被迫在对其应用任何更改之前复制整个遗留系统。考虑到单个应用程序中元素之间的巨大相互依赖性，开发人员必须长期而认真地考虑他们计划实现的更改将如何反映整个应用程序。

几乎不可能考虑所有可能的场景，开发人员必须在重新部署应用程序之前再次测试整个系统，以确保一切都按预期工作。这个测试过程通常是乏味的，可能是相当昂贵和耗时的。还有一个事实是，考虑到遗留系统是建立在过时的技术上的，开发人员在向现有系统引入新功能时受到了严重的限制。

使用微服务，这个过程既快速又简单。开发人员只需担心他们正在开发的单个微服务，只需在将其部署到云中之前测试其功能。这使得组织能够基于新技术部署出色的数字服务，比使用单片体系结构的速度快十倍。

当您需要开发新的数字服务或更新您的应用程序，但您的整个遗留应用程序都基于本地服务时，所有这些实例又如何呢？大多数组织错误地认为他们只有三种选择：

• 坚持他们的传统系统
• 将整个遗留应用程序迁移到云
• 创建全新的云本地应用程序

现代的微服务抽象了这种选择，弥补了传统IT和云之间的鸿沟。OpenLegacy使您能够在云中创建微服务，直接从遗留系统（大型机、中端系统和数据库）中提取数据。

这样，您仍然可以保留现有遗留系统的功能，同时通过云本地微服务提供基于新技术的数字服务。

云原生应用的关键特征

云本地架构几乎与基于微服务的应用程序同义。为了更好地理解过渡到云本地架构的影响，让我们看看云本地应用程序的关键特性。

云本地应用程序的关键特征是：

• 设计成松散耦合的微服务
• 以API为中心
• 包装成轻型容器
• 不依赖于服务器和操作系统
• 部署在灵活的基础架构上
• 自动化功能
• 独立生命周期
• 提高资源利用率

设计成松散耦合的微服务

微服务是独立设计和部署的，通常依赖异步通信来相互共享信息。这意味着它们是完全自给自足的，永远不会直接调用另一个服务的数据存储。

换句话说，当一个服务失败时，无论出于什么原因，其他微服务都将继续正常工作。

由于这种解耦，开发人员可以将每个微服务视为完全不同的实体。这使他们能够专注于每个微服务的核心功能，并实现整个应用程序的高效生命周期管理。每个服务都是独立维护的，每个开发团队都拥有他们开发的服务的所有权。

以API为中心

Cloud-native云本地架构以api（应用程序编程接口）为中心。API本质上是最终用户所看到的—例如，应用程序中的登录表单。单个微服务可以公开不同的api，但不是每个微服务都必须公开。可以说，有些在后台工作，并处理最终用户不直接与之交互的功能。

云原生微服务通常依赖于诸如表示性状态转移（REST）、Google的开源远程过程调用（gRPC）和NATS等协议。REST通常用于通过超文本传输协议（HTTP）公开API。对于微服务之间的内部通信，gRPC通常是首选。NATS支持事件源，并具有发布-订阅功能，方便应用程序内的异步通信。

包装成轻型容器

云本地应用程序本质上是独立的微服务的集合，这些服务被打包为轻量级容器并开发到云中。容器允许轻松部署到任何云平台（AWS、Google等），并可以快速伸缩。通过这种方式，基础设施利用率得到充分优化，因为扩展单元从应用程序整体（在单片体系结构中）转移到容器。

不依赖于服务器和操作系统

云本地应用程序与特定的服务器或操作系统无关。默认情况下，微服务可以部署在多个服务器上，并且可以在任何操作系统上运行。一个例外是，特定的微服务需要某些功能，如固态驱动器（ssd）和图形处理单元（gpu），在这种情况下，它在某种程度上依赖于硬件提供的物理功能。

部署在灵活的基础架构上

云代表了一个虚拟的、灵活的、弹性的基础设施。这使云本机应用程序能够与底层基础设施相协调，以动态地调整自己以适应不同的工作负载。

考虑到微服务可以跨多个服务器部署，这意味着您可以自由选择将哪些服务放在私有云中，哪些放在公共云中。基础设施的这种灵活性使您能够利用公共云的计算能力，在不同的环境之间自由地迁移服务，以有效地处理工作负载高峰。

自动化功能

云本地应用程序的美妙之处在于，它们是为自动化而设计的。由于云本地应用程序是作为微服务交付的，这意味着您可能需要部署数百个容器。手动操作将是一场噩梦。

这就是为什么开发人员从一开始就密切关注编排需求和自动化。这涉及到明确定义实现应用程序的不同组件所需的过程，并最小化应用于每个组件的配置级别。

说到云本地架构，自动化包括：

• 自动IP地址分配—云本机应用程序通常依赖动态主机配置协议（DHCP）自动获取IP地址。也就是说，IP地址可以在必要时硬分配给云本地网络功能（CNF）。
• 自动发现—云本地应用程序通常依赖域名服务器（DNS）或服务网格来发现需要与之通信的对等方。
• 共享配置存储—云本地应用程序中的组件始终参与共享的分布式键值存储。这使他们能够自动获得大部分初始配置，而不需要orchestrator的直接输入。

独立生命周期

在云本地架构中，每个微服务都有一个独立的生命周期。这使得不同的团队能够同时开发不同的服务集，并允许组织利用多个连续集成/连续交付（CI/CD）管道来开发、部署和管理云本地应用程序。

提高资源利用率

开发云本地应用程序的组织通常会创建策略，通过这些策略定义如何将资源分配给特定服务。

在企业场景中，central IT可以根据每个团队正在处理的项目的范围和服务的功能，创建策略来为每个部门分配资源。这意味着每个开发人员团队对分配给他们的资源拥有完全的访问权和所有权。

云本地架构的优缺点

组织选择采用云本地方法的原因有很多。同时，如果您决定在云中开发应用程序，您应该意识到您可能面临的潜在挑战。

让我们来看看云本地架构的优缺点：

优点

很大程度上要感谢基于微服务的事实，云本地架构提供了各种好处：

• 它们更容易管理——考虑到迭代改进是使用DevOps和敏捷流程执行的，因此云本地应用程序比单一应用程序更容易管理。
• 增量改进—微服务是独立部署和扩展的，允许对云本地应用程序进行增量改进，以不断改进应用程序的功能并引入新功能。在微服务级别上进行了改进，这意味着没有停机时间，并且最终用户体验是不间断的。
• 微服务与平台无关——正如我们所提到的，开发人员可以使用最合适的编程语言和数据存储创建微服务。它们还可以跨不同的环境部署，并在多个平台上工作，这样您就不会遇到类似于Windows特定API的问题。
• 最高效率—云本机体系结构使中央编排器能够根据需求快速高效地管理和调度微服务。
• 与创新保持同步—云本地应用程序的开发过程使组织能够快速接受创新和新技术，并将其集成，而无需重新构建整个应用程序。

缺点

云本地架构并非没有挑战。在采用云本地架构之前，需要考虑以下几点：

• 操作系统和硬件或软件依赖性—如果某些微服务需要特定的硬件或软件功能（如SSD或GPU），则它们可能依赖于特定的操作系统或机器。
• 更新安全系统-云本地架构中的容器化需要更改当前的安全系统。
• 采用DevOps—除非您的组织已经是敏捷的，否则如果您的开发和操作团队不习惯一起工作，采用DevOps可能是一个挑战。

云本地应用程序示例

云本地应用程序中的每个微服务都执行特定的功能。以一家电子商务商店为例。一个微服务将用于登录表单，另一个用于接受客户订单，第三个用于特殊折扣和优惠券。尽管客户将电子商务商店视为一个整体，但它们中的每一个都可以独立地进行更新和扩展。

要实现新功能或更改特定的微服务，您不必关闭整个站点。一个特定的功能可能暂时不可用，但由于开发人员一次只处理一个微服务，更新和新功能可以在几个小时内推出。

以下是一些云本地应用程序的示例：

• UBank-UBank希望改进其住房贷款申请流程，帮助客户更轻松地申请贷款。他们使用IBMDevOps工具链创建了一个云本地智能助手应用程序——RoboChat，它回答了客户的询问，帮助将房屋贷款完成率提高了15%！
• 美国航空公司-该公司与IBM合作开发并部署了一个动态重订应用程序，该应用程序为客户提供详细信息，使航班重订更加快捷和方便。
• ThinkResearch—ThinkResearch利用云本机架构创建和部署一个应用程序，将最新的研究和相关的医疗信息提供给医疗点的医生。该公司依靠云中基于微服务的api来快速交付解决方案，而无需进行巨额前期投资来构建内部IT基础设施。

结论

在当今的数字商业世界中，变化是唯一不变的。创新和新技术的引进速度很快，严重依赖其遗留系统的公司将难以跟上步伐，而且很可能会将客户流失给技术更为娴熟的竞争对手。

如果您想跟上不断变化的客户需求并快速、无缝地将新技术与现有系统集成，云本地架构和基于微服务的API是完美的解决方案！

原文地址：https://www.openlegacy.com/blog/what-is-cloud-native-architecture