微服务适用于哪些业务场景？

微服务和业务场景无关，什么时候使用微服务呢？当你的项目或者产品遇到如下问题：
1、 代码冲突加剧
多个人或者一个团队一起维护一个模块，共同开发。当提交代码的时候发现大量冲
突，每次提测或者发版的时候需要花大量的时间来解决冲突。 随 着团队规模的增大
以及项目复杂程度增加，代码冲突的现象越严重 ；
2 、 模块耦合严重
模块之间通过接口或者 DB 相互依赖，耦合越来越严重。而且不同的人，写代码的
风格不一样，代码质量也不一样，上线前需要协调多个团队，任何小模块的异常都
会导致整个项目发 布 失败；
3 、 项目质量下降
由于所有的代码都是在一个服务里面，做一次改动，可能会牵一发而动全身，代码
冲突以及耦合严重，导致测试覆盖范围不充分，经常会出现没有更改的模块在线上
突然出现问题，查询后发现是由于工程师不小心做了某种改动，但是测试用例并没
有覆盖；
4 、 团队效率下降
由于大量时间在处理代码冲突，消耗了研发人员大量的时间；而测试人员为了提高
项目质量，不得不在每次发版之前做全方位的回归测试，本身一次小的迭代结果项
目时间却很长；
此时就可以开展微服务了。实施过程中首要解决的就是服务拆分问题， 服务拆分是否合理直接影响到微服务架构的复杂性、稳定性以及可扩展性。服务拆分过小，会导致不必要的分布式事务产生，而且整个调用链过程也会变长，反之，如果服务拆分过大，会逐步演变为单体应用，不能发挥微服务的优势。判断一个服务拆分的好坏，就看微服务拆分完成后是否具备服务的自治原则，如果把复杂单体应用改造成一个一个松耦合式微服务，那么按照业务功能分解模式进行分解是最简单的，只需把业务功能相似的模块聚集在一起。比如：
ü 用户管理：管理用户相关的信息，例如注册、修改、注销或查询、统计等。
ü 商品管理：管理商品的相关信息。