阿里架构转型史 —— 企业IT架构转型之道笔记

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

从单体应用到分布式服务

2008 年前,淘宝拥有超 500 人的技术团队,整个淘宝网站是一个几百兆的 war 包,功能模块超 200 个,所有数据保存在同一个 Oracle 数据库集群中,业务计划处于每隔几个月翻番的高速发展期。这样一种大团队在多功能模块的单体应用上协作开发的模式逐渐呈现疲态:

  • 版本管理困难,协同成本高,响应时间越来越慢。
  • 当非核心功能设计不合理时,它可能会致使整个系统崩溃。
  • 不能对流量较大的功能模块进行单独扩容,只能选择整体扩容。
  • 数据库集群的连接池有限,峰值时间逼近了官方指定的连接数上限。
  • 应用和业务复杂度超过了单个人的认知边际,业务和功能设计限于瓶颈 —— 没人能全面了解功能模块的边界(它可能会影响整个系统)。

2008 年初,以用户中心作为试点,基于 SOA 理念使服务分治;随后逐步剥离出交易中心、类目中心、商品中心、店铺中心等。经历了 14 个月的改造后,最终形成了上百个 war 包独立部署的服务化架构,同时每一个核心服务中心都由各自独立的数据库,这样就有效避免上述各种问题。

在服务架构上,淘宝没有选择基于 ESB 总线的“中心化”服务架构,而是选择了基于 HSF 的“去中心化”服务架构。这样的架构选择主要基于以下考虑:

  • “烟囱式”应用簇:在企业使用外买或自建系统的模式中,各系统可能采用不同的技术平台、框架、开发语言、通信协议,系统间的通信采用点对点模式。上游的接口调整必须告知下游进行相应的调整。
  • 基于 ESB 总线的“中心化”服务架构:系统间的点对点通信通过 ESB 总线中转,在总线上适配不同通信协议和开发语言、转换数据格式、裁剪数据、路由服务请求、对服务作负载均衡、管控服务等。ESB 总线主要解决的是异构系统间的交互,适合处理企业外部服务。其问题有:通过中心点周转的方式会使 ESB 总线承担过重的压力,访问洪流会冲垮 ESB 服务器(一台宕机的情况下,其余机器要承受过重的负载;一旦击溃,逐台重启的方式也是不理想的,因为访问洪流还是会击溃所有 ESB 服务器尚未就位的总线);单一请求在中心点周转的方式下会比点对点通信多两次 ESB 总线中转,这会影响响应性能。
  • “去中心化”的分布式服务架构:该架构基于同一的技术接口标准、网络协议、规范进行不同系统间的直接通信,不会出现中心点引起的雪崩问题;对比传统的点对点通信模式,“去中心化”服务架构以服务契约先行的方式保障了接口的稳定性,且支持多版本、负载均衡(通过服务注册中心将可用的服务推送给调用方)。

阿里所使用的分布式服务是 HSF服务

从共享业务事业部到中台战略

2003 年,阿里成立淘宝事业部;2008 年,成立天猫事业部,技术支持由淘宝团队提供。2009 年,成立共享业务事业部。最开始,共享业务事业部相对淘宝、天猫等业务部门并没有过多的话语权,它没有充分发挥出沉淀底层服务、避免重复建设的价值。组织结构对业务、技术架构的影响也可见一斑。2010 年,聚划算团购平台的出现是集团层面明确规定淘宝、天猫、1688 必须通过共享业务事业部对接聚划算,共享业务事业部才掌握了足够的业务对话权,逐渐演变成核心业务平台。2015 年,阿里启动“厚平台,薄应用”的中台战略。

共享服务中心建设

淘宝的共享服务中心最初有四个服务中心:UIC 用户中心、IC 商品中心、TC 交易中心、SC 店铺中心。后续又增加了物流中心、营销中心、数据服务中心等。

  • 用户中心:构建了整个阿里巴巴集团统一的用户体系,对外提供统一的服务接口,便于作数据分析,组织独立的运营团队。
  • 商品中心:商品中心在功能上包含商品描述能力、商品发布能力、商品管理能力、商品巡检能力、商品数据分析能力、商品评价能力,对接的用户包含卖家、运营小二,团队成员包含运营、产品、研发、大数据各方面的专家。随着商品中心的发展,后来抽离出了库存中心、评价中心。关于这部分内容,笔者将在电商系统建模中加以分析。
  • 交易中心:初期整合购物车、交易流程、订单管理、支持、结算、营销等业务,后来拆解出营销中心等。
  • 店铺中心:整合了店铺管理、店铺装修、店铺生命周期管理、店铺日常管理等业务,后来发展出第三方店铺装修市场。

服务中心是随着业务不断演化的,淘宝的服务化架构有三个阶段的发展:尝试服务化阶段;全面服务化阶段,以建立共享业务事业部为标志;部分服务中心向平台化转变阶段,这样能更好地支持上层业务的多样化、定制化需求。服务中心需要贴合业务需求,不能做过于超前、过于理想化的架构。服务中心是根据业务和数据的完整性和独立性来设立的,其所包含的子模块更多是从系统设计和业务架构层面来考虑的。服务中心不止提供接口,还可能包含用户操作界面、数据看板等。

服务中心划分原则

共享服务中心建设的核心诉求:

  • 通过业务拆分降低系统的复杂性;
  • 通过服务共享提供服务的可重用性;
  • 通过服务化来达到业务支持的敏捷性;
  • 通过统一的数据架构来打通数据孤岛。

遵从以上目标,”以终为始“,再来看下不同视角下所关切的内容指标:

  • 从设计层面看,服务中心的业务和系统建模需要遵循面向对象的基本原则。
  • 从运营层面看,服务中心应该是一个完整的业务模型,要有数据运营和业务整合的价值,其数据具备完整性、业务要有可运营性。
  • 从工程层面看,共享服务架构基于分布式架构,需要面对分布式事务、问题排查等技术难题,需要综合考虑投入产出比。

钟华总结共享服务架构的四大原则:

  • 高内聚、低耦合:服务中心内的各业务应该保持高相关性、高依赖性;服务中心之间尽可能的隔离,追求低耦合。比如积分中心是划入用户中心,还是营销中心,钟华认为,在积分中心还不成形的情况下,它可以划入用户中心,一来能维持会员服务的粒度,二来避免积分中心只包含增删改查等业务需求。等积分中心足够丰富或对其他业务中心的影响不可忽略时,再拆分出来。
  • 数据完整性:这里的数据包含业务逻辑的关键数据以及相关性数据,也包含在线数据和离线数据,以便实现服务化架构的一个重要业务价值 —— 数据模型统一。
  • 业务可运营:服务中心不单是一个技术产物,更多的是一个承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。其运营价值体现在,快速支撑上层业务需求,这个时候属于沉淀阶段(即业务滋养服务中心);由服务中心内部孕育出创新想法(即服务中心反哺业务)。
  • 渐进式建设:指的是服务中心的设计要贴合业务,避免超前设计,如拆得过细会导致调用链路过长、延时太长,数据过于分散,数据库性能不佳,分布式事务过多,服务接口过于庞大等。