中台战略思想与架构总结

在2015年年中，马云带领阿里高管，拜访了游戏公司Supercell，以《部落战争》《海岛奇兵》《卡通农场》等游戏知名。

Supercell是一家典型的以小团队模式进行游戏开发的公司，一般来说两个员工，或者5个员工，最多不超过7个员工组成独立的开发团队，称之为Cell（细胞），这也是公司名字Supercell（超级细胞）的由来。

团队自己决定做什么样的产品，然后最快的时间推出产品的公测版，看看游戏是否受用户欢迎。如果用户不欢迎，迅速放弃这个产品，再进行新的尝试，期间几乎没有管理角色的介入。

团队研发的产品失败后，不但不会受到惩罚，甚至会举办庆祝仪式，以庆祝他们从失败中学到了东西。

使用这样的模式使得Supercell公司2015年App畅销排行榜上Top 10的游戏中，Supercell公司开发的游戏占据了榜单的大半江山。

这家游戏公司经过6年的时间将游戏开发过程中公共、通用的游戏开发素材、算法做了很好的沉淀，企业的文化充分鼓励员工进行创新，甚至进行试错。这种强大的业务试错能力是Supercell相比于其他游戏公司最大的差别，也是最核心的竞争力。

所谓“中台”，从字面理解，就是居于前台和后台之间。

阿里公共事业部的演变：

在这里插入图片描述

公共事业部：将阿里集团前端业务中公共、通用的业务沉淀到了这个事业部，这也是“厚平台”的真实体现。

"烟囱式"系统建设模式：

在这里插入图片描述

三套电商体系的架构完全独立，各自应用独立开发和运维。

共享服务体系

共享服务架构的建设使得阿里摆脱了因为“烟囱式”系统建设方式所带来的种种发展桎梏。

SOA（Service-Oriented Architecture，面向服务的架构）的本质、核心价值是服务重用，微服务概念也可以额认为是 SOA 方法经过演变后的另一种呈现方式。

在这里插入图片描述

共用服务支持前端业务的示意图

基于共享服务体系建设的服务中心，原生就将相关业务领域的业务功能和数据做了很好的统一。

今天阿里整个集团有超过2000多个应用，因为各个应用在核心业务层已经通过共享服务体系实现了统一和畅通。

在这里插入图片描述

阿里共享业务事业部的5大价值定位

在这里插入图片描述

共享业务事业部中的“交易中心”对不同业务中交易场景的支持

为了理解中台，一段关于美军作战阵型演变的描述可以作为参考。

美军在二战时，以军为单位作战；

到了越战时，以营为单位作战；

到了中东战争时，以7人或者11人的极小班排去作战，它是今天全世界范围内最灵活的军事组织，也是核心竞争力和打击能力最强的组织。

美军之所以能灵活作战，敢放这么小的团队到前面，是因为有非常强的导弹指挥系统，有非常强大的中后台能力，能支持这样的小团队快速做判断，并且引领整个进攻完成。

美军这样的战斗阵型与阿里如今的“大中台、小前端”战略完全一致，与华为公司提的头狼团队也有异曲同工之妙。

在这里插入图片描述

战场中的中台阵型

新的项目都会基于共享服务体系建设，在项目的建设周期和资源投入上会相比之前带来很大的效率提升。

共享服务体系搭建

构建共享服务体系，必然需要采用一套服务化框架来支撑整个服务体系的运转。

了解服务化框架之前，需要回顾一下 SOA 架构的主要特性：

面向服务的分布式计算
服务间松散耦合
支持服务的组装
服务注册和自动发现
以服务契约方式定义服务交互方式

“中心化”服务框架：以 ESB（企业服务总线）实现 SOA 的方案

“去中心化”服务框架：

需要注意的是：

“中心化”服务框架/架构和“去中心化”服务框架/架构两者并没有优劣之分，这两套架构解决企业的根本诉求是完全不同的。

ESB 模式的“中心化”服务架构的根本诉求：

在ESB这样一个中心服务总线上，提供了诸如对各种技术接口（HTTP、Socket、JMS、JDBC等）的适配接入、数据格式转换、数据裁剪、服务请求路由等功能。

核心目的是让企业客户能基于这些SOA的产品实现系统间的互联互通，同时提高开发集成效率，更快地实现SOA项目的落地。

这一种架构解决的根本诉求是实现异构系统之间的交互。

在这里插入图片描述

