微服务似乎可以改善一点这方面的问题
系统开发有点像是公司还很小的时侯
当你公司还很小的时侯
某个职员要当客服 又要兼仓管 又要兼销售
所以这个职员可以拿到各种不同的数据
当公司开始变大以后
就会有财务部 客服部 商品部
每个部门的数据再也不像小公司时可以任意取得
每个部门内部各自处理管理
其他部门不用管另一个部门也不用知道他们怎么管理
部门之间的沟通要透过窗口或部长
当系统一开始小的时候
就像小公司校长兼撞钟
一包系统可以同时去存取会员资料与商品资料与物流资料
当系统变大以后
其实也应该像小公司变大公司那样划分不同部门
把各个不同性质的资料抽出来变成微服务
这样的好处就是减少耦合
服务内部不管如何改变
只要对外保持一致就不用担心
如果有那种万年不用更动的服务
那就让他安静的待在角落 不要管他
新进人员也不用花心力去理解那个服务
每个服务很小
小就代表容易理解也容易测试也容易改动
不同部门的资料互相隔离 也更安全
一间公司变大很自然就会划分成各个部门
一个系统变大非程式人员却不容易理解为什么要拆开成不同包
想像有一间 5000人的大公司
每个人都可以任意去各部门拿资料拿数据
而任何部门有任何变动都要想办法去确定这5000人都确定这个变动
这就是程式的世界
系统写久了 5000支程式是有可能的
任何变动都要确定这5000程式没受影响
那改起来就是灾难
自然而然很不想去乱动
或者动不动就想重写
用公司变大去解释或许可以让人理解
公司变大了要有不同部门
可以把部门的小变动固定在某个部门内
不会去影响全公司
当然微服务要弄起来也要有一些成本
所以小公司才校长兼撞钟