---

第一章：数据库水平扩展

复杂业务系统的结构化与服务化、解耦
大型系统的消息处理
去IOE：IBM的小型机、Oracle数据库、EMC存储设备
大规模数据的线性可扩展问题，包括存储与访问，方案：开发中间件
全球分布式部署，99.99的高可用、容灾
企业互联网应用运行全程动态感知与管理，提供全部监管能力、且要根据业务流量进行业务的优雅降级，确保系统可用性。
企业架构发展
烟囱式架构（基于单个项目建设、部门间无技术、业务沉淀）-分布式架构-共享式架构
系统的建设要从生产型模型上升到运营型模型
案例
共享服务理念给企业业务发展带来的业务价值*************
案例1：大型国企进行互联网转型尝试与探索
案例2：零售企业如何基于阿里提供的企业级互联网架构重构企业IT架构

第二章：中台战略

构建符合DT- Data technology时代，“大中台，小前台“组织机制和业务机制，即前台一线业务更加敏捷、快速适应市场，而中台将集合整个集团的运营数据能力、产品技术能力，对前台业务形成支撑。居于前台和后台之间。
启发来源：Supercell公司，超级（小）团队尝试快速开发产品，不断跌迭，探索市场和用户喜爱的经营模式。
共享业务事业部框架：

SOA面向服务体系架构Service -Oriented Architecture
落地大多通过搭建企业有ESB-企业服务总线，属于“中心化“服务框架。大多IT企业系统都采用烟囱式架构，各种系统纷繁林立，如采用技术平台、框架、开发语言各异，为实现各种异构系统间交互。ESB-企业服务总线，提供各种技术接口（HTTP、Socket、JMS、XML、WS）的适配接入、数据格式转换、服务请求路由等功能，核心目标让企业客户能力基于SOA产品实现各系统间互联互通，同时提高开发集成效率，更快实现SOA项目落地，但各系统间服务调用每次都必须经过ESB进行服务路由。
主要特征：面向服务的分布式计算、服务间松散耦合、支持服务的组装、服务注册与自动发现，以服务契约方式定义服务交互。
SOA架构的核心-服务重用，服务共享，构建共享服务体系，将相关业务领域的业务功能和数据模型原生在业务层汇聚。
服务需要不断的滋养

业务拆分
可解放对单数据库集群连接数的能力依赖，缓解数据库连接瓶颈，整个平台拆分成多个服务中心以及专门应用模块（应用扩展、拆分），数据层也相应拆分，即每个核心服务和应用都拥有独立的数据库-分布式数据库。
分布式服务框架
去中心化服务器架构，中心化服务架构避免因为‘中心点’带来平台难扩展以及潜在的‘雪崩’影响。

第三章：阿里分布式服务架构HSF（high speed Framework）、早期Dubbo

架构（主要组件）：服务提供者、服务调用者、地址服务器（配置服务器列表信息，Nginx提供服务能力）、配置服务器、Diamond服务器。
架构图：

服务交互：Netty + Hession 数据序列化（比JDK 序列化时间开销缩短20倍）协议实现

微服务架构：分布式服务组成的系统、按业务划分组织、实现产品而不是项目、智能化服务端点与傻瓜式服务编排、自动化运维、系统容错、服务快递演化。
本质上来说是SOA演变后的形态，与SOA方式和原则上没有本质区别。
面临难点：有效服务管控，即分布式服务体系下服务琏的跟踪、分析、实时业务指标的监控等问题；分布式事务管理；自动化运维和平台稳定性；微服务的服务设计（服务边界划分）

第四章：共享服务中心建设原则

