1 出发点：企业IT系统建设普遍面临的问题和处境
很多企业面临的问题和处境：
『烟囱式』系统建设模式。
当业务部门提出业务需求，信息中心部门进行系统集成商的招投标，再进入到需求收集、需求分析、开发、测试、上线的项目周期中。某种程度上，每个新系统的上线都预示着一座新的烟囱矗立而成。这种完全基于业务需求建设系统的方式，已经成为过去20多年企业建设IT系统的标准流程，导致IT系统建设早的企业内部系统烟囱林立。这正是今天很多企业面临互联网转型难的根结所在。
它带来三大弊端：
-
重复功能建设和维护带来的重复投资。因为大量的功能和业务在多个系统中同时存在，单单从开发和运维两个方面成本投入的角度，对于企业来说就是一种很显性的成本和资源浪费。
-
打通『烟囱式』系统间的集成和协作成本高昂。业界早前就提出了SOA的理念，多家厂商推出了ESB产品及解决方案，重点就是来解决此类异构系统之间的交互问题。
-
不利于业务的沉淀和持续发展。在传统IT系统建设模式下，上线的系统就进入了系统维护期，这个时间段实际上是系统对业务需求响应非常不敏感的阶段，一般半年或一年才会进行一次系统的升级。也就是说，系统业务需求响应的能力和企业本身业务发展对系统建设的要求不成比例。如果说过去，业务需求的增长态势还算比较平滑，没有体现出系统的响应能力有多大差距，那么在今天，互联网时代业务需求的增长越来越迅猛，原有系统对业务响应的能力就显得更加捉襟见肘了。
企业信息中心的组织职能只停留在『业务支持』上
各个企业都认可信息技术部门对于企业发展的重要地位，但是，该部门往往不具有与核心部门同等的部门话语权。该问题的核心是，IT信息部门在现有模式下已经被更高的领导层定位成了业务支持部门，是一个花钱的成本中心。
作者认为，造成这种困境的原因是因为IT信息部门的人员不懂业务。作者所说的『懂业务』是指能对业务的下一步发展有着自己的理解和看法，对业务流程如何进一步优化能更好地提升业务，甚至对企业现有的业务提出创新的想法，为企业带来新的业务增长点。
而其根本原因，是因为很多大型企业的IT信息化部门已经存在了20多年，一成不变的就是项目制的系统建设模式，这样建设项目的模式除了带来『烟囱式』建设的一系列弊端，同时使得IT信息化部门一直处于『业务支持』的职能位置，即只为了满足业务部门需求而进行IT系统建设的实施和运维部门。这种模式下， 很多企业的IT信息化部门的员工大多数的工作内容都是项目管理。当一个项目顺利上线验收后，这些员工开始投入到下一个项目的工作中。因此，其结果是，员工增长了项目经验，但并不能在某一专业领域得到了知识和经验的沉淀，其最终结果是IT信息中心的员工很多少能在一个业务领域做足够深入的了解和业务沉淀。
这些问题是如今大多数企业都遇到的问题，阿里巴巴在2008年业务系统的建设模式、组织架构以及遇到的问题，都和大多数企业是一样的。
2 解决之道：共享式业务中台
阿里巴巴电商系统的架构经历了烟囱式架构，到分布式架构，再到共享式架构的转变。
当前的阿里巴巴『厚平台，薄应用』架构形态如下图所示。目前阿里巴巴集团前端超过了25个业务单元，比如淘宝天猫聚划算等，均不是独立地构建在阿里云的云平台之上。在后端阿里云技术平台和前端业务之间有了一个『共享业务事业部』，将阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含额用户中心、商品中心、交易中心、评价等十几个中心。共享业务事业部正是『厚平台』的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。
3 价值：摆脱『烟囱式』系统建设带来的各种困境
共享服务架构的建设，使得阿里巴巴摆脱了因为『烟囱式』系统建设方式带来的各种问题，最终成为阿里巴巴业务中台战略的核心组成。
1. 回归 SOA 的本质 - 服务重用
作者非常认可SOA的理念，但是SOA在落地时候变了味。具体表现在：
-
SOA 在企业落地时，无一例外都是通过ESB（企业服务总线），使各个系统以服务封装或服务调用方式实现了不同系统见的业务交互。其本质上，仅仅是采用了服务的形态，以技术的视角选择了一个科学的方式实现了系统互联。
-
这对于企业中业务服务的持续发展和沉淀没有任何帮助，根本就没有实现SOA理念最核心的架构：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。
-
SOA 理念的提出，原本是真正为企业的IT系统建设指出一条光明大道，真正提现SOA核心价值的正是这些服务，只有这些服务在业务发展过程中得到持续的演进、功能逐步完善和增强，最终变为企业在该领域最为专业的IT资产时，才能真正打到SOA中所描述的业务的快速响应，更好地支持业务创新。但实际上，SOA的项目都沦为了实现多个系统之间的集成。
而阿里巴巴已经将集团20多个核心业务中的公共的、通用的业务以服务的形式沉淀到了共享业务事业部。整个集团的核心业务能力均建立在这样一套共享服务体系之上，使得SOA架构的核心价值 - 服务用重用 得以实现和发挥。
2. 服务被业务不断滋养
要解决的问题：『烟囱式』系统方式以及SOA『项目制』的建设方式，导致了业务得不到沉淀和持续发展，从而造成服务不能真正成为可重用的组件，为业务的快速响应、支持业务快速创新带来业务价值。
原因：SOA项目是一种集成项目建设的方式，就很容易造成服务提供者面对业务提出更多要求时，考核指标、工作回报都不能得到很好提现，服务提供者主观上没有太大的积极性来满足新的业务需求；再加上如果当初服务设计的功能扩展性和业务前瞻性不足，导致有心无力满足新的需求，结果是这些服务无法再进行功能扩展，成为企业『业务稳定』运行的『服务』。
结果：如果一个服务一味追求功能的不变，一定程度上就是固步自封，这样的做法是在逼着其它系统去建设同样的轮子。当越来越多的系统都建设自己轮子的时候，之前的服务就慢慢少有人问津，它就会逐步退出历史舞台了。
解决之道：服务不需要『业务稳定』，而是需要不停的滋养。只有在滋养中才能从最初仅提供单薄业务功能的服务，逐步成长为企业最宝贵的IT资产，而服务所需的滋养正式来自新的业务不断进行服务的接入。
做法：阿里巴巴共享事业部的『服务』『滋养』『稳定』这三大价值定位，定义了共享服务的真谛。服务能力的沉淀和体现的业务价值是完全成正比的，需要一个长期、持续的过程。企业不能再走入『项目制』实施SOA项目的误区，而是需要更多一些耐心，在接下来的业务发展过程中打造这些服务。这就要求新的业务必须接入这些已经产生的服务，为这些服务能够变得更加专业和稳定带来急需的需求养分。
3 共享服务体系是创新的土壤，业务中台赋予业务快速创新和试错能力
需求：今天所有的企业，应该在互联网时代具备一种跟互联网公司一样的业务快速创新，甚至是试错的能力。
问题：传统企业中，一定是需要申报预算和立项来落实业务创新的想法，传统『烟囱式』的系统建设方式对项目投入的资金和资源自然不会少。在申请大量资金而且项目还有失败的可能性的情况下，有业务创新想法的人在考虑到失败带来的影响时，一定会权衡其中的利弊，大多数人会选择退缩。
解决之道：利用业务中台为业务创新提供一个坚实的中台。通过中台资源的优势，支撑业务的快速创新和业务试错。有了业务中台后，利用原本就建设好了的专业服务，使得企业在投入少的情况，快速收获了更多的结果。
4 为真正发挥大数据威力做好储备
需求：大数据会是展现企业核心竞争力并发掘新的商业模式的推动器。
问题：很多企业的大数据项目并未带来期望的成效，因为有以下两个主要问题：
-
数据分布广、格式不统一、不标准。这还得归咎于『烟囱式』系统建设方式，使得相关业务领域的数据分布在不同的系统中。这位大数据平台项目初期数据的抽取和同步带来了很多的复杂工作。
-
缺少具有能基于数据进行业务建模的专家。大数据平台的威力，要有人知道怎么利用它来发挥出真正的业务价值，这是很多大数据平台难于落地或真正让企业感受到器价值的最大障碍。
解决之道：共享服务体系是解决这两大问题的不二法门。
-
一方面，通过业务中台，在各相关领域在业务和数据层做了很好的融合。
-
另一方面，共享服务体系能帮助企业信息部门培育出懂业务的专家，这些人有技术功底，随着业务能力提升，他们能成为能发挥大数据平台价值的『数据科学家』。
5 改变组织阵型会带来组织效能的提升
问题：大多数企业的信息中心部门的职能还停留在『业务支持』的程度，是为企业的业务部门提供IT系统支持的组织。
解决之道：有了业务中台，整个共享服务体系中的这些服务中心进行持续的『运营』的职能势必会落在企业信息中心这个部门。这时，可以将信息中心部门的员工按照服务中心的方式进行人员组织的重新编排，让员工在各自擅长和感兴趣的业务领域持续发展。
结果：让信息中心部门从之前在企业中『业务支持』的组织职能，转变为基于企业核心业务和数据进行运营的团队，逐步培养出企业最稀缺的『既精通业务，又熟悉技术』的复合型人才。
4 建设：分布式框架选择
2007年，淘宝已经拥有超过500人的技术团队规模，整个淘宝网站是一个几百兆字节的WAR包，大小功能模块超过200个。
这带来了以下几个问题：
-
项目团队间协同成本高，业务响应越来越慢。
-
应用复杂度已超出人的认知。
-
错误难于隔离。
-
数据库连接能力很难扩展。
-
应用扩展成本高。
解决以上问题的根本在于业务的拆分。结果，在应用部署形态上，由之前一个几百兆字节大小的WAR包部署模式改造成为上百个WAR包独立部署的服务化架构。
好处：
-
降低不同模块开发团队间的协同成本，业务响应更加迅速。
-
大大降低系统间的耦合度以及整体复杂度，各个开发团队可专注与各自的业务模块。
-
避免了个别模块的错误给整体带来影响。
-
业务拆分后解放了对单数据库集群连接数的能力依赖。每一个核心服务中心都拥有各自独立的数据库，缓解了之前的数据库连接瓶颈。
-
做到针对性的业务能力扩容，减少不必要的资源浪费。
技术选型：SOA ESB 架构还是分布式架构？
SOA 主要特征：
-
面向服务的分布式计算
-
服务间松散耦合
-
支持服务的组装
-
服务注册和自动发现
-
以服务契约方式定义服务交互方式
传统SOA ESB的服务调用方式的问题：
-
每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。
-
从逻辑上看，所有服务调用都通过服务总线，服务总线的访问和计算压力会非常大。
-
企业所有的业务都通过服务总线方式，则服务调用量比较大，所需的网络带宽要求非常高，企业需要在网络上投入更大的成本。
-
基于企业总线构建的服务体系，会成为企业服务调度的核心枢纽，这可能会导致『雪崩』效应，给整个平台带来灾难性后果。
阿里巴巴分布式服务框架 HSF：
主要组件：
-
服务提供者。为了保障服务高可用，一般都是集群部署。每个HSF应用均是以War包的形式存在，运行在Tomcat容器中。在Tomcat 容器层，已经集成了HSF服务框架对服务提供者或服务调用者进行配置服务器发现、服务注册、订阅、失败转移等功能。目前，淘宝内部大部分应用的部署方式，还是一个虚拟机运行一个tomcat容器，每个tomcat运行一个服务应用。
-
服务调用者。这是服务的消费者，大多数也是以WAR应用包的方式运行在 tomcat 容器中。
-
地址服务器。由 Nginix 实现。
-
配置服务器。负责记录所有服务发布和服务订阅信息，并将服务相关信息推送到服务节点上。
-
Diamond 服务器。本质上也是一个通用的统一配置管理服务。
5 建设：共享服务中心建设原则
关于『服务中心』的概念：
-
服务中心一定是不断发展的。业务架构是能反应业务变化的，服务中心作为共享架构的核心元素一定也会提现出这种变化。
-
服务中心的服务形态的多样性。有人理解的服务中心是狭义的接口服务，这比较片面化，虽然接口是服务最重要的形式。服务中心提供的服务能力，可以分为三类：
-
依赖于接口的服务
-
依赖于工具的服务
-
依赖于数据的服务
-
服务中心设计的一些原则：
-
高内聚、低耦合。
-
数据完整性原则。
-
业务可运营行原则。服务中心应该是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。
-
渐进性的建设原则。服务化架构本来就是一种敏捷的实践，推荐小步快跑的方式逐步推进。
6 实现：数据拆分实现数据库线性能力扩展
需求：
服务中心需要能很好地支撑将来任何业务场景的访问性能的要求，而数据库是最容易产生性能瓶颈的服务组件。
几个步骤：
淘宝的做法是基于数据库分库分表的方式，利用分布式数据库平台解决数据库瓶颈问题。
第一步：数据库的读写分离。拓展了数据库读读的处理能力，整体上也提高了数据库的读写能力，但这样的架构在主数据库上的写能力依然没法扩展。
第二步：当出现单个表的数据量很大的情况，则需要采用水平分区的方式对数据进行拆分，即将同一个表中的不同数据拆分到不同的数据库中。比如，对用户数据按照用户 ID 进行 has 取模的方式实现用户数据平均分到 8个数据库中，确保了单个数据库中保存的数据量在单机数据库能提供良好读写性能的范围内。
第三步：在2008年，阿里巴巴内部开始了分布式数据库的研发。
一些最佳实践：
-
开发了分布式数据层框架TDDL。针对分库分表场景，提供了对各种业务场景的支持更加完善，开发人员体验更加友好，管控能力大幅提升。
-
数据尽可能平均拆分。在分库分表场景下，最重要的一个原则就是被拆分的数据尽可能的平均拆分到后端的数据库中。如果拆分不平均，还会产生数据访问热点，这就同样存在热点数据因为增长过快而面临数据单表数据过大的问题。
-
尽量减少事务边界。
-
异构索引表尽量降低全表扫描概率。一个解决思路是『拿空间换时间』。
-
将多条件频繁查询引入搜索引擎平台。
-
简单就是美。
7 实现：使用异步化与缓存
业务流程异步化
问题：淘宝的订单创建流程需要调用超过200个服务。如果是全线性调用，即使每个服务的响应时间都在20ms之内，那么全部流程也会超过4秒。这对客户来说难以接受。
解决之道：流程异步化。
总结：在分布式服务架构中，通过业务流程异步化，即通过服务异步调用的方式让业务流程中业务逻辑上允许同步执行的服务同时被调用，从而解决了大量远程服务线性调用带来的性能问题。
2 大促秒杀活动催生缓存技术的高度使用
需求：平台如何完美支持大促秒杀场景是一个体系工作，牵涉到应用架构设计的合理、平台稳定性报障、极强的系统扩展能力等多个方面。其中，利用缓存技术实现商品数据的高性能读取，以满足秒杀活动中对商品数据访问的同时不会出现商品超卖等严重的业务问题。下图是商品秒杀架构示意图：
示例：在小库存商品秒杀场景下的示例：
流程：
-
1.1：用户通过商品详情页查看商品时，获取的商品基本信息以及库存是从缓存Tair 中获取的。
-
2.1：当用户查看到当前商品还有可卖库存时，进入到 Buy 商品下单界面，此时商品的相关信息依然还是从缓存获取。
-
3.1： 用户在进行下单操作后，此时就通过数据库本机事务操作的方式，通过商品中心的服务（IC）获取到当前商品的真实库存信息。
-
3.2： 当此时获取的库存大于 0 时，则进行库存的扣减操作。
-
3.3： 通过该步骤更新了商品数据库中的库存信息
-
3.4： 在3.3 步骤的同时，也更新缓存中该商品的库存信息。此时，前方用户再访问该商品信息时，看到的就是已经更新了的信息。
7 服务治理：通过鹰眼平台跟踪服务调用链
业务服务化带来的问题：
分布式服务体系建设后，整个淘宝平台变成了一个复杂无比的服务交互链路网。这会带来很多问题，比如：
-
如何对每天发生的几千亿次服务调用出现报错时快速定位问题。
-
如何实时监控到服务的运行状态是否正常。
-
如何给运营团队关注的业务指标提供实施呈现以便他们进行实时的精准营销。
解决之道：
-
对于分布式服务调用跟踪方面的需要，阿里打造了针对分布式服务调用链的跟踪平台 - 鹰眼。它通过一套分布式日志平台实现对服务调用链路的跟踪，基于阿里巴巴海量日志分布式处理平台 TLog。
-
它是JStorm 流式计算引擎，对应用集群接收到的日志进行内容的解析拆分，按照不同业务场景的需求将拆分后的数据保存到不同的存储系统中。
-
其原理是通过服务调用链各服务处理节点生成相应的日志信息，通过同一请求中生成的日志具有同一个ID将不同系统或服务孤立的日志串在一起，重组还原出更多有价值的信息。
-
价值：
-
服务实时监控。通过在应用的不同层次进行埋点日志的打印，鹰眼平台可以实现从应用入口、服务层、服务方法层的精细管控。结合监控报警能力，鹰眼可以实现异常报警。
-
服务调用链跟踪：鹰眼可以帮助运维人员在Web界面上清晰还原出每一次业务请求所产生的服务链调用情况。该功能着重于对业务链路数据的实时监控。这既能帮助快速定位问题，还能对应用的优化分析带来帮助。正是有了调用链跟踪功能，阿里巴巴的服务化平台从一个无服务管控状态变成为一个具备真正可管可控的状态，形成了完善的服务化管控体系。
-
服务调用链分析。这是针对业务架构诉求的服务调用链分析功能，让业务架构师对于自己设计的业务链路在实际生产中的运行状况有一个直观的了解。该功能着重于对服务调用数据按照不同维度进行离线的统计和分析。利用分析出的数据，可以更针对性地优化业务链路流程，或提升某些服务的服务质量，给用户提供更好的用户体验。
-
业务全息排查：这本质上是将服务链路信息与业务事件进行了集成，将业务事件通过服务调用链的 traceID&rcpID 进行双向关联。
-
业务实时监控：将发生的业务指标变化在秒级就体现在业务大屏上。有了这样的业务实时大屏，给市场运营人员提供有价值的参考数据，真正对企业的运营提供了精准有效的数据支持。
8 服务治理：通过多种措施保证平台稳定性
1. 限流与降级：
-
阿里巴巴的 Sentinel 平台提供了限流和降级功能。它为整个服务化体系的稳定运行行使着警戒任务，是对资源调用的控制平台，主要涵盖了授权、限流、降级、调用统计监控四大功能模块。
-
限流：其作用在当过载的时候掐掉一些流量，让系统有能力集中资源以较快的速度处理平台处理范围内的业务请求。
-
首先需要采用压力测试的方法对系统进行压测。阿里巴巴开发了线上压测巩固，来获取该服务所能提供的最大处理能力。
-
然后对服务资源的使用情况进行监控。在实际中，都会通过服务的QPS作为限流的关键判断指标。
-
将资源监控的指标与之前获得的服务处理上线进行比较，如果超过服务处理上限，则启动限流。
-
阿里巴巴是通过在 Nginx 上实现的扩展组件 TMD 实现了接入层限流。
-
降级：判断依赖的资源的响应情况，当依赖的资源响应时间过长时进行自动降级，并在指定的时间后自动恢复调用。
-
监控：提供了全面的运行状态监控，实时监控资源的调用情况，包括QPS，响应时间，限流降级等信息。
2.流量调度：
- 目标：针对分布式服务系统的流量调度平台，用于屏蔽所有机器的软硬件差异，根据机器的实时服务能力来分配机器的实时流量。
- 原理：通过秒级获取服务器系统运行指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线等操作，以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影响。
3.业务开关：
-
Switch 是一个轻量级的开关集成框架，用来集中管理集群各应用的开关，统一业务操作业务开关的方式和API，方便进行集中化管理。
-
4.容量压测及评估规划：
-
需求：要知道一个平台的处理能力是否能支持大促活动的访问量，最常见的方式是对平台进行性能测试。
-
容量压测：将线上真实的流量引流到压测目标服务器上，来获取单机QPS能力。
-
容量规划：利用服务的单机QPS数据，结合对各种服务器机型处理能力的差异化分析，对到底需要部署多少线上服务器资源才能满足大促活动有更准确的预测。
5.全链路压测：
- 这是阿里全系统每个环境都参与的双11实战演习，主要对零点峰值流量进行评估，以及网站承压能力进行测试。
6.业务一致性平台：
-
平台还是偶尔会出现业务与数据不一致的问题。
-
阿里巴巴利用BCP 平台来解决该问题。
-
9 服务治理：治理平台 - 共享服务平台
服务化野蛮发展带来的问题：
-
服务的数量和业务覆盖范围越来越大。
-
应用和业务架构越分越细，服务越来越专业化，跨领理解的成本越来越高。
-
服务安全控制层缺乏。
-
开发体验很不友好，产品在接入流程，开发使用手册建设非常之差。
-
整体服务体系缺乏一个统一的服务治理层。
上面这些问题，可归结为一个问题，服务治理。针对这些问题，集团的共享服务平台 SPAS 应运而生，其目标是对阿里巴巴集团的服务更好地进行治理和共享。
主要功能：
-
服务的描述元数据
-
服务注册与发现机制
-
服务的访问控制与安全策略
-
应用服务 portal
-
服务依赖与运维管理
-
服务SLA协议
-
服务消费者的管理与支持
-
服务化辅助工具支持
-
服务调用分析与报表
-
服务成本核算与服务能力变现
-
文档与开发工具支持
SPAS 也是一个协作的平台，是以服务为对象建立的一个在线市场。其中有三个角色：服务共享平台、服务提供者、服务消费者：
三个角色之间的协作方式：
示例：业务中台与前端应用协作：
-
业务中台对前端核心业务的紧密沟通机制。各个服务中心的核心架构师和运营人员会定期参与前端业务方的业务会议或重大项目的研讨会。这样，让业务中台对于前端重要应用的业务发展动向有一个准确及时的了解，从而为业务中台如何更好地支撑这些业务做好准备和服务能力的提升。
-
建立分歧升级机制：因为两方所处岗位和诉求的差别，有时难免对于讲一个业务功能的实现放到业务中台还是在前端应用中实现存在分歧。此时，一般按照业务负责的层级关系依次升级。
-
岗位轮动推动真正换位思考：将业务中台某服务中心的负责人与对口业务的负责人进行岗位对调，让双方在实际工作中更真切地感知到出于不同岗位时对业务的理解和出发点。
-
业务持续沉淀及共建模式：业务中台是一个不断沉淀，不断完善的过程。在进行业务沉淀到中台的过程中，又会出现两种情况：
-
一种是业务中台现有的人员对于要沉淀的业务功能自身就有较强的业务能力，能够很好地完成将业务功能沉淀和融入到业务中台的能力，这是一种业务沉淀的典型方式。
-
另一种则是对于要沉淀到业务中台的业务，业务中台现有人员没有足够的业务理解和能力，此时，就会采取共建的模式，业务中台和前端应用方各自派出人员共同组建一个团队，一起负责该业务功能的实现，以及到中台的能力沉淀。
-
业务中台的考核机制：
-
服务稳定是重中之重。40%。
-
业务创新推动业务发展。25%。
-
服务接入量是衡量服务价值的重要考核。20%。
-
客户满意度促动服务的提升。15%。
谢谢您的阅读，也欢迎关注本公众号：
