微服务如果共享同一个数据存储,那将紧密耦合,例如,更改一个微服务表的结构,那么可能会导致另一个微服务出现问题,拥有自己数据库后,其他服务需要避免访问别人服务的数据库,切记别为了省事方便而去共享,一个服务所拥有的数据库,只能由该服务提供API来访问。那么，微服务改如何用来拆分呢？

微服务拆分的过程，是基于某个痛点出发，是业务真正遇到快速迭代和高并发等问题，如果不拆分，将对于业务的发展带来影响，只有这个时候，微服务的拆分才是有确定收益的，增加的运维成本才是值得的。

单体应用开发通常是几十人开发一个系统，代码管理时经常会遇到代码提交冲突。微服务架构通过快速迭代可实现开发独立，将系统拆分成不同的微服务，每个微服务对外提供接口，其他依赖服务不用关注具体的实现细节，只需保证接口正确即可。每几个人维护一个服务模块，降低代码冲突的概率，出现冲突时也可快速解决。

微服务架构对于快速迭代可带来独立上线的效果。微服务拆分后，在服务接口稳定的情况下，不同的微服务可独立上线。上线的次数增多，单次上线的需求量变小，可随时回滚，风险变小，时间变短，影响面小，从而加快迭代速度。

微服务的拆分一直是历史性的难题，行业内更是没有具体的拆分标准，拆分的好坏更多取决于拆分者的经验，并经过反复迭代，逐步优化、调整，以达到比较合适的划分。