共享服务中心是集团中台架构的基石。如何构建稳定可靠、最高效地支撑上层业务快速创新的共享服务能力是中台战略成功落地的关键。
服务能力包括两个层次：底层Paas的能力（解决大型架构在分布式、可靠性
可用性、容错、监控以及运维层面上的通用需求）、业务能力（提供云化的核心业务支撑能力，直接决定了对上层业务达到敏捷、稳定、高效的支撑结果）
淘宝共享服务中心：用户中心、商品中心、交易中心、店铺中心。
用户中心：统一各业务线分散的用户体系，统一用户数据、存储、服务接口;
商品中心：提供6核心服务能力，商品描述能力（商品描述数据模型-类目属性体系、SPU、SKU，商品存储模型、商品服务接口）；商品发布能力；商品管理能力（大数据量管理）；商品巡检能力（在有效生命周期内对商品管理，纠正用户搜索违规行为）；商品数据数据分析；商品评价能力；
交易中心：交易业务领域的服务中心，包括交易相关的服务信息（如交易流程、订单管理、支付、结算等）。
店铺中心：承担卖家店铺管理、装修、生命同期管理以及日常管理等业务。
***什么是服务中心：***1）随着业务不断发展 2）服务形态多样化：依赖于接口的服务、依赖于工具的服务（定制配置服务、运营管理类服务）、依赖于数据的服务（如大数据分析能力）、，接口只是服务的最主要形式，服务不能拘泥于接口形式，如有可提供界面形式的服务能力
3）服务中心可进一步划分，服务中心是根据业务和数据的完整性与独立性来设立，服务中心包含的子模块更多是从系统设计和业务架构层面来考虑。现实中业务通常需要多个子服务模块协作配合实现服务，所以真实的服务中心场景中分为单个服务模块和多个服务模块两种形态，如多个服务模块交易中心服务包括订单服务和购物车服务。
服务中心划分原则：建设考量三方面：设计、运营、工程。设计原则上的平衡，技术、成本、资源、性能、团队等各方面的平衡。
从共享服务中心目标服务层面：通过业务拆分降低系统复杂性;通过服务共享提供可重用性;通过服务化达到业务支持的敏捷性;通过统一的数据架构消除数据交互的屏障;
从设计层面：主要遵循面向对象的分析和设计的方法，即业务和系统建模遵循面向对象的基本原则。
从运营层面：服务中心是一个完整的业务模型，有数据运营和业务整合的价值。
从工程方面：共享服务的架构基于分布式架构，在规划服务中心时需要综合评估业务层对服务中心在数据库、业务以及运营方面的需求和技术上需要的投入。
总结基本原则：
1）高内聚、低耦合原则：服务中心内的服务间是相关性高、依赖性高，而各服务中心间业务隔离性大，即尽可能的低耦合。
2）数据完整性原则
3）业务可运营性原则，期望服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。
4）渐进性的建设原则，服务化从简单开始，通过真实的业务需求锤炼稳定可靠的共享服务。

第五章：数据拆分实现数据库能力线性扩展

5.1数据库瓶颈阻碍业务的持续发展
采用数据垂直分区方式对业务数据进行分区。数据库读写分离扩展数据库对数据读的处理能力。而主库因写入数据量大而产生数据压力时，采取水平分区方式对数据行为拆分，即将同表中的不同数据拆分到不同数据库中，如用户中心用户数据6亿，通过用户ID hash取模方式实现用户数据平均分布。
5.2数据库分库分表的实践
分布式数据库产品DRDS-Distributed Relational Database Service，按量付费，共享实例的DRDS，目前价格为0.2元/小时。

第六章：异步化与缓存原则

好的设计可很好提高分布式应用架构和性能。
6.1 业务流程异步化
6.2 数据库事务异步化
6.2事务与柔性事务。数据库事务核心体现ACID[Atomicity、Consistency、Isolation、Durability]，业务一致性，分布式领域CAP[强一致性Consistency、可用性Availability、网络容错性Partition-tolerance]理论和BASE理论[基本可用性BA、柔性状态Soft State、最终一致性Eventual Consistency]。

第七章：打造平台稳定性能力

7.1 限流和降级，限流一般通过服务的QPS[Queries-per-second]作为限流的关键指标，业务场景有：能力+平台+省份业务限流、黑名单限流、Cookie限流等。降级是指当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。
7.2 流量调试
7.3业务开关
7.4容量压测及评估规划

第八章 共享服务中心对内和对外的协作共享

共享服务平台建设思路：借鉴SOA和API管理的思想。