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类型的调用链条应该扁平化,如果调用链非常深,流程太长,可控就越难;