编排微服务

Question

编排微服务的标准模式是什么？

如果一个微服务只知道它自己的领域，但是有一个数据流需要多个服务以某种方式交互，那该怎么做呢？

假设我们有这样的东西：

null

在某个地方，有人按下GUI中的一个按钮，“我完成了，让我们这么做吧！”在一个典型的整体服务体系结构中，我认为有一个ESB来处理这个问题，或者装运服务了解发票服务并直接调用发票服务。

但在这个美丽的微服务新世界里，人们是如何处理这件事的呢？

我确实知道这可以被认为是高度基于意见的。但它也有具体的一面，因为微服务不应该做上述的事情。因此，必须有一个“根据定义它应该做什么”，这不是基于意见的。

Answer 1

《构建微服务》一书详细描述了@Rogeralsing在回答中提到的风格。

在第43页“编排与编舞”一节中，这本书说：

随着我们开始为越来越复杂的逻辑建模，我们不得不处理管理跨越单个服务边界延伸的业务流程的问题。有了微服务，我们将比往常更快地达到这个极限。[...]当涉及到实际实现这个流时，我们可以遵循两种架构风格。对于配器，我们依赖于一个中央大脑来引导和驱动这个过程，就像管弦乐队中的指挥一样。通过编舞，我们告诉系统的每一部分它的工作，并让它制定细节，就像舞者在芭蕾舞剧中找到自己的方式，并对周围的人做出反应。

业务流程样式

在这种文体下，上书提到：

让我们想想这个流程的编排解决方案是什么样子的。在这里，最简单的做法可能是让我们的客服充当中央大脑。在创建时，它通过一系列请求/响应调用与忠诚度积分银行、电子邮件服务和邮政服务进行对话[...]。然后客户服务本身可以跟踪客户在此过程中的位置。它可以进行检查，看看客户的账户是否已经建立，或者发送的电子邮件，或者投递的邮件。我们可以把流程图[...]并将其直接建模到代码中。我们甚至可以使用为我们实现这一点的工具，也许可以使用适当的规则引擎。商业工具正是为了这个目的而存在的，它以业务流程建模软件的形式存在。假设我们使用同步请求/响应，我们甚至可以知道每个阶段是否工作了[...]这种编排方法的缺点是，客户服务可能会变得过于集中管理机构。它可以成为web中间的枢纽和逻辑开始生存的中心点。我已经看到这种方法导致了一小部分聪明的“上帝”服务告诉贫乏的基于CRUD的服务该做什么。

在编舞风格下，作者说：

使用编排好的方法，我们可以让客户服务以异步方式发出一个事件，说是customer Created。电子邮件服务、邮政服务和忠诚度积分银行只需订阅这些活动并作出相应反应[...]这种方法的去耦性明显更强。如果某个其他服务需要到达客户的创建，它只需要订阅事件并在需要时完成它的工作。缺点是我们在[工作流]中看到的业务流程的显式视图现在只隐式地反映在我们的系统中[...]这意味着需要额外的工作来确保您可以监视和跟踪正确的事情已经发生。例如，如果忠诚积分银行有一个bug，由于某种原因没有设置正确的帐户，你会知道吗？我喜欢的一种处理方法是构建一个监视系统，它显式地匹配[工作流]中的业务流程视图，但随后跟踪每个服务作为独立实体所做的工作，让您看到映射到更显式流程流上的奇怪异常。[流程图][...]不是驱动力，而只是一个镜头，通过它我们可以看到系统的行为。一般而言，我发现更倾向于编排方法的系统更加松散耦合，并且更加灵活和易于更改。但是，您确实需要做额外的工作来监视和跟踪跨系统边界的进程。我发现大多数精心编排的实现都非常脆弱，而且更改的成本更高。考虑到这一点，我强烈地倾向于一个编排好的系统，每个服务都足够聪明来理解它在整个舞蹈中的角色。