传统企业服务总线下的服务交互方式

传统ESB的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。

“去中心化”分布式服务架构解决的问题：

互联网行业中发源的“去中心化”服务框架是由互联网业务的特性决定的，因为用户群体是整个互联网公众，所以系统架构设计人员首先要解决的是系统扩展性的问题，然后才是更快地进行业务响应、更好地支持业务创新等。

“去中心化”的服务交互方式很像IT技术发展早期通过系统间“点对点”打通的方式实现不同系统间的集成，ESB的出现很好地解决了这种系统集成带来的各种弊端，新的“去中心化”服务框架在某种程度上是否是一种倒退？

其实忽略了“去中心化”服务框架一般是运行在企业内部网络环境中（即不会出现跨内外网的服务交互），基于统一的技术接口标准、网络协议、规范进行交互，已使服务的交互效率最高，又因为是以服务契约先行的方式进行了服务接口功能的约定，在某种程度上很好地保障了服务接口和稳定性，所以大大降低了因为服务接口发生变化给服务调用者带来的影响；同时“去中心化”服务框架中辅以多版本支持、负载均衡的支持，从本质上屏蔽掉了之前“点对点”模式下的各种系统稳定性问题。

在这里插入图片描述

分布式服务架构中的服务交互方式

阿里分布式服务框架 HSF（High Speed Framework）:

在这里插入图片描述

HSF服务框架实现服务高可用性原理示意图:

在这里插入图片描述

HSF服务框架对服务能力线性扩展支持:

在这里插入图片描述

微服务

谈到分布式服务框架，最热门的就是“微服务”。

Martin Fowler 对于微服务架构的典型特征有这样的描述：

分布式服务组成的系统
按照业务而不是技术来划分组织
做有生命的产品而不是项目
智能化服务端点与傻瓜式服务编排
自动化运维
系统容错
服务快速演化

从本质上说，“微服务”是SOA的一种演变后的形态，与SOA的方法和原则没有本质上的差别。

相比于虚拟机，容器技术（如 Docker）的主要差异化优势在于：

能够包装
便于移植
为适合用途而随需创建
减少了资源占用空间
缩短了启动时间
具有可重复性
提高了服务器的资源利用率
更好地集成整个开发生态系统（比如持续集成/持续交付生命周期）

但微服务、容器化（Docker）也有它们的问题：

微服务化的应用架构如何进行有效的服务管理。

在分布式服务体系下，服务链路跟踪、实时业务指标的监控等问题，整体服务平台的管控能力问题。
分布式事务难题。

服务化后的应用如何解决随之而来的分布式事务问题，一定需要针对业务的需求在事务一致性和性能间做好平衡。
自动化运维和平台稳定性。原有运维平台和工具是否能高效支撑微服务架构的运维，微服务架构从服务器数量以及服务交互复杂成都都上升到一个新的等级。
微服务的服务设计。微服务中服务边界的一定是从业务的维度，但以什么样的服务颗粒度定义服务？以什么样的数据模型支撑服务能力的线性扩展？如何保持设计出的服务具有很好的业务前瞻性？在高效满足现有业务需求的前提下，还能保证整个服务能力的通用性、扩展能力
原有组织架构是否满足微服务架构持续发展的需要。服务强调持续的演变。

在数据库的理论中，事务具备大家都熟悉的ACID特性，分别如下：

Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。
Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。完整性包括外键约束、应用定义的等约束不会被破坏。
Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

对于这里面的C（一致性），我们以一个非常具体的业务例子，来进行解释。假如我们正在处理一个转账业务，假设是A转给B 30元，在本地事务的支持下，我们的用户看到A+B的总金额，在整个转账前后，以及转账过程中，都是保持不变的。那么这个时候用户认为他看到的数据是一致的，符合业务约束的。

当我们业务变复杂，引入多个数据库和大量微服务时，上述本地事务的一致性，依旧是业务非常关心的。假如一个业务更新操作，跨库或者跨服务时，那么此时业务关心的一致性问题，就变成了分布式事务中的一致性问题。

在单机本地事务中，A+B的总金额在任何时刻去查（以常见的ReadCommitted或ReadRepeatable隔离级别），都是不变的，也就是业务约束一直都保持的这种一致性，我们称之为强一致性。

无法做到强一致

目前在跨库、跨服务的分布式实际应用中，尚未看到有强一致性的方案

