来自阿里CTO张建锋对阿里中台战略思想与架构实战的深度评价:
本篇讲述了阿里巴巴的技术发展史,同时也是一部 互联网技术架构的实践与发展史。
为一个复杂的、高速发展的业务构建一个技术系统是一个巨大的挑战。阿里巴巴集团主要是以电子商务、支付为业务主体,这类系统都是复杂的商业系统。这个业务又承载于互联网之上,互联网又具有海量的访问请求与数据。这两者的结合,形成了阿里巴巴集团的业务系统的关键特点。
不同于搜索、社交之类的应用系统,电子商务、支付的业务特性决定了其必须有很高的稳定性与可靠性。用户在使用搜索引擎的时候,哪怕丢失了一半的搜索结果,用户可能都没有觉察。但在电子商应用中,每一笔订单、 每-一个状态、每一次支付都不能有丝毫差错。与此同时,像双十一-这种业务高峰时刻,每秒钟就需要处理十万笔以上的订单。高可用、海量、复杂的业务逻辑交织在- -起,是阿里巴巴业务系统的主要挑战。
阿里巴巴集团为了应对这些挑战,在技术上、组织架构上都进行了广泛的实践。
并进一步将此种实践提升至中台这样的概念。
阿里巴巴集团在很多技术方面进行了不断的探索,如数据库的水平扩展、复杂业务系统的结构化与服务化、大型系统的消息处理、关键业务系统的实时调控等。
在数据库层面,阿里巴巴很早就启动了去IOE的项目,本质上是想解决大规模数据的线性可扩展问题,包括存储与访问两个方面。为了实现这个目标,发展了一系列的中间件来支撑这种新的架构。
随着业务的发展,阿里巴巴也面临着复杂业务系统的解耦问题。在互联网行业,需求的迭代速度非常快,通常每周都会有数十个功能更新或增加,并要及时发布。
如何保持业务相对隔离可以让工程师大规模并行工作,传统上有很多解决方案,如SOA、ESB等,但如何在解耦的同时仍能满足互联网海量访问且具有高性能的要求,阿里巴巴集团对传统技术进行了革新,提出了一系列实用的技术方案。系统规模进一步变大之后, 需要解决更多、更复杂的问题,比如在全球进行分布式的部署、999%以上的高可用、容灾等,这对系统的架构与设计提出了更多的挑战。
解决了系统的静态架构之外,很快就会发现,像此类复杂的企业级互联网应用需要在运行时可以全程进行动态感知与管理,不仅要有全部的监控能力,更要根据业务流量进行业务的优雅降级,确保系统高可用等。
我认为本篇将阿里巴巴一系列在工程上的实践进行了系统的总结,也为进一步的系统演进积累了很好的经验,打下了坚实的基础。
第1章阿里巴巴集团中台战略引发的思考
1.1 阿里巴巴共享业务事业部的发展史
1.2 企业信息中心发展的症结
第2章构建业务中台的基共享服务体系
2.1 回归SOA的本质一服务重用
2.2 服务需要不断的业务滋养
2.3 共享服务体系是培育业务创新的土壤
2.4 赋予业务快速创新和试错能力
2.5 为真正发挥大数据威力做好储备
2.6 改变组织阵型会带来组织效能的提升
第3章分布式服务框架的选择3.1 淘宝平台"服务化”历程
3.2 "中心化"与"去中心化"服务框架的对比
3.3 阿里巴巴分布式服务框架HSF
3.4 关于微服务
第4章共享服务中心建设原则
4.1 淘宝的共享服务中心概貌
4.2 什么是服务中心
4.3 服务中心的划分原则
第5章数据拆分实现数据库能力线性扩展
5.1 数据库瓶颈阻碍业务的持续发展
5.2 数据库分库分表的实践
第6章异步化与缓存原则
6.1 业务流程异步化
6.2 数据库事务异步化
6.3 事务与柔性事务
6.4 大促秒杀活动催生缓存技术的高度使用
第7章打造数字化运营能力7.1业务 服务化带来的问题
7.2 鹰眼平台的架构
7.3 埋点和输出日志
7.4 海量日志分布式处理平台
7.5 日志收集控制
7.6 典型业务场景
第8章打造平台稳定性能力
8.1 限流和降级
8.2 流量调度
8.3 业务开关
8.4 容量压测及评估规划
8.5 全链路压测平台
8.6 业务-致性平台
第9章共享服务中心对内和对外的协作共享
9.1 服务化建设野蛮发展带来的问题
9.2 共享服务平台的建设思路
9.3 共享服务平台与业务方协作
9.4 业务中台与前端应用协作
9.5 业务中台绩效考核
9.6 能力开放是构建生态的基础
第10章大型央企互联网转型10.1 项目背景
10.2 项目实施
10.3 客户收益
10.4 笔者感想
10.5 项目后记
11.1 项目背景
11.2 供应链的改造
11.3 基于SCRM的全渠道整合营销