问单微服务中的多个进程

EN

非常普遍的需求是让后台进程与API一起使用单个微服务大小的数据块--特别是在使用数据总线或消息队列来缓冲最终可能一致的东西的环境中。并且希望将它们与实际的API一起托管，这样就可以减少部分部署失败的可能性。

也就是说，它们需要有足够的凝聚力，使您的微服务仍然专注于一个具有很小数据范围的单一责任。并且将它们全部运行在一起可能会导致性能、监视、安全和操作问题。

就像大多数事情一样，这取决于。这两种方法都有权衡，您可能会错误地将它们保持为单独的服务，但是在一些常见的场景中，将它们捆绑在一起是很好的。

设计良好的软件很容易改变

你所做的任何事情都会使你更难改变这个系统，从定义上来说，这并不是一个很好的设计。

在不了解部署基础结构的情况下，必须部署两个直接使用相同数据库模式的不同包使它们紧密耦合，因此需要测试两件事，即使其中一个正在更改。这使得改变变得更加困难。

如果只部署了一个包，那么API和批处理之间的差异就是摩擦的另一个根源。API通常需要动态、快速、单独的记录更新，而批处理在长时间运行的大容量记录更新中效果最好。您可以使批处理作为API驱动程序工作。这将适用于低卷早期，但将成为问题与更高的卷。总之，这两个过程的数据生命周期是非常不同的。将它们限制在单一模式将导致问题，使更改变得更加困难。

最明智的做法是将这些过程完全分开。我建议使用Customer Notification Service。它的唯一目标是通过任何客户喜欢的方式来管理通知。它将作为数据转储接收，或者通过其他服务的某种事件日志添加/取消。除了健康之外，这还可以满足直接的业务需求：How is the business engaging a given customer?

批处理/API融合

在有些情况下，让相同的程序同时作为API和批处理操作是有意义的。诸如Jenkins或石化SCM的程序:导出Web前端和API；同时提供批处理。

不同之处在于，每个接口都提供相同的“服务”，即使每个接口都是由单独的进程提供的。

更改必须发生在(接近)锁定步骤中的所有接口上。如果每个接口都是由独立的独立服务在不同的代码库中提供的，那么这样的更改必须在每个接口上执行一次。在一个项目中检测到的任何缺陷都需要在所有项目中进行验证(以确保一致性)。这为每一次变更都做了大量的工作。

与之相比，使用单个代码库可以显著减少每个添加的接口的实现和维护时间。但是，要想成为竞争者，需要有几个属性：

• 域逻辑需要是可共享的，如果重复的话，很容易被公共实现无关的特性测试验证为一致。
• 接口需要提供一致的域行为，只有少数省略的特性(例如新的/实验性的/不推荐的行为)，并且在接口行为(如分页结果、分组数据传输、数据转义和编码等)方面仅略有差异.