我们来看看一致性级别最高的XA事务，是否是强一致的，我们以跨行转账（在这里，我们以跨库更新AB来模拟）作为例子来说明，下面是一个XA事务的时序图：

在这里插入图片描述

在这个时序图中，我们在如图所示的时间点发起查询，那么我们查到的数据，将是A+B+30，不等于A+B，不符合强一致的要求。

共享服务中心建设原则

共享服务中心是中台架构的基石，如何构建稳定可靠、最高效地支撑上层业务快速创新的共享服务能力是中台战略成功落地的关键。

一般来说，服务能力包括两个层次:

一个层次是底层PaaS的能力。

PaaS层解决大型架构在分布式、可靠性、可用性、容错、监控以及运维层面上的通用需求。

第二个层次是业务能力。

业务服务能力提供云化的核心业务支撑能力，这层能力建设的好与坏，直接决定了是否能真正支持上层业务达到敏捷、稳定、高效。

淘宝的共享服务中心包括多个服务中心。最初有四大服务中心：用户中心（UIC）、商品中心（IC）、交易中心（TC）、店铺中心（SC）。随着业务的不断发展，越来越多的服务能力沉淀到了共享服务中心，比如后期的物流中心、营销中心、数据服务中心等。

在这里插入图片描述

淘宝共享服务中心建设历程

服务中心的划分原则更多的是架构设计经验总结，很难对一些具体的问题给一个精确的量化指标。

架构本来就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各方面进行平衡，以最高效地解决主要问题。

共享服务中心的架构目的是：

通过业务拆分来降低系统的复杂性；
通过服务共享来提供可重用性；
通过服务化来达到业务支持的敏捷性；
通过统一的数据架构来消除数据交互的屏障。

可以从三个维度进行共享服务中心的划分：

从设计层面来看：

主要是要遵循面向对象的分析和设计的方法，即业务和系统建模遵循面向对象的基本原则。

从运营层面来看，服务中心应该是一个完整的业务模型，要有数据运营和业务整合的价值。

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

同时可以遵循以下几个原则：

1、高内聚、低耦合

高内聚是从服务中心的业务界域来说的，在一个服务中心内的业务应该是相关性很高、依赖性很高的；而服务中心之间应该是业务隔离性比较大的，即追求尽可能的低耦合。注意这里的业务隔离性是从应用场景来说的。

举一个例子，很多应用一般都有一个会员中心，在会员的业务中，有些用户会倾向于把积分独立出来建立一个独立的积分中心，有些用户会觉得积分直接放在会员中心和会员等级挂钩。

其实，从之前的项目实践来看，一般建议用户先不要独立积分中心出来，因为拆分出一个积分中心，意味着你把会员服务的粒度缩小了，但是你的积分业务还不足够丰富的时候其实就只剩下增、删、改查的服务需求，对这种服务中心，不建议一开始就独立出来一个服务中心，还是等积分相关业务发展到足够丰富的程度或者对其他业务中心影响已经不可忽略的时候再去拆分出来不迟。

2、数据完整性原则

这个原则其实和上面的“高内聚、低耦合”一脉相承，是把这个思想穿透到数据模型层面，因为服务化架构一个很重要的业务价值就是数据模型统一（业务数据、业务相关性数据的统一；在线数据、离线数据的统一等等）。

数据模型统一可以参考以下几个标准：

统一数据架构标准。所引用的大数据引擎、数据开发工具必须统一。
统一基础数据标准。将各业务系统的组织、项目、人员、客户、供应商等高度共享的数据进行统一采集管理与分发，实现基础数据实体 ID 统一，为支撑企业数据资产沉淀做好铺垫。
统一数据资产标准。要求每一个业务板块都按照统一模式去把其数据进行规范化的治理，形成多维模型、指标模型和标签模型等数据资产，并基于模型的应用场景封装，提供标准的查询服务 API。
统一数据分析标准。数据分析师可以直接应用数据资产模型的查询服务，不用进行繁琐的数据准备，保证数据口径的一致性。
统一数据开放标准。面向业务数据消费场景提供统一数据共享工具。

通过以上五个标准，把数据的产生端、数据的生产端、数据的消费端和数据的开放端都统一。

3、业务可运营性原则

单纯的技术型的服务中心可以存在，但不是这里讨论的重点，我们期望服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。

业务的运营性有两个层面含义，

一是指业务本身的活力，当业务处于快速生长期，这时候的运营目标是满足上层的业务需求，这个时候属于沉淀阶段；

