【云计算】Practical Use of Microservices in Moving Workloads to the Cloud

微服务在将工作负载转移到云中的实际使用

什么是服务，什么时候服务是微服务？

好问题。在使用服务时，我们利用远程方法或行为，而不是简单地将信息提取或发布到远程系统。此外，我们通常将此远程服务抽象为另一个称为复合应用程序的应用程序，该应用程序通常由多个服务组成。
服务的一个很好的例子是风险分析过程，它在企业内部运行，以计算金融交易的风险。这个远程应用服务本身用处不大，但是当抽象成一个更大的应用程序（例如，一个交易系统）时，远程应用服务就具有附加价值。
请注意，我们利用这个远程服务的行为，而不是它产生或使用的信息。如果您是一名程序员，您可以将应用程序服务视为子例程或方法，您可以调用它们来实现某些功能。
面向服务架构（service-oriented architecture，SOA）和使用云计算的SOA的基本概念是利用这些远程服务，使用一些受控制的基础设施，允许应用程序调用远程应用程序服务，就像它们是应用程序的本地服务一样。结果（或目标）是由许多本地和远程应用程序服务组成的复合应用程序。由于它们独立于位置和平台，因此可以驻留在本地或许多云计算提供商中的一个。
此外，一旦服务被识别和公开，或者从零开始开发，我们就可能拥有可以放置在本地平台和云平台上并跨越它们的服务。所以，这些是概述。

进入微服务

微服务是一种体系结构和机制，经常与传统的SOA类型服务混淆。确实，有很多重叠。它是一种体系结构模式，在这种模式中，复杂的应用程序由使用与语言无关的api相互通信的独立小进程组成。
这是面向服务的计算，其本质是将应用程序分解为功能原语，并将其构建为可由其他应用程序或应用程序本身利用的服务集。这也是重用的基础，这些服务对于容器和非基于容器的应用程序都是系统性的。（见https://blog.akana.com/the venn of microservices。）
这种方法的好处包括通过重用微服务提高效率。当我们为云重建应用程序时，我们修改它们以公开其他应用程序可以访问的服务。更重要的是，我们可以使用重新构建的应用程序中的服务，因此不必从头构建功能。
例如，一些程序具有必须维护的内置系统，如信用验证、映射和地址验证服务。这每年要花费数十万美元。基于服务的方法允许我们接触并使用提供此功能和更多功能的远程服务，这样您就可以不必维护在其他地方可以找到的服务。它还允许我们公开服务供其他应用程序在企业内使用，甚至可以通过开放的Internet向其他企业销售服务。

进入容器

使用容器包装或容器化现有应用程序具有一些优点，包括通过利用容器抽象来降低复杂性的能力。容器消除了对底层基础设施服务的依赖，从而降低了处理这些平台的复杂性。这意味着我们可以从应用程序本身抽象出对资源（如存储）的访问。这使得应用程序可移植，但也加快了应用程序的重构，因为容器处理对本机云资源的大部分访问。
容器还提供了利用自动化最大限度地提高其可移植性的能力，并且具有可移植性，还提供了其价值。通过使用自动化，我们正在编写一个也可以手动执行的功能脚本，例如将容器从一个云迁移到另一个云。然而，这个选项的用例被证明是有限的。实际上，大多数新的应用程序都是为了利用容器而构建的，但是现有的应用程序通常很难进行容器化。正如最初所认为的那样，利用容器的目标似乎是分布式体系结构价值与可移植性。然而，可移植性始终是利用容器的副产品。
还要考虑通过将这些服务放在容器周围而不是放在容器中来提供更好的安全性和治理服务的能力。在许多情况下，安全和治理服务是特定于平台的，而不是特定于应用程序的。例如，传统的内部部署应用程序往往没有应用程序固有的安全和治理功能。在重构时，将安全和治理服务置于应用程序域之外的能力提供了更好的可移植性和更少的复杂性。在此上下文中利用微服务的能力也提供了相同的优势，无论您是否使用容器。
容器也可以提供更好的分布式计算能力。传统的应用程序可以分为许多不同的域，它们都位于容器中。这些容器可以在任何数量的不同云平台上运行，包括那些提供最高成本和性能效率的云平台。因此，应用程序可以根据其在容器内对平台的利用率进行分布和优化。
例如，可以将应用程序的I/O密集型部分放在提供最佳性能的裸机云上，将应用程序的计算密集型部分放在可以提供适当扩展和负载平衡的公共云上，甚至可以将应用程序的一部分放在传统硬件和软件上。所有这些元素一起形成应用程序，应用程序被分离成可以优化的组件。

重构容器和微服务的传统应用程序

