• / 162
  • 下载费用:20 金币  

《淘宝软件架构实践》培训材料

关 键 词:
淘宝软件架构实践
资源描述:
《淘宝软件架构实践》 曾宪杰 2013-3 个人介绍 •毕业于浙江大学计算机系; •07年加入淘宝平台架构部,参与淘宝从2.0架构到3.0架构的改造工作; •设计实现了淘宝V3.0中消息中间件以及参与了数据层的相关工作,这是淘宝V3.0改造中的三 个利器中的两个; •后与10年负责整个中间件团队,这是平台架构部中篇技术的一块儿; •在09年和同事一起合作出版了《OSGi原理与最佳实践》一书,这是第一本中文的OSGi的书 籍,并且也是先于英文版出版的OSGi的书籍。 课程目的 • 了解大型网联网系统的演进过程和遇到的挑战 • 了解支撑大型互联网整体架构的通用系统设计 • 了解网站非功能性的属性实现 • 了解淘宝V4的思考和进展 主题 • 淘宝架构V1.0到V3.0的变化 • 支撑V3.0的重要系统介绍 • 和架构相关的非功能性属性介绍 • 淘宝架构V4.0思考和进行中工作 淘宝架构V1.0到V3.0的变化 V1.0 2003.5 – 2004.1 • 淘宝网的诞生-PHPAuction •LAMP •MySQL读写分离 Linux Apache PHP MySQL Slave1Slave2 MySQL Master 复制复制 ReadRead Read/Write V1.0 Apache mod_php4 pear DB Function Apache mod_php4 pear DB Function 3 Apache mod_php4 pear DB Function 2 Apache mod_php4 pear DB Function 1 V1.1 过渡版本 •V1.0问题 – 数据一致性 – 数据库容量限制 V1.1 2004.1 – 2004.5 •MySQL迁移至Oracle • 引入SQL Relay中间件 • 迁移阶段开发人员写两种SQL Linux Apache PHP SQL Relay Oracle V1.1 Oracle Apache mod_php4 pear DB Function 4 SQL Relay Apache mod_php4 pear DB Function 3 SQL Relay Apache mod_php4 pear DB Function 2 SQL Relay Apache mod_php4 pear DB Function 1 SQL Relay V2 需求 • 支撑高速业务发展 • 支撑团队并行开发 • 支撑系统的可伸缩 V2.0 2004.2-2005.03 •php迁移至java • 三层结构 • 自主的MVC框架 • 自主的IoC容器 • 自主的项目管理工具 • 自主的搜索引擎 Linux Apache Weblogic 淘宝MVC框架 EJB OR-Mapping Oracle V2.0 Oracle Read/Write dump Search Node1Node2Noden …… Weblogic 淘宝MVC EJB Function 4 OR-Mapping Weblogic 淘宝MVC EJB Function 3 OR-Mapping Weblogic 淘宝MVC EJB Function 2 OR-Mapping Weblogic 淘宝MVC EJB Function 1 OR-Mapping V2.1 的需求 • 降低成本 • 提高性能 • 增加开发效率 V2.1 2004.10 – 2007.01 • weblogic迁移至jboss • JDK 1.4逐步升级到1.5 • 支持分库的数据访问框架 • 抛弃EJB • 引入Spring • session框架 • 基于BDB的缓存 • Taobao自己的CDN Linux Apache JBoss 淘宝MVC框架 Spring OR-Mapping Oracle V2.1 cache Read/Write Read/Write dump Search Node1Node2Noden …… Oracle Oracle Oracle Oracle JBoss 淘宝MVC Spring …… OR-Mapping JBoss 淘宝MVC Spring Function 3 OR-Mapping JBoss 淘宝MVC Spring Function 2 OR-Mapping JBoss 淘宝MVC Spring Function 1 OR-Mapping V2.2 需求 • 提高系统性能 • 降低存储成本 • 支撑海量数据的搜索 V2.2 2006.10 – 2007.12 • 分布式存储 • 前端页面缓存 • 搜索引擎升级 Linux Apache ESI JBoss 淘宝MVC框架 Spring OR-Mapping Oracle分布式存储 V2.2 Read/Write Oracle Oracle Oracle Oracle Read/Write dump Search Node1Node2Noden …… Node1Node2Noden JBoss 淘宝MVC Spring …… Ibatis JBoss 淘宝MVC Spring Function 3 Ibatis JBoss 淘宝MVC Spring Function 2 Ibatis JBoss 淘宝MVC Spring Function 1 OR-Mapping cache 分布式存储 Node1Node2Noden V2 问题 • 数十人维护一个代码几十万行的核心工程 • 多个业务系统中的超过1/3的核心代码重复 • 所有系统都要关心数据拆分规则 • 数据库连接达到上限 • 停电  V3.0 需求 • 支撑大型团队,丰富业务的并行开发 • 支撑高速的业务增长 • 透明的数据和应用伸缩 • 提高可用性 V3.0 2007.12 –2011.8 • 淘宝数据层 • 淘宝服务框架 • 淘宝消息系统 • 非核心数据迁移MySQL • 同城容灾 服务/消息 Linux Apache JBoss 淘宝MVC框架 Spring Linux JBoss 淘宝服务容器 淘宝数据层 Oracl e MySQ L 分布式 存储 V3.0 LoadBalancer WebAppWebApp ServiceService Cache 分布式存储 搜索 消息 中间 件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DBDB(S)DB(S) 监控 运维平台 数据复制/迁移 支撑V3.0的重要系统介绍 主要要解决的问题 • 集中式架构演进为分布式架构 • 架构概念和模型如何落地 • 同城多机房问题 架构演进和落地 • 服务化架构 • 消息解耦 • 数据可扩展 计算机硬件结构图 外存 内存 运算 器 控制 器 输入 设备 输出 设备 数据、程序 CPU 主机 数据、程序 数据、程序 冯.诺依 曼型计 算机 计算机组成 Consistent Hash CAP •Consistency •Availability •Tolerance to network Partions •服务框架介绍 V3.0之前的样子 前台后台论坛…… DB 缓存 分布式文件存储 搜索通知系统 DB 服务化 Service1Service2Service3 App1App1App2App2App3App3 为什么要SOA? SOA能带来什么好处? 系统间调用 调用者服务提供者 How? 系统间调用 调用者服务提供者 How? 调用者服务提供者 系统间调用 调用者服务提供者 调用者服务提供者 调用者服务提供者 调用者服务提供者 另外一种方式 调用者 服务提 供者 调用者 服务提 供者 服务框架 服务框架 服务框架 服务框架 服务框架-调用过程 • helloService.sayHello(“Chris”) • 服务寻址 • 负载均衡 • 序列化请求 • 发送请求 • 接收响应 • 反序列化结果 • 结束 服务框架-服务寻址 • 静态 vs 动态 • 主动 vs 被动 • 服务粒度 服务框架-服务寻址 • 分组 – 指定分组 – IP分组 • 路由 – 按接口路由 – 按方法路由 – 按参数路由 • 跨机房问题 服务框架-负载均衡 • failover; • 随机规则; • 机房权重; • 动态权重; 服务框架-序列化/反序列化 • Java • Hessian • Json • Protocol Buffer • 。。。。。。 服务框架-发送请求/接收响应 • RPC – TCP/IP – WebService – Http • Oneway • Callback • Future • 可靠异步 服务框架要解决的问题 • 统一的服务提供和使用方式 • 服务寻址 • 软件负载均衡支持 • 序列化协议 • 高性能通信 服务框架 • 为什么不用ESB? • 为什么不走透明代理的方式? 服务框架 • 远程通信 – 通信方式和模型 •TCP vs UDP • 连接管理 •BIO vs NIO – 协议选择 • 性能 • 跨语言支持 服务框架 • 稳定性相关 – 隔离 • 慢 vs 挂 • 线程池隔离 • 机器隔离 • 基于调用者隔离 – 降级 • 统一开关 • 开关粒度 •0-1 or 0-100 – 调用方并发数控制 服务框架 • 服务注册查找中心 – 这不应该是一个任何时刻都关键的应用 – 性能问题 – 集群问题 服务框架 •Jar包冲突和隔离 – 服务框架与应用的Jar包冲突 – 应用引入的包导致的冲突 • 如何解决 – class隔离 – 消除冲突 服务框架 • 支持各种场景 – 需要有很好的扩展性 – Core+Plugin方式 – 在整个流程上暴露多个扩展点 – 保证主体流程的前提下能够高度定制 服务框架 • 服务管理 – 运行状况查询 – 依赖关系查询管理 – 服务上下线 – 服务分组管理 – 路由规则 – 流量分配 服务框架 • 非内部跨机房支持 • 分布式事务 • 异步、并行 服务框架 • 服务框架使得单机调用变为了远程调用 • 完成了应用从集中式到分布式的第一步 • 构建新系统的架构的思考 分布式数据层介绍 分布式数据层-前世 Ø ORACLE+IBM小型机+HDS Ø 单机已经不能承担,开始数据水平拆分 Ø 希望拆分不要过多的影响开发人员 IBM 小型机 HDS高端存储 分布式数据层 • 数据层前身的jar – 基于数据库标识的路由 – 基于用户id的路由 – 对开发不完全透明 • 来看一个当时的url – http://auction1.taobao.com/auction/item_detail-0db1- a0c6773727d2e1184badbcf9cdc54c07.jhtml 分布式数据层 • 网站高速发展带来的问题 – 数据量快速增长 – 访问量快速增长 – 小型机也显得有些无力 分布式数据层 • 透明的支持数据水平扩展 • 使得应用不用关心底层数据库的构成细节 数据库架构的演进 User User1 User2 User1-M User2-MUser2-S User1-S 分库分表 读写分离 进入Java中间件-TDDL 使用方式的选择 • Client-DB与Client-Proxy-DB 数据访问接入 •SQL vs 专有 API User1-M User2-MUser2-S User1-S TAtomDataSource TGroupDataSource TDataSource 数据复制 • 这是个问题么? Mast er Slave 数据复制 Slave Master1 Slave1-1Slave1-2…… …… 数据复制 • Master的数据怎么到Slave – 没什么特别好的现成的工具 – 解析Master日志,然后做复制 – 拦截SQL操作,做复制 2008~诞生 数据层是部署在应用上 的一个jar,没有服务端 基于消息中间件完成了 第一版的数据复制 性能也满足业务的需求 ,99.96%的复制低于 200ms 非对称数据复制 数据变更通知平台 • 之前版本的非对称数据复制 • 解析binlog的方式的启发 • 只是一个通道,接入多种源,接出多个出 口 数据变更通知平台 • 数据需要流向DB外 •DB外的数据回流DB Source1 Source2 Source3 Event管道 Dest1 Dest2 Dest3 DB自动切换 •需求来源 –PC Server vs 小型机 • 方案 – Agent + ZooKeeper • 切换方式 – 自动收集数据 – 人工决策 – 自动决策? 数据平滑迁移 •Sql vs NoSQL的弱点 •RowKey vs 业务规则 数据平滑迁移 • 与规则引擎相互配合 • 不关心具体的规则,只要能够表示的规则 ,都可以进行数据迁移 • 对业务的影响几乎为零 全 量 复 制 增 量 复 制 数 据 检检 查查 部 分 停 写 规规 则则 切 换换 数据库运维平台 • 三层数据源的配置管理 • 主备切换、权重管理 • 发现会出现瓶颈的数据库生成扩容方案 大数据层 • SQL • NOSQL • DFS • Cache • Search 总结 • 解决分库分表后的访问 – 解析、规则、路由 • 数据分发 – 非对称复制 – 数据变更通知平台 • 扩容和切换支持 – 自动切换 – 平滑迁移 – 运维工具 •服务注册查找中心介绍 配置中心 订阅订阅者发发布者 配置中心是一个基于经典的“发布/订阅”模型的通讯框架。并在此 基础上融入了适合淘宝网情的一些本土化特性,比如数据发布的 自动聚合、生命周期关联…… 自动聚合 配置中心 使用场景:服务集群的成员信息汇聚,如 : 地址聚合 生命周期关联 配置中心 使用场景:自动关联服务的可用状态,如: 服务框架中即时感知服务提供者的加入/ 退出 服务注册查找中心 • 支持指定分组 • 基于IP的分组 • 流量分配 服务注册查找中心 • 走集群的道路 • 延展性瓶颈:单点容量的上限 • 可靠性瓶颈:单点失效的风险 • 实时性瓶颈:大量推送的延迟 • 升级的风险:重启阶段的冲击 服务注册查找中心 • 集群的设计挑战 • 一致性 (Consistency) • 延展性 (Scalability) • 可靠性 (Availability) • 实时性 (Real-time) • 一致性 (Consistency):集群中数据的稳态全局一致性 集群的“时空相对性”:集群中不存在跨节点的绝对时间 • 在不同的观察节点上,可能看到两个事件的先后次序是相反的 。 集群的设计 · 挑战 82 Node M Value 2 overwrote Value 1 Node N Value 1 overwrote Value 2 Node X Datum A (Value 1) Node Y Datum A (Value 2) • 一致性 (Consistency):集群中的非稳态短时局部一致性 非稳态一致性:节点失效/复位等暂态下的短时数据冗余或缺失 • 由于网络时延的不确定性,路径切换可能造成数据的短时不一致 。 集群的设计 · 挑战 83 Node X Datum A Node Y Datum A → → Datum A X Datum A Datum A X • 延展性 (Scalability):构筑有前瞻性的可延展架构 延展过程中面临的问题 • “水平延展” v.s. “垂直延展” • 耗散:路由转发、数据同步、数据校正…… 延展性的度量:Scalability Factor = Δ收益 / Δ投入 • 可接受:Factor 略小于 1 (正面因素),Factor 略大于1 (负面因素) • 优秀: Factor 1 (正面因素),Factor 1 (正面因素),Factor 数据的发布OPS,SDKOPS,客户端API 人工可控√× 客户端容灾√× 持久配置中心 • 集中保存应用的持久配置信息 • 使用OPS和SDK发布持久配置 • 支持多种方式获取持久数据 – 主动获取 – 定时获取 Nginx Nginx Web AppWeb App 流量控制 ClientSDK MySQL File File 更新 更新时&定时dump 读取数据的请求 OPS MySQL MySQL MySQL replication commonconfig.config-host.taobao.com 主动/定时获取配置 发布配置 系统架构 Server端的保护 • 通过Nginx对请求做流量控制 • 通过连接池限制对数据库的并发更新操作 •MySQL做一主三备 • 读取配置走本地静态文件,MySQL挂掉不 影响读取服务 客户端容灾保护 • 手工放置到本地的配置优先生效 – 缺省位置~/diamond/data – 可以手工把server上的 map-file.js和config-data目录 copy到这里 • 客户端会自动dump配置 – 缺省位置~/diamond/snapshot – 自动生成,server挂掉时应用可以依靠这个dump启动 • 优先级:本地配置网络读取自动dump ~/ diamond/data/map-file.js config-data ┠ group ┠ ┠dataId ┠ ┗dataId ┗ group … 持久配置中心 • 配置集中管理 • 配置持久化 • 配置存在变化 • 需要及时准确送达 • 对于集群管理,有非常大的意义 •消息中间件介绍 消息中间件 •Message-oriented middleware (MOM) is software infrastructure focused on sending and receiving messages between distributed systems. --- from wikipedia.org •MOM的优点 –松耦合 –异步处理 Application AApplication B Application Programming Interface Message Oriented Middleware 消息中间件 do action Call A Call B SystemA SystemB 传统传统 方式 使用消息中间间件方式 do action Send message SystemA SystemB MOM 消息中间件 业务系统完成一件事情后,需要其他系统进行处理的,通过 定时程序来驱动 业务系统 Do something 业务DB 定时程序 获取任务 Do action Messaging Models •Point-to-Point (PTP) – 每个消息只有一个消费者 – 发送者和接收者没有时间依赖 – 接收者确认消息处理成功 Client1 Msg 发送 QueueClient2 Msg 消费 确认 Messaging Models •Publish/Subscribe – 每个消息可以有多个订阅者 – 客户端只有订阅后才能收到消息 – 持久订阅 – 非持久订阅 Client1 Msg 发布 Topic Client2 Msg 订阅 投递 确认 Client3 订阅 投递 确认 Publish/Subscribe • 发布者和订阅者有时间上的依赖。 – 客户端只有建立了订阅关系后,才能收到消息 • 非持久订阅 – 订阅者为了接收消息,必须一直在线 • 持久订阅 – 订阅关系建立后,消息就不会丢失,不管订阅者是否 在线 – 当只有一个订阅者时,≈PTP 非持久订阅 持久订阅 消息中间件 • 消息发送和业务操作的一致性 • 订阅者集群 • 扩展性 • 可靠性 • 稳定性 • 高性能 消息发送和业务操作的一致性 • do action 和send message要保证一致 –do action成功,send message也要成功 –do action失败,send message也要失败 do action Send message SystemA SystemB MOM 消息发送和业务操作的一致性 • JMS中的XA系 –在普通的Connection、Session等基础上,提供了XAConeection、 XASession等接口和类 –采用的是消息存储和其他资源的分布式事务的方式,保证一致性 –业务操作的资源要支持分布式事务,消息存储使用的资源也要支 持分布式事务 –性能受影响,也有更多的限制 • AMQP的Transactions –AMQP定义了事务的语义和协议,实现取决于最终产品 消息发送和业务操作的一致性 • 通用的MQ产品支持XA分布式事务 – 优点 • 跨越多个资源ACID的保证 • 编程模型简单一致 – 缺点 • 性能和可用性都不高 • 故障难于恢复 消息发送和业务操作的一致性 Publisher Broker Storage T1 发 送 hal f消 息 T3业务操作 T4 提 交/ 回 滚 T2存储half消息 T5 提交:更新数据库 标识消息可发送 回滚:删除消息 S1 定期 检查 未提 交的 消息 S2提交/回滚 本地事务域 本地事务域 业务操作 S3 提交:更新数据库 标识消息可发送 回滚:删除消息 消息发送和业务操作的一致性 • 业务操作和消息存储都在本地事务域进行,不存在跨资源的事 务。 • 提交/回滚消息有可能失败,系统会处于短暂的不一致状态 • Broker会主动发送Check消息,确认消息是否提交或回滚 • 最终一致 • 将分布式事务分解在两个本地事务中 • 客户端需要付出的代价 – 实现Check消息的接口接口 消息发送和业务操作的一致性 • 最终一致性方案引入的问题 –Broker慢 –Broker整体Down掉 –皆是因为发送消息变为主流程的重要一环 • 如何解决 –Publisher自身对业务操作和发送消息的分离和补偿 –通用的可靠异步的方案 订阅者集群:消息的一个逻辑上的订阅者是有多个物理节点组成 的一个集群 A1和A2是SystemA中的两个机器 A1和A2共同来消费投递到SystemA的消息 B1和B2也是类似的关系 订阅者集群 PublisherMOM A1A2 SubscriberA B1B2 SubscriberB 订阅者集群(JMS) • Queue in JMS • Topic in JMS 发布 订阅 投递 确认 订阅 投递 确认 Client1 Msg Topic Client2 Msg Client3 Client1 Msg QueueClient2 Msg 发送 消费费 确认认 订阅者集群(AMQP) • AMQP Exchange – Direct Exchange – Topic Exchange – Fanout Exchange – Headers Exchange • 可以做到近似的订阅者集群的效果,但还是会受到Queue 这个约束的限制 订阅者集群 • 一种基于订阅者分组的实现 – 每个节点有一个GroupId,相同的GroupId的节点组成集群 – 订阅消息根据消息的Topic和Type订阅 – 支持消息Header的属性过滤 • 同一个组接收消息近似于共享一个Queue • 多个组之间,是多个Queue,处理的消息是一样 的 扩展性 •MOM自身的扩展 •Publisher的扩展 •Subscriber的扩展 Publisher SubscriberA SubscriberB MOM 扩展性 • MOM自身的扩展 • Broker自身无状态 – 能方便的添加Server以及应对有Server down掉的情况 – 不能保证消息的顺序,对每个消息是离散的处理 • NameServer(NS) – Publisher、Subscriber、Broker和NS都保持连接 – Publisher、Subscriber通过NS拿到Broker的列表 Publisher SubscriberA SubscriberB Broker Broker MOM Cluster NameServer 扩展性 • MOM存储节点扩展性 •持久消息不绑定具体存储节点 – 可以方便的扩充存储节点 – 如何解决查找消息的问题? Publisher SubscriberA SubscriberB Broker Broker MOM Cluster Storage Storage 扩展性 • 订阅 者的扩展性 • 订阅 者集群的支持 – 每个订阅 者节点和每个Broker建立一个连接 – 集群中多个节点的选择 – 流控的支持 – 集群中单个节点的动态 控制 Publisher Broker Broker MOM Cluster SubscriberA A1A2 SubscriberB B1B2 Storage Storage •发布者的扩展性 •发布者集群 – 每个发布者节点和每个Broker建立一个连接 – 发布者对Broker的选择 扩展性 Broker Broker MOM Cluster SubscriberA A1A2 SubscriberB B1B2 Storage Storage Publisher P1P2 扩展性 •JMS – 规范本身对于扩展性本身没有过多提及 – 对于消息顺序的规定,实现上对扩展性是有影 响的 •AMQP – 没有对于顺序的规定,在实现上,是可以达到 很好的扩展性的 可靠性 • 服务质量 (QOS) 级别 – Exactly-once • 投递一次且仅一次 – At-least-once • 最少会投递一次,有可能会重复投递 – At-most-once • 最多投递一次,有可能丢失 • 不能丢消息 可靠性 • 消息的投递分为两个阶段 – 发布者向Broker发送消息 – Broker向订阅者投递消息 • 因此,消息有可能在三个地方丢失 – 发布者到Broker之间 – Broker本身 – 从Broker到订阅者 可靠性 • 三个阶段的可靠性保证 Broker Broker MOM ClusterSubscriberA A1A2 SubscriberB B1B2 Storage Storage Publisher P1P2 可靠性 •Publisher-Broker – Broker收到消息,放入存储节点中,才会返回”成功”给Publisher – Publisher需要去判断和处理发送消息到Broker的调用返回结果 – Broker Crash,不会导致消息丢失 Broker Broker MOM ClusterPublisher P1P2 可靠性 •Storage的可靠性 – 没有绝对的可靠,需要定义级别 ü File ü Oracle+小型机+存储 ü Mysql ü Mysql + Replication – 同步写入两个节点 Broker Broker MOM Cluster Storage Storage 可靠性 • Broker-Subscriber – Subscriber处理消息结束后回应处理结果 – 显示的返回处理失败或者出现异常,都会导致消息重发 – Broker只有明确的收到”处理成功”的响应,才会删除消息 Broker Broker MOM Cluster SubscriberA A1A2 SubscriberB B1B2 稳定性 •优雅降级 – 尝试投递长时间没有投递成功的消息 – 当前消息的投递 – 不重要的消息的接收 Broker Broker MOM Cluster SubscriberA A1A2 SubscriberB B1B2 Storage Storage Publisher P1P2 稳定性 • 监视 – Broker内存使用 – 消息收发功能 – 消息堆积情况 – 存储的插入速度 – 各个任务队列长度 – 其他各项即时统计数据等 稳定性 • 控制 – 自动移除失效存储节点 – 优雅降级的控制 – 添加新存储节点 – 添加新Broker 高性能 • KISS – 采用能够满足需求的尽量简单的方案来实现 – 例如:基于消息属性的过滤的实现 • SEDA – Broker的内部处理流水线化,分为多个阶段来进行 • Local Cache – 降低对于存储节点的压力 • 采用DB作为存储时的优化 – 表结构设计的考虑 – Batch操作 消息系统的本质 • 发布者产生消息 • 消息的主题、类型 • 订阅者消费消息 需要注意的问题 • 内存问题 • 消息延时问题 • 隔离和降级的问题 • 消息的处理跟踪的问题 • 成本的问题 消息系统2 •Broker-1 Topic-1 partition0 partition1 partition2 partition3 Topic-2 partition0 partition1 partition2 partition3 Broker-2 Topic-1 partition0 partition1 partition2 Topic-3 partition0 partition1 partition2 partition3 messages 一些经验 • 做好监控 • 可以优雅降级 • 越简单越好,一些看起来很土的方式,其 实很好用 • 不要求全,做好取舍 V3.0 LoadBalancer WebAppWebApp ServiceService Cache 分布式存储 搜索 消息 中间 件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DBDB(S)DB(S) 监控 运维平台 数据复制/迁移 和架构相关的非功能性属性介绍 147 哈勃系统架构 整个系统分为“采集”,“分析报警”和“应用(展现)”三个层次,实 现了“采集”,“分析”,“报警”,“存储”和“展示”五大功能。 稳定性平台 148 支撑系统 • 发布系统 – 旧有发布方式 – 开发 测试 SCM PE的解放 – 多种发布方式支持 – 分发效率提升 支撑系统 • 灰度系统 – 分流 – 效果跟踪 支撑系统 • 服务治理 其他系统 • 分布式调用追踪-类Google Dapper 淘宝架构V4.0思考和进行中工作 • 私有云 • 异地机房 私有云 l2010年引入虚拟化,1台物理机装3个虚拟 机,一定程度降低了成本; l机器规模增长非常快,其中1/3的虚拟机的 peak load 0.5; l做一个产品来提升机器的资源利用率。 私有云 l运维成本不够低的主要原因 l单台物理机上跑的应用不够多; l分给应用的机型以及机器数是静态的; l 集群的资源利用率不均衡。 私有云 l单台物理机上跑更多的应用; l 超配; l 支持资源可共享; l 支持共享的资源的动态调整。 l 部署的应用的合理搭配; l 资源消耗多的和少的搭配; l 消耗的资源不同的互补。 私有云 l分配应用的机型以及机器数需要是动态的 l 根据应用的资源利用率动态调整; l 机型需要支持动态调整; l 机器数要动态的要求是应用新上线机器和下线机器 的动作需要全自动化。 l集群的资源利用率做到均衡 l根据集群各机器的资源利用率状况动态迁移应 用; 私有云 l 动态 l 单机资源的搭配以及数量可动态调整; l 需要一个可很好支持此需求的虚拟化方案; l 动态迁移应用保障单机应用搭配的合理性以及集群资源利用率的 均衡。 l强大的监控; l资源管理系统; l 应用上下线的全自动化。 l 弹性 l 根据应用的资源消耗状况动态调整机型以及机器数●强大的监控; l 资源管理系统; l 依赖动态特性。 私有云 l虚拟化方案 l需要支持动态搭配以及数量的调整; l内部应用的特征 lShare Nothing,集群化; l统一的OS; l安全级别要求不是很高。 l选择了LXC(Linux Container) 多机房 • 同城机房 • 异地机房 建议 •尊重硬件工程师的成果 • CAP原则 • 8/2法则 •能水平扩展很重要 •未必需要全自动 •自动化系统也要留下人工介入的口子 Q&A
展开阅读全文
  麦档网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
0条评论

还可以输入200字符

暂无评论,赶快抢占沙发吧。

关于本文
本文标题:《淘宝软件架构实践》培训材料
链接地址:https://www.maidoc.com/p-15687218.html
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

[email protected] 2018-2020 maidoc.com版权所有  文库上传用户QQ群:3303921 

麦档网为“文档C2C模式”,即用户上传的文档所得金币直接给(下载)用户,本站只是中间服务平台,本站所有文档下载所得的金币归上传人(含作者)所有。
备案号:蜀ICP备17040478号-3  
川公网安备:51019002001290号 

本站提供办公文档学习资料考试资料文档下载


收起
展开