大规模编排与精心编排的面向服务的架构？

Question

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

从一开始，核心思想就是尽可能遵循面向微服务的原则（并确保工程师已阅读Sam Newman撰写的“构建微服务”一书）。

到现在为止，我已经到了十字路口。我们的服务主要是使用Swagger进行自动化文档的JSON REST服务，但是为了在我们的业务流程中使用这些服务并确保不将业务逻辑写入这些服务域之外的服务，我们一直使用Camunda作为编排工具。而且Camunda很好（虽然有些人认为Corezoid是替代品），但在一套优雅的服务中却有些笨拙。

现在，服务编排是大多数工程师非常熟悉的概念。但由于仍然拥有驱动一切的中央引擎，因此我并不完全满意。在以后的路上更换它是非常昂贵的（虽然比单块更换更便宜）。即使这个中央引擎被分成多个引擎（实际上就是今天的情况），它也不一定会好得多。

近年来，微服务朝着精心设计的（接近事件驱动的）架构发展。正是在这一点上，我正在寻找那些面临类似十字路口决策点的工程师和建筑师的建议。

我非常喜欢分离式架构的想法，尽管在杀死巨型单元和拥有优雅的独立服务方面感觉良好，但我仍然在当前的协调解决方案中检测到业务流程中的大量依赖关系，而这些解决方案实际上并不存在。< / p>

这并不像我们在避免事件。我们实际上已经在我们的体系结构上实现了事件，以便将许多进程与核心原则分离，如果您不需要同步响应并且只需要通知发生的事情以启动另一个进程，则可能会发生一个事件。被另一个开始执行的进程捕获。并且编排更容易解释和可视化，更容易由更具技术头脑的业务用户进行调整和修改。我认为从业务角度来测试和验证更容易。像这样的协调体系结构（通常）期望良好的服务发现和高质量的自动化文档和非功能性需求，这些都是我非常重视的。

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

但我想你知道我来自哪里。我试图考虑替代方案，而不必后悔以其他方式驾驶公司。

也许您可以在类似情况下分享自己的经验或分享一两个有趣的链接？或者我在寻找一个尚不存在的银弹？

Answer 1

服务需要交互 - 不交互的服务不属于同一系统。搜索需要访问目录，购物车不从页面获取价格信息，帐户需要购买历史记录，推荐者需要购买历史记录，购物车需要验证当前可用的优惠券，库存需要知道某些内容被购买等。

设置服务边界以最小化所需的交互。将服务切割为较小的组件是有意义的，但如果它们共享数据库（内部结构），则它们是different aspects of the service。

当服务交互时，它会创建一个耦合级别 - 至少，这种耦合是服务必须“维护”的一些API（JSON或其他），以便其他服务可以与之交互。

另一种耦合类型是时间耦合 - 这是您在请求 - 回复情况下获得的（并且您可以在事件驱动系统中消除）但是，Orchestration vs. Choreography不是关于这些差异（即使编排主要与请求相关联） /回复） - 它涉及中央控制和治理与灵活性和偶然性。

Orchestration存在将业务逻辑从服务迁移到业务流程中的风险，而编排则存在混乱的风险。顺便说一句，直接请求/回复集成在两个世界中都是最糟糕的，但是当系统足够小时，它会在简单性上获胜。

在两者之间进行选择是一种平衡行为（就像大多数架构决策一样），例如，Netflix在编排的基础上建立了很长时间但后来发现他们需要一些控制权并introduced an orchestration engine。什么都不是银弹：）

就个人而言，我更喜欢编舞，因为耦合和灵活性降低，并且赞成像open Zipkin这样的工具来为混乱带来一些秩序。

您可以在slides 10-22 of a presentation I did about microservices

中看到基于业务流程的拱门的部分示例

Answer 2

我想我了解你的来源，最近将系统重新设计为“微服务”架构。我喜欢（并使用）这些人的方法：http://scs-architecture.org/

重点是，你试图避免你的“服务”之间的交叉依赖，这基本上使编排过时。困难的部分是将您的问题域分解为块，这些块对于任何已执行的业务案例都不需要彼此。他们可能需要不同类型的数据，这些数据可能是“共享”，也可能不是“共享”，如同在多个系统中一样，但对于任何给定的业务案例，它们不需要在它们之间进行同步调用。

这与Netflix正在做的事情完全不同。那些人/女孩正在通过不同的服务层进行链式调用，每个服务层都将其逻辑添加到“进程”中。在某些情况下，此模型可能适合，并且可能适合Netflix的情况。但对你来说可能没有必要。

理想的自包含系统将完全独立于其他自包含系统，涵盖一个或多个高度内聚的业务功能（从UI到持久性的全面深度！），并且不要同步调用任何其他系统。理想的系统只需通过其Web（HTML）界面提供链接，即可让客户“协调”。

更像亚马逊。 “登陆页面”是与“搜索”不同的应用程序，它仍然与“结帐”不同。它们完全不同，有时甚至看起来有点不同！由HTML中的链接和表单集成，未明确编排。

这可能就是你要找的东西。

一些警告：某些人的第一直觉是拥有“客户”微服务，或“产品存储库”微服务，类似。这不会导致自包含系统，因为您需要同步调用这些东西，使它们成为“中心”组件。关键是分割业务领域，因此有限的背景是Eric Evans。