第二个层面的运营是指业务内部的孕育出来的创新想法，比如淘宝基于大数据分析技术生长起来的商品巡检技术、前台类目自动聚合推荐技术等。

数据模型统一之后，可用很低成本把大数据技术引入到服务中心的架构中，让数据来源、数据分析、业务生产可以自然形成闭环。所以能否用大数据能力提升运营水平是服务中心原则之一。

4、渐进性的建设原则

渐进性的建设原则是从降低风险和实施难度这个角度出发，服务化架构本来就是一种敏捷的实践，我们是推荐小步快跑的方式逐步推进，不是轰轰烈烈地推翻重来。

同时需要明白，服务中心一定是伴随着业务不断发展变化的，服务形态一定是多样性的。

服务形态多样性是指：

依赖于接口的服务。为上层应用提供编程接口。
依赖于工具的服务。提供定制的配置服务和运营管理类工具
依赖于数据的服务。对大数据的分析能力。

数据拆分实现数据库能力线性扩展

服务中心建设过程中，数据库时最容易产生性能瓶颈的服务组件。

因此需要采取以下方式：

1、数据库的读写分离

读写分离基本原理是让主数据库处理事务性增、改、删（INSERT、UPDATE、DELETE）操作，而从数据库专门负责处理查询（SELECT）操作，在数据库的后台会把事务性操作导致的主数据库中的数据变更同步到集群中的从数据库。

在这里插入图片描述

采用读写分离方式扩展数据库读写能力

2、数据的均衡拆分

读写分离的方式，拓展了数据库对数据读的处理能力，整体上大大提升了数据库的读写能力，但这样的架构在主数据库的额数据写入能力依然没法扩展，一旦数据库写压力比较大时，则对整个平台带来非常大的影响。

因此还要基于数据库分区的思路，当出现单个表的数据量很大的情况，则需要采用水平分区的方式对数据进行拆分，即将同一个表中的不同数据拆分到不同的数据库中。

在这里插入图片描述

用户数据按用户ID取模进行数据均衡拆分

以上两个方式总结起来，就是对数据库的分库分表。

异步化与缓存原则

异步化与缓存两个技术都与系统的性能有很大关系。

由原来单一WAR应用包方式转换成为以共享服务中心为核心的服务化架构后，原本当后台应用接收到来自淘宝页面上的请求时，所有业务逻辑的处理均在同一个运行容器（对应一个JVM）中完成执行，现在则需要在多台服务器间进行多次的服务交互才能完成，每一个服务所修改的数据大多还不在一个数据库中。而且后端的数据库由原来的单一数据库集群（即所有数据均在同一数据库中）按照业务的维度进行了划分，对于原来应用中利用数据库事务特性解决的事务性问题在新的技术体系下给应用开发带来了新的挑战。

异步化

所谓异步化，通俗来说就是：将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。

以还款为例：

在这里插入图片描述

用户还款流程

当一名借款人在该平台上成功借款后，例如借款金额为10万元，共有500人提供了借款，每月月底为还款日。

这样一个大的数据库事务中，每一位借款人进行的还款操作至少会引起500条还款详单（修改详单状态）+ 500次借款人账户表修改（扣款）+ 500名收款人账户表修改（收款），共计1500条数据表的修改，而平台的扣款日往往又都集中在自然月的最后一天，这样就导致在最后一天的最后几个小时，平台接收到密集的还款请求，使得数据库的压力持续高水位（超过95%）运行，用户在进行一次还款操作最长要等到10分钟后才收到系统返回的结果。这个问题的根本原因就是大的数据库事务对数据库的资源占用、表记录长时间被事务锁住带来的数据库请求排队。

在实际的改造方案中，同样基于消息服务提供的异步机制，将整个还款流程进行异步化的处理，在五个主要处理流程间（还款开始、还款计算、还款计划分派、还款计划处理、详单处理）通过消息服务进行下一步业务的触发，执行的步骤如下：

在这里插入图片描述

异步化后的还款实现流程

1）当用户在平台上点击了“还款”按钮后，会生成一条还款启动的消息，发送到消息服务上。

2）“还款开始”程序接收到此消息后，首先执行“找到未还款的计划”，并同时进行“写入还款请求”和发送“还款计划计算消息”到消息服务上。

3）“还款计算”接收到还款计划计算消息后，进行还款总额的计算，并同时进行占款和发起支付流程的消息到消息服务上。

