Ali*_*i n 7 architecture event-driven microservices
我们有一条数据处理管道，可在其中接收来自不同来源的数据。整个管道是通过使用事件驱动的体系结构和微服务来实现的。服务之一具有三个单独的任务。其中两个在不同的数据源之间是完全相同的，但是第三个任务范围可能会根据我们的数据源是什么而略有变化。例如，对于一个源，可以基于文件1和文件2计算唯一签名，对于另一个源，可以根据字段2和3计算唯一签名。实现此服务的最佳方法是如何与微服务粒度原则保持一致？
我想到了三种方法：
1）创建一个服务，并对每个源使用不同的实现（例如工厂设计模式）。根据来源，将在运行时使用其中一种实现。
优点：服务数量少。复杂度降低
缺点：由于该服务将在所有数据源之间共享，因此，通过添加任何新的数据源，应重新部署该服务，这将在该服务与负责从源收集数据的任何服务之间创建隐式依赖关系。
2）将此服务分为两个服务，对所有源使用一个，然后重新实现每个数据源的提取服务。
优点：收集器与这两个服务之间没有依赖性。通过添加新的源，需要实施新的服务，并且不需要重新部署与其他源相关的服务。
缺点：更多的服务，并且由于服务太小，我们将来可能会面临纳米服务的问题。
3）不要更改服务的粒度，而是在运行时创建服务的不同实例。每个都有不同的配置，以指定用于每个源的字段集。在这种情况下，代码是共享的，但是运行时实例根据它属于哪个源而有所不同。
优点：服务数量少，没有操作依赖性
缺点：将逻辑的复杂性转移到运行时，这可能使部署和操作更具挑战性
这取决于。仅供参考，我知道卡夫卡，但没有这方面的经验。
对于选项 3：您管理具有不同配置的解决方案的各种实例的能力有多成熟？会有多少个实例？您如何能够观察所有实例的健康状况、行为和性能？
此选项意味着开发不太复杂，但操作方面更复杂：您只有一个代码库要测试，但需要测试许多不同的配置排列。
对于选项 1：开发方面会更复杂，并且操作方面仍然有一定的复杂性。其原因取决于解决方案如何设置以识别在运行时使用哪个实现。IOC 方法可以工作，但它仍然是需要管理的配置。
对于这两种方法，您都可以使用正确的配置设置实例并对其进行测试，这很好。
关于系统变更：理想情况下，微服务应该易于更换。确保服务之间的界限清晰，以便您可以理想地替换解决方案的一部分，而不会破坏另一部分。在将此类更改部署到生产中之前，它还应该易于测试 - 既可以单独测试服务/模块，也可以与解决方案的其余部分以及相关配置进行集成测试。如果您认为一种方法比另一种更适合，那么我可能会采用这种方法。
更新 - 选项 2
这意味着有多个服务来处理某些请求（但不是其他请求），因此现在您必须管理服务之间的流程（在运行时），以及它们之间的相互依赖关系（在开发、部署时）；更难测试。
微服务部分是关于拥有独立的服务 - 选项二并不真正符合这种精神 - 这没关系，只要意识到它不是严格意义上的微服务，取决于你对这些事情的特殊程度。