微服务的拆分一直是历史性的难题，行业内更是没有具体的拆分标准，拆分的好坏更多取决于拆分者的经验，并通过反复迭代，逐步优化、调整，以达到比较合适的划分。web
数据库
本文包括微服务的拆分时机、拆分原则、拆分方法，用于指导微服务的拆分工做，但愿可以对你们有所启示。后端
安全
微服务拆分绝非是一个大跃进的过程，拆分时机不对，很容易把一个应用拆分的七零八落，最终大大增长运维成本，却不会带来明显收益。微信
架构
微服务拆分的过程，是基于某个痛点出发，是业务真正遇到快速迭代和高并发等问题，若是不拆分，将对于业务的发展带来影响，只有这个时候，微服务的拆分才是有肯定收益的，增长的运维成本才是值得的。并发
有快速迭代的需求app
互联网时代，业务快速变化，应用的交付须要快速响应式交付。经过微服务架构，采用快速迭代的方式进行架构演进，将系统拆分红多个独立的微服务，微服务之间彼此独立，经过服务接口交互。当某个微服务遇到问题时发版修复，不会致使整个系统不可用，从而支撑业务的快速试错。运维
提交代码频繁出现大量冲突
编辑器
单体应用开发一般是几十人开发一个系统，代码管理时常常会遇到代码提交冲突。微服务架构经过快速迭代可实现开发独立，将系统拆分红不一样的微服务，每一个微服务对外提供接口，其余依赖服务不用关注具体的实现细节，只需保证接口正确便可。每几我的维护一个服务模块，下降代码冲突的几率，出现冲突时也可快速解决。
小功能要积累到大版本才能上线
传统模式单次上线的需求一般较多、风险较大，小功能的错误可能会致使大功能没法上线。所以每次上线都会带来较大的工做量。
微服务架构对于快速迭代可带来独立上线的效果。微服务拆分后，在服务接口稳定的状况下，不一样的微服务可独立上线。上线的次数增多，单次上线的需求量变小，可随时回滚，风险变小，时间变短，影响面小，从而加快迭代速度。
解决高并发横向扩展问题
互联网时代，业务应用的高并发要求愈来愈高，单体应用虽然能够经过部署多份承载必定的并发量，可是会形成资源很是浪费。有的业务须要扩容，例以下单和支付，有的业务不须要扩容，例如注册。若是一块儿扩容，消耗的资源多是拆分后的几倍。所以，对于并发量大的系统，选择微服务拆分是颇有必要的。
单一职责原则： 每一个微服务只需关心本身的业务规则，确保职责单一，避免职责交叉，耦合度太高将会形成代码修改重合，不利于后期维护。
服务自治原则：每一个微服务的开发，必须拥有开发、测试、运维、部署等整个过程，而且拥有本身独立的数据库等，能够彻底把其看成一个单独的项目来作，而不牵扯到其余无关业务。
轻量级通讯原则：微服务间需经过轻量级通讯机制进行交互。首先是体量较轻，其次是须要支持跨平台、跨语言的通讯协议，再次是须要具有操做性强、易于测试等能力，如：REST通讯协议。
接口明确原则：明确接口要实现的内容，避免接口依赖，如A接口的改动会致使B接口的改动。
持续演进原则：单体架构向微服务架构拆分过程当中，没法作到一蹴而就，刚开始不建议拆分过小，过分拆分将会带来架构复杂度的急剧升高，开发、测试、运维等环节很难快速适应，将会致使故障率大幅增长，可用性下降，非必要状况，应逐步拆分细化，持续演进，避免微服务数量的瞬间爆炸性增加。
微服务的拆分应遵循上述拆分时机、拆分原则，并选择合适的拆分方法，逐步拆分。在实际拆分过程当中，除了要遵循拆分原则，还要从实际业务领域出发，并结合考虑非业务的因素，好比需求变动的频率、高性能、安全性、团队规模以及技术异构等因素。这些非业务因素对于最终落地也会起到决定性的做用，所以在微服务拆分时须要重点关注。
业务领域拆分
基于领域模型，围绕业务界限上下文边界，将同类业务划归为一个微服务，按单一职责原则、功能完整性进行微服务的拆分。
需求变化频率
须要识别业务需求的变更频率，考虑业务变化频率与相关度，将业务需求变更较高和功能相对稳定的业务进一步分离拆分。
由于需求的常常性变更必然会致使代码的频繁修改和版本发布，这种拆分能够有效下降频繁发布版本的业务对不须要常常发布版本的业务的影响。
服务性能要求
须要识别性能压力较大的业务。由于对性能指标要求高的业务在资源需求上会比其余业务的高，这样可能会拖累其余业务，也会形成资源无谓的浪费。为了下降对系统总体性能和资源要求的影响，咱们将对性能方面有较高要求的业务与对性能要求不高的业务进一步拆分。
组织架构和团队规模
除非有意识地优化组织架构，不然微服务的拆分应尽可能避免对组织架构和团队的调整，避免因为功能的从新划分，而增长大量且没必要要的团队之间的沟通成本。
在进行微服务拆分和组建项目团队时，应尽可能将沟通边界控制在团队内。
安全边界
对于有特殊安全要求的业务，应独立出来，避免因不一样的安全要求，而带来没必要要的成本，或带来泄密的风险。
技术异构
虽然都是在同一个业务领域内，但因为各类条件的限制，在技术实现时可能会存在较大的差别（存在技术异构的问题）。
大部分都是采用Java语言实现，但因为业务场景或者技术条件的限制，有的可能须要采用Go语言实现，甚至有的采用大数据技术架构。
对应这些存在技术异构的业务功能，能够考虑按照技术栈的边界进一步拆分。
- END -
往期回顾
点一下在看再走吧
本文分享自微信公众号 - 互联网后端架构（fullstack888）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。