编排微服务 [英] Orchestrating microservices

查看：233 发布时间：2018/7/9 14:23:15 http orchestration hypermedia microservices

本文介绍了编排微服务的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

What is the standard pattern of orchestrating microservices?

如果微服务只知道自己的域，但是有一个数据流需要多个服务交互在某种程度上，它的方法是什么？

If a microservice only knows about its own domain, but there is a flow of data that requires that multiple services interact in some manner, what's the way to go about it?

假设我们有类似的东西：

Let's say we have something like this:

发票

货件

并且为了参数的缘故，假设订单一旦发货，就应该创建发票。

And for the sake of the argument, let's say that once an an order has been shipped, the invoice should be created.

在某个地方，有人按下GUI中的按钮，我已经完成了，让我们这样做！
在一个经典的整体服务架构中，我会说有一个ESB处理这个，或者发货服务知道发票服务，只需要调用它。

Somewhere, someone presses a button in a GUI, "I'm done, let's do this!" In a classic monolith service architecture, I'd say that there is either an ESB handling this, or the Shipment service has knowledge of the invoice service and just calls that.

但是，在这个勇敢的微服务新世界中人们处理这个问题的方式是什么？

But what is the way people deal with this in this brave new world of microservices?

我确实认为这可以被认为是基于意见的。但是它有一个具体的方面，因为微服务不应该做上述事情。
所以必须有一个定义应该做什么而不是，这不是基于意见的。

I do get that this could be considered highly opinion-based. but there is a concrete side to it, as microservices are not supposed to do the above. So there has to be a "what should it by definition do instead", which is not opinion-based.

拍摄。

推荐答案

本书构建微服务在他的回答中详细描述了@RogerAlsing提到的风格。

The Book Building Microservices describes in detail the styles mentioned by @RogerAlsing in his answer.

在Orchestration vs Choreography下的第43页，该书说：

On page 43 under Orchestration vs Choreography the book says:

当我们开始建模越来越复杂的逻辑时，我们必须处理
管理跨越
边界的业务流程的问题个人服务。使用微服务，我们将比平时更快地达到
这个限制。 [...]实际上，实现这个流程实际上是
，有两种架构我们可以跟随
。通过编排，我们依靠中央大脑来指导和
驱动这个过程，就像管弦乐队中的指挥一样。通过
编舞，我们告知系统的每个部分它的工作，并让它b $ b b计算细节，就像舞者都找到他们的方式和
对周围的人做出反应芭蕾舞。

As we start to model more and more complex logic, we have to deal with the problem of managing business processes that stretch across the boundary of individual services. And with microservices, we’ll hit this limit sooner than usual. [...] When it comes to actually implementing this flow, there are two styles of architecture we could follow. With orchestration, we rely on a central brain to guide and drive the process, much like the conductor in an orchestra. With choreography, we inform each part of the system of its job, and let it work out the details, like dancers all find‐ ing their way and reacting to others around them in a ballet.

然后本书继续解释这两种风格。业务流程样式更多地符合编排/任务服务的SOA思想，而编排风格对应于< Martin Fowler的文章中提到了一个href =http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes =noreferrer>哑管和智能终端。

The book then proceeds to explain the two styles. The orchestration style corresponds more to the SOA idea of orchestration/task services, whereas the choreography style corresponds to the dumb pipes and smart endpoints mentioned in Martin Fowler's article.

编排风格

在此风格下，上述图书提及：

Under this style, the book above mentions:

让我们考虑一下这个流程的
的编排解决方案。在这里，最简单的事情可能就是让
我们的客户服务充当中心大脑。在创建时，它通过一系列请求/响应调用向忠诚度积分银行，电子邮件服务和邮政服务[...]，
进行
。然后，
客户服务本身可以跟踪客户在此
流程中的位置。它可以检查客户的帐户是否已设置为
up，或已发送的电子邮件，或已发送的帖子。我们可以使用
流程图[...]并将其直接建模到代码中。我们甚至可以使用
工具为我们实现这一点，也许使用适当的
规则引擎。为此目的，商业工具以
的业务流程建模软件的形式存在。假设我们使用同步
请求/响应，我们甚至可以知道每个阶段是否有效[...]
这种编排方法的缺点是客户
服务可能变得过多中央管理机构。它可以
成为网络中心的中心，也是逻辑
开始生存的中心点。我已经看到这种方法导致少量的
智能上帝服务告诉贫血的基于CRUD的服务该怎么做。

