web-services - 大规模编排与编排的面向服务的架构？

Question

我是一家大型金融公司的架构师，我们正在开始在不同国家实现新的面向业务的信息系统。

从一开始，核心理念就是尽可能地遵循面向微服务的原则(并确保工程师阅读了 Sam Newman 的《构建微服务》一书)。

至此，我已经走到了十字路口。我们的服务主要是使用 Swagger 进行自动化文档的 JSON REST 服务，但为了在我们的业务流程中使用这些服务并确保不会将业务逻辑写入这些服务域之外的服务中，我们一直使用 Camunda 作为编排工具。 Camunda 很好(尽管有些人认为 Corezoid 作为替代方案)，但在一套优雅的服务方面有些笨拙。

现在服务编排是大多数工程师非常熟悉的概念。但我对它并不完全满意，因为它仍然有一个驱动一切的中央引擎。以后更换起来非常昂贵(尽管更换起来仍然比整体便宜)。而且即使这个中央引擎被拆分成多个引擎(今天的实际情况就是这样)，它也不一定会让它变得更好。

近年来，微服务向编排(接近事件驱动)架构发展。正是在这一点上，我正在向面临类似十字路口决策点的工程师和建筑师寻求建议。

我非常喜欢解耦架构的想法，尽管我对杀死单体和拥有优雅的独立服务感觉很好，但我仍然在当前的协调解决方案中检测到整个业务流程中的许多依赖关系，而这些依赖关系实际上不应该存在。

这不像我们在回避事件。我们实际上也在我们的架构上实现了事件，以便将许多进程与核心原则解耦，即如果您不需要同步响应而只需要通知发生的事情以启动另一个进程，则会提出一个事件，这可能是被另一个开始执行的进程捕获。编排更容易解释和可视化，更容易被更多具有技术头脑的业务用户调整和修改。而且我认为从业务角度测试和验证更容易。像这样的编排架构也(通常)期望良好的服务发现和高质量的自动化文档以及非功能性需求，这些都是我非常看重的东西。

所有这些在编排方法中对我来说都是一个问题，因为我没有大规模运行它的第一手经验——只有一些本地测试原型(prototype)。

但我想你明白我来自哪里。我正在尝试考虑替代方案，而不必后悔最终将公司推向另一条路。

也许您可以分享您在类似情况下的经验或分享一两个有趣的链接？还是我在寻找尚不存在的 Elixir ？

Answer 1

服务需要交互——不交互的服务不是同一个系统的一部分。搜索需要访问目录，购物车没有从页面获取价格信息，账户需要购买历史，推荐人需要购买历史，购物车需要验证当前可用的优惠券，库存需要知道一些事情被购买等

设置服务边界以最小化所需的交互。将服务切割成更小的组件是有意义的，但如果它们共享一个数据库(内部结构)，它们是 different aspects of the service .

当服务交互时，它会产生一定程度的耦合——至少，这种耦合是服务必须“维护”的一些 API(JSON 或其他)，以便其他服务可以与之交互。

另一种耦合类型是时间耦合 - 这是您在请求 - 回复情况下得到的(并且您可以在事件驱动的系统中消除)但是，编排与编排与这些差异无关(即使编排主要与请求/回复相关联) - 这是关于中央控制和治理与灵 active 和偶然性的对比。

编排存在风险，例如将业务逻辑从服务迁移到编排中，而编排则存在困惑的风险。顺便说一句，直接请求/回复集成是两全其美的，但当系统足够小时，它会在简单性上获胜。

在两者之间进行选择是一种平衡行为(就像大多数架构决策一样)，例如，Netflix 在编排上建立了很长时间，但后来发现他们需要一些控制权，introduced an orchestration engine .没有什么是 Elixir :)

就个人而言，我更喜欢编排，因为减少了耦合性和灵 active ，并且喜欢 open Zipkin 之类的工具。给困惑带来一些秩序。

您可以在 slides 10-22 of a presentation I did about microservices 中看到基于编排架构的部分示例。