4）“还款计划分派”接收到支付流程的消息后，在给平台的账号转账的同时，发送分期支付消息，这里的消息会针对每一位还款详单中对应的还款人生成还款计划处理消息，这个处理是此次改造方案的核心，将之前在一个事务中处理500次还款处理的操作拆分为500个不同的事务。

5）“还款计划处理”程序在接收到每一个还款详单支付请求的消息后，进行详单查找，计算还款详单，最后同时进行从借款人账户中进行扣占款以及发送还款详单处理的请求消息。

6）最后则是“还款详单”接收到“详单处理”请求的消息后，依次进行给还款人账户加钱，更新详单表信息等操作。

在上面两节中不管是业务流程异步化，还是数据库事务异步化，其实都面临一个如何保证业务事务一致性的问题。面对这个问题目前并没有完美的解决方案。但可以参考 CAP 理论和 Base 理论。

2000年7月，加州大学伯克利分校的Eric Brewer教授在分布式计算原则研讨会议上提出CAP猜想。直到2002年，由麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP理论，从而让CAP理论正式成为分布式计算领域的公认定理。

CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出了BASE理论。

BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency,CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。BASE是指基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）。

“基本可用”是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
“柔性状态”是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是柔性状态的体现。MySQL Replication的异步复制也是一种柔性状态体现。
“最终一致性”是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

缓存技术

对内存的数据操作时间一般是纳秒级，而传统的数据库访问中，一次SSD盘数据访问在几十微秒，一次SATA盘数据访问在几十毫秒，显然处理时间有数量级的差异，所以通过缓存（大部分缓存产品均是基于内存的数据存取实现）让应用具备更好的处理性能和系统吞吐率早已经在应用开发领域广泛使用。

阿里使用的分布式缓存产品 Tair，以及其他优秀的缓存平台如 Redis。

打造数字化运营能力

分布式服务体系建设后，整个淘宝平台变成了一个复杂无比的服务交互链路网，如何对每天发生的几千亿次服务调用出现报错时快速定位问题，如何实时监控到服务的运行状态是否正常，如何给运营团队关注的业务指标提供实时呈现以供他们进行实时的精准营销，这一系列的问题都是应用基于分布式服务体系建设后所面对的问题和诉求，阿里采用分布式日志引擎解决各类技术和业务问题，为今天阿里的数字化运营能力逐步奠定了坚实的平台和数据基础。

在这里插入图片描述

淘宝订单创建服务调用流程示意图

服务之间的调用形成了一个网状关系，在这样的服务调用状况下，假如“库存检查”服务出现了异常，就很难定位这次异常到底是在哪个业务场景中产生的。

作为一个服务开发人员，当他开发的服务投入生产环境后，这个服务是否正常可能直接影响他的绩效考核。

业务架构师主要负责针对业务的需求，通过对服务的组装设计出满足业务需求的服务调用链路，但不能苛求业务架构师对所有参与这次业务请求实现的所有服务都了如指掌，每一个服务都有可能是由不同的团队开发或维护的。

正是因为服务开发人员和业务架构师对于分布式服务调用跟踪方面的需要，阿里中间件团队历时两年多的时间打造了针对分布式服务调用链跟踪平台——“鹰眼”。

在业界，跟淘宝的鹰眼类似的平台有不少，如 Twitter 的 Zipkin，这一类平台的实现都起源于Google Dapper论文（http://research.google.com/pubs/pub36356.html）

如果我们把整个淘宝的分布式服务架构比喻为遍布全国的高速公路网络，每一次的页面请求都可以认为是一辆汽车在这个高速公路网络中穿行，把高速上的每一个收费站比喻为处理请求的服务。那么我们希望查看一辆汽车在高速上的行走轨迹的话，如何实现？最简单的方法就是在这辆车每次经过收费站的时候记录下车辆通过的时间和相关信息，并将这些信息统一发送到服务器端保存起来。

在这里插入图片描述

上面高速路网络和汽车的示例直观地展现了鹰眼平台的核心实现思路，就是通过一套分布式日志平台实现对服务调用链路的跟踪。

鹰眼平台架构

在这里插入图片描述

鹰眼平台架构示意图

首先在每个应用集群的运行环境中，每当应用中进行了远程服务调用、缓存、数据库访问等操作时，都会生成相关的访问日志并保存到应用所在的服务器上。

