4.3　服务中心的划分原则

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

从服务中心设计来看，一定要兼顾三个方面的需求，如图4-3所示。如果不能兼得，就抓住需要解决的主要矛盾。

图4-3　服务中心建设要考量的三个重要方面

共享服务中心的架构目的是通过业务拆分来降低系统的复杂性；通过服务共享来提供可重用性；通过服务化来达到业务支持的敏捷性；通过统一的数据架构来消除数据交互的屏障。所以，所有的原则和方法都是为了这些目标服务的，“以终为始”再来看服务中心建设的原则和方法就会明确很多。

从设计层面来看，主要是要遵循面向对象的分析和设计的方法，即业务和系统建模遵循面向对象的基本原则，这些是多年软件工程学的沉淀，服务化不是开创一套新的设计方法，而是一个指路的明灯。

从运营层面来看，服务中心应该是一个完整的业务模型，要有数据运营和业务整合的价值，前面在介绍淘宝的服务中心时，一直在强调服务中心的发展变化性和可运营性，比如淘宝的商品中心，绝对不只是简单的商品增删改查的服务接口，而是建立一个全球最大的商品库，同时提供该商品库的管理运营的方法和配套工具服务。当然淘宝的商品中心建立成这样是淘宝的电商业务决定的，并不意味着其他业务系统也要按这样的标准去建立自己的商品中心，一切要根据业务来做判断。

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

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

1.高内聚、低耦合原则

这是系统设计一开始就会强调的一个基本原则，不过很多时候在实践中我们都在不知不觉中就违背了这个原则。高内聚是从服务中心的业务界域来说的，在一个服务中心内的业务应该是相关性很高、依赖性很高的；而服务中心之间应该是业务隔离性比较大的，即追求尽可能的低耦合。注意这里的业务隔离性是从应用场景来说的。

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

2.数据完整性原则

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

3.业务可运营性原则

服务中心首先是从业务出发，单纯的技术层面抽象出来的服务框架一般不作为一个可运营的服务中心。单纯的技术型的服务中心可以存在，但不是这里讨论的重点，我们期望服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。

业务的运营性有两个层面含义，一是指业务本身的活力，当业务处于快速生长期，这时候的运营目标是满足上层的业务需求，这个时候属于沉淀阶段；第二个层面的运营是指业务内部的孕育出来的创新想法，比如淘宝基于大数据分析技术生长起来的商品巡检技术、前台类目自动聚合推荐技术等。数据模型统一之后，可用很低成本把大数据技术引入到服务中心的架构中，让数据来源、数据分析、业务生产可以自然形成闭环。所以能否用大数据能力提升运营水平是服务中心原则之一。

4.渐进性的建设原则

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

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