在微服務的路上，拆分服務一直是個難點和熱點，那么服務拆分必須要考慮哪些因素呢？
業務因素：服務拆分時先從業務角度確定拆分的方案，邊界要充分考慮業務的獨立性和專業性，按服務的業務功能合理的划出拆分邊界，所有技術方面的考慮包括架構設計和解耦拆分都要考慮業務的需要。
投入產出比：拆分的收益要大於付出的成本，一個衡量指標是拆分前的維護成本要大於拆分后的維護成本，因為軟件主要的工作量還是后期的維護定制成本。
系統擴展：提高系統的擴展性是拆分的一個理由之一，把具有不同擴展性需求的服務拆分出來分別部署、可以降低成本，提高效率。尤其是對系統中容易變化的部分要分離出來，便於后面的擴展定位和故障時快速定位。
拆分策略：優先抽象容易識別、邊界明顯、有獨立屬性的服務以及抽象核心服務，可采用絞殺者模式，在遺留系統外圍，隨着時間的推移，逐漸用新的服務替換老系統。 應該盡量保證單向調用，避免兩個服務互相調用。
拆分前提：有一個持續集成平台，自動化測試驅動，能方便大量的回歸測試驗證；數據庫設計不應該有大量聯合查詢，復雜查詢通過應用層或ES實現，盡量做到應用的無狀態化。
服務拆分帶來的問題：數據的一致性，服務的可用性，請求多次網傳轉發帶來的系統性能，測試部署運維實施復雜。
不求完美，能在保證質量、按時完成落地最重要。
1、世界上沒有完美的架構，如果有，那一定是你過度設計了；
2、並不是所有的系統都得到了很好的設計，而最清楚問題的人應該是寫代碼的人，而不是管理者或者不寫代碼的架構師；
3、你認為的最適合的架構，不會得到所有人的認可，因為你們站的角度不一樣。