阿里中台战略
阿里巴巴共享业务事业部从建立、摸索及系列演变，最终变为阿里巴巴业务中台战略中核心组成部分
厚平台、薄应用
2015启动中台战略
中台基础-共享服务体系
SOA的本质 ———— 服务重用
服务需要不断的业务滋养：业务沉淀和持续发展，让服务真正成为可重用的组件。服务最不需要”业务稳定”，需要不停的滋养中，从最初提供单薄的业务功能逐渐成长为企业最宝贵的IT资产，而服务所需的滋养正是来自新业务不断进行服务接入
共享服务体系搭建
业务拆分、基于SOA理念的分布式服务架构
“中心化”与”去中心化”服务架构：
1、服务调用方式的不同带来业务的响应和扩展成本
2、”雪崩”效应束缚了”中心化”服务架构的扩展能力
dubbo、HSF、sofa-rpc
HSF: 采用Netty + Hession数据序列化协议实现服务交互。采用多路复用的TCP长连接方式，在服务提供者和调用者间有多个服务区请求同时会共用一个长连接，即一个连接交替传输不同请求的字节块。它既避免反复建立开销，又避免了连接的等待闲置，还避免了TCP顺序传输中的线头阻塞。Hessian在处理大量用户访问时很有优势，是性能和稳定性同时考虑下最优的序列化协议。容错机制、线性扩展支持
服务路由权重、QPS阀值、安全管控
docker
服务链路跟踪、链路分析、实时业务指标的监控、自动化运维、平台的稳定性(容错)、分布式事务
共享服务中心建设原则
一般来说，服务能力包括两个层次，一个层次是底层PaaS的能力，PaaS层解决大型架构在分布式、可靠性、可用性、容错、监控以及运维层面上的通用需求；第二个层次是业务能力，业务服务能力提供云化的核心业务支撑能力，这层能力建设的好与坏，直接决定了是否能真正支持上层业务到达敏捷、稳定、高效
淘宝的共享服务最初四大服务中心：用户中心(UIC)、商品中心(IC)、交易中心(TC)、店铺中心(SC)。随后根据业务发展越来越多的服务能力沉淀到了共享服务中心，比如后期物流中心、营销中心、数据服务中心等
商品中心：
- 商品描述能力
- 商品的描述数据模型，具体就是类目属性体系、SPU、SKU等
- 商品的存储模型，就是商品数据在数据库中的存储结构
- 对外提供的服务接口，上层业务通过服务接口操作商品数据
- 商品发布能力：对上层业务来说，商品发布能力是一个个性需求比较大的能力。所以发布能力再商品中心是提供通用的发布服务接口和标准的发布工具，业务层自己会根据业务需求提供满足业务需要的发布工具
- 商品管理能力：第一商品数据量大、第二类目总是跟着时代变化
- 商品巡检的能力：商品都是有生命周期的，用户发布的商品如果太长时间没有管理，用户本身也长时间没有登录，那这种非活跃卖家可能本身就不再经营店铺了。要识别这种商品，从活跃商品库中剔除。还有些卖家利用搜索引擎排序规则，为商品加上热门搜索词，严重干扰搜索的准确率，或随意描述商品，这些都需要系统发现并纠正
- 商品数据数据分析的能力
- 商品评价的能力
服务中心：
1、服务中心一定是不断发展的
2、服务中心中的服务形态多样性(大类分为：依赖于接口的服务、依赖于工具的服务、依赖于数据的服务)
3、一个服务中心可以进一步划分(单个服务模块、多个服务模块)
服务中心的划分原则：设计、运营、工程
1、高内聚、低耦合原则
2、数据完整性原则
3、业务可运营原则
4、渐进性的建设原则
数据拆分
数据库是最容易产生性能瓶颈的服务组件
读写分离、水平拆分、分库分表实践(Cobar、TDDL)
数据尽可能水平拆分：比如订单(主要由订单主表、子订单表、订单详细表组成)，可以由两个维度进行。一个是通过订单ID取摸，另一个是通过买家ID的维度进行取摸
数据归档：比如超过3个月的数据归档到专门的归档数据库
尽量减少事务边界：事务边界即是指单个SQL语句在后端数据库上同时执行的数量，事务边界越大，会给系统带来弊端：系统的锁冲突概率越高，系统越难扩展、整体性能越低
发送获取订单请求 – 发送SQL请求(并行扫描/全表扫描) – 获取订单结果 – 结果内存聚合 – 返回订单列表
全表扫描其实在真实的业务场景中很难完全避免，对于在分布式数据层的内存中进行数据量不大的聚合这类的SQL请求，如果不是高并发同时请求的情况下，比如对订单进行复杂的条件检索，就一定会采用全表扫描的方式，但由于调用不频繁，且计算数据量不大，所以整体不会给数据库整体性能造成太大影响。如果是高并发情况下同时请求，为了数据库整体的扩展能力，则需要考虑异构索引手段来避免这种情况产生。对于在内存中进行大数据聚合操作和计算的SQL请求，如果不是大量并发或频繁调用的话，每台性能影响也不会太大，如果很频繁或有并发下，可以考虑采用其他平台来满足这一场景，比如Hadoop这类做大数据量离线分析的产品，如果对请求实时性比较高，可采用如内存数据库或HBase这类平台
异构索引表尽量减低全表扫描频率：
按订单ID取摸很好地满足订单数据平均保存，但买家查看自己订单的场景中，就出现了全表扫描的情况。针对这一场景问题，最常用的是采用异构索引表的方式解决，即采用异步机制将原表内的每一次创建或更新，都换另一个维度保存一份完整的数据表或索引表，本质上就是拿空间换时间。另外在某些场景，获取主业务表的列表时，可能需要依赖此业务表的子业务表信息，比如订单的主、子订单，所以相关子订单和订单明细都保存在同一个数据库中，如果仅仅对主订单做了数据全复制的异构订单列表，就会出现扩库join的问题，所以一般建议采用仅仅做索引表，而不是数据全复制，同时采用两次SQL请求的方式解决出现全表扫描的问题
将多条件频繁查询引入搜索引擎平台
如果在”尽量减少事务边界”与”数据尽可能水平拆分”两个原则间发生冲突，请选择”数据尽可能水平拆分”作为优先考虑原则，因为事务边界的问题相对来说更好解决，无论做全表扫描或是异构索引复制都是可以解决的。而写入或单机容量出现不平衡，出来起来的难度会比较大
82法则，在实际中，我们仅针对那些在80%情况下访问的那20%场景进行如数据异构索引这样的处理，达到这类场景的性能最优化，而对其他80%偶尔出现跨库join、全表扫描的场景，采用最为简单直接的方式往往就是最有效的方式
异步化与缓存原则
异步化与缓存两个技术都与系统性能有很大的关系
业务流程异步化、数据库事务异步化(大事务拆分小事务，降低数据库资源被长时间事务锁占用造成数据库瓶颈)
事务与柔性事务
数据库ACID(原子性、一致性、隔离性、永久性)，基于CAP(一致性、可用性、分区容错性)和在其基础上延伸出的BASE(基本可用、柔性状态、最终一致性)理论，提出了”柔性事务”的概念
互联网应用的最核心需求就是高可用。分布式系统特性决定了柔性事务第二个特征就是最终一致，而采用最终一致，一定会产生柔性状态
传统分布式事务
二阶段提交(准备阶段、提交阶段)。有一个重要的优化，”最末参与者优化”(LPO)，允许两阶段提交协议中有一个参与者不实现准备操作(成为单阶段参与者)。本质上LPO将最后一个参与者的准备操作与提交/放弃操作合并成了一个提交操作
X/OPen组织为基于二阶段协议的分布式事务处理系统提出了标准的系统参考模型(X/OPen事务模型)以及不同组件间与事务协调相关的接口，使不同厂商的产品能够互操作
柔性事务
引入日志和补偿机制，类似传统数据库，柔性事务的原子性主要由日志保证，为避免单点，事务日志是记录在分布式节点上的，数据REDU/UNDO日志一般记录在业务数据库上，可以保证日志和业务操作同时成功/失败。通常柔性事务能通过日志记录找回事务的当前执行状态，并根据状态决定是否重试异常步骤(正向补偿)，还是回滚前序步骤(反向补偿)
在分布式环境下，由于”网络通信危险期”的存在，节点间的消息传递会有成功、失败、不知道成功还是失败三种状态。这也给进行分布式事务处理时提出了更多的考虑点和要求。可靠消息投递就是为了解决这类问题产生的服务平台。根据不知道成功还是失败状态的处理，消息至少投递一次，但可能会投递多次，因此要求消息处理程序必须实现幂等，每种业务场景不同，实现幂等的方法也有所不同，最简单的幂等实现就是根据业务流水号写日志(排重表)
造成数据库性能和吞吐率瓶颈往往是因为强事务带来的资源锁。放弃锁是一个解决问题的思路，但是放弃锁不意味着放弃隔离性。实现事务隔离的方法有很多，实际业务场景可以灵活选择以下几种典型实现方式：1.避免事务进入回滚。2.辅助业务变化明细表(扣减库存时在库存预减明细表中添加一条对应商品的库存预减记录，而无需对原商品表进行库存修改操作，一旦用户支付成功，则真正将商品数据数据表中库存减去)。3.乐观锁(大多基于版本号机制实现)
柔性事务在阿里内部实现
1、消息分布式事务
淘宝平台中被广泛用来解决分布式事务场景的方案就是基于消息分布式事务，通过MQ事务消息功能特性达到分布式事务的最终一致。从本质上说，对比柔性事务解决分布式事务的思路，消息服务在其中扮演了事务日志的职能，对全局事务有一个统一的记录和调度能力；事务的参与者通过对消息订阅关系建立了事务间的关联。在采用消息服务实现分布式事务的常见如果出现异常时，一般采用正向补偿的方式，即不会像传统事务方式出现异常时依次进行回滚，会通过消息的不同重试和人工干预的方式让该事务链路继续朝前执行，而避免出现事务回滚
2、支付宝XTS框架
基于BASE的思想实现的一套类似两阶段提交的分布式事务方案，XTS可同时支持正向和反向补偿
3、阿里AliWare TXC事务服务
无论基于消息分布式事务还是XTS分布式事务框架，都要求开发人员在业务出现异常时，执行实现事务的补偿或回滚。因此设计出新一代分布式事务平台TXC
总结：绝大部分场景下，不需要使用两阶段提交这样低效的方式来解决分布式事务问题。为了充分发挥柔性事务框架性能的优势并实现业务的最终一致性，需要采纳以下配合方案：1.应用程序一定要做幂等实现，特别是对数据库进行数据修改操作时。2.远程模块之间用异步消息来驱动，异步消息还可以起到检查点的作用。两阶段提交的方案可以保证最强的ACID要求，开发者因此不需要仔细考虑到底接受什么级别的ACID；同时两阶段提交的方案开发简单，只需要指定事务边界即可
秒杀大促催生缓存技术高度使用
Tair与Redis都在使用
1、小库存商品秒杀：
负责秒杀场景的商品中心应用实例与满足普通商品正常访问的商品中心应用实例隔离部署，通过服务分组的方式，保持两个运行环境的隔离，避免因为秒杀产生的过大访问流量造成整个商品中心的服务实例均受影响。一定要通过缓存服务器将商品的详细信息(包括库存信息)保存在缓存服务器上，商品详情页和购买页所有有关商品的信息均通过缓存服务器获取
商品库存的乐观锁。避免商品出现超卖的问题，核心技术是利用数据库的事务锁机制，即不允许同一商品的库存记录在同一时间被不同的两个数据库事务修改。由于用户进行商品下单操作中，会进行一系列业务逻辑判断与操作，对于商品库存信息这一热点数据，如果采用数据库悲观锁，会给订单处理带来很大的性能阻塞，所以会采用乐观锁的方式实现库存操作。实现方式也很简单，就是最后执行库存扣减操作时，将事务开始获取的库存数量带入到SQL语句中与目前数据库记录的库存数量进行判断，如果数量相等则这条更新库存语句成功执行，如果不相等则放弃该条执行，可采用重试机制重新执行该事务，避免超卖的发生
2、大库存商品大促：
如果按小库存秒杀方案减库存，在库存信息和事务开始没有变化时才进行库存更新，否则进行重试，会导致用户长时间订单创建等待，还可能出现后点击创建订单的用户提前下单成功。为解决这一场景，需要进一步发挥缓存的作用，将之前仅仅作为商品信息浏览的缓存作用，提升到为库存操作提供事务支持的角色
用户下单操作后，会首先为该订单创建一个订单详情记录，只不过在库存成功扣减前，该订单状态是用户不可见的。保存改订单的信息非常重要的作用是当缓存服务器出现故障时，可通过商品数据库中初始缓存的信息和数据库中订单详情信息还原出订单处理的最新状态。在数据库中成功创建订单后，会发送一个库存修改的请求到消息服务器，因为一般的缓存平台还不支持MVCC或数据锁的功能，此时利用消息服务可以让库存修改的请求线性处理，这里可以利用事务消息的方式，保证订单创建成功后，发送消息到消息服务器，当消息的订阅程序从消息服务器取到消息后，这对缓存中的库存数据进行更新处理。当缓存中的库存数据成功更新后，则将之前创建的订单详情状态修改为成功下单，整个订单创建过程结束
打造数字化运营能力
作为服务开发人员，会关心：
1、我的服务在什么链路下被调用，调用场景和数据是否合理
2、目前服务调用趋势怎么样？产生的瞬间峰值是多少？是否达到服务能力的最高水平？
作为业务架构师，会关心：
1、在当前的业务流程设计中，我依赖了哪些应用，哪些服务？
2、整个链路的依赖路径是怎样的？哪些服务对当前业务处理来说是最为核心的？这些依赖如果出错，会有什么影响？
3、一次业务请求处理的时间到底花在了什么地方？是因为某一个服务耗时很长，还是某一个数据库的访问操作耗时最久，需要一个清晰直观的定位
4、我所负责的业务链路中，过去一段时间哪些服务是出错率比较高的，哪些服务是业务链路的处理瓶颈？
阿里的鹰眼、Twitter的Zipkin，这一类平台实现都源于Google Dapper论文，介绍了分布式服务跟踪平台的原理实现
全链路稳定性背后的数字化支撑：阿里巴巴鹰眼技术解密
#研发解决方案介绍#Tracing（鹰眼）
liaokailin/zipkin
埋点与输出日志。实现分布式服务跟踪系统的主要思路是通过服务调用链各服务处理节点生成相应的日志信息，通过同一请求中生成的日志具有同一ID将不同系统或服务孤立的日志串在一起，重组还原出更多有价值的信息。也就是每个请求都会生成一个全局唯一ID，鹰眼平台成为TraceId，这个ID会出现在该请求中所有服务调用、数据库、缓存、消息服务访问时生成的日志中。为了不带来大量代码侵入，将实现服务调用、各种资源的访问所需生成服务链路日志以及TranceId传递等代码(埋点)置入到服务框架层和各种资源的访问驱动层，也就是在中间件层面上统一实现了鹰眼的上下文创建以及日志埋点功能，让调用上下文在中间件的网络请求中传递，同时将调用上下文信息保存在了本地ThreadLocal中，从而实现了鹰眼平台所需的调用上下文和日志信息对于应用开发人员完全透明
海量日志分布式处理平台：日志采集、日志数据处理流程自定义、API方式数据获取
日志收集控制：任何给定进程的消耗和每个进程单位时间的日志采样率成正比，也就是采样率越高，则进程用于日志处理的消耗越高。通过对采样率的调整，可以动态设置针对某一应用实例所产生的日志采样率。在较低采样率和较低传输负载下，可能会导致错过重要事件，而想要较高的采样率就需要接受一定的性能损耗，所以实际使用上，需要结合服务调用频率和业务访问量，调整适合的日志采样率
典型业务场景：服务实时监控、服务调用链路跟踪、服务调用链分析、业务全系排查、业务实时监控、
打造平台稳定性
在整个稳定性体系中，所包含的范围非常广泛，从机房的布线、网络通信、硬件部署、应用架构、数据容灾等方面都与之相关、从共享服务中台的角度，则更多是从应用架构设计和中间件平台的维度对平台的稳定性实现更精细化的管控和保障
限流和降级：接入层是最佳限流点。授权(黑白名单)、限流、降级、调用统计监控
流量调度：分布式服务环境调用链路局部问题会放大到整个链路。单点、局部问题会被放大成面。流量调度的核心是通过秒级获取服务器系统运行指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线等操作，以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影响
业务开关：除了服务降级中需要对代码中static值的修改，还有对应不同版本的兼容，不同时间点走不同的优惠服务等这样的需求，都是采用类似业务开关的方式，通过修改程序中的static值实现业务逻辑的切换
容量压测与评估规划：对生产环境服务压测，可以利用HSF服务框架对服务器路由权重的支持，通过对服务器路由权重逐步增加，导到对路由到某测试服务器的服务请求逐步增加的目的，只需要在控制台设置好HSF服务实例的服务路由权重增长方式、被压测的单机关键指标(CPU利用率、系统整体负载、QPS、响应时间等)到达阀值后立即自动停止压测，以免对生产环境产生影响。一旦系统停止后，就能在平台中查看到该服务实例在系统资源打到阀值时，单机服务实例能提供的最大QPS处理值
全链路压测平台：基础数据抽取、链路与模型构造、链路验证、业务改造、数据平台、流量平台、影子表、中间件改造、安全机制
业务一致性平台：实时业务审计平台
共享服务中心对内对外协作共享
服务的数量和业务覆盖范围越来越大；应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高；服务安全控制层缺乏；开发体验不友好，产品在接入流程，开发使用手册建设差；整体服务体系缺乏一个统一的服务治理层
搭建：
1、确定服务化的对象是API
2、建立共享服务的基础设施，实现API的服务封装
3、服务化实施阶段：分为API as Service、Product as Service、Solution as Service三个阶段
4、增强服务和基础设施实现服务的精细治理