因为这些本地日志信息仅仅是一次业务请求处理中的部分日志信息，必须要将这些日志信息汇聚到一个地方才能进行全局的统计和查看，所以在每个运行应用所在的服务器上均有一个代理程序，专门负责实时地将生成的日志文件（增量）发送到鹰眼的处理集群上。

鹰眼平台是阿里中间件团队自主研发的JStorm流式计算引擎，对应用集群接收到的日志进行内容的解析拆分，按照不同业务场景的需求将拆分后的数据保存到不同的存储系统中。

对于需要对日志信息进行实时业务统计的需求，会将日志信息保存到HBase中，对接收到的日志信息进行实时的汇总计算，最后给鹰眼服务器提供实时业务统计数据。

实现分布式服务跟踪系统的主要思路是通过服务调用链各服务处理节点生成相应的日志信息，通过同一请求中生成的日志具有同一个ID将不同系统或服务“孤立的”日志串在一起，重组还原出更多有价值的信息。

也就是说，在每一个URL请求都会生成一个全局唯一的ID，鹰眼平台中称为TraceID，这个ID会出现在该请求中所有服务调用、数据库、缓存、消息服务访问时生成的所有日志中。

打造平台稳定性能力

在整个稳定性体系中，所包含的范围非常广泛，从机房的布线、网络通信、硬件部署、应用架构、数据容灾等方面都与之相关。从共享服务中台的角度，则更多的是从应用架构设计和中间件平台的维度对平台的稳定性实现更精细化的管控和保障。

服务就是给其他应用提供服务的，用户怎么调用服务是很难控制的，所以必须从服务自身做好保护，否则可能因为一个小的问题而造成平台级的故障。

限流就是让1000万用户中的100万用户进入后端的处理流程中，将其余900万用户的请求通过队列排队或直接阻挡在平台处理单元之外的方式，保障平台能在处理能力范围内对100万的用户请求进行处理。

平台要具备限流的能力，首先需要对服务部署的能力有一个准确的评估，知道服务实例的部署量到底最大能满足多少业务请求的处理要求。这就需要采用压力测试的方式对系统进行压测。

从实践的角度来看，采用模拟数据进行压力测试的方式并不能准确测量出平台的能力峰值。阿里中间件团队针对这个问题，开发了线上压测工具，能更方便和准确地对服务的容量进行评估，即获取到该服务所能提供的最大处理能力。

在掌握服务的容量后，接下来就是要针对服务资源的使用情况进行监控，通过资源监控的指标与之前所获取的服务处理上限进行比较，如果超过服务处理上限则启动限流。通过CPU、内存、磁盘IO等资源的使用情况来判断系统目前的负载往往是不准确的，因为很多情况下系统本身的处理能力处于什么样的水位跟这些操作系统资源的使用情况没有一个清晰地对应关系，所以在实际中，都会通过服务的QPS作为限流的关键判断指标。

对于平台限流的实现，先从一个典型服务化应用架构的角度来看。用户的请求首先会通过前端接入层（一般采用Nginx）分发到后端的应用集群上，应用集群中主要负责用户的前端交互以及基于业务需求对后端服务集群中的服务进行服务调用。为了避免大促秒杀场景时，远超过系统处理负载上限的访问请求，同时也能很好的兼顾安全问题，通过一些安全策略防止对平台的恶意攻击，所以最优的限流拦截点在前端接入层面，因为让访问洪流进入到系统的下层，对于系统的冲击以及限流的难度都会加大。

阿里是通过在Nginx上实现的扩展组件TMD（Taobao Missile Defense，淘宝导弹防御系统）实现了接入层限流的主要工作，TMD系统可通过域名类限流、cookie限流、黑名单以及一些安全策略等很好地实现了在接入层的限流措施。

TMD系统包含了淘宝技术团队开发的开源模块nginx-http-sysguard，主要用于当访问负载和内存达到一定的阀值之时，会执行相应的动作，比如直接返回503,504或者其他URL请求返回代码，一直等到内存或者负载回到阀值的范围内，站点恢复可用。对于nginx-http-sysguard模块的具体使用，在淘宝开放的Tengine平台上有非常详细的介绍，读者可自行到该站点（http://tengine.taobao.org/document_cn/http_sysguard_cn.html）上学习。

在这里插入图片描述

接入层的最佳限流点