Let’s think about what an orchestration solution would look like for this flow. Here, probably the simplest thing to do would be to have our customer service act as the central brain. On creation, it talks to the loyalty points bank, email service, and postal service [...], through a series of request/response calls. The customer service itself can then track where a customer is in this process. It can check to see if the customer’s account has been set up, or the email sent, or the post delivered. We get to take the flowchart [...] and model it directly into code. We could even use tooling that implements this for us, perhaps using an appropriate rules engine. Commercial tools exist for this very purpose in the form of business process modeling software. Assuming we use synchronous request/response, we could even know if each stage has worked [...] The downside to this orchestration approach is that the customer service can become too much of a central governing authority. It can become the hub in the middle of a web, and a central point where logic starts to live. I have seen this approach result in a small number of smart "god" services telling anemic CRUD-based services what to do.

注意：我认为当作者提到工具时，他指的是 BPM （例如活动， Apache ODE ， Camunda ）。事实上，工作流模式网站有一套很棒的模式来进行这种编排，它还提供了评估细节有助于以这种方式实现它的不同供应商工具。我不认为作者暗示需要使用这些工具之一来实现这种集成方式，但是可以使用其他轻量级编排框架，例如， Spring Integration ， Apache Camel 或 Mule ESB

Note: I suppose that when the author mentions tooling he's referring to something like BPM (e.g. Activity, Apache ODE, Camunda). As a matter of fact the Workflow Patterns Website has an awesome set of patterns to do this kind of orchestration and it also offers evaluation details of different vendor tools that help to implement it this way. I don't think the author implies one is required to use one of these tools to implement this style of integration though, other lightweight orchestration frameworks could be used e.g. Spring Integration, Apache Camel or Mule ESB

然而，其他书籍我读过有关微服务的主题，一般来说，我在网上找到的大多数文章似乎都是不赞成这种方法，而是建议使用下一个。

However, other books I've read on the topic of Microservices and in general the majority of articles I've found in the web seem to disfavor this approach of orchestration and instead suggest using the next one.

编舞风格

在编舞风格下，作者说：

Under choreography style the author says:

通过精心设计的方法，我们可以让客户
服务以异步方式发出事件，s aying Customer
created。电子邮件服务，邮政服务和忠诚度积分银行
然后只是订阅这些事件并做出相应的反应[...]
这种方法明显更加分离。如果需要一些
其他服务来创建客户，那么只需
需要订阅事件并在需要时完成其工作。
的缺点是我们在
[工作流程]中看到的业务流程的显式视图现在仅隐含地反映在我们的系统中[...]
这意味着需要额外的工作来确保您可以监控
并跟踪正确的事情。例如，您是否会知道忠诚度积分银行是否有错误，并且由于某种原因没有
设置正确的帐户？我喜欢处理这个
的一种方法是构建一个监视系统，该系统在[工作流程]中明确地匹配
业务流程的视图，但随后跟踪服务中每个
的内容作为独立实体，让您看到映射到更明确的流程流的奇数
异常。 [流程图]
[...]不是驱动力，而只是通过
的一个镜头，我们可以看到系统的行为方式。一般来说，我发现
表示更倾向于编排方法的系统更多是
松散耦合，并且更灵活，更易于改变。但是，
需要做额外的工作来监视和跟踪系统
边界的进程。我发现大多数精心策划的
实现都非常脆弱，变化成本更高。
考虑到这一点，我更倾向于选择一个精心设计的
系统，每个服务都足够聪明，可以了解整个舞蹈的价值
。

With a choreographed approach, we could instead just have the customer service emit an event in an asynchronous manner, saying Customer created. The email service, postal service, and loyalty points bank then just subscribe to these events and react accordingly [...] This approach is significantly more decoupled. If some other service needed to reach to the creation of a customer, it just needs to subscribe to the events and do its job when needed. The downside is that the explicit view of the business process we see in [the workflow] is now only implicitly reflected in our system [...] This means additional work is needed to ensure that you can monitor and track that the right things have happened. For example, would you know if the loyalty points bank had a bug and for some reason didn’t set up the correct account? One approach I like for dealing with this is to build a monitoring system that explicitly matches the view of the business process in [the workflow], but then tracks what each of the services does as independent entities, letting you see odd exceptions mapped onto the more explicit process flow. The [flowchart] [...] isn’t the driving force, but just one lens through which we can see how the system is behaving. In general, I have found that systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change. You do need to do extra work to monitor and track the processes across system boundaries, however. I have found most heavily orchestrated implementations to be extremely brittle, with a higher cost of change. With that in mind, I strongly prefer aiming for a choreographed system, where each service is smart enough to under‐ stand its role in the whole dance.

