本文介绍了编排微服务的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 29岁程序员，3月因学历无情被辞！ 编排微服务的标准模式是什么？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:然后本书继续解释这两种风格。业务流程样式更多地符合编排/任务服务的SOA思想，而编排风格对应于哑管和智能终端。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:注意：我认为当作者提到工具时，他指的是 BPM （例如活动， Apache ODE ， Camunda ）。事实上，工作流模式网站有一套很棒的模式来进行这种编排，它还提供了评估细节有助于以这种方式实现它的不同供应商工具。我不认为作者暗示需要使用这些工具之一来实现这种集成方式，但是可以使用其他轻量级编排框架，例如， Spring Integration ， Apache Camel 或 Mule ESBNote: 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:注意：这听起来很像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:所以，正如你所看到的，菲尔丁认为没有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.应用程序客户端（例如本机移动应用程序）可以赚取对各个服务的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: 微服务简介 构建Micro服务：使用API网关 构建微服务：微服务架构中的IPC 微服务架构中的服务发现 微服务的事件驱动数据管理 选择微服务部署策略 将Monolith重构为微服务Introduction to MicroservicesBuilding Microservices: Using an API GatewayBuilding Microservices: IPC in a Microservices ArchitectureService Discovery in a Microservices ArchitectureEvent-Driven Data Management for MicroservicesChoosing a Microservices Deployment StrategyRefactoring a Monolith into Microservices 这篇关于编排微服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
