好吧,按照计划,我们接下来要做的就是根据项目现有的功能,依照相关的标准抽离出相关的服务。

把这个任务根据我们公司的实际情况,还可以细分,不过不确定是否对大家有参考价值,但是为了记录下每一步重构流程,我还是坚持要写出来的,所以如果你觉得不耐烦,请移步到该系列其它文章,谢谢合作。

服务发现

首先,小弟花了三天的时间,把公司相关的项目文档和代码粗略的滤了一遍,方法简单粗暴,谈不上合理,但个人感觉还是有点用的,根据之前提到的基准,整理出了个文档,如下:

其中每个维度的满分为5(不建议选用过大的分值范围),粗略的解释一下每个分值的含义:

重要度:

1分:作用程度几乎可以不考虑

2分:出现问题不影响业务正常工作

3分:普通,出现问题允许在1天的时间内给予修复即可

4分:重要,不允许失效

5分:核心,不允许失效,且要保证高的执行效率

复杂度:

1分:简单的直接操作一张表,或表达为入职一个月的普通应届生就可完成的任务(这么说可能容易被拍)

2分:需要同时操作多张表,存在一对多关系的数据组合

3分:包含较多的业务逻辑,但全部操作都在同一个上下文中完成(单进程单线程)

4分:产生RPC调用

5分:使用了多线程

复用度:

1分:只有自己使用,这里的“自己”表示自身所在的单个系统中的个别操作使用

2分:自身所在的单个系统中不超过5个操作使用

3分:自身所在单个系统中超过5个操作使用

4分:2个以上的系统都使用

5分:可预见的所有系统都会使用

频度:

1分:偶尔会用,或叫几乎不用(其实大多数操作都属于这一类,又一次验证了二八定理)

2分:普通操作,但并非日常必须

3分:通用操作,正常用户日常会经常使用的

4分:热门操作,所有用户日常会经常使用的

5分:必经操作,所有用户一定会频繁使用的

类型:

原子:基础服务,可以理解为自包含,有明确边界的功能

复合:组合服务,需要由1个以上的原子服务组合出来的功能

以上打分并不是非常的严谨,只是争取做到了有个粗略的标准来区分服务的目的。

服务关系梳理

粗略的数了数,我们公司的在使用项目大概也有十四个之多,上一篇文章介绍过,由于初期设计时就考虑到了系统间的依赖,所以单独在某个项目自身上去发现服务,是不准确的,很可能A系统中的一些功能是依赖B系统的,这样上述的列表中就会有大量的重复内容,所以我们下一步需要做的,就是梳理服务之间的关系

既然要研究关系,视角就不能只局限在某个系统,而是应该上升到平台上,自嘲的说,我们团队现有的项目用”平台”二字有点小题大做,不过意思到了就行了,不要在意细节,咱们聊的是方法论。

其实在服务发现时,根据基准,就可以第一轮筛选出一部分较为合适的服务集合了,我们只需要把选中的服务的关系整理出来即可。依然采用图的方式,如下:

PS:哥知道画的很丑,但确实没有美化的能力啊,求推荐工具


这样下来,目标就明确很多了。但,这还不够,接下来就是要深入到每一个服务中,根据实际情况来设计该服务的实现细节。我们放在下一篇来继续。