一体式微型服务

Question

我们计划从单一体系结构迁移到基于微服务的体系结构。现在，我承担了从monolith中谈论一个模块的责任。

现有的Monolith:

( 1)代码是紧密耦合的。

2)使用不同的参数递归调用API。

3)在我计划提取的模块中，有些调用包含了对一个系统的调用，大约需要9分钟才能完成。不幸的是，这是同步的。

指出要注意：

1)我从一个api迁移开始，这是一个非常重要的迁移，而且性能不佳。2)该api由对另一个系统的并行调用组成，用于执行多个任务。所有呼叫都是阻塞和耗时的(假设avg响应时间为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)初始数据源在系统间共享。

做这类复杂任务的最佳方法应该是什么？

Answer 1

你得处理几件事。

First

使用微服务的速度会比单块要慢(90%的时间)，因为您会引入延迟。所以当你和它一起去的时候，永远不要忘记它。

第二

你会问这是不是卡夫卡的好方法。在大多数情况下，我可能会回答“是”，但您提到，今天的过程是同步的。如果是出于事务原因，您将无法使用message来解决这个问题--我猜是因为您将将您强大的一致性系统更新为最终的一致性系统。一致性

我并不是说这是一个糟糕的解决方案，只是因为它改变了您的工作流程，可能会影响一些业务规则。

作为解决办法，我提出如下：

1-通过在monolith中引入功能键和api组合来打破monolith中的接缝(阅读Sam的书以提供帮助)。

2-引入单体内部的最终一致性，以测试其是否符合目的。如果不是的话，回滚会更容易。

不，你必须有可能：

第二步进行得很好，所以请继续，将服务的代码放在monolith之外的微服务中。

第二步不适合，然后考虑在特定的服务中执行危险的事情，或者使用分布式事务(小心这个解决方案，很难管理)。

Answer 2

我认为最好的办法是将备选方案1:分阶段移动。然而，这是有可能做到这一点，同时有一个后备战略。如果新服务遇到问题，可以保留未触及后端的一个版本作为备份。

该方法在本文中有更详细的描述：微型服务演进的低风险单体，它提供了实现的更多细节，以及为什么分阶段的方法具有较低风险的思想过程。然而，修改后端的需求仍然存在，但希望通过单元测试来减轻。