我们计划从整体架构迁移到基于微服务的架构。现在我有责任将模块从整体中剥离出来。
现有整体:
1) 代码耦合非常紧密。
2) 使用不同的参数递归调用 API。
3) 我计划提取的模块内的一些调用包含对系统的调用，大约需要 9 分钟才能完成。 不幸的是，这是同步的。
注意事项:
1) 我从单个 api 迁移开始，这是一个非常重要的迁移，但性能不佳。 2) 该 api 由对另一个系统的并行调用组成，用于执行 一堆任务。所有的调用都是阻塞且耗时的(考虑 平均响应时间为 5-6 分钟)
迁移到基于微服务的架构:在将上述 api 从整体迁移到单独的微服务时，我想到了两种方法，同时解决由于时间阻塞而导致线程阻塞的问题来电。
a) 分阶段进行:
- Create a separate module
- In this module provide an api to push events to kafka, another
module will in-turn process the request and push the response back
to kafka
- monolith for now will call above mentioned api to push events to
kafka
- New module will inturn call back the monolith when the task
complete (received response on a separate topic in kafka)
- Monolith once get response for all the tasks will trigger some post
processing activity.
Advantage:
1) It will solve the problem of sync- blocking call.
Disadvantage:
1) Changes are required in the monolith, which could introduce some
bugs.
2) No fallbacks are available for the case if bug gets introduced.
b) 立即将 API 移至微服务:
最初将共享共同点 数据源采用单体并解决阻塞调用问题 通过在新的微服务和模块之间引入kafka 需要时间来处理请求。
优点:
1) 回退可在整体中使用
缺点:
1) 最初数据源在系统之间共享。
完成此类复杂任务的最佳方法应该是什么？
最佳答案
您必须处理几件事。
第一
采用微服务会比单体应用慢(90% 的情况下)，因为会引入延迟。因此，当您使用它时，永远不要忘记它。
第二
你问使用kafka是否是一个好方法。在大多数情况下我可能会回答"is"，但您提到今天的过程是同步的。如果是出于事务原因，我想您将无法使用消息代理来解决它，因为您将把强一致性系统更新为最终的系统。 https://en.wikipedia.org/wiki/Eventual_consistency
我并不是说这是一个糟糕的解决方案，只是它改变了您的工作流程并可能影响某些业务规则。
作为解决方案，我提供以下解决方案:
1 - 通过在整体中引入功能键和 API 组合来打破整体中的接缝(请阅读 Sam Newman 的书以获取帮助)。
2 - 在整体内部引入最终一致性以测试其是否符合目的。如果没有的话回滚会更容易。
不，你必须有可能性:
第二步进展顺利，因此请继续将服务代码放入单体中的微服务中。
第二步不适合，然后考虑在特定服务中做有风险的事情或使用分布式事务(小心这个解决方案，它可能很难管理)。
关于microservices - 整体架构到微服务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44928556/