微服务划分的思考

为什么

微服务不是十全十美的，不是银弹，是什么原因导致必须要做微服务划分，是否有足够的动机支撑，是项目需要，还是领导的想法，公司层面是否有相应的规划。

拆分后的服务谁来维护，研发同学是否愿意参与

为什么，思考清楚了，接下来看还需要考虑怎么做

单体应用的不足

1. 随着时间推移逐渐变大，难以维护。
2. 降低开发速度，应用越大，启动时间越长。
3. 不同模块发生资源冲突时，扩展困难。密集计算型模块与密集I/O型模块资源冲突。
4. 可靠性难以保障，任何一个模块的bug都有可能拖垮整个服务
5. 采用新架构或者新技术非常困难

以上是单体服务面临的一些问题，但是不止于此。

微服务优点

微服务的核心价值在于以下几点：

1. 粒度小，单个服务可以紧贴业务快速迭代；
2. 去中心化组织和部署结构，减少不必要的协同；
3. 数据和商业逻辑受同一个服务控制，从而在商业逻辑快速变更的同时，保障数据模型的一致性；
4. 数据和状态独立封装，保障一个业务快速演变的同时，还不污染其他业务；
5. 服务本身的独立部署能力使得容错和容量弹性最大化；
6. 细粒度服务发布回滚和故障响应能够有效隔离，出了问题可以迅速降级或回滚。

微服务缺点

1. 微服务应用是分布式部署，需要考虑服务间的协作通信
2. 微服务的数据库是分区的，需要考虑数