概貌和说明
1.活性演进的：服务中心一定是不断发展的
2.多样的：服务能力形式多样
（1）依赖于接口的服务(RPC、Web API)
（2）依赖于工具的服务
（3）依赖于数据的服务：对大数据的分析能力
3.可再划分的：服务中心是有划分的，且可以进一步划分的
共享服务的设计考虑和设计原则
一、考虑
不建议使用的标准：LOC(Line of Code)
设计层面：业务和系统建模主要是遵循面向对象的分析和设计方法
运营层面：应该是一个完整的业务模型，要有数据运营和业务整合的价值
工程层面：基于分布式架构的共享服务架构，解决了大规模应用的问题，也引入了分布式事务、问题排查等挑战
不能图一时之快把业务拆的太碎，到最后不得不用很大资源投入来解决技术上面对的问题
二、原则
- 高内聚、低耦合原则
耦合性分类(低――高)
| 耦合程度 (越大越耦合) |
耦合性分类 | 说明 |
|---|---|---|
| 0 | 无直接耦合 | - |
| 1 | 数据耦合 | 指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言的值传递 |
| 2 | 标记耦合 | 指两个模块之间传递的是数据结构，如高级语言中的数组名、记录名、文件名等这些名字即标记，其实传递的是这个数据结构的地址 |
| 3 | 控制耦合 | 指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该控制变量的值有选择地执行块内某一功能 |
| 4 | 公共耦合 | 指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加 |
| 5 | 内容耦合 | 这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部 |
内聚性分类(低――高)
| 内聚程度 (越大越内聚) |
内聚性分类 | 说明 |
|---|---|---|
| 0 | 偶然内聚 | 指一个模块内的各处理元素之间没有任何联系 |
| 1 | 逻辑内聚 | 指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能 |
| 2 | 时间内聚 | 把需要同时执行的动作组合在一起形成的模块为时间内聚模块 |
| 3 | 通信内聚 | 指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据 |
| 4 | 顺序内聚 | 指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一功能元素的输入 |
| 5 | 功能内聚 | 这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。与其他模块的耦合是最弱的 |
遗留问题：如何结合业务演化界定拆分边界和粒度？
遗留问题：如何量化衡量？
数据完整性原则
该原则可以认为是将高内聚低耦合原则穿透到数据模型层面
服务化架构的一个很重要的业务价值就是数据模型的统一
大数据思维：不光是业务逻辑的关键数据，还包括业务的相关性数据；不光是业务实时在线数据，还要考虑到离线计算的数据业务可运营性原则
我们期望服务中心是可运营的，是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。
业务的运营性的两个层面
沉淀阶段：当业务处于快速生长期，这时候的运营目标是满足上层的业务需求
创新阶段：运营业务内部孕育出来的创新想法
* 基于统一的数据模型，低成本的引入大数据技术；让数据来源、数据分析、业务生产形成闭环 *
能否用大数据能力提升运营水平是服务中心原则之一渐进性的建设原则
坑：
拆得过细，有延迟太长的问题
数据过于分散，有数据库性能的问题和分布式事务的问题，服务接口过于庞大的问题
服务化应该从简单开始，用真实的业务需求锤炼出稳定可靠的共享服务。