微服务划分原则

确切地说，服务中⼼的划分原则更多的是架构设计经验总结，我们很难对⼀些具体的问题给⼀个精确的量化指标，但有⼀点，我很反对现在微服务中的LOC（Line Of Code）这种指标，即⽤代码的⾏数来衡量⼀个微服务落地的标准。架构本来就是⼀个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各⽅⾯进⾏平衡，以最⾼效地解决主要问题。我认为这也是⼀名优秀架构师的必备特质，偏执地追求⼀个维度的完美肯定会在其他⽅⾯付出代价。从服务中⼼设计来看，⼀定要兼顾三个⽅⾯的需求，如图所⽰：

如果不能兼得，就抓住需要解决的主要⽭盾。共享服务中⼼的架构⽬的是通过业务拆分来降低系统的复杂性；通过服务共享来提供可重⽤性；通过服务化来达到业务⽀持的敏捷性；通过统⼀的数据架构来消除数据交互的屏障。所以，所有的原则和⽅法都是为了这些⽬标服务的，“以终为始”再来看服务中⼼建设的原则和⽅法就会明确很多。

从设计层⾯来看，主要是要遵循⾯向对象的分析和设计的⽅法，即业务和系统建模遵循⾯向对象的基本原则，这些是多年软件⼯程学的沉淀，服务化不是开创⼀套新的设计⽅法，⽽是⼀个指路的明灯。从运营层⾯来看，服务中⼼应该是⼀个完整的业务模型，要有数据运营和业务整合的价值，前⾯在介绍淘宝的服务中⼼时，⼀直在强调服务中⼼的发展变化性和可运营性，⽐如淘宝的商品中⼼，绝对不只是简单的商品增删改查的服务接⼝，⽽是建⽴⼀个全球最⼤的商品库，同时提供该商品库的管理运营的⽅法和配套⼯具服务。当然淘宝的商品中⼼建⽴成这样是淘宝的电商业务决定的，并不意味着其他业务系统也要按这样的标准去建⽴⾃⼰的商品中⼼，⼀切要根据业务来做判断。

从⼯程层⾯来看，共享服务的架构是基于分布式架构，分布式架构解决了⼀体化架构在⼤规模应⽤上的问题，但是也引⼊了分布式事务、问题排查等⽅⾯的⼀些难题，所以在规划服务中⼼的时候，⼀定要综合评估业务层对服务中⼼在数据库、业务以及运营⽅⾯的需求和技术上需要的投⼊。不能图⼀时之快把业务拆得⾮常彻底，到最后却不得不⽤很⼤资源投⼊来解决技术上⾯对的问题。

总体上，我们从这三个维度出发来决定服务中⼼的设计和评估。下⾯我们具体介绍在实际项⽬中总结的⼀些基本原则。

1.⾼内聚、低耦合原则

这是系统设计⼀开始就会强调的⼀个基本原则，不过很多时候在实践中我们都在不知不觉中就违背了这个原则。⾼内聚是从服务中⼼的业务界

域来说的，在⼀个服务中⼼内的业务应该是相关性很⾼、依赖性很⾼的；⽽服务中⼼之间应该是业务隔离性⽐较⼤的，即追求尽可能的低耦合。注

意这⾥的业务隔离性是从应⽤场景来说的。

举⼀个例⼦，很多应⽤⼀般都有⼀个会员中⼼，在会员的业务中，会有⽤营销⼿段来保持会员的忠诚度和活跃度，有些⽤户会倾向于把积分独⽴出来建⽴⼀个独⽴的积分中⼼或者放到营销中⼼，有些⽤户会觉得积分直接放在会员中⼼和会员等级挂钩。这⾥如果是你的系统，你会选择怎么做？其实，从之前的项⽬实践来看，⼀般建议⽤户先不要独⽴积分中⼼出来，因为拆分出⼀个积分中⼼，意味着你把会员服务的粒度缩⼩了，但是你的积分业务还不⾜够丰富的时候其实就只剩下增、删、改查的服务需求，对这种服务中⼼，不建议⼀开始就独⽴出来⼀个服务中⼼，还是等积分相关业务发展到⾜够丰富的程度或者对其他业务中⼼影响已经不可忽略

的时候再去拆分出来不迟。

2.数据完整性原则

这个原则其实和上⾯的“⾼内聚、低耦合”⼀脉相承，是把这个思想穿透到数据模型层⾯，因为服务化架构⼀个很重要的业务价值就是数据模型统⼀。这⾥特别想强调⼤数据的思维，不光只是业务逻辑的关键数据，还要考虑到业务的相关性数据；不光是实时在线数据，还要考虑到离线计算的数据。

3.业务可运营性原则

服务中⼼⾸先是从业务出发，单纯的技术层⾯抽象出来的服务框架⼀般不作为⼀个可运营的服务中⼼。单纯的技术型的服务中⼼可以存在，但不是这⾥讨论的重点，我们期望服务中⼼是承载业务逻辑、沉淀业务数据、产⽣业务价值的业务单元。业务的运营性有两个层⾯含义，⼀是指业务本⾝的活⼒，当业务处于快速⽣⻓期，这时候的运营⽬标是满⾜上层的业务需求，这个时候属于沉淀阶段；第⼆个层⾯的运营是指业务内部的孕育出来的创新想法，⽐如淘宝基于⼤数据分析技术⽣⻓起来的商品巡检技术、前台类⽬⾃动聚合推荐技术等。数据模型统⼀之后，可⽤很低成本把⼤数据技术引⼊到服务中⼼的架构中，让数据来源、数据分析、业务⽣产可以⾃然形成闭环。所以能否⽤⼤数据能⼒提升运营⽔平是服务中⼼原则之⼀。

4.渐进性的建设原则

渐进性的建设原则是从降低⻛险和实施难度这个⾓度出发，服务化架构本来就是⼀种敏捷的实践，我们是推荐⼩步快跑的⽅式逐步推进，不是轰轰烈烈地推翻重来。其实在分布式架构体系下，在企业互联⽹架构体系下，试错的成本已经降到⾜够低，渐进式的建设也是服务中⼼建设的⼀个重要原则。

有些⼈会觉得服务中⼼是基础服务，应该是⾮常稳定的，所以⼀开始规划设计的时候应⽤了太多的设计原则，最后从设计上看的确很清晰，但是在实施阶段，可能会碰到拆得过细有延迟太⻓的问题，数据过于分散有数据库性能的问题和分布式事务的问题，服务接⼝过于庞⼤的问题。这些实践证明都不是好的服务化实践。我们推荐服务化从简单开始，只有真实的业务需求才会锤炼出稳定可靠的共享服务。