企业IT架构转型之道
2020-06-02 14:08:11 7 举报AI智能生成
企业IT架构转型之道：阿里巴巴中台战略思想与架构事件
作者其他创作
大纲/内容
第1章 阿里集团中台战略引发的思考
“烟囱式”系统建设带来的弊端
重复建设和重复维护带来的重复投资
开发及维护
打通“烟囱式“系统间交互的集成和协作成本高昂
不利于业务的沉淀和持续发展
现实中出现的情况
服务提供者团队心理上拒绝收到新的服务需求，导致产生新的“烟囱”
想要对系统进行改造，但受限于之前服务设计的通用性和对业务的前瞻性不足，可能需要改变现有服务的数据模型及业务逻辑，考虑到存在改造的风险，于是保持现有服务的稳定性
第2章 构建业务中台的基础--共享服务体系
服务重用
松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新
服务需要不断的业务滋养
只有在滋养中才能从最初仅提供单薄业务功能的服务逐渐成长为企业最为宝贵的IT资产
共享服务体系是培育业务创新的土壤
好的创新一定基于企业的现状因地制宜，而这决定了在很大程度上创业的创新会来自于企业内部，而且提出创新的人对行业有深刻的认识和理解
赋予业务快速创新和试错的能力
小团队作战，对商机的把握会更敏锐、调整方向会更快捷；一旦发现正确目标，可以全力扩大战果
为真正发挥好大数据威力做好储备
大数据项目可能存在的问题
数据分布广、格式不统一、不标准
带来的工作：数据层访问的打通、数据权限的控制、数据格式的转换、数据清洗、数据同步等
缺少能基于数据有业务建模能力的专家
改变组织阵型会带来组织效能的提升
把信息中心部门从“业务支持”转变为基于企业核心业务和数据进行运营的团队
第3章分布式服务框架的选择
共享服务体系作为业务中台的核心中枢，面临的问题
服务的稳定性
服务能力的扩展性
对需求的快速响应能力
HSF_Diamond服务器使用场景
设置白名单（服务调用者所在服务节点IP地址）的方式设置某些服务或服务中的方法只能让特定IP地址的服务器调用
用户认证的方式控制服务是否能够调用
按照不同的服务器权重设置服务调用者对多个服务提供者服务节点的访问
设置某些服务的QPS能力上限值，一旦该服务的QPS达到该阀值，则拒绝服务的继续调用
实现服务限流的技术实现，在平台进行大促或秒杀场景时，保障平台稳定性的重要屏障
第4章 共享服务中心建设原则
服务能力
底层PaaS能力，PaaS层解决大型架构在分布式、可靠性、可用性、容错、监控已经运维层面的通用需求
业务能力，直接决定是否能真正支持上层业务达到敏捷、稳定、高效
淘宝的共享服务中心（核心所在）
用户中心
跟用户相关的服务是被上层业务调用最频繁的服务，节省开发和维护成本的同时，也最能验证出服务化后和系统解耦后给业务快速响应带来的效果。另外业务复杂程度和重要性上都要小一些，所以对于采用新架构进行的重构尝试，能将服务化改造的风险降到比较低的水准。
商品中心
对上层提供的服务能力
商品的描述能力
类目属性体系、SPU、SKU等
商品的存储模型/存储结构
对外提供的接口
商品发布能力
服务中心一定是实现通用的能力，个性化尽量在业务层实
商品管理能力
商品巡检的能力
关注商品的生命周期，及时提出非活跃商品，节省计算和存储资源
商品数据数据分析的能力
能自动聚合推荐的类目数据并提供调整的决策支持
商品评价的能力
识别正常的评价
交易中心
比如购物车、交易流程、订单管理、支持、结算、营销
后期拆分成 库存中心及营销中心
店铺中心
卖家店铺管理、店铺装修、店铺生命周期管理、店铺日常管理等业务
物流中心
营销中心
数据服务中心
提供的服务形式
依赖于接口的服务
RPC或Web API
依赖于工具的服务
一类用于提供定制的配置服务，比如淘宝商品中心要设置前台类目体系，交易中心要配置业务的交易流程
另一类是运营管理类的工具，比如商品巡检服务
依赖于数据的服务
对大数据的分析能力，实时交易型的数据能力一定要通过接口服务对外暴露
服务中心的划分原则
高内聚、低耦合
数据完整性
强调大数据的思维，不光只是业务逻辑的关键数据，还要考虑到业务的相关性数据；不光是实时在线数据，还要考虑到离线计算的数据
业务可运营性
让数据来源、数据分析、业务生产可以自然形成闭环
渐进性的建设
小步快跑的方式逐步推进，不是轰轰烈烈地推翻重来
第5章 数据拆分实现数据库能力线性扩展
数据库瓶颈阻碍业务的持续发展
读写分离，拓展了数据库对数据读的处理能力，整体上也大大提升了数据库的读写能力，但单表数据量达到一定数量后数据库性能会出现显著下降
数据库分库分表的实践
订单拆分维度
订单ID（一般为自增ID），为分库分表键
买家用户ID，为分库分表键
存在交易量非常大的卖家，可能导致数据不平均，提早进入到数据归档
尽量减少事务边界
所谓的事务边界即是指单个SQL语句在后端数据库上同时执行的数量。事务边界的数量越大，弊端越明显
系统的锁冲突概率越高
系统越难以扩展
整体性能越低
异构索引表尽量降低全表扫描频率
精卫—基于MySQL的实时数据复制框架
多线程管道实现
存在数据同步的顺序问题
数据的安全机制
平台稳定性保障
心跳+报警
MySQL主备切换
友好的用户自服务接入体验
平台管控和统计
心跳监控
延迟堆积监控
任务状态、数据监控（TPS、异常）等
将多条件频繁查询引入搜索引擎平台
简单就是美
第6章 异步化与缓存原则
业务流程异步化
数据库事务异步化
事务与柔性事务
CAP
一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）
一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）
解决数据一致性的问题
建立类似操作系统中锁的机制，要求确保所有数据节点的数据均同步之后，才能进行数据的访问操作。
但数据同步需求时间，大量采用锁机制会给数据层带来严重的性能瓶颈，从而可能导致平台在业务繁忙时的服务瘫痪或糟糕的用户体验
但数据同步需求时间，大量采用锁机制会给数据层带来严重的性能瓶颈，从而可能导致平台在业务繁忙时的服务瘫痪或糟糕的用户体验
CAP之间的取舍
放弃分区容忍性
分布式系统退 VS 单机系统
放弃可用性
遇到分区事件需要等待数据同步，此时无法对外提供服务；恢复节点后需要处理逻辑才可平滑地返回服务状态
放弃一致性
数据分片也存在弊端
BASE理论
基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）
基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）
“基本可用”是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
即，服务层只提供降级服务
即，服务层只提供降级服务
允许不同节点间副本同步的延时
系统中的所有数据副本经过一定时间后，最终能够达到一致的状态
分布式系统的首选不是这种强同步而是最终一致
传统分布式事务
当事务的并发量达到一定数量的时候，就会出现大量事务积压甚至出现死锁，系统性能和处理吞吐率就会严重下滑，也就是系统处理的吞吐率与资源上的时间消耗成反比
柔性事务如何解决分布式事务问题
引入日志和补偿机制
可靠消息传递
实现无锁
辅助业务变化明细表
比如抢购或者大促时，避免锁的方式就是在订单创建事务中只是在“库存预减明细表”中添加一条对应商品的库存预减记录，而无需对原商品数据表进行库存修改的操作，一旦用户成功付款，则真正地将商品数据表中的库存减除
避免事务进入回滚
乐观锁
乐观锁大多是基于数据版本（Version）记录机制实现
柔性事务在阿里巴巴内部的几种实现
消息分布式事务
支付宝XTS框架
阿里巴巴AliWare TXC事务服务
关于柔性事务的总结
远程模块之间用异步消息来驱动，异步消息还可以起到检查点的作用
大促秒杀活动催生缓存技术的高度使用
小库存商品秒杀典型架构
前期部署
活动商品与普通商品隔离部署，避免整个服务被影响
区分商品数据库与缓存服务器，将商品信息放在缓存服务器上，无需访问后端数据库
*注意同步修改更新库存数据
*注意同步修改更新库存数据
商品定时上架
风控点：验证服务端接收到的下单请求的时间是否晚于活动开始的时间
商品库存的乐观锁实现
商品库存控制业务流
缓存的重要性：缓存平台提供了对商品相关信息的缓存服务，使得用户只有在最终的下单环节才需要对数据库进行访问操作，大大降低了数据库的访问频率
大库存商品大促架构
缓存服务器
第7章 打造数字化运营能力
业务服务化带来的问题
针对分布式服务调用链跟踪平台—“鹰眼”
鹰眼平台的架构
埋点和输出日志
海量日志分布式处理平台
一个专业、成熟、稳定的分布式日志处理平台应该是互联网时代企业所需要的IT基础架构中的基础组件之一
日志收集控制
典型业务场景
服务实时监控
服务调用链跟踪
定位应用的性能瓶颈点及优化点
服务调用链分析
业务全息排查
本质上是将服务链路信息与业务事件进行了集成，将业务事件通过服务调用链的traceID&rcpID进行双向关联
业务实时监控
将业务数据从在线交易数据库通过ETL的方式同步到数据仓库中，业务展现大屏通过访问数据仓库获取到相关业务指标和统计数据从实际的案例来说，这一类方案能实现的业务指标一般是分钟级
第8章 打造平台稳定性能力
限流和降级(服务降级）
措施：通过域名类限流、cookie限流、黑名单以及一些安全策略
用户体验：限流页面的风格会与当前大促秒杀活动的风格统一，页面也会包含跳转引导界面，以形成用户体验和业务处理流程的闭环
授权、限流、降级、调用统计监控
流量调度
业务开关
容量压测及评估规划
全链路压测平台
全链路压测
基础数据抽取
链路与模型构造
链路验证
业务改造
数据平台
流量平台
影子表
中间件改造
安全机制
防止数据错乱+白名单+过滤压测流量，避免别识别为攻击流量
业务一致性平台
业务与数据不一致及时报警
事件监听框架
第9章 共享服务中心对内和对外的协作共享
服务化建设野蛮发展带来的问题
服务的数量和业务覆盖范围越来越大
应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高
服务安全控制层缺乏
开发体验很不友好，产品在接入流程，开发使用手册建设非常之差
整体服务体系缺乏一个统一的服务治理层
共享服务平台的建设思路
实现服务共享的条件
要找到一个合适的服务化对象
建设对象服务化的基础设施
服务化实施阶段
增强服务和基础设施实现服务的精细治理
阿里巴巴共享服务平台
确定服务化的对象是API
建立共享服务的基础设施，实现API的服务封装
服务化实施阶段
API as Service
Product as Service
Solution as Service
共享服务平台与业务方协作
务中台与前端应用协作
业务中台对前端核心业务的紧密沟通机制
定期会议，了解前端业务发展动向
建立分歧升级机制
岗位轮转推动真正换位思考
业务持续沉淀及共建模式
业务中台绩效考核维度
服务稳定是重中之重
业务创新推动业务发展
服务接入量是衡量服务价值的重要考核
主要考量了服务能力的专业度以及对外的服务运营能力
客户满意度促动服务的提升
能力开放是构建生态的基础
第10章 大型央企互联网转型
打造“厚平台”+“瘦前端”体系架构
彻底解决原来“烟囱式”项目建设的方式带来的数据难打通、业务交互成本高、功能重复建设、业务得不到沉淀的问题，
而且能真正做到业务的可持续发展和沉淀，为将来企业在互联网转型过程中所需的业务快速响应、业务的创新或试错打下坚实的服务中台
而且能真正做到业务的可持续发展和沉淀，为将来企业在互联网转型过程中所需的业务快速响应、业务的创新或试错打下坚实的服务中台
第11章 时尚行业品牌公司互联网转型
快速建设POS、SCRM等系统
由于分库分表，数据一致性以及跨数据库操作需要特别注意
系统自动为门店补货，减少商品管理人员的日常重复计算工作
改造生产制造环节的思考模式--款式多、定量少、交期短、频率高
基于SCRM进行全渠道整合营销，将品牌传播与市场营销移动化、互动化、游戏化，以消费容易接受的方式来增加趣味性与粘性，引导PK来促进分享传播（社交属性）
*围绕用户感受与体验进行营销活动
*围绕用户感受与体验进行营销活动
收藏
收藏
0 条评论
下一页
