1

我们正计划从单体架构迁移到基于微服务的架构。现在我有责任从单体中谈论一个模块。

现有单体：

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) 最初数据源在系统之间共享。

完成这些复杂任务的最佳方法应该是什么？

4

2 回答 2

2

You have to take care of several things.

First

Going to microservice will be slower (90% of the time) than a monolith because you introduce latency. So never forget it when you go with it.

Second

You ask if it is a good way to go with kafka. I may answer yes in most of the case but you mentioned that today the process is synchronous. If it is for transactional reasons, you won't be able to solve it with a message broker I guess because you'll update your strong consistency system to an eventually one. https://en.wikipedia.org/wiki/Eventual_consistency

I am not saying that it is a bad solution only that it change your workflow and may impact some business rules.

As a solution I offer this:

1 - Break the seams in your monolith by introducing functional key and api composition inside the monolith (read Sam Newman's book to help).

2 - Introduce the eventual consistency inside the monolith to test if it fits the purpose. It will be easier to rollback if not.

No you have to possibility:

The second step went well so go ahead and put the code of the service into a microservice out of the monolith.

The second step did not fit then think about doing the risky thing in a specific service or use distributed transactions (be careful with this solution it could be hard to manage).

于 2017-08-11T17:08:34.520 回答
0

我相信最好的方法是移动选项 1：分阶段移动。但是，可以在有后备策略的同时执行此操作。如果您的新服务遇到问题，您可以保留未修改的后端版本作为备份。

文章中更详细地描述了该方法：从低风险单体到微服务演进它提供了更多的实施细节以及分阶段方法为何具有较低风险的思考过程。但是，仍然存在更改后端的需求，但希望通过单元测试来缓解。

于 2019-05-15T03:39:46.080 回答