微服务拆分需要考虑的必要因素与坚持原则

创业公司往往因为有限的时间和投入，把系统所有的功能都聚集在一起。随着业务的不断发展，技术人员开始不断地对架构进行解耦和拆分。微服务在最近几年大行其道，很多公司的研发人员都在考虑微服务架构，或者在做微服务的路上，拆分服务是个很热的话题。那么我们应该按照什么原则将现有的业务进行拆分？是否拆分得越细就越好？这里我想谈谈系统拆分需要考虑的因素和坚持的原则。

业务因素

所有技术方面的考虑，包括架构设计和解耦拆分都要考虑业务的需要。在服务拆分时，先从业务角度确定拆分的方案。拆分的边界要充分考虑业务的独立性和专业性，比如搜索类服务、支付类服务、购物车类服务，按服务的业务功能合理地划出拆分边界。避免按团队来定义服务边界，这样做会出现土匪抢地盘的局面，严重破坏团队之间的信任，削弱创新的潜在机会。

投入产出

衡量拆分收益的标准是拆分后的维护成本要低过拆分前的维护成本，也就是说不能因为拆分而带来更大的维护工作。

拆分前的维护成本 - 拆分后的维护成本 ≧ 0

服务的维护成本包括维护该服务所需要耗费的人力、物力和时间。如果一个系统拆分成两个或两个以上，导致所有的资源都加倍，那将会很失败。最好的结果是原来维护服务的同一套人马分成两个部分，因为拆分后服务的复杂性降低，所需要的维护资源显著减少，或者对人员能力的要求大大降低。

组织结构

拆分不仅仅是架构上的调整，也意味着要在组织结构上做出相应的适应性调整，确保拆分后的服务由相对独立的团队负责维护，尽量不要出现在不同服务之间的交叉调用。在这里要坚持的原则是明确每个服务的分工，充分授权而且自给自足的相对独立。切不可出现一个服务由几个不同的团队共同负责的情况，这会造成无人负责或多方争抢，也不利于团队积累相关服务的经验。

系统扩展

拆分的一个重要理由也是最有价值的结果是提高了系统的扩展性。用户对不同的服务有不同的并发和性能方面的要求，因此服务具有不同的扩展性。把具有不同扩展性要求的服务拆分出来分别进行部署，可以降低成本，提高效率。比如电商平台的搜索服务有很多请求，需要特别好的扩展性，应该把搜索服务分离出来，单独考虑其扩展性的需求。这样可以确保不会因为搜索服务突然繁忙而影响其他的服务。也可以根据搜索服务的特点，设计出适合扩展的部署方案。

软件发布

系统中经常变动的部分大约只占20%，剩下的80%基本不变或极少变化，因此软件的发布周期完全不同。我们可以把不变的80%分离出来，单独部署，单独管理。这不仅有利于降低系统的复杂性，精简团队的规模；也有利于在系统发生故障的时候快速定位。如果不做这种拆分，系统在扩展的过程中会浪费很多资源。

信息安全

不同的服务可能对信息安全有不同的要求，因此把需要高度安全的服务拆分出来，进行特别的部署，比如放在防火墙的后面，可以更有针对性地满足信息安全的要求，也可以降低对防火墙等安全设备吞吐量、并发性等方面的要求，降低成本，提高效率。这就像对家里不同房间的安全做不同的安排，确保需要加锁的加锁，减少了对锁的需求量，也减少了开门的麻烦。

总结

所以我们在考虑服务拆分时，要坚持：面向业务、大道至简、分而治之的三个原则，充分考虑业务需求、投入产出、组织结构、系统扩展、软件发布和信息安全等方面。不能只从技术角度出发，把服务切成很多细微的小块，这样做很有可能会出现劳民伤财、欲速而不达的结果。

作者简介：陈斌，现任易宝首席技术官（CTO），一直专注于互联网技术领域的探索和创新，拥有丰富的海外经历、多年的架构经验，深谙移动互联网对传统行业的影响。作为业界最前沿技术的实践者和布道者，致力于推动移动互联网技术引领行业变革，出版过多本书籍，荣登京东新书销售榜第一名，并获中央电视台隆重推介。

（责编／魏伟）

SDCC 2017

11月25日，SDCC 2017“前端技术实战线上峰会”将在CSDN学院以线上直播形式召开。

作为SDCC系列技术峰会的一部分，来自阿里巴巴、苏宁云商、美团点评、饿了么、去哪儿网、白鹭时代等多家企业的前端专家及技术图书作者，将围绕React、AngularJS、Weex前端热门框架在企业中的应用实践，及WebAssembly、MVVM等技术热点展开深入分享，帮助大家解决实际生产中遇到问题。每个演讲时段均设有答疑交流环节，与会者和讲师可零距离互动。

扫描下方二维码，欢迎入群交流。