架构学习-系统重构(技术)

      01.xxx.消灭问题

      如果旧系统业务迭代规模没有那么频繁,那么旧的垂直系统不需要微服务化,因为体现不出来微服务的价值; 如果旧系统中的其他业务将来可能需要重构,那么不需要微服务化,因为将来可能会大改动; 如果旧系统中的业务只是其他业务的支撑业务,并且迭代频率低,没有不要进行拆分;如果没有类似客户端,那么垂直系统怎么改微服务都可以,兼容旧版本app总是非常多的问题;如果有厉害的技术专家,开始主导微服务,就么就尽可能不要出现垂直系统改微服务;

      A01.前提背景

      前提问题:是否有必要的理由把垂直项目的微服务处理; 衍生问题:把垂直项目微服务化处理的好处是什么; 最终问题:把某个业务模块微服务化是否能带来真正的好处,如果没什么好处,那么就不要浪费人力.

      A05.问题划定

      目标:如何把垂直系统进行微服务化改造; 前提:对整个系统每个模块并不是那么熟悉,或理想情况对整个系统非常熟悉

      A10.存在问题

      X1.确定垂直系统中每个模块使用接口的调用情况来判断每个业务模块需要改动的接口; X2.确定垂直系统中每个模块使用接口的调用情况来判断Android或IOS调用情况; X3.对于PC端则不存在这个问题

      A15.解决问题

      1.面临的严重问题就是所有版本的app强制更新问题.如果每次小版本接口更新,可能会存在app每次都要强制更新的情况; 如果每次小版本接口更新,app不更新,那么就要做旧接口兼容更新.[很烦躁,几十个上百个接口,需要调试维护]; 2.如果一次性全部修改完,那么就是大版本迭代,考虑人力成本,业务迭代速度[绝对禁止大版本迭代]; 3.如果每次小版本更新不做旧接口兼容,那么就是新旧系统并行,然后某段时间客户端集中修改调用的接口,最后强制更新,目前所选择的方式.

      A20.存在问题

      x1.如何拆分

      1.先拆分整体,还是拆出来部分模块呢? 2.整体拆是作死,如果对业务不熟悉,只能局部拆分,逐步进行处理掉. 3.人力,工期,时间的约束下,即使对系统了如执掌,你也只能逐步进行拆分

      x2.业务迭代

      1.在拆分后的模块进行业务迭代,还是垂直系统业务迭代呢? 2.在拆分后的业务模块进行服务迭代,并且客户端等调用微服务的接口; 3.因为将来会进行一次强制更新,如果实在躲避不了,在进行旧业务迭代; 4.最怕的就是新业务迭代必须一定兼容旧接口内容

      x3.拆分顺序

      1.我们如何判断先拆分哪个业务模块?判断依据维度有哪些? 2.判断维度:耦合情况,熟悉程度,业务约束 3.优先处理对业务约束严重的模块,微服务后提高系统伸缩性 4.其次处理微服务化后业务拓展比垂直系统快捷方面的模块,便于业务发展的模块 5.最后处理对业务发展的影响不重要的模块,和其他模块耦合性比较低的模块.