从微服务划分,微服务之间通信到程序员能力提高的一些思考

Posted 2020-10-02 李斯特王

　　这个问题是由工作中的一次需求的变动引起的。

1:为什么会有这个思考

　　我们当前做的是一个视频门户系统,这个系统分为四个子系统:cms(内容系统),bms(订购系统),tms(终端管理系统),ims(用户系统)。这四个系统对应同名的四个数据库,分别记录相关的数据。

　　问题出现在一次需求变动后,我们要用各地的CDN播放地址替换源播放地址,所以我们要对业务做一下小小的改动。但是在改动的过程中发现,ims的一些业务功能也用到了播放地址,所以不仅cms要改动,ims也要改动。这样的话改动的地方就比较多,比较大了。

2:存在这个问题的原因

　　为什么会出现这个问题呢?最初我们在设计这个系统的时候,数据库的划分还是比较明确的。但是在业务划分方面,由于没有经验,导致业务模块的边界划分的不够清晰。而且在后期的系统构建过程中,为了图方便,用到其它系统的数据的地方就直接引用其它系统的数据库了。这些原因就导致了要修改一个功能，却要修改多个项目的多个地方的问题。

3:关于这个问题的思考

　　出现这个问题首先是因为设计之初没能深入透彻的明白业务需求,导致业务划分,特别是业务边界的划分不够明确,导致我们关于某个功能的实现可能同时出现在多个系统中。

　　然后就是业务划分的粒度不够细,因为粒度划分的越细,越容易实现模块间的解耦,模块间的复用。而不用因为一个问题的出现到处去修改。

　　还有就是对于某个模块或某个功能,对外暴露出来的供外部使用或调用的接口一定要是唯一的,这样如果业务改变我们只用修改这个接口的内部实现就行了。例如：对于一个数据表的操作,如果四个子系统都有一定的实现,那么当数据库表有改动时,四个子系统都要改动。如果只有一个子系统实现了这个数据库的操作,别的子系统都是通过调用这个子系统暴露的接口来对数据库进行操作的话,这个问题就变得很简单了。

4:后记

　　当然,任何复杂的系统都不是一蹴而就的，都是由一些简单的甚至不合理的系统慢慢进化而来的。在设计之初,我们也不可能将系统架构的十全十美。在这种情况下,我们一定要擦亮眼睛,因为一切让我们感觉到复杂甚至不合理的地方都是我们进一步优化的入口。我们一定要保持思维的敏感与洁癖,因为你对问题的将就和习惯可能会使你的技术与能力止步不前。