从阿里中台战略看TT快三企业 IT架构转型之道

此文是TT快三我 阅读《TT快三企业 IT架构转型之道》一书的学习笔记,所有内容出自钟华老师的这本书。

零、为何读《TT快三企业 IT架构转型之道》

  在加入XTT快三公司 后,开始了微TT快三服务 架构的实践,也开始了共享平台TT快三服务 的建设,在这方面阿里巴巴的中台战略是一个较好的参考。于是,领导就赠了这么一本《TT快三企业 IT架构转型之道》给TT快三我 ,希望TT快三我 学以致用,TT快三更多 的是有这样的一个眼界去指导TT快三TT快三我 们 的中台架构设计。因此,TT快三我 花了两周时间快速地阅读了一下此书,总结了此文作为学习笔记以供日后复习用。此书的确讲了一些干货,虽然很多内容留于表面,但是对于中台的定义和思考,建设中台的TT快三方法 以及阿里中间件有比较完整的描述,和多年前出版的《淘宝TT快三技术 这十年》以及《大型网站TT快三技术 架构-核心原理与案例分析》一样,是一本值得学习的好书。

一、引子

Part 1 阿里中台战略引发的思考

  • 起源自2008年阿里巴巴三大电商体系的TT快三技术 支持架构
    • 1688、淘宝、天猫三套电商体系架构完全独立
    • 三座烟囱分别矗立支撑阿里巴巴最核心的电商业务
  • 烟囱式系统建设系统对TT快三企业 的“三大”弊端
    • 重复功能建设和维护带来的重复投资
    • 打通“烟囱式”系统间交互的集成和协作成本高昂
    • 不利于业务的沉淀和持续发展 => 对TT快三企业 伤害最大
  • TT快三企业 信息中心的TT快三组织 职能是业务支持?
    • 问题核心在于IT信息部门在现有模式下大多被高管定位为业务支持的部门 => 一个花钱的成本中心
    • 问题原因在于IT信息部门的人员不懂业务 => 这里的懂业务是指“能对业务的下一步发展有着自己的理解和看法,对业务流程如何进一步TT快三优化 能更好的地提升业务,甚至对TT快三企业 现有的业务提出创新的想法,为TT快三企业 带来新的业务增长点。”
    • 问题结果导致了IT信息部门的人员很少能在一个业务领域做足够的业务沉淀 => 对业务知其然而不知其所以然

“烟囱式”的系统建设模式

Part 2 构建业务中台的基础—共享TT快三服务 体系

  • SOA架构的核心价值
    • TT快三服务 重用 => 从TT快三服务 重用到共享TT快三服务
  • 共享TT快三服务 体系的建设:克服“烟囱式”架构的三大弊端
    • 避免重复功能建设和维护带来的成本浪费 => 没有实现系统业务互通的诉求
    • 最大程度避免打通不同系统间实现业务交互带来的集成和协作成本 => 各个应用在核心业务层已经实现了统一和畅通
    • 能够很好地培养出特定领域的专家 => “既精通业务,又熟悉TT快三技术 ”的复合型人才
  • TT快三企业 信息中心TT快三组织 阵型的调整
    • 针对共享TT快三服务 体系重新TT快三组织 人员,使TT快三成员 有机会成为业务领域的专家(复合型人才)
    • 最核心的角色是架构师,他们会是各TT快三服务 中心的业务负责人
    • 信息团队会从“业务支持”的TT快三组织 职能转向基于TT快三企业 核心业务和数据进行运营的团队

阿里巴巴的“大中台”体系建设

PS:在阅读这一部分时,个人最大的感触就在于TT快三企业 信息中心的境遇,TT快三我 所在的TT快三公司 是一个传统TT快三行业 ,TT快三TT快三我 们 部门是从2018年末开始扩建的信息中心,和广大TT快三企业 信息中心一样,虽然无一不被认可信息部门对TT快三企业 发展的重要地位,行政级别也和核心业务部门的级别相当,但是实际情况却是没有同样平等的话语权,因为在高层领导的眼里就只是单纯把信息中心定位为了业务支持部门,是一个花钱的成本中心。而造成这样处境的原因,也很赞同钟华老师在书中的观点,那就是信息部门的员工不懂业务,这里的不懂业务是指能对业务的下一步发展有着自己的理解和看法,对业务流程如何进一步TT快三优化 能更好的地提升业务,甚至对TT快三企业 现有的业务提出创新的想法,为TT快三企业 带来新的业务增长点。而要提高信息部门的员工对于业务的精进,需要建设类似阿里巴巴的共享TT快三服务 中心,TT快三服务 需要不断的业务滋养才能足够强大地支持前线的士兵,也只有在滋养中才能从最初提供单薄业务功能的TT快三服务 组件成长为TT快三企业 最为宝贵的IT资产。正如钟华老师所示,未来在整个社会进入开放共享的时代,TT快三企业 最大的价值将会是基于核心业务和数据进行对外开放的运营,到那时信息部门的共享TT快三服务 体系将成为TT快三企业 最为宝贵的资产。

