大规模的精心策划与精心设计的面向服务的架构？

Question

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

从很早开始,核心思想就是尽可能遵循面向微服务的原则(并确保工程师阅读Sam Newman撰写的"构建微服务"一书).

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

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

近年来,有一种微服务向精心设计(接近事件驱动)架构的运动.正是在这一点上,我正在寻找那些面临类似十字路口决策点的工程师和建筑师的建议.

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

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

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

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

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

Answer 1

服务需要交互-不交互的服务不是同一系统的一部分。搜索需要访问目录，购物车没有从页面中获取价格信息，帐户需要购买历史，推荐者需要购买历史，购物车需要验证当前可用的优惠券，库存需要了解一些信息已购买等

设置服务边界以最大程度地减少所需的交互。将服务切成较小的组件可能很有意义，但是如果它们共享数据库（内部结构），则它们是服务的不同方面。

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

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

编排具有诸如将业务逻辑从服务中迁移到编排中的风险，而编排则具有混乱的风险。顺便说一句，直接请求/答复集成在这两个方面都是最糟糕的，但是当系统足够小时，就可以在简单性上取胜。

两者之间的选择是一种平衡行为（例如，与大多数架构决策一样），Netflix大量时间基于编排构建，但随后发现它们需要一些控制，并引入了编排引擎。没有什么是银弹:)

就个人而言，我更喜欢编舞，因为它减少了耦合和灵活性，并喜欢使用开放Zipkin之类的工具将一些秩序弄乱。

您可以在我关于微服务的演示文稿的幻灯片10-22中看到基于编排的弓的部分示例