我们计划从整体架构迁移到基于微服务的架构。现在我有责任用巨石来谈论模块。
现有Monolith：
1）代码紧密耦合。
2）使用不同的参数递归调用API。
3）我计划提取的模块中的一些调用包含对系统的调用，大约需要9分钟才能完成。 不幸的是，这是同步的。
注意事项：
1）我开始使用单个api迁移，这是一个非常重要的迁移，但效果不佳。 2）此api包含对另一个系统的并行调用以执行 一堆任务。所有的电话都是阻塞和耗时的（考虑一下） 平均响应时间为5-6分钟）
转向基于微服务的架构：将上述api从monolith转移到单独的微服务时，我想到了两种方法，同时解决了因阻塞时间而阻塞线程的问题调用。
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移至微服务：
最初会分享共同点 使用monolith的数据源并解决阻塞调用的问题 通过在新的微服务和模块之间引入kafka 需要时间来处理请求。
优势：
1）回归可用于整体
缺点：
1）最初数据源在系统之间共享。
执行这些复杂任务的最佳方法是什么？
答案 0 :(得分：2)
你必须要处理好几件事。
<强>第一
由于引入了延迟，转向微服务的速度将比单片机慢（90％的时间）。所以，当你选择它时，永远不要忘记它。
<强>第二
你问这是否是一个很好的方式去卡夫卡。在大多数情况下，我可能会回答“是”，但您提到今天的过程是同步的。如果是出于交易原因，我无法通过消息代理解决问题，因为您会将强一致性系统更新为最终系统。 https://en.wikipedia.org/wiki/Eventual_consistency
我并不是说这只是一个糟糕的解决方案，只会改变您的工作流程并可能影响某些业务规则。
作为解决方案，我提供了这个：
1 - 通过在整体内部引入功能键和api组合来打破整体中的接缝（阅读Sam Newman的书以帮助）。
2 - 介绍整体内部的最终一致性，以测试它是否符合目的。如果没有，它将更容易回滚。
不，你有可能：
第二步进展顺利，继续将服务代码放入整体的微服务中。
第二步不合适然后考虑在特定服务中执行有风险的事情或使用分布式事务（小心这个解决方案可能很难管理）。
答案 1 :(得分：0)
我认为最好的方法是选择方案1：分阶段进行。但是，可以在具有后备策略的同时执行此操作。如果您的新服务遇到问题，您可以保留未修改后端的版本作为备份。
此方法在文章中有更详细的描述：Low risk monolith to microservice evolution它提供了有关分阶段实施方法具有较低风险的实施和思想过程的更多详细信息。但是，仍然存在更改后端的需求，但希望可以通过单元测试来缓解。