某核心服务依赖了某一个非核心的服务，但发现因为这个非核心服务的处理性能和服务响应时间较长，导致了当前核心服务的处理出现了瓶颈，这时为了保证核心服务的正常处理，就需要在核心服务业务逻辑中对于那个非核心服务的调用暂时停止。这样类似的场景就称为服务降级，即从服务调用者的角度，对所依赖的下游服务采取停止调用的措施，以保证当前服务的处理效率。

要实现服务降级，需要在应用或服务实现中，首先留下可供服务降级进行服务是否调用切换的逻辑。一般在代码中采用static值的方式，作为业务逻辑分支的判断条件，通过对这些static值的修改，实现服务调用逻辑的变化。

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

随着共享服务中心的服务数量不断增加，会有越来越多的内部应用、甚至外部平台要接入这些服务，如何高效实现应用对服务中心的服务对接，是一个分布式服务体系发展到一定阶段后必然要面临的问题。

共享服务平台的建设思路借鉴了SOA和API管理的思想，可以从应用服务治理的角度入手来解决这些问题。

首先需要了解服务和服务化的概念：

服务是一个名词，通常我们说的服务是指服务端暴露出来的一种服务接口，与服务消费者相对应，其代表了服务端一个具体的能力。在SOA架构中的服务被当成一个组件对象，组件就包括服务接口和附加在这个接口上的组件规范：服务策略、限制、描述等，我们把这种服务称为组件化服务。
服务化是一个动词，它更像是一个商业策略，核心是从产品能力转化直接服务客户的能力。这首先是一个理念的转变，产品能力是从产品出发，以产品为核心，就像我们从产品出发来抽象API；服务化是以面向客户的服务为核心，就像我们根据用户的需求来提供最适配用户需求的设计方案，是按需服务（Service On Demand）的体验。服务化的思路就是把产品和服务的中心转移到用户身上，以方便用户使用、降低使用成本为目标。如果服务的用户是开发，我们就要从开发的需求出发；如果服务的用户是运营，我们就要从运营的需求出发。

产品发展的必然结果就是产品服务化，专业分工更细。

践行共享服务最基本的目标就是把普通的服务能力升级为组件化服务并提供良好的服务治理支持。

共享服务平台的构建可以采用如下流程：

1、确定服务化的对象是 API

基于 Interface（而不是 method 或 method 的集合，也不是 Interface 的集合）这个粒度。

2、建立共享服务的基础设施，实现API的服务封装

把现有的API加工成服务组件，打个通俗的比喻就是，我们要对阿里的业务服务能力做一次结构化包装，这个包装让服务能力具有规范的描述，可以与服务治理工具进行交互。具有服务治理的能力，这时候API就成了治理良好的组件服务。

在这里插入图片描述

共享服务平台功能架构

3、服务化实施阶段

服务化实施划分为API as Service、Product as Service、Solution as Service三个阶段。

在这里插入图片描述

服务建设三个阶段

API as Service

这个阶段就是让API具有服务组件的能力。API只是一个接口。API as Service的具体任务就是要把HSF、分布式数据库、消息服务、配置服务、缓存等这些中间件能力API服务化

在这里插入图片描述

对技术平台的能力API化

Product as Service

API as Service解决存量API的服务化问题。Product as Service基于API初级服务的深加工，把API形态的服务利用共享服务平台“封装服务”来暴露让开发者尖叫的服务。

在这里插入图片描述

对API进行服务的封装

用户可以在共享服务平台上利用API服务来开发和部署组合服务。这类组装的服务更面向业务场景，更专业化。对开发者来说，使用会非常友好，对提供者来说，对这类服务的管理可以支持到非常细腻，提升管理服务的效率。

服务组装旨在真正实现服务粒度的敏捷，让服务开发和部署的流程可以非常简单和快速。

在这里插入图片描述

服务组装的流程

经过这个阶段，服务提供者提供的服务就不仅是一堆API的列表，还会包括从业务需求出发梳理出来的一些场景化的服务接口。

Solution as Service

上一个阶段完成后，阿里从基础计算能力到业务能力在共享服务平台的服务市场上都可以找到、发现，让淘宝上的各种业务场景和解决方案在共享服务平台上达到最大程度的复用。比如我们在大陆的三淘市场，可以通过共享服务平台的方式沉淀出针对海外淘宝的解决方案，以后淘宝业务的扩展是基于服务的扩展而不是基于代码的方式进行扩展，这是Soluting as Service的目标。