大规模编排还是编排的面向服务的架构？
Orchestrated vs Choreographed Service-Oriented Architecture in large scale?
我是一家大型金融公司的架构师，我们正着手在我们不同的国家/地区实施新的面向业务的信息系统。
从一开始，核心思想就是尽可能遵循面向微服务的原则（并确保工程师阅读了 Sam Newman 的《构建微服务》一书）。
至此，我来到了十字路口。我们的服务主要是 JSON REST 服务，使用 Swagger 实现自动化文档，但为了在我们的业务流程中使用这些服务并确保不将业务逻辑写入这些服务域之外的服务，我们一直在使用Camunda 作为编排工具。 Camunda 很好 （虽然有些人认为 Corezoid 是替代品），但在一套优雅的服务方面有些笨拙。
现在服务编排是大多数工程师都非常熟悉的概念。但由于仍然有一个驱动一切的中央引擎，我对此并不完全满意。日后更换非常昂贵 （尽管更换仍然比整体更便宜）。而且即使这个中央引擎拆分成多个引擎（今天实际就是这样），也不见得会好很多。
近年来，微服务向编排 （接近事件驱动） 架构发展。正是在这一点上，我正在寻求面临类似十字路口决策点的工程师和建筑师的建议。
我非常喜欢解耦架构的想法，尽管我对消除单体应用和拥有优雅的独立服务感觉很好，但我仍然发现在当前协调的解决方案中，业务流程作为一个整体存在很多依赖性，而这些依赖性实际上不应该存在.
而且我们并不是在逃避事件。我们实际上也在我们的架构上实现了事件，以便将许多流程与核心原则分离，如果您不需要同步响应并且只需要通知发生的事情以启动另一个流程，那么事件可能是被另一个开始执行的进程捕获。编排更容易解释和可视化，更容易被更具技术头脑的业务用户调整和修改。而且我认为从业务角度进行测试和验证更容易。像这样的精心安排的架构也 （通常） 期望良好的服务发现和高质量的自动化文档以及非功能性需求，这些都是我非常看重的东西。
所有这些问题对我来说都是编排方法的问题，因为我没有运行大规模的第一手经验 - 只是一些本地测试原型。
但我想你明白我的意思了。我正在尝试考虑替代方案，而不必后悔最终以其他方式驾驶公司。
或许您可以分享您自己遇到类似情况的经验或分享一两个有趣的 link？还是我正在寻找一个还不存在的灵丹妙药？
我想我明白你的意思，最近将系统重新设计为 "microservices" 架构。我喜欢（并使用）这些人的方法：http://scs-architecture.org/
要点是，您要尽量避免相互依赖 "services"，这基本上会使编排过时。困难的部分是将您的问题域分解成块，这些块对于任何已执行的业务案例都不需要彼此。他们可能需要不同类型的数据，这些数据可能是也可能不是 "shared"，就像存在于多个系统中一样，但对于任何给定的业务案例，他们不需要在它们之间进行同步调用。
这与 Netflix 正在做的事情有很大的不同。那些 guys/gals 正在通过不同的服务层进行链式调用，每个服务都将其逻辑添加到 "process"。这个模型可能适用于某些情况，并且可能适用于 Netflix 的情况。但对你来说可能没有必要。
理想的自包含系统将完全独立于其他自包含系统，将涵盖一个或多个高度内聚的业务功能（从UI 到持久性！），并且不会同步调用任何其他系统。理想的系统会让客户端 "orchestrate"，仅通过其 Web (HTML) 界面提供链接。
像亚马逊一样思考。 "Landing Page" 与 "Search" 是不同的应用程序，后者仍然不同于 "Checkout"。它们完全不同，有时甚至看起来有点不同！通过 HTML 中的链接和表单集成，未明确编排。
这可能就是您要找的。
一些警告：某些人的第一直觉是拥有 "Customer" 微服务或 "Product Repository" 微服务，以及类似的服务。这不会导致自包含系统，因为您将需要同步调用这些东西，使它们本质上成为 "central" 组件。关键是要拆分业务领域，所以像 Eric Evans 那样有界上下文。
服务需要交互 - 不交互的服务不是同一系统的一部分。搜索需要访问目录，购物车不从页面获取价格信息，账户需要购买历史，推荐者需要购买历史，购物车需要验证当前可用的优惠券，库存需要知道一些东西已购买等
设置服务边界以尽量减少所需的交互。将服务切割成更小的组件是有意义的，但如果它们共享一个数据库（内部结构），它们就是 different aspects of the service.
当服务交互时，它会产生一定程度的耦合 - 至少，这种耦合是某种 API（JSON 或其他）服务必须 "maintain"服务可以与之交互。
另一种耦合类型是时间耦合——这是你在请求-回复情况下得到的（并且你可以在事件驱动系统中消除）但是，编排与编排与这些差异无关（尽管编排主要是相关的） request/reply) - 它是关于中央控制和治理 vs.flexibility 和意外发现。
编排存在风险，例如将业务逻辑从服务迁移到编排中，而编排则存在混乱的风险。顺便说一下，直接 request/reply 集成是两全其美的缺点，但当系统足够小时，它会以简单性取胜。
在两者之间做出选择是一种平衡行为（就像大多数架构决策一样），例如，Netflix 在编排方面建立了很长时间，但后来发现他们需要一些控制权 introduced an orchestration engine。没有什么是灵丹妙药:)
就个人而言，我更喜欢编排，因为它减少了耦合和灵活性，并且喜欢 open Zipkin 这样的工具来为混乱带来一些秩序。
您可以在 slides 10-22 of a presentation I did about microservices
中查看基于编排架构的部分示例
我是一家大型金融公司的架构师，我们正着手在我们不同的国家/地区实施新的面向业务的信息系统。
从一开始，核心思想就是尽可能遵循面向微服务的原则（并确保工程师阅读了 Sam Newman 的《构建微服务》一书）。
至此，我来到了十字路口。我们的服务主要是 JSON REST 服务，使用 Swagger 实现自动化文档，但为了在我们的业务流程中使用这些服务并确保不将业务逻辑写入这些服务域之外的服务，我们一直在使用Camunda 作为编排工具。 Camunda 很好 （虽然有些人认为 Corezoid 是替代品），但在一套优雅的服务方面有些笨拙。
现在服务编排是大多数工程师都非常熟悉的概念。但由于仍然有一个驱动一切的中央引擎，我对此并不完全满意。日后更换非常昂贵 （尽管更换仍然比整体更便宜）。而且即使这个中央引擎拆分成多个引擎（今天实际就是这样），也不见得会好很多。
近年来，微服务向编排 （接近事件驱动） 架构发展。正是在这一点上，我正在寻求面临类似十字路口决策点的工程师和建筑师的建议。
我非常喜欢解耦架构的想法，尽管我对消除单体应用和拥有优雅的独立服务感觉很好，但我仍然发现在当前协调的解决方案中，业务流程作为一个整体存在很多依赖性，而这些依赖性实际上不应该存在.
而且我们并不是在逃避事件。我们实际上也在我们的架构上实现了事件，以便将许多流程与核心原则分离，如果您不需要同步响应并且只需要通知发生的事情以启动另一个流程，那么事件可能是被另一个开始执行的进程捕获。编排更容易解释和可视化，更容易被更具技术头脑的业务用户调整和修改。而且我认为从业务角度进行测试和验证更容易。像这样的精心安排的架构也 （通常） 期望良好的服务发现和高质量的自动化文档以及非功能性需求，这些都是我非常看重的东西。
所有这些问题对我来说都是编排方法的问题，因为我没有运行大规模的第一手经验 - 只是一些本地测试原型。
但我想你明白我的意思了。我正在尝试考虑替代方案，而不必后悔最终以其他方式驾驶公司。
或许您可以分享您自己遇到类似情况的经验或分享一两个有趣的 link？还是我正在寻找一个还不存在的灵丹妙药？
我想我明白你的意思，最近将系统重新设计为 "microservices" 架构。我喜欢（并使用）这些人的方法：http://scs-architecture.org/
要点是，您要尽量避免相互依赖 "services"，这基本上会使编排过时。困难的部分是将您的问题域分解成块，这些块对于任何已执行的业务案例都不需要彼此。他们可能需要不同类型的数据，这些数据可能是也可能不是 "shared"，就像存在于多个系统中一样，但对于任何给定的业务案例，他们不需要在它们之间进行同步调用。
这与 Netflix 正在做的事情有很大的不同。那些 guys/gals 正在通过不同的服务层进行链式调用，每个服务都将其逻辑添加到 "process"。这个模型可能适用于某些情况，并且可能适用于 Netflix 的情况。但对你来说可能没有必要。
理想的自包含系统将完全独立于其他自包含系统，将涵盖一个或多个高度内聚的业务功能（从UI 到持久性！），并且不会同步调用任何其他系统。理想的系统会让客户端 "orchestrate"，仅通过其 Web (HTML) 界面提供链接。
像亚马逊一样思考。 "Landing Page" 与 "Search" 是不同的应用程序，后者仍然不同于 "Checkout"。它们完全不同，有时甚至看起来有点不同！通过 HTML 中的链接和表单集成，未明确编排。
这可能就是您要找的。
一些警告：某些人的第一直觉是拥有 "Customer" 微服务或 "Product Repository" 微服务，以及类似的服务。这不会导致自包含系统，因为您将需要同步调用这些东西，使它们本质上成为 "central" 组件。关键是要拆分业务领域，所以像 Eric Evans 那样有界上下文。
服务需要交互 - 不交互的服务不是同一系统的一部分。搜索需要访问目录，购物车不从页面获取价格信息，账户需要购买历史，推荐者需要购买历史，购物车需要验证当前可用的优惠券，库存需要知道一些东西已购买等
设置服务边界以尽量减少所需的交互。将服务切割成更小的组件是有意义的，但如果它们共享一个数据库（内部结构），它们就是 different aspects of the service.
当服务交互时，它会产生一定程度的耦合 - 至少，这种耦合是某种 API（JSON 或其他）服务必须 "maintain"服务可以与之交互。
另一种耦合类型是时间耦合——这是你在请求-回复情况下得到的（并且你可以在事件驱动系统中消除）但是，编排与编排与这些差异无关（尽管编排主要是相关的） request/reply) - 它是关于中央控制和治理 vs.flexibility 和意外发现。
编排存在风险，例如将业务逻辑从服务迁移到编排中，而编排则存在混乱的风险。顺便说一下，直接 request/reply 集成是两全其美的缺点，但当系统足够小时，它会以简单性取胜。
在两者之间做出选择是一种平衡行为（就像大多数架构决策一样），例如，Netflix 在编排方面建立了很长时间，但后来发现他们需要一些控制权 introduced an orchestration engine。没有什么是灵丹妙药:)
就个人而言，我更喜欢编排，因为它减少了耦合和灵活性，并且喜欢 open Zipkin 这样的工具来为混乱带来一些秩序。
您可以在 slides 10-22 of a presentation I did about microservices
中查看基于编排架构的部分示例