集中式工程拆解为分布式（微服务）需要注意的一些事情

1. 背景

可能存在种种原因，会使得一个工程（或者功能模块）是堆积的，臃肿的，维护困难的。下面说下如何化解这个问题。

2. 走向服务化

把集中式工程进行拆解的一般成熟的套路是：工程模块化，然后搭配（局域）网络完成通信交互；

2.1 拆分步骤：

2.1.1 从功能上拆分

从功能上拆分后，可以进一步把粒度分的细一些。根据功能拆分，是有一定的判定依据可遵循的（即根据业务线来清晰划分）。
通过业务线划分后，可能粒度还是非常大，那么可以再通过流程里面的各个功能点进行拆分。

2.1.1.1可能引入的问题

一个功能A需要调用功能B，并且B的执行非常耗时（可能理解成像耗时的批处理一样的情形），后来由于拆分的缘故，将A和B拆分到了两个服务中，那么拆分后，A调用B时，这个超时时间的把控变得非常重要，如果处理不好，那么A调用B的情况可能并没有拆解之前要好（毕竟原来是在同一个进程中，少了一个网络通信的环节）；比如，A调用B，如果超时后，A已经感知到超时异常（此时A怎么办，重试吗？），但是此时B还在执行（B要中断执行吗？）；

2.1.1.2 应对方法

针对上面的问题，可能是我们服务拆解粒度过度造成的，也可能是服务本身（或者流程上）也有优化的地方。我的建议是先不拆解，暂时保持A和B在在同一个进程中执行。

还有另外一种解决方法，但是A调用B的关系需要满足一定的前提要求：A调用B仅仅是A把消息发送给B，具体B的执行成功与否，A是不关心的，但是有一个管理的模块在追踪B的执行状态。这种情况就是一种离线的流式处理流程。

需要注意的是，我们这里讲的都是在线的实时调用，A调用B，大多情况都是需要等下去，一直等到得到反馈的，因此后面的解决方法可能不太适合。

3.微服务的一些好与坏

3.1 拆分的好处：

1.可针对性地进行服务扩容，监控等；
2.串行变并行(pipline、无锁化)（因为操作系统的特性使得可以进行异步的网络读写）；

3.2 拆分的坏处：

1.过度拆分，使得调用关系复杂，网络RTT时间的占比增加；
2.对于request-response类型的调用链条应该扁平化，如果调用链非常深，流程太长，可控就越难；