注意：这听起来很像CQRS和EvenSourcing。直到今天，我仍然不确定编排是否只是事件驱动架构（EDA），但如果EDA只是一种方法，那么其他方式是什么？（另请参阅事件驱动是什么意思？和事件驱动架构的含义）

Note: This sounds a lot like CQRS and EvenSourcing. To this day I'm still not sure if choreography is just another name for event-driven architecture (EDA), but if EDA is just one way to do it, what are the other ways? (Also see What do you mean by "Event-Driven"? and The Meanings of Event-Driven Architecture)

现在，这之后就变得有趣了。微服务书并不假设微服务将通过REST实现。事实上，在本书的下一部分中，他们将继续考虑基于RPC和SOA的解决方案，最后考虑REST。重要的一点是，微服务并不意味着REST。

Now, after this comes the fun. The Microservices book does not assume microservices are going to be implemented with REST. As a matter of fact in the next section in the book they proceed to consider RPC and SOA-based solutions and finally REST. Important point here is that Microservices does not imply REST.

那么，HATEOAS怎么样？

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

Now, if we want to follow the RESTful approach we cannot ignore HATEOAS or Roy Fielding will be very much pleased to say in his blog that our solution is not truly REST. See his blog post on REST API Must be Hypertext Driven:

我对使用REST API调用任何基于HTTP的
接口的人数感到沮丧。为了使超文本成为
约束这一概念，需要做些什么来使REST
架构风格明确？换句话说，如果应用程序状态的引擎（以及
因此API）不是由超文本驱动的，那么它不能是
RESTful并且不能是REST API。期。是否有一些需要修复的手册
？

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?

所以，正如你所看到的，菲尔丁认为没有HATEOAS你并不是真正构建RESTful应用程序。对于守备HATEOAS是协调服务的方法。我只是在学习这一切，但对我来说，HATEOAS没有明确定义实际跟踪链接背后的驱动力是谁或是什么。在可能是用户的UI中，但在计算机到计算机的交互中，我认为需要通过更高级别的服务来完成。

So, as you can see, Fielding thinks that without HATEOAS you are not truly building RESTful applications. For fielding HATEOAS is the way to go when it comes to orchestrate services. I am just learning all this, but to me HATEOAS does not clearly define who or what is the driving force behind actually following the links. In a UI that could be the user, but in computer-to-computer interactions, I suppose that needs to be done by a higher level service.

根据HATEOAS， API消费者真正需要知道的唯一链接是启动与服务器通信的链接（例如POST /订单）。从这一点开始，REST将进行流程，因为在此端点的响应中，返回的资源将包含指向下一个可能状态的链接。 API使用者然后决定要关注的链接并将应用程序移动到下一个状态。

According to HATEOAS, the only link the API consumer truly needs to know is the one that initiates the communication with the server (e.g. POST /order). From this point on, REST is going to conduct the flow, because in the response of this endpoint, the resource returned will contain the links to next possible states. The API consumer then decides what link to follow and move the application to the next state.

尽管听起来有多酷，但客户端仍然需要知道链接是否必须是POST，PUTed，GETed，PATCHed等。客户端仍然需要决定要传递的有效负载。客户仍然需要知道如果失败该怎么办（重试，补偿，取消等）。

Despite how cool that sounds, the client still needs to know if the link must be POSTed, PUTed, GETed, PATCHed, etc. And the client still needs to decide what payload to pass. The client still needs to be aware of what to do if that fails (retry, compensate, cancel, etc.).

我对这一切都很新，但对于我，从HATEOAs的角度来看，这个客户端或API使用者是一个高阶服务。如果我们从人的角度来思考它，你可以想象一个网页中的最终用户，决定要遵循的链接，但是网页的程序员还必须决定使用什么方法来调用链接，以及有效载荷通过。所以，就我而言，在计算机到计算机的交互中，计算机扮演最终用户的角色。再一次，我们称之为业务流程服务。

