威廉退尔交响曲_容器，微服务和整个交响曲的编排-CSDN博客

威廉退尔交响曲

微服务架构远非新趋势。如今，人们普遍认为它是构建应用程序的更好方法。直到几年前，构建应用程序的常用方法还是单片式方法-如果从功能角度来看，它基本上是一个部署单元，可以完成所有工作。整体应用适合小型团队和项目，但是当您需要规模更大且涉及许多团队的东西时，它就会成为问题。随着代码库的扩大和越来越多的人对其进行更改，更改变得更加困难。

基本上，这与连续交付的所有事物完全相反，因为它之间的耦合更加紧密，并且需要不断增加的协调量才能进行连续更新。因此，更新变得更加痛苦且频率更低，从而进一步加剧了应用程序的脆弱性。

那么，微服务到底是什么？该架构如何改善交付周期？

开发微服务是一种分而治之的方法。

基本上，微服务方法概括地说，不是由所有开发人员都使用一个庞大的代码库，而是常常使管理变得危险，而是由小型和敏捷的团队来管理许多较小的代码库。这些代码库之间唯一的依赖关系就是它们的API。这意味着，只要保持向后和向前的兼容性（尽管这不是那么简单），每个团队就可以在与其他团队脱钩的发布周期中工作。在某些情况下，这些发布周期是耦合的，其中一个服务依赖于另一个服务或依赖于另一个服务中的新功能，但这不是通常的情况。

当时领先的是像Netflix或Amazon这样的公司。他们决定，与其构建一个单一的应用程序来处理其服务的所有方面，不如构建用于处理离散业务功能的小型服务。这些单元之间的边界是功能性API，它们公开了每个服务的核心功能。对于Amazon.com，这将是其网站的不同方面-建议，购物车，发票，库存管理等。 Amazon并非将所有功能都整合到一个庞大的部署单元中，而是将每个功能实现为具有明确定义的接口的自包含服务。这样做的好处是您可以拥有不同的团队，每个团队负责他们从A到Z的服务的各个方面。因此，如果有一个团队负责计费，那么他们将负责从编写代码，测试代码到生产的所有工作。，处理故障以及该服务可能发生的任何其他情况。

不用说，这对于连续交付更好，因为较小的单元更易于管理，测试和部署。

好的，什么是开源连接？

Netflix就是一个例子。作为这种架构趋势的领导者，Netflix还构建了许多工具，这些工具可以促进分布式和复杂架构成为开放源代码项目，任何人都可以进行分叉和自定义，这在一定程度上也影响了随之而来的众多技术。一种这样的技术是Kubernetes，它是通过扩展Docker的功能而专门为微服务设计的。这使公司能够为工作选择合适的工具，并在没有复杂许可周期的情况下Swift采用它们，并对其进行调整和扩展，以满足其特定的体系结构和业务需求。

听起来好得令人难以置信？

当然，有了好，总有不好。这就产生了另外一系列问题，例如从整体上理解系统，什么取决于什么，以及当一项服务失败时，它会引起级联失败的可能性要大得多，这是很难追踪的。有关微服务架构带来的折衷的更多信息，请阅读ThoughtWorks的精彩文章。

“使用这样的服务确实有弊端。远程调用比进程内调用更昂贵，因此远程API需要更粗粒度，这通常更笨拙。如果您需要更改组件之间的职责分配，，当您跨越流程边界时，这样的行为移动就很难做到。”

为什么Docker非常适合微服务？

如果我们深入研究技术，则Docker在微服务方面非常出色，因为它将容器隔离到一个进程或服务中。单个服务或流程的这种故意容器化使得管理和更新这些服务非常简单。因此，不足为奇的是，在Docker之上的下一波浪潮导致了框架的出现，其唯一目的是管理更复杂的场景，例如：如何管理集群中的单个服务或跨主机的服务中的多个实例。，或如何在部署和管理级别上协调多个服务。

为此，我们已经看到了Kubernetes ， Maestro-ng ， Mesos和Fleet等开源项目 Swift应对这一日益增长的需求。例如，如果我们看一下Kubernetes，它现在正真正受到人们的关注，它得到了Google的支持，现在看到像Microsoft和Red Hat这样的领先企业加入其中。该项目通过提供一些关键功能而针对微服务而构建。

借助Kubernetes，您可以通过智能标记系统轻松部署和管理相同类型的多个Docker容器。您基本上描述了要部署的映像的特征（例如，实例数，CPU，RAM），并且Kubernetes还将根据要部署的主机集上的实际可用资源为您分配映像。由于标签系统使您可以唯一地标识图像，因此您无需关心它们的物理位置。在标签之上，您可以创建称为“ pods”的另一组分组，这实际上是对具有一个或多个标签的容器的连续查询。 Kubernetes会不断更新满足查询条件的容器集，并在这些容器之间实现负载平衡，以便任何人从外部访问它们都可以使用一个端点。

由Codemotion提供。

这种格式非常适合微服务和Docker，因为它可以满足对微服务体系结构非常重要的确切特征-轻松部署新服务（这就是Docker封装所在的位置），独立地扩展每个微服务，导致失败。对访问它的客户端透明的单个mircoservice实例，并允许基于端点的简单，临时名称发现服务端点。

少了什么东西？

当涉及可以跨负载均衡的简单无状态服务且所有实例完全相同时，这都是非常有用的。此类服务的一个很好的例子是某种形式的Web服务或无状态Web应用程序。

当您具有状态服务时，或者当微服务本身由多个部分（例如数据库或消息传递队列）组成时，事情会变得更加复杂。 Kubernetes有一个隐含的假设，即服务实例（例如，存储用户配置文件的Mongo集群）之间共享的所有状态都在Kubernetes之外进行管理。

但是，在许多情况下，您要管理的内容由相互依赖的多个层次（Web，数据库，消息传递等）组成。因此，通常，与Kubernetes一起使用即使不是不可能也很难。 Kubernetes专为每个容器实际上是独立的且可复制的情况而设计；很多时候不一定是这种情况。如果要自动化不是微服务的应用程序层的部署和管理（例如中央数据存储库，例如Hadoop或Cassandra），也是如此。后两个不能部署在Kunernetes上（尽管更简单的Redis）可）。

图片由Martin Fowler提供。

在这种情况下，您需要一个能够描述更复杂的拓扑和部署的协调器，而这正是TOSCA的用武之地。

TOSCA的想法是采用最理想的方法来部署每个组件。如果这是一个简单的无状态微服务，那么最好的方法是使用Docker和Kubernetes（或类似的东西）。当您处理需要复杂编排的更复杂的拓扑（例如，完全复制和分片的mongo集群，或更复杂的微服务）时，这就是使用TOSCA蓝图的方案。当然，如果您想坚持采用单一的处理方式，则也可以将TOSCA蓝图用于前一种情况（即生成Docker映像的几个实例）。

Cloudify Docker编排插件就是这种实现方式的一个例子，该插件利用TOSCA进行简单的微服务部署（使用TOSCA输出参数作为公开特定服务端点的手段），并通过支持复杂应用程序堆栈的编排来实现更复杂的拓扑。基于这种方法，您还可以获得支持部署后问题的附带好处，例如通过Cloudify基于TOSCA的蓝图实现的自动缩放，监视和自动修复。