这本书构建微服务 https://rads.stackoverflow.com/amzn/click/com/1491950358详细描述了@RogerAlsing 在他的回答中提到的样式。
在第 43 页的 Orchestration vs Choreography 下，该书说：
当我们开始建模越来越复杂的逻辑时，我们必须处理
管理跨越整个业务流程的问题
个人服务的边界。借助微服务，我们将实现
这个限制比平常要早。 [...]当谈到实际上
实现这个流程，我们可以使用两种风格的架构
跟随。通过编排，我们依靠中枢大脑来指导和
推动整个过程，就像管弦乐队中的指挥一样。和
编排，我们告知系统的每个部分其工作并让它
弄清楚细节，就像舞者都找到自己的方式一样
在芭蕾舞中对周围的人做出反应。
然后本书继续解释这两种风格。编排风格更符合SOA理念编排/任务服务 http://serviceorientation.com/soamethodology/task_services，而编舞风格对应于哑管道和智能端点 http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipesMartin Fowler 的文章中提到过。
编曲风格
在这种风格下，上面的书提到：
让我们考虑一下编排解决方案是什么样的
这个流量。在这里，最简单的事情可能就是
我们的客户服务是我们的中枢。论创造，它会说话
忠诚度积分银行、电子邮件服务和邮政服务 [...]，
通过一系列请求/响应调用。这
然后，客户服务本身可以跟踪客户在其中的位置
过程。它可以检查客户的帐户是否已设置
上，或发送的电子邮件，或传递的帖子。我们要采取
流程图 [...] 并将其直接建模为代码。我们甚至可以使用
为我们实现这一点的工具，也许使用适当的
规则引擎。为此目的而存在的商业工具的形式如下：
业务流程建模软件。假设我们使用同步
请求/响应，我们甚至可以知道每个阶段是否有效[...]
这种编排方法的缺点是客户
服务可能会成为一个过多的中央管理机构。它可以
成为网络中间的枢纽和逻辑的中心点
开始生活。我已经看到这种方法的结果是少数
智能“上帝”服务告诉缺乏活力的基于 CRUD 的服务该做什么。
注意：我想当作者提到工具时，他指的是类似的东西BPM http://en.wikipedia.org/wiki/Business_process_modeling (e.g. Activity http://activiti.org/, 阿帕奇常微分方程 http://ode.apache.org, Camunda http://camunda.com）。事实上，工作流程模式网站 http://workflowpatterns.com有一组很棒的模式来进行这种编排，它还提供了不同供应商工具的评估详细信息，有助于以这种方式实现它。我不认为作者暗示需要使用这些工具之一来实现这种集成方式，但可以使用其他轻量级编排框架，例如弹簧集成 https://projects.spring.io/spring-integration/, 阿帕奇骆驼 http://camel.apache.org or Mule ESB https://www.mulesoft.com/platform/soa/mule-esb-open-source-esb
然而，其他书籍 http://www.oreilly.com/programming/free/software-architecture-patterns.csp我读过有关微服务的主题，一般来说，我在网上找到的大多数文章似乎都是不赞成这种做法 https://www.thoughtworks.com/insights/blog/scaling-microservices-event-stream编排，并建议使用下一个。
编舞风格
在编舞风格下，作者说：
通过精心设计的方法，我们可以只让客户
服务以异步方式发出一个事件，表示 Customer
创建的。电子邮件服务、邮政服务和忠诚度积分银行
然后只需订阅这些事件并做出相应的反应 [...]
这种方法明显更加解耦。如果有一些
创建客户所需的其他服务，它只是
需要订阅事件并在需要时完成其工作。这
缺点是我们看到的业务流程的明确视图
[工作流程]现在仅隐式反映在我们的系统中[...]
这意味着需要额外的工作来确保您可以监控
并跟踪正确的事情已经发生。例如，你会
知道忠诚度积分银行是否有错误，但由于某种原因没有错误
设置正确的帐户？我喜欢处理这个问题的一种方法
是建立一个明确匹配视图的监控系统
[工作流程]中的业务流程，然后跟踪每个流程的内容
这些服务作为独立的实体，让你看到奇怪的东西
异常映射到更明确的流程。 [流程图]
[...]不是驱动力，而只是一个镜头
我们可以看到系统的行为方式。一般来说，我发现
更倾向于精心设计的方法的系统更
松散耦合，并且更加灵活且易于更改。你做
需要做额外的工作来监控和跟踪整个系统的流程
然而，边界。我发现最精心策划的
实施极其脆弱，变更成本更高。
考虑到这一点，我强烈倾向于以精心设计的方式为目标
系统，其中每个服务都足够智能，可以理解其在
整个舞蹈。
注：直到今天我仍然不确定编舞是否只是舞蹈的另一个名称事件驱动架构 http://radar.oreilly.com/2015/02/variations-in-event-driven-architecture.html（EDA），但如果 EDA 只是一种方法，那么其他方法是什么？ （另请参阅“事件驱动”是什么意思？ https://martinfowler.com/articles/201701-event-driven.html and 事件驱动架构的含义 https://www.youtube.com/watch?v=STKCRSUsyP0）。另外，像 CQRS 和 EventSourcing 这样的东西似乎与这种架构风格产生了很大的共鸣，对吗？
现在，这之后就是乐趣了。 《微服务》一书并不假设微服务将通过 REST 来实现。事实上，在本书的下一部分中，他们将继续考虑基于 RPC 和 SOA 的解决方案，最后考虑 REST。这里重要的一点是微服务并不意味着 REST。
那么，HATEOAS 怎么样？ （超媒体作为应用程序状态的引擎）
现在，如果我们想遵循 RESTful 方法，我们就不能忽视 HATEOAS，否则 Roy Fielding 会非常高兴地在他的博客中说，我们的解决方案并不是真正的 REST。请参阅他的博客文章REST API 必须是超文本驱动的 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven:
我对调用任何基于 HTTP 的服务的人数感到沮丧
接口 REST API。需要做什么才能进行 REST
架构风格清楚地表明超文本是一种
约束？换句话说，如果应用程序状态引擎（并且
因此API）不是由超文本驱动的，那么它不能
RESTful 并且不能是 REST API。时期。有没有破损的说明书
有什么地方需要修复吗？
因此，正如您所看到的，Fielding 认为如果没有 HATEOAS，您就无法真正构建 RESTful 应用程序。对于 Fielding 来说，HATEOAS 是编排服务的最佳选择。我刚刚了解这一切，但对我来说，HATEOAS 并没有明确定义实际跟踪链接背后的驱动力是谁或什么。在可能是用户的 UI 中，但在计算机到计算机的交互中，我认为这需要由更高级别的服务来完成。
根据 HATEOAS 的说法，API 使用者真正需要知道的唯一链接是发起与服务器通信的链接（例如 POST /order）。从此时起，REST 将执行流程，因为在该端点的响应中，返回的资源将包含指向下一个可能状态的链接。然后，API 使用者决定遵循哪个链接并将应用程序移至下一个状态。
尽管听起来很酷，但客户端仍然需要知道链接是否必须进行 POST、PUT、GET、PATCH 等操作。并且客户端仍然需要决定要传递哪些有效负载。客户端仍然需要知道如果失败该怎么办（重试、补偿、取消等）。
我对这一切还很陌生，但对我来说，从 HATEOA 的角度来看，这个客户端或 API 消费者是一个高阶服务。如果我们从人类的角度思考，您可以想象网页上的最终用户决定要遵循哪些链接，但是网页的程序员仍然必须决定使用什么方法来调用链接，以及要传递的有效负载。因此，就我而言，在计算机到计算机的交互中，计算机扮演最终用户的角色。这又是我们所说的编排服务。
我想我们可以将 HATEOAS 与编排或编排一起使用。
API网关模式
克里斯·理查森 (Chris Richardson) 提出了另一种有趣的模式，他也提出了他所谓的“API网关模式 http://www.infoq.com/articles/microservices-intro.
在整体架构中，应用程序的客户端（例如 Web
浏览器和本机应用程序，通过负载发出 HTTP 请求
平衡器到应用程序的 N 个相同实例之一。但在一个
微服务架构，单体已被替换
服务的集合。因此，我们需要回答一个关键问题
客户与什么互动？
应用程序客户端（例如本机移动应用程序）可以使
对各个服务的 RESTful HTTP 请求 [...] 表面上
这可能看起来很有吸引力。然而，很可能有一个
各个 API 之间的粒度存在显着不匹配
客户所需的服务和数据。例如，显示一个
网页可能需要调用大量服务。
以亚马逊网站为例，描述 http://highscalability.com/amazon-architecture多少
页面需要调用 100 多个服务。提出那么多要求，甚至
通过高速互联网连接，更不用说较低的带宽，
较高延迟的移动网络，效率会非常低，并导致
用户体验不佳。
更好的方法是让客户制作少量的
每页的请求，也许只有一个，通过互联网发送到
称为 API 网关的前端服务器。
API网关位于应用程序的客户端和
微服务。它提供为客户量身定制的 API。这
API网关为移动客户端提供粗粒度的API
为使用高性能的桌面客户端提供更细粒度的 API
网络。在此示例中，桌面客户端发出多个请求
检索有关产品的信息，而移动客户端
发出单个请求。
API网关通过向某些设备发出请求来处理传入请求
高性能 LAN 上的微服务数量。 Netflix，为
例子，描述 http://techblog.netflix.com/2013/01/optimizing-netflix-api.html每个请求如何平均分发到六个后端服务。在这个
例如，来自桌面客户端的细粒度请求很简单
代理到相应的服务，而每个粗粒度
来自移动客户端的请求通过聚合结果来处理
调用多个服务。
API网关不仅优化了客户端之间的通信
和应用程序，但它也封装了细节
微服务。这使得微服务能够在无需
影响客户。例如，两个微服务可能是
合并了。另一个微服务可能被划分为两个或多个
服务。只需更新 API 网关即可反映这些
变化。客户不受影响。
现在我们已经了解了 API 网关如何在
应用程序及其客户端，现在让我们看看如何实现
微服务之间的通信。
这听起来与上面提到的编排风格非常相似，只是意图略有不同，在这种情况下，它似乎都是关于性能和交互的简化。
