文章目录
- 简介
- 传统IT中心问题
- 共享服务体系优势
- 分布式框架
- 单体架构
- 中心化框架
- 去中心化框架
- 微服务
- dubbo
- 服务中心
- 定义
- 划分原则
- 数据拆分
- 纵向拆分
- 横向拆分
- 分库分表原则
- 数据库中间件
- 异步化
- 方式
- 传统分布式事务
- 柔性事务
- 缓存和秒杀
- 数字化运营
- 服务调用监控
- 日志处理
- 稳定平台
简介
传统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读。
异步化
- 异步化后,传统的分布式事务的强一致无法保证,需要柔性事务保证最终一致性。
- CAP和BASE理论
方式
- 业务流程异步化。对有严格调用关系的服务顺序执行,能够同时执行的服务异步化。
- 数据库事务异步化。大事务拆成小事务,资源分段占用,减少资源被占用的时间。
传统分布式事务
- 传统分布式事务遵循ACID,牺牲系统可用性追求获取强一致。
- 传统分布式事务
柔性事务
- 遵循BASE,针对大型分布式系统,牺牲强一致,获得高可用。
高可用=系统构建在多机=分布式系统->高性能
- 柔性事务
缓存和秒杀
- 小库存秒杀,走db。少量变更db足以应付。
- 定时上架。
- 乐观锁优化。
- 大库存秒杀,走redis。db热点明显,大量请求吞吐量低,redis原子化的增减操作性能高。
数字化运营
- 业务服务化,各个服务调用关系复杂,造成错误很难定位。
服务调用监控
- 淘宝鹰眼。
- CAT。
- cat wiki
- cat客户端。业务线程Threadlocal内记录打点,结束时放入阻塞队列,netty异步发送到服务端。
日志处理
- ELK:log4j->kafka->logstash->es->kibana。
- 分析方便。日志集中提供搜索能力。
- 业务影响小。不占用服务端的存储。
稳定平台
- 限流降级。
- 淘宝Sential。
- 单机限流。使用注解或dubbo接口,基于AtomicInteger实现。
- 流量调度。可考虑用重启替代调度。
- 调度走单点或局部故障的流量,原因:
- 机器超配、超卖带来的资源争抢。
- 部分机器初始化cpu高。
- JVM假死、GC。
- 宿主机影响。
- 网络抖动。
- 业务开关。配置中心实现,如Apollo和LEO。
- admin->server->db->task->netty->client。
- 单机压测。hengshan。
- 全链路压测。taishan。
- 业务一致性平台。balancer。