二、共享TT快三服务 体系的搭建

Part 3 分布式TT快三服务 框架的选择

  • “中心化”与“去中心化”TT快三服务 框架的对比
    • TT快三服务 调用方式的不同带来业务的响应和扩展成本:基于ESB的响应速度慢(因为网络开销大一倍),而要扩展ESB需要承担软硬件的不小投入(比如巨大的授权费)
    • 雪崩”效应束缚了“中心化”TT快三服务 框架的扩展能力:不适合TT快三互联网 TT快三企业 的根本原因,因为一旦雪崩故障恢复的时间和成本都非常高昂!
  • 阿里巴巴的分布式TT快三服务 框架HSF
    • 组成部分:TT快三服务 提供者、TT快三服务 调用者、TT快三地址 TT快三服务 器(Nginx)、配置TT快三服务 器(TT快三服务 注册&发现)、DiamondTT快三服务 器(类似于Zookeeper)
    • 工作原理:TT快三服务 节点对配置TT快三服务 器列表的获取、TT快三服务 的注册发布、TT快三服务 的订阅、TT快三服务 规则的推送(如果需要)、TT快三服务 交互
    • 核心能力:Netty+Hession数据序列化协议实现TT快三服务 交互(大并发量下的高性能)、容错机制(长连接+秒级感知)、线性扩展(增加TT快三服务 实例即可扩展TT快三服务 能力)
  • TT快三关于 微TT快三服务
    • 阿里巴巴2009年开始的共享TT快三服务 体系算得上是微TT快三服务 实践的先驱
    • 从本质上说,微TT快三服务 是SOA的一种演变后的形态,与SOA的TT快三方法 和原则没有本质上的差别
    • 微TT快三服务 与SOA的两点最鲜明差异在于:
      • 传统SOA架构基于“中心化”的ESB构建,而微TT快三服务 采用的是系统提供TT快三服务 的方式实现系统间的互通;
      • 传统SOA实施的方式是项目制,而微TT快三服务 是以做TT快三产品 的方式让TT快三服务 在业务发展过程中快速演化;
    • 概念一时爽,问题一堆堆:
      • 微TT快三服务 化的应用架构的有效TT快三服务 管控?
      • 分布式事务的难题?
      • 自动化运维和平台稳定性?
      • 微TT快三服务 的TT快三服务 设计?=> DDD

PS:微TT快三服务 不是“免费的午餐”,阿里巴巴2009年开始的共享TT快三服务 体系建设历程算得上是微TT快三服务 架构的建设过程。正如钟华老师所说,“罗马不是一天建成的”,TT快三企业 如果要构建微TT快三服务 架构体系,也是需要多一份耐心的,通过TT快三服务 能力在业务发展过程中的不断沉淀,当业务的能力沉淀到一个阶段后,才能真正感受到微TT快三服务 架构给TT快三企业 的业务发展带来的长远价值。