I am fairly new to all this, but for me, from HATEOAs perspective, this client, or API consumer is a high order service. If we think it from the perspective of a human, you can imagine an end user in a web page, deciding what links to follow, but still the programmer of the web page had to decide what method to use to invoke the links, and what payload to pass. So, to my point, in a computer-to-computer interaction, the computer takes the role of the end user. Once more this is what we call an orchestrations service.

我想我们可以将HATEOAS用于编排或编排。

I suppose we can use HATEOAS with either orchestration or choreography.

API网关模式

另一个有趣的模式是Chris Richardson建议的他还提出了他所谓的 API网关模式。

Another interesting pattern is suggested by Chris Richardson who also proposed what he called an API Gateway Pattern.

在单一体系结构中，应用程序的客户端（例如web
浏览器和本机应用程序）通过加载
平衡器向N之一发出HTTP请求相同的申请实例。但是在
微服务架构中，monolith已被
服务集合所取代。因此，我们需要回答
的关键问题是客户端与之交互的内容是什么？

In a monolithic architecture, clients of the application, such as web browsers and native applications, make HTTP requests via a load balancer to one of N identical instances of the application. But in a microservice architecture, the monolith has been replaced by a collection of services. Consequently, a key question we need to answer is what do the clients interact with?

应用程序客户端（例如本机移动应用程序）可以赚取
对各个服务的RESTful HTTP请求[...]表面
这看起来很有吸引力。但是，单个
服务的API与客户端所需数据之间的粒度可能存在巨大的b $ b差异。例如，显示一个
网页可能需要调用大量服务。
Amazon.com，例如，
描述一些
页面需要拨打100多项服务。通过高速互联网连接提出这么多请求，甚至是
，更不用说低带宽，低b $ b更高延迟的移动网络，效率非常低，导致
a糟糕的用户体验。

An application client, such as a native mobile application, could make RESTful HTTP requests to the individual services [...] On the surface this might seem attractive. However, there is likely to be a significant mismatch in granularity between the APIs of the individual services and data required by the clients. For example, displaying one web page could potentially require calls to large numbers of services. Amazon.com, for example, describes how some pages require calls to 100+ services. Making that many requests, even over a high-speed internet connection, let alone a lower-bandwidth, higher-latency mobile network, would be very inefficient and result in a poor user experience.

更好的方法是让客户通过互联网向每个页面发送少量
请求（可能只有一个）到
前端服务器称为API网关。

A much better approach is for clients to make a small number of requests per-page, perhaps as few as one, over the Internet to a front-end server known as an API gateway.

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

The API gateway sits between the application’s clients and the microservices. It provides APIs that are tailored to the client. The API gateway provides a coarse-grained API to mobile clients and a finer-grained API to desktop clients that use a high-performance network. In this example, the desktop clients makes multiple requests to retrieve information about a product, where as a mobile client makes a single request.

API网关通过在高性能LAN上向一些
数量的微服务发出请求来处理传入请求。 Netflix，价格为
，
描述
每个请求如何平均支持六个后端服务。在这个
示例中，来自桌面客户端的细粒度请求只是代表相应服务的
，而来自移动客户端的每个粗粒度
请求都是通过聚合$的结果来处理的。 b $ b调用多个服务。

The API gateway handles incoming requests by making requests to some number of microservices over the high-performance LAN. Netflix, for example, describes how each request fans out to on average six backend services. In this example, fine-grained requests from a desktop client are simply proxied to the corresponding service, whereas each coarse-grained request from a mobile client is handled by aggregating the results of calling multiple services.

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

Not only does the API gateway optimize communication between clients and the application, but it also encapsulates the details of the microservices. This enables the microservices to evolve without impacting the clients. For examples, two microservices might be merged. Another microservice might be partitioned into two or more services. Only the API gateway needs to be updated to reflect these changes. The clients are unaffected.

现在我们已经了解了API网关如何在
应用程序与其客户端之间进行调解，现在让我们看一下如何实现$微服务之间的b $ b通信。

Now that we have looked at how the API gateway mediates between the application and its clients, let’s now look at how to implement communication between microservices.

这听起来非常类似于上面提到的业务流程风格，只是意图略有不同，情况似乎与性能和简化交互有关。

This sounds pretty similar to the orchestration style mentioned above, just with a slightly different intent, in this case it seems to be all about performance and simplification of interactions.

进一步阅读

最近在 NGINX博客上发表了大量文章，我建议深入研究所有这些概念：

There is a great series of articles recently published in the NGINX Blog that I recommend to delve deeper into all these concepts: