最近一直在思考服务拆分的尺度，微服务也好单体也好这样的争论也在视野范围内不断出现。然而突然发现自己的思维不知不觉掉入了一个非常大的误区。这个误区就是上来就试图自业务开始切服务。
拆分服务这个行为，在我脑海中习惯性的映射成一把刀，面对乱做一团的业务代码，一刀下去，清爽利索。不客气的说，这是巨大的误区，这个场景是不可能存在的。世界的真相是，自下而上，层层组装层层叠加，越小粒度不可拆的逻辑复用率越高，复用率越高代码质量也会越来越好，所有的优化都会沉淀下来，而只有小粒度的优化才能沉淀下来，或者说，才是有意义的。
而作为现实世界的映射，业务系统最小粒度的逻辑，应是一个动作，以及连带产生的一组数据。很明显，这样的粒度必然会产生巨大量的冗余。所以一般我们堆业务的时候，不会做这种程度的拆分，而是大而化之，以快速上线为目标。当业务进展到了某个时期，才会去做一些拆分，并且增加一些冗余。而这个随着业务进行拆分、合并、重组的过程，也就是架构的演化。
这样看来，带着业务应用的方向，技术上不能脱离自下而上的视角，才是架构优化的正确姿势。迫不及待对着一团乱麻期待一刀斩下解决一切问题，始终只是妄念，软件工程里没有银弹。
带着这个角度重新思考手上的业务逻辑时，发现可以做的事非常非常多。将微服务和单体之争丢到一边吧，遵循规律，顺势演化就是最合适的。
本作品由 IvyWooo 采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可，转载请注明出处。
小站生存不易，如果本次分享内容对你有用，请点击广告支持一下，谢谢～
「真诚赞赏，手留余香」
猫猫和狗狗的小窝
真诚赞赏，手留余香
使用微信扫描二维码完成支付
本文总阅读量次