「不要熬夜写代码」为什么有些公司不愿意微服务化，因为“太南了”

本文插图
微服务是这几年比较火的概念了，很多 IT 公司也都在做微服务转型，那么微服务化适合所有的公司么？微服务架构可以解决一切问题么？我觉得并不是这样的，企业是否需要做微服务转型还是要从实际情况出发。 01微服务倒逼组织架构
【「不要熬夜写代码」为什么有些公司不愿意微服务化，因为“太南了”】说到微服务，很多人会认为这是个技术架构，但我认为微服务不只是技术架构这么简单，它甚至会涉及到组织架构。
通常 IT 公司的岗位都会分成产品、开发、测试、运维，有些公司甚至会分成不同的部门，一个需求的开发到上线，会从前到后经过四个部门的流转，而进行微服务的转型，目的是为了加速业务的响应，快速开发，快速上线，缩短迭代周期，快速试错并纠正。
如果企业想做服务化转型，那么组织架构也需要做相应的调整，否则还像以往一样，部门和部门之间、岗位和岗位之间需要很大的沟通成本，那么微服务是“快不起来”的；比较理想的是把不同的岗位揉在一起，一个团队中包含产品、开发、测试、运维四种角色，团队成员彼此协作负责一个或几个微服务的迭代和运维。

本文插图
02设计更为复杂
判断是不是适合微服务化，也要看自己的业务场景，如果服务做拆分，只是为了拆分而拆分，是没有意义的，通常要考虑：
拆分之后的服务，能否被复用？
如果一个功能在 A 系统，只被 A 系统自己使用，那么没有拆出来的价值，如果 B/C/D 系统都需要使用这个功能，那么可以拆分出来复用；微服务的优势之一，增加复用，减少重复开发，缩短开发时间，进而降低成本；
访问量大还是小？如果访问量不大且平稳，未来很长时间访问量也不会有很大的增长，那就没必要微服务化，如果有高并发、流量不可预计，那么可以做微服务化。
微服务在设计上也存在着一定的难度，拆成几个微服务？新需求来了，是新建一个微服务，还是在老服务上改造？这些设计层面的考虑，也是非常复杂的。

本文插图
03技术上的难度
虽然我们的服务容易复用了，一个新需求的开发可能做一个页面，调几个接口就完成了，但是微服务的开发和维护，也给 IT 带来了很大的挑战。
服务被拆成了多个微服务，每个微服务又会部署很多套，这时候才使用人肉运维就不合适了；
以前 A 系统的一个接口，变成 A->B->C->D 这样的调用链路了，如果一个环节出现问题，可能导致整个链路上的系统都不可用，而且问题的定位也会变得更难；
单个系统做数据的增改删很简单，通过事务就很容易控制，但微服务化之后，就变成了多个系统的分布式事务，这个难度很大，大多数系统只能做到数据的最终一致；
因为一个功能可能会涉及多个系统，那么测试也变得复杂了。
总之，很多公司不原因做微服务转型，第一就是微服务化的难度比较大，企业没有能力做；第二就是，企业可能真正地思考和评估过，现有架构足以满足业务，没必要做微服务。不同见解欢迎大家留言讨论