在微服务的路上，拆分服务一直是个难点和热点，那么服务拆分必须要考虑哪些因素呢？
业务因素：服务拆分时先从业务角度确定拆分的方案，边界要充分考虑业务的独立性和专业性，按服务的业务功能合理的划出拆分边界，所有技术方面的考虑包括架构设计和解耦拆分都要考虑业务的需要。
投入产出比：拆分的收益要大于付出的成本，一个衡量指标是拆分前的维护成本要大于拆分后的维护成本，因为软件主要的工作量还是后期的维护定制成本。
系统扩展：提高系统的扩展性是拆分的一个理由之一，把具有不同扩展性需求的服务拆分出来分别部署、可以降低成本，提高效率。尤其是对系统中容易变化的部分要分离出来，便于后面的扩展定位和故障时快速定位。
拆分策略：优先抽象容易识别、边界明显、有独立属性的服务以及抽象核心服务，可采用绞杀者模式，在遗留系统外围，随着时间的推移，逐渐用新的服务替换老系统。 应该尽量保证单向调用，避免两个服务互相调用。
拆分前提：有一个持续集成平台，自动化测试驱动，能方便大量的回归测试验证；数据库设计不应该有大量联合查询，复杂查询通过应用层或ES实现，尽量做到应用的无状态化。
服务拆分带来的问题：数据的一致性，服务的可用性，请求多次网传转发带来的系统性能，测试部署运维实施复杂。
不求完美，能在保证质量、按时完成落地最重要。
1、世界上没有完美的架构，如果有，那一定是你过度设计了；
2、并不是所有的系统都得到了很好的设计，而最清楚问题的人应该是写代码的人，而不是管理者或者不写代码的架构师；
3、你认为的最适合的架构，不会得到所有人的认可，因为你们站的角度不一样。