服务调用方式的不同带来业务的响应和扩展成本：基于ESB的响应速度慢（因为网络开销大一倍），而要扩展ESB需要承担软硬件的不小投入（比如巨大的授权费）
“雪崩”效应束缚了“中心化”服务框架的扩展能力：不适合互联网企业的根本原因，因为一旦雪崩故障恢复的时间和成本都非常高昂！
阿里巴巴的分布式服务框架HSF
组成部分：服务提供者、服务调用者、地址服务器（Nginx）、配置服务器（服务注册&发现）、Diamond服务器（类似于Zookeeper）
工作原理：服务节点对配置服务器列表的获取、服务的注册发布、服务的订阅、服务规则的推送（如果需要）、服务交互
核心能力：Netty+Hession数据序列化协议实现服务交互（大并发量下的高性能）、容错机制（长连接+秒级感知）、线性扩展（增加服务实例即可扩展服务能力）
关于微服务
阿里巴巴2009年开始的共享服务体系算得上是微服务实践的先驱
从本质上说，微服务是SOA的一种演变后的形态，与SOA的方法和原则没有本质上的差别
微服务与SOA的两点最鲜明差异在于：
传统SOA架构基于“中心化”的ESB构建，而微服务采用的是系统提供服务的方式实现系统间的互通；
传统SOA实施的方式是项目制，而微服务是以做产品的方式让服务在业务发展过程中快速演化；
概念一时爽，问题一堆堆：
微服务化的应用架构的有效服务管控？
分布式事务的难题？
自动化运维和平台稳定性？
微服务的服务设计？=> DDD
PS：微服务不是“免费的午餐”，阿里巴巴2009年开始的共享服务体系建设历程算得上是微服务架构的建设过程。正如钟华老师所说，“罗马不是一天建成的”，企业如果要构建微服务架构体系，也是需要多一份耐心的，通过服务能力在业务发展过程中的不断沉淀，当业务的能力沉淀到一个阶段后，才能真正感受到微服务架构给企业的业务发展带来的长远价值。
Part 4 共享服务中心建设原则服务中心的三个特征
服务中心是伴随业务不断发展的：不做过于超前的设计，也不做过于理想化的架构
服务中心的服务形态多样化：接口、工具、数据...
一个服务中心还可以进一步划分：单个服务模块、多个服务模块...
服务中心的划分原则
更多靠的是架构设计经验总结，很难给出精确的量化指标
一般来说会兼顾3个方面的需求：
设计 => 遵循面向对象的分析和设计方法论
运营 => 服务中心应该是一个完整额业务模型
工程 => 综合评估业务层对服务中心在DB、业务以及运营方面的需求和技术上需要的投入
实际中的一些基本原则：
高内聚、低耦合原则
数据完整性原则：特别强调大数据思维
业务可运营性原则：服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元
渐进性的建设原则：小步快跑，服务化从简单开始！
PS：记得张逸老师在《领域驱动战略设计实践》课程中的开篇提到他向DDD大师Eric Evans提问“如何正确地识别限界上下文？”，结果Eric Evans思考了一会儿，严肃地回答了一句：“By experience！”。这是一个正确的废话，但好像又蛮有道理。对于共享服务中心的建设和划分来说，也同样如此，更多的是依靠架构设计经验的总结，作者也很难给出一些具体问题给出一个精确的量化指标。正如作者所说，架构本来就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各方面进行平衡，以最高效地解决主要问题。
Part 5 数据拆分实现数据库能力线性扩展数据库分库分表的实践
阿里巴巴分布式数据层平台发展演变：Cobar(2006) => TDDL(2008) => DRDS(2014)
数据尽可能平均拆分：需要结合业务数据的结构和业务场景来决定
尽量减少事务边界：“事务边界”指单个SQL语句在后端数据库上同时执行的数量
异构索引表尽量降低全表扫描频率：“拿空间换时间”，阿里巴巴的精卫填海产品
将多条件频繁查询引入搜索引擎平台：采用专业搜索引擎平台提供搜索服务，Lucene、Solr、ElasticSearch
简单就是美：“数据尽可能平均拆分”作为第一优先考虑，82法则