注意：直到今天，我仍然不确定编排是否只是事件驱动架构(EDA)的另一个名称，但如果EDA只是实现它的一种方式，那么其他的方式是什么呢？（还请参见“事件驱动”是什么意思？以及事件驱动架构的含义）。而且，像CQRS和EventSourcing这样的东西似乎与这种架构风格有很大的共鸣，对吗？

接下来就是乐趣了。《微服务手册》并没有假设微服务将用REST实现。事实上，在本书的下一节中，他们将继续考虑基于RPC和SOA的解决方案，最后讨论REST。这里很重要的一点是，微服务并不意味着REST。

那Hateoas呢？（超媒体作为应用程序状态的引擎）

现在，如果我们想要遵循RESTful方法，我们不能忽视HATEOAS或Roy Fielding将非常高兴地在他的博客中说，我们的解决方案不是真正的REST。参见他关于REST API必须是超文本驱动的博文：

因此，正如您所看到的，Fielding认为没有HATEOAS就不能真正构建RESTful应用程序。对于Fielding来说，当涉及到编排服务时，HATEOAS是可以走的路。我只是在学习这一切，但对我来说，HATEOAS并没有明确定义谁或什么是背后的驱动力实际跟随链接。在UI中可以是用户，但在计算机到计算机的交互中，我认为这需要由更高级别的服务来完成。

根据HATEOAS的说法，API使用者真正需要知道的唯一链接是启动与服务器通信的链接（例如POST/order）。从这一点开始，REST将引导流程，因为在此endpoint的响应中，返回的资源将包含到下一个可能状态的链接。然后，API使用者决定要遵循什么链接，并将应用程序移动到下一个状态。

尽管这听起来很酷，客户端仍然需要知道链接是否必须发布、推送、预算、补丁等等，并且客户端仍然需要决定要传递什么有效负载。客户端仍然需要知道如果失败（重试、补偿、取消等）该怎么做。

我对所有这些都很陌生，但对我来说，从HATEOAs的角度来看，这个客户机或API使用者是一个高级服务。如果我们从人类的角度来考虑，您可以想象一个web页面上的最终用户决定要遵循什么链接，但是web页面的程序员仍然必须决定使用什么方法来调用链接，以及要传递什么负载。所以，在我的观点中，在计算机对计算机的交互中，计算机扮演了最终用户的角色。再一次，这就是我们所说的编排服务。

我想我们可以用HATEOAS来编制或编舞。

API网关html" target="_blank">模式

应用程序客户端（如本机移动应用程序）可以向各个服务发出RESTful HTTP请求[...]从表面上看，这似乎很吸引人。但是，单个服务的API和客户机所需的数据之间很可能在粒度上存在很大的不匹配。例如，显示一个网页可能需要调用大量服务。例如，Amazon.com描述了某些页面如何需要调用100+个服务。即使是在高速的internet连接上发出如此多的请求，更不用说在低带宽、高延迟的移动网络上发出请求，也是非常低效的，并且会导致糟糕的用户体验。

一种更好的方法是让客户机通过Internet向称为API网关的前端服务器每页发出少量的请求，可能只有一个请求。

API网关位于应用程序的客户端和微服务之间。它提供了为客户机量身定制的API。API网关向移动客户端提供粗粒度的API，向使用高性能网络的桌面客户端提供细粒度的API。在本例中，桌面客户端发出多个请求以检索有关产品的信息，而移动客户端发出一个请求。

API网关通过向高性能LAN上的一些微服务发出请求来处理传入的请求。例如，Netflix描述了每个请求是如何向平均六个后端服务发起的。在本例中，来自桌面客户端的细粒度请求仅被代理到相应的服务，而来自移动客户端的每个粗粒度请求则通过聚合调用多个服务的结果来处理。

API网关不仅优化了客户端和应用程序之间的通信，而且还封装了微服务的细节。这使得微服务能够在不影响客户端的情况下发展。例如，可以合并两个微服务。另一个微服务可能被划分为两个或多个服务。只需要更新API网关来反映这些变化。客户端不受影响。

既然我们已经了解了API网关是如何在应用程序及其客户端之间进行中介的，现在我们来看看如何实现微服务之间的通信。