在这一点上，将应用程序和服务同时进行容器化的过程比科学更具艺术性。然而，随着企业开始使用容器和面向服务的架构将传统应用程序迁移到云端，一些成功模式开始出现。
模式1快速决定如何将应用程序分解成组件，这些组件将在分布式环境中的容器内部运行。这意味着将应用程序分解为其功能原语，并将其作为组件进行备份，以最小化需要更改的代码量。
模式2将数据访问构建为应用程序使用的服务，并让所有数据调用通过这些数据服务。这将使数据与应用程序组件（容器）分离，并允许您在不中断应用程序的情况下更改数据。此外，您正在将数据复杂性放到它自己的域中，这将是另一个使用面向数据的微服务访问的容器。
模式三在测试上挥霍。尽管许多人会指出容器的稳定性是解决黑盒和白盒测试的一种方法，但是应用程序现在以一种新的体系结构存在，具有新的服务依赖性。在部署之前，可能需要进行大量的调试。
这也有其他方面。我的顾问委员会成员之一Lori MacVittie在一封电子邮件中指出，容器和微服务似乎将许多无关紧要的主题混合在一起，但微服务与容器无关，只是它们碰巧同时出现。
这里的重点应该放在一起工作的技术上，而不是作为一个独立的技术。这个概念是为了理解利用容器和微服务（它们确实是独立的）有一些附加的优势。也就是说，如果说微服务确实是传统意义上的服务，那么我没有反驳。

当应用程序投入生产时，那些负责云操作的人应该利用容器架构。

操作注意事项

与迁移之前相比，支持云的传统应用程序在生产中的管理方式必须有所不同。这一阶段称为云操作，或云中应用程序容器的操作。
当应用程序投入生产时，那些负责云操作的人应该利用容器架构。将它们作为分布式组件进行管理，这些组件一起工作以形成应用程序，并且还可以单独扩展。例如，管理用户界面的容器可以跨服务器复制，因为当用户早上登录时，对该容器的需求会增加。这为云操作提供了一种方便的方法，可以围绕应用程序构建自动缩放功能，在需求变化时扩展和取消扩展云资源的使用。
大多数企业相信云将成为应用程序的新家。然而，并非所有的应用程序都适合云计算，至少现在还不适合。必须注意选择正确的应用程序才能移动。
容器和微服务的使用使事情变得更容易。这种方法迫使负责重构应用程序的应用程序开发人员考虑如何最好地重新设计应用程序，使其成为容器化和面向服务的。从本质上讲，您将使用一个单片应用程序，并将其转换为更复杂、更分布式的应用程序。然而，它也应该更具生产力、敏捷性和成本效益。这才是真正的目标。

微服务耦合

当我们创建微服务以服务于新的或现有的应用程序时，我们需要了解松耦合的好处。与微服务相关的松耦合有一些基本模式。
在位置独立模式中，微服务存在于何处并不重要；需要利用该服务的其他组件可以在目录中发现它，并通过后期绑定过程利用它。当您利用不断改变物理和逻辑位置的微服务时，这一点非常有用，特别是您可能不拥有的组织外部服务，例如云交付的资源。您的风险计算服务可能在周一在本地，周二在云中，这对您没有任何影响。
动态发现是这个概念的关键，这意味着调用组件可以根据需要定位微服务信息，而不必与服务紧密绑定。这些服务通常是私有、共享或公共服务，因为它们存在于目录中。
在通信独立模式中，所有组件都可以相互通信，无论它们在接口或协议级别如何通信。因此，我们利用使能标准（如微服务）来调解协议和接口差异。
安全独立模式是基于调解组件内部和组件之间安全模型之间的差异的概念。这有点难实现，但对于任何基于服务的体系结构都是必要的。要启用此模式，您必须利用可以在组件之间创建信任的联合安全系统，不管组件的本地安全模型是什么。这是支持松散耦合模型和Web服务的联邦安全标准数量背后的主要力量。
在实例独立模式中，ar架构应支持使用同步和异步模型的组件间通信，并且不要求其他组件在接收请求或消息之前处于任何特定状态。因此，如果做得对，所有服务都应该能够异步地为任何请求组件提供服务，并且不管顺序是什么，都可以保留和管理状态。
在云计算解决方案中需要松散耦合的架构并不是问题所在。如果您正确地利用了云计算，那么您应该有一个松散耦合的体系结构，除非在某些罕见的情况下。分析和规划也是混合的一部分，理解您的需求以及架构的每个组件应该如何利用架构的其他组件也是混合的一部分。杠杆作用最适合您的需求的耦合模型。
==虽然这看起来工作很多，但实际上只是对现有服务的快速调查和解释。==此外，虽然我建议使用基本概念和基本方法，但是您的IT环境的需求是独特的，可能需要稍微不同的方法。只要能够完全理解问题域中的微服务，那么如何完成这个项目就取决于你了。在服务级别理解域的另一个好处是，您可以轻松地在其他方向利用这项工作，可能是为了支持核心企业体系结构或构建和/或优化您的体系结构。

参考