Part 4 共享TT快三服务 中心建设原则

  • TT快三服务 中心的三个特征
    • TT快三服务 中心是伴随业务不断发展的:不做过于超前的设计,也不做过于理想化的架构
    • TT快三服务 中心的TT快三服务 形态多样化:接口、TT快三工具 、数据...
    • 一个TT快三服务 中心还可以进一步划分:单个TT快三服务 模块、多个TT快三服务 模块...
  • TT快三服务 中心的划分原则
    • TT快三更多 靠的是架构设计经验总结,很难给出精确的量化指标
    • 一般来说会兼顾3个方面的需求:
      • 设计 => 遵循面向对象的分析和设计TT快三方法 论
      • 运营 => TT快三服务 中心应该是一个完整额业务模型
      • 工程 => 综合评估业务层对TT快三服务 中心在DB、业务以及运营方面的需求和TT快三技术 上需要的投入
    • 实际中的一些基本原则:
      • 高内聚、低耦合原则
      • 数据完整性原则:特别强调大数据思维
      • 业务可运营性原则:TT快三服务 中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元
      • 渐进性的建设原则:小步快跑,TT快三服务 化从简单开始!

 PS:记得张逸老师在《领域驱动战略设计实践》课程中的开篇提到他向DDD大师Eric Evans提问“如何正确地识别限界上下文?”,结果Eric Evans思考了一会儿,严肃地回答了一句:“By experience!”。这是一个正确的废话,但好像又蛮有道理。对于共享TT快三服务 中心的建设和划分来说,也同样如此,TT快三更多 的是依靠架构设计经验的总结,作者也很难给出一些具体问题给出一个精确的量化指标。正如作者所说,架构本来就是一个追求平衡的艺术,不仅是设计原则上的平衡,还要在TT快三技术 、成本、资源、性能、团队等各方面进行平衡,以最高效地解决主要问题。

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

  • 数据库分库分表的实践
    • 阿里巴巴分布式数据层平台发展演变:Cobar(2006) => TDDL(2008) => DRDS(2014)
    • 数据尽可能平均拆分:需要结合业务数据的结构和业务场景来决定
    • 尽量减少事务边界:“事务边界”指单个SQL语句在后端数据库上同时执行的数量
    • 异构索引表尽量降低全表扫描频率:“拿空间换时间”,阿里巴巴的精卫填海TT快三产品
    • 将多条件频繁查询引入TT快三搜索 引擎平台:采用专业TT快三搜索 引擎平台提供TT快三搜索 TT快三服务 ,Lucene、Solr、ElasticSearch
    • 简单就是美:“数据尽可能平均拆分”作为第一优先考虑,82法则

PS:阿里巴巴的分布式数据层平台发展的演变可谓是一部TT快三技术 驱动变革的历程,经历了一个又一个的TT快三技术 难题,出现了一个又一个的开源/商用TT快三产品 ,提高了阿里巴巴的效率。印象深刻的地方在于,TT快三TT快三我 们 都有一个印象就是在数据库开发和调用时,要充分利用索引,避免全表扫描。但是,作者说到在真实的业务场景中很难完全避免全表扫描,比如对于订单进行复杂的分布式条件检索的时候,就会需要采用全表扫描,将查询语句同时推送到后端的数据库中才能实现该场景。但是,因为调用量不会很频繁,而且计算的数据量并不大,所以整体上不会给DB产生太大的影响。另外一个点就是,从系统风险的角度来看,以82法则,在实际中,作者建议仅对那些在80%情况下访问的那20%的场景进行如数据异构索引这样的处理,达到这类场景的性能最TT快三优化 ,而对于其他80%偶尔出现跨库join、全表扫描的场景,采取最为简单直接的方式往往就是最有效的方式。

Part 6 异步与缓存原则

  • 异步化
    • 业务流程异步化:TT快三服务 异步调用,提升大量远程TT快三服务 线性调用带来的性能问题
    • 数据库事务异步化:将大事务拆分成小事务,提升吞吐量和事务操作的响应时间
      • 事务 => 核心是ACID
      • 柔性事务 => 基础是CAP理论和BASE理论,因为TT快三互联网 应用最核心的需求是高可用(BASE中的BA)
        • 解决分布式问题的机制:①日志和补偿机制、②可靠的消息传递、③无锁实现(避免事务回滚、辅助业务变化明细表、乐观锁等)
      • ACID与BASE一般在系统中会结合使用,追求最终一致性
  • 缓存
    • 小库存商品秒杀典型架构
      • 核心问题:处理好商品的库存的扣减,不出现超卖的情况
      • 核心方案:
        • 缓存商品的详细信息(包括库存),不直接访问后端数据库
        • 商品库存使用乐观锁,避免出现超卖
        • 商品库存控制业务流,只在下单环节才对数据库访问,降低数据库访问频率
    • 大库存商品大促架构
      • 核心问题:处理好库存更新的准确与用户等待时间的平衡
      • 核心方案:
        • 将缓存提升到为库存操作提供事务支持的角色 => 将订单交易创建环节在缓存TT快三服务 器中运行,提高响应速度
        • 借助消息队列实现缓存TT快三服务 器中的库存修改线性处理
        • 缓存TT快三服务 故障时通过缓存数据和数据库订单信息还原订单处理的最新状态

