阿里中台思想重点

简介

传统IT中心问题

• 烟囱式系统建设模式。缺点：
  • 重复功能建设和维护带来的重复投资。
  • 系统间的交互和集成成本高昂。ESB这种总线式SOA代价高昂。
  • 不利于业务的沉淀和持续发展。项目制造成设计扩展性、维护积极性不高。
• IT中心局限于业务支持。缺点（恶性循环）：
  • IT中心人不懂业务，无法对业务发展有自己的看法，无法优化创新业务流程。
  • 项目制重复劳动较多，对能力的提升不是线性的，IT人无法对业务有足够了解和沉淀。

共享服务体系优势

• 服务重用。
  • SOA的本质是服务重用，但是ESB中则作为集成工具，没有实现松耦合带来的业务复用。
  • ESB中同类数据如订单等分散在各个模块，打通成本高。
• 滋养服务。
  • 项目制度造成服务提供者没有积极性发展已有的服务。
  • 新服务不稳定，应该是做强服务，而不是定制。
• 业务创新。
  • 共享中心接触各种业务场景，培养特定业务专家，带来创新。
• 业务快速试错。
  • 小前台协作效率高、方向调整快，可以用较小的成本决定是投入还是放弃该业务。
• 发展大数据。
  • ESB数据分布广、格式不统一，并且缺少有业务能力的数据专家。
• 组织效能提升。
  • 项目制类似流水线，无法让员工沉淀积累，积极性受影响。

分布式框架

单体架构

• 缺点：
  • 协作成本高。冲突较多，业务响应慢。
  • 复杂度高。牵一发动全身，需要关注自身之外的模块。
  • 错误难以隔离。非核心代码的故障影响核心功能，比如OOM。
  • 数据库连接难以扩展。多个实例连接同一个数据库，连接数接近上限。
  • 应用扩展成本高。扩容时非瓶颈模块也跟着扩容，浪费资源。

中心化框架

• ESB（企业服务总线），通过技术接口适配接入、数据格式转换、数据裁剪、服务请求路由，解决异构系统之间的交互。
  
• 缺点：
  • 响应慢。请求需要通过总线，rpc次数翻倍。
  • 总线扩展成本高。压力大，需要的硬件带宽等成本很高。
  • 总线雪崩隐患。流量高峰时总线单机故障，容易造成更多机器宕机，造成整体不可用。

去中心化框架

• HFS框架和他的开源版本dubbo。

微服务

• 微服务演化过程和特点

dubbo

• dubbo原理和特点

服务中心

定义

• 提供一块业务的服务能力，特点：
  • 不断发展。服务化->平台化。
  • 服务形态多样。实时接口服务、工具任务类服务、大数据服务。
  • 可进一步划分。
• 商品中心的能力：
  • 商品描述能力。包括
    • 描述数据模型。goods,sku,spu,类目,属性等。
    • 商品存储模型。数据库的库表设计。
    • 对外服务接口。需要屏蔽商品内部实现，简化上层业务的使用。
  • 商品发布能力。提供通用的发布接口和标准发布工具，业务层提供个性化发布工具，如B端页面、B端开平、C端app、C端小程序等。
  • 商品管理能力。总量大、更新频繁。
  • 商品巡检能力。冷数据归档、违规商品识别等。
  • 商品数据分析能力。大数据支持决策。
  • 商品评价能力。偏用户，可放在用户中心。

划分原则

• 高内聚、低耦合原则。
  • 一个服务中心内的业务相关性依赖性很高，服务中心之间业务隔离比较大。
  • 服务中心粒度适中，最好在业务足够丰富或者对其他中心的影响不可忽略时拆出。
• 数据完整性原则。
  • 除核心在线数据外，包括相关、离线数据。
• 业务可运营性原则。
  • 业务快速发展期满足上层业务需求，沉淀。
  • 业务内部创新，比如大数据、巡检等。
• 渐进性建设原则。
  • 降低风险和实施难度，小步快跑。
  • 服务化是敏捷的一种实践。

数据拆分

• 数据拆分优缺点

纵向拆分

• 纵向拆分。各个业务独立数据库。

横向拆分

• 分库分表。
• 读写分离。mysql一主多从，主写从读。

分库分表原则

• 数据尽可能平均拆分。注意路由键选取。
• 尽量减少事务边界（单条sql同时执行的数量）。db操作尽量带路由键，否则会出现全表扫描+内存聚合操作，后果：
  • 锁冲突概率高。
  • 系统难以扩展。瓶颈是单个数据库性能。
  • 整体性能低。对并发扫描结果的聚合在大量数据的场景下很耗时。
• 异构索引表减少全表扫描。不需要全量数据，少量空间换时间。
  • 索引表分为：
    • db分库分表。
    • es。支持复杂条件查询。
  • 构建方式：binlog->kafka->索引，check任务兜底。
• 简单。极少场景的全表扫描可以接收，避免冗余数据、数据一致性、系统复杂度问题。

数据库中间件

• zebra是一种数据源代理的数据库中间件方案。
  
  • ShardDataSource用于分库分表。
  • GroupDataSource用于读写分离。
• 使用方式。
  • 一个服务写，只连master读写，避免跨库事务、避免主从延时、减少连接。
  • 多个服务读，只需连slave读。
• zebra wiki。

异步化

• 异步化后，传统的分布式事务的强一致无法保证，需要柔性事务保证最终一致性。
• CAP和BASE理论

方式

• 业务流程异步化。对有严格调用关系的服务顺序执行，能够同时执行的服务异步化。
• 数据库事务异步化。大事务拆成小事务，资源分段占用，减少资源被占用的时间。

传统分布式事务

• 传统分布式事务遵循ACID，牺牲系统可用性追求获取强一致。
• 传统分布式事务

柔性事务

• 遵循BASE，针对大型分布式系统，牺牲强一致，获得高可用。

高可用=系统构建在多机=分布式系统->高性能

• 柔性事务

缓存和秒杀

• 小库存秒杀，走db。少量变更db足以应付。
  • 定时上架。
  • 乐观锁优化。
• 大库存秒杀，走redis。db热点明显，大量请求吞吐量低，redis原子化的增减操作性能高。

数字化运营

• 业务服务化，各个服务调用关系复杂，造成错误很难定位。

服务调用监控

• 淘宝鹰眼。
• CAT。
  • cat wiki
  • cat客户端。业务线程Threadlocal内记录打点，结束时放入阻塞队列，netty异步发送到服务端。
    

日志处理

• ELK：log4j->kafka->logstash->es->kibana。
  • 分析方便。日志集中提供搜索能力。
  • 业务影响小。不占用服务端的存储。
• ELK快速搭建教程。

稳定平台

• 限流降级。
  • 淘宝Sential。
  • 单机限流。使用注解或dubbo接口，基于AtomicInteger实现。
• 流量调度。可考虑用重启替代调度。
  • 调度走单点或局部故障的流量，原因：
    • 机器超配、超卖带来的资源争抢。
    • 部分机器初始化cpu高。
    • JVM假死、GC。
    • 宿主机影响。
    • 网络抖动。
• 业务开关。配置中心实现，如Apollo和LEO。
  • admin->server->db->task->netty->client。
• 单机压测。hengshan。
• 全链路压测。taishan。
• 业务一致性平台。balancer。