微服务该如何拆分.docxVIP

微服务该如何拆分 ? 单体应用开发通常是几十人开发一个系统，代码管理时经常会遇到代码提交冲突。微服务架构通过快速迭代可实现开发独立，将系统拆分成不同的微服务，每个微服务对外供应接口，其他依靠服务不用关注具体的实现细节，只需保证接口正确即可。每几个人维护一个服务模块，降低代码冲突的概率，消灭冲突时也可快速处理。 小功能要积累到大版本才能上线 ? 传统模式单次上线的需求通常较多、风险较大，小功能的错误可能会导致大功能无法上线。因而每次上线都会带来较大的工作量。 ? 微服务架构对于快速迭代可带来独立上线的效果。微服务拆分后，在服务接口稳定的情况下，不同的微服务可独立上线。上线的次数增多，单次上线的需求量变小，可随时回滚，风险变小，时间变短，影响面小，从而加快迭代速度。 处理高并发横向扩展问题 ? 互联网时代，业务应用的高并发要求越来越高，单体应用虽然可以通过部署多份承载肯定的并发量，但是会形成资源格外铺张。有的业务需要扩容，例如下单和领取，有的业务不需要扩容，例如注册。假如一起扩容，消耗的资源可能是拆分后的几倍。因而，对于并发量大的系统，选择微服务拆分是很有必要的。 ? 拆分准绳 ? 单一职责准绳： 每个微服务只需关怀本人的业务规章，确保职责单一，避开职责交叉，耦合度过高将会形成代码修改重合，不利于后期维护。 服务自治准绳：每个微服务的开发，必需拥有开发、测试、运维、部署等整个过程，并且拥有本人独立的数据库等，可以完全把其当作一个单独的项目来做，而不牵扯到其他无关业务。 轻量级通信准绳：微服务间需通过轻量级通信机制进行交互。首先是体量较轻，其次是需要支持跨平台、跨言语的通信协议，再次是需要具备操作性强、易于测试等力量，如：REST通信协议。 接口明确准绳：明确接口要实现的内容，避开接口依靠，如A接口的改动会导致B接口的改动。 持续演进准绳：单体架构向微服务架构拆分过程中，无法做到一蹴而就，刚开头不建议拆分太小，过度拆分将会带来架构简单度的急剧上升，开发、测试、运维等环节很难快速顺应，将会导致毛病率大幅添加，可用性降低，非必要情况，应逐渐拆分细化，持续演进，避开微服务数量的霎时爆炸性增长。 拆分方法 微服务的拆分应遵照上述拆分时机、拆分准绳，并选择合适的拆分方法，逐渐拆分。在实际拆分过程中，除了要遵照拆分准绳，还要从实际业务领域动身，并结合考虑非业务的因素，比如需求变更的频率、高功能、平安性、团队规模以及技术异构等因素。这些非业务因素对于最终落地也会起到打算性的作用，因而在微服务拆分时需要重点关注。 业务领域拆分 ? 基于领域模型，围绕业务界限上下文边界，将同类业务划归为一个微服务，按单一职责准绳、功能完整性进行微服务的拆分。 需求变化频率 ? 需要识别业务需求的变动频率，考虑业务变化频率与相关度，将业务需求变动较高和功能相对稳定的业务进一步分别拆分。 ? 由于需求的经常性变动必定会导致代码的频繁修改和版本发布，这种拆分可以有效降低频繁发布版本的业务对不需要经常发布版本的业务的影响。 服务功能要求 ? 需要识别功能压力较大的业务。由于对功能目标要求高的业务在资源需求上会比其他业务的高，这样可能会拖累其他业务，也会形成资源无谓的铺张。为了降低对系统全体功能和资源要求的影响，我们将对功能方面有较高要求的业务与对功能要求不高的业务进一步拆分。 组织架构和团队规模 ? 除非无意识地优化组织架构，否则微服务的拆分应尽量避开对组织架构和团队的调整，避开由于功能的重新划分，而添加大量且不必要的团队之间的沟通成本。 ? 在进行微服务拆分和组建项目团队时，应尽量将沟通边界把握在团队内。 平安边界 ? 对于有特殊平安要求的业务，应独立出来，避开因不同的平安要求，而带来不必要的成本，或带来泄密的风险。 技术异构 ? 虽然都是在同一个业务领域内，但由于各种条件的限制，在技术实现时可能会存在较大的差异（存在技术异构的问题）。 ? 大部分都是接受Java言语实现，但由于业务场景或者技术条件的限制，有的可能需要接受Go言语实现，甚至有的接受大数据技术架构。 ? 对应这些存在技术异构的业务功能，可以考虑依据技术栈的边界进一步拆分。 - END - 往期回顾 ◆ 360°透视：云原生架构及设计准绳 ◆ 4种主流的API架构风格对比 ◆ 实践微服务六年，我获得了这些心得体会 点一下在看再走吧