PS:异步化与缓存两个TT快三技术 都和TT快三TT快三我 们 的系统性能有很大的关联,在分布式应用架构中,如果没有这两项TT快三技术 的引入,相信设计出来的应用很难有优质的性能表现。淘宝平台是一个典型的分布式TT快三服务 架构,通过业务流程异步化提升了性能,分库分表后又在异步操作场景下实现了事务一致性与数据库处理性能的平衡。最后,通过适当使用缓存TT快三技术 实现了商品秒杀场景下的TT快三技术 架构,这都是TT快三TT快三我 们 需要学习和借鉴的。

小库存商品秒杀场景订单处理流程图

大库存商品秒杀场景订单处理流程图

Part 7 打造数字化运营能力

  • 业务TT快三服务 化带来的问题
    • TT快三服务 调用关系纷繁复杂,难以定位问题
    • 不同角色的TT快三技术 人员需要一些列的管控
  • 分布式TT快三服务 调用链路平台
    • 阿里巴巴内部实现:“鹰眼”平台,JStorm流式计算引擎
    • 核心思路:埋点和输出日志
  • 海量日志分布式处理平台
    • 阿里巴巴内部实现:TLog平台,日志处理流程“所见即所得”
    • 日志收集控制:遇到大量请求时只记录其中一部分数据,而非全量收集

PS:实现初步的分布式TT快三服务 体系之后,TT快三TT快三我 们 的平台必然会变成一个比较复杂的交互链路网,这会对TT快三TT快三我 们 的管控带来一些问题,比如TT快三服务 调用链监控、TT快三服务 运行状态是否正常,如何提供关键指标以实现精准营销等等。好在无论是商用TT快三产品 还是开源TT快三产品 ,都有了比较成熟的TT快三技术 方案,TT快三我 司已经在调研学习Skywalking和ElasticSearch,以后有机会做这方面的分享。

  在此TT快三推荐 一波Skywalking:

  在 ASP.NET Core 中集成 Skywalking APM (from savorboard 杨晓东)

  Apache SkyWalking 为.NET Core带来开箱即用的分布式追踪和应用性能监控 (from Lemon 刘浩杨)

  使用docker-compose 一键部署TT快三你 的分布式调用链跟踪框架Skywalking (from 一线码农 黄星辰)

  TT快三更多 Skywalking分享https://github.com/OpenSkywalking/Community

Skywalking Demo

Skywalking中的请求调用链拓扑视图

Part 8 打造平台稳定性能力

  • 提高稳定性的实践
    • 限流和降级:限流相当于电路保险丝,而降级则是为保证核心TT快三服务 而牺牲自己,阿里巴巴自研Sentinel限流平台
    • 流量调度:通过实时指标监控,对预计发生故障的TT快三服务 进行下线等操作,以避免单点或局部故障
    • 业务开关:通过集中化管理业务API操作开关,阿里巴巴自研Switch平台
    • 容量压测及评估规划:将线上真实流量引到压测TT快三服务 器,并差异化分析对线上TT快三服务 器的增减提供实时参考决策
    • 全链路压测:每个环节都参加的实战演习,例如双11实战演习
    • 业务一致性平台:保证业务与数据一致的业务稳定性,实时检测业务不一致的问题,阿里巴巴自研BCR业务审计平台

  #Sential Github: https://github.com/alibaba/Sentinel (轻量级的流量控制、熔断降级 Java 库)

  #Sential Wiki:分布式系统的流量防卫兵

  Sential Main Features

Sentinel 的主要特性

Part 9 共享TT快三服务 中心对内和对外的协作共享

  • 共享TT快三服务 平台的建设思路
    • Step1.找到一个合适的TT快三服务 化对象:比如API
    • Step2.建设对象TT快三服务 化的基础设施:比如结构化TT快三包装 ,让API成为治理良好的组件TT快三服务
    • Step3.TT快三服务 化实施阶段:循序渐进的过程,三个阶段参考
      • API as Service => TT快三服务 化的第一步
      • Product as Service => 大量业务API升级为TT快三服务 化平台的组件TT快三服务
      • Solution as Service => 经过长时间的沉淀可以形成解决方案,如海外淘宝解决方案
    • Step4.增强TT快三服务 和基础设施实现TT快三服务 的精细治理
  • 对内:共享TT快三服务 平台的协作
    • 与业务方的协作:以TT快三服务 为对象建立一个在线市场,三大角色
      • 共享TT快三服务 平台 => SPAS
      • TT快三服务 提供者 => 商品、交易、店铺、物流等
      • TT快三服务 消费者 => 商品、交易、店铺、物流等 (消费者通常也是提供者)
    • 与前端应用协作:TT快三服务 提供者与消费者,相辅相成,共同发展
      • 阿里巴巴的一些实践:紧密沟通,分歧升级、岗位轮转(换位思考)、业务沉淀及共建
  • 对内:业务中台绩效考核
    • No.1 TT快三服务 的稳定:比如一年只允许两次P1故障
    • No.2 持续业务创新:鼓励业务中台运营团队业务创新,包容业务创新引起的故障
    • No.3 TT快三服务 接入量:考量TT快三服务 能力的专业度以及对外的TT快三服务 运营能力
    • No.4 客户满意度:对中台TT快三服务 运营团队起到督促作用
  • 对外:开放能力构建生态
    • 核心内容:将自身平台中的数据以TT快三服务 的方式对外进行开放,从而吸引众多外部群体基于这些TT快三服务 提供增值TT快三服务 ,持续地为客户提供优质的运营平台能力,从而最终构建基于开放平台的生态体系。

PS:在这部分内容里边,印象最深刻的还是作者提到在TT快三互联网 转型时,很多人想要构建生态,但却没搞清楚“生态”和“上下游”的关系,它们之间的最本质的区别在于:在“上下游”模式中整个体系中所有的参与者都是被动的使用者,而“生态”模式中的参与者确是主动使用者,他们会持续地往整个体系中注入自己的智慧和创新的源泉,不断贡献自己的价值,只有这样的模式才能打造出TT快三企业 所希望的生态效果。而传统TT快三企业 现在应该着眼于TT快三企业 内部的核心业务能力的打造,等到有一天需要通过能力开放的方式拓展TT快三企业 业务边界或构建生态的时候,这些沉淀的TT快三服务 会是TT快三企业 最大的资产,而信息中心部门也不会只是一个成本中心,而有可能变为对外进行能力输出的关键运营部门。

三、阿里巴巴的实践案例

Part 10 大型央企TT快三互联网 转型

  阿里巴巴协助国内某大型央企在90天构建出了一个B2B电商平台,整体平台架构基于阿里巴巴的共享TT快三服务 理念和阿里云飞天Aliware的一系列TT快三产品 ,现在已经成为了国有大型TT快三企业 进行TT快三互联网 业务成功转型的标杆性项目。

Part 11时尚TT快三行业 品牌TT快三公司 TT快三互联网 转型

  某TT快三服装 品牌民营TT快三企业 基于阿里巴巴的共享TT快三服务 架构完成了TT快三企业 全渠道分销平台的重构,解决了高库存和高流单率的难题,实现了O2O的融合,建立了以客户体验为中心的系统架构,为TT快三企业 在同TT快三行业 的竞争中建立了差异化的竞争能力。

PS:2014年开始,国家就开始倡导“TT快三互联网 +”的转型,越来越多的传统TT快三企业 加入到TT快三互联网 转型的浪潮,像TT快三我 司一样的传统家居TT快三企业 也开始了转型,于是开始建设信息中心,于是TT快三我 就来了... 幸运的是,TT快三我 司已经在成都地区小有名气,并且是一个知名的品牌,接下来要做的,借用作者的原话就是需要TT快三TT快三我 们 信息中心能够更好地使用TT快三互联网 TT快三技术 、利用TT快三互联网 TT快三服务 、借鉴TT快三互联网 TT快三企业 的运营模式,更好地实现价值链中各节点的连接,让流程更加透明,业务更加可视,最终能够挖掘TT快三企业 的瓶颈,更好地满足消费者的需求,以获得更好的成长。对TT快三我 个人而言,在此期间能够积累和沉淀TT快三更多 的经验是最重要的,加油!

参考资料

 

钟华,《TT快三企业 IT架构转型之道-阿里巴巴中台战略思想与架构实战》

James,《给架构师的TT快三推荐 -TT快三企业 IT架构转型之道》

马崇,《TT快三企业 IT架构转型之道的思考》

 

posted @ 2019-05-15 22:42 Edison Chou 阅读(...) 评论(...) 编辑 收藏