Recommended
More Related Content
Similar to Config Server 1.3 - 从一到多的跨越
Similar to Config Server 1.3 - 从一到多的跨越 (17)
Config Server 1.3 - 从一到多的跨越
- 1. 从一到多的跨越 配置中心集群 设计经验分享 无锋 Taobao Arch Team 1
- 2. 集群的使命召唤 • 延展性瓶颈：单点容量的上限 • 可靠性瓶颈：单点失效的风险 • 实时性瓶颈：大量推送的延迟 • 升级的风险：重启阶段的冲击 Taobao Arch Team 2
- 3. 集群的设计挑战 • 一致性 (Consistency) • 延展性 (Scalability) • 可靠性 (Availability) • 实时性 (Real-time) Taobao Arch Team 3
- 4. • 一致性 (Consistency)：集群中数据的稳态全局一致性 集群的“时空相对性”：集群中不存在跨节点的绝对时间 • 在不同的观察节点上，可能看到两个事件的先后次序是相反的。 集群的设计 · 挑战 Taobao Arch Team 4 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)
- 5. • 一致性 (Consistency)：集群中的非稳态短时局部一致性 非稳态一致性：节点失效/复位等暂态下的短时数据冗余或缺失 • 由于网络时延的不确定性，路径切换可能造成数据的短时不一致。 集群的设计 · 挑战 Taobao Arch Team 5 Node X Datum A Node Y Datum A → → Datum A X Datum A Datum A X
- 6. • 延展性 (Scalability)：构筑有前瞻性的可延展架构 延展过程中面临的问题 • “水平延展” v.s. “垂直延展” • 耗散：路由转发、数据同步、数据校正…… 延展性的度量：Scalability Factor = Δ收益 / Δ投入 • 可接受：Factor 略小于 1 (正面因素)，Factor 略大于1 (负面因素) • 优秀： Factor > 1 (正面因素)，Factor < 1 (负面因素) • 理想： Factor > > 1 (正面因素)，Factor < < 1 (负面因素) 集群的设计 · 挑战 Taobao Arch Team 6
- 7. • 延展性 (Scalability)：针对性的解决延展需求 配置中心延展需求的两个维度 • 客户端（包括连接及其下的订阅者/发布者）：中长期稳步增长 – 客户端的增长主要带来连接数、推送次数和时延的压力 • 数据（包括数据集和分组）：阶段性跳跃增长 – 数据的增加主要带来内存消耗和检索性能的压力 需要一个可兼顾二维延展的方案 集群的设计 · 挑战 Taobao Arch Team 7
- 8. • 可靠性 (Availability)：构筑高可靠性的集群 可靠性的评估 • 是否存在单点失效 • 是否存在可靠性瓶颈 • 是否具有故障抵御性（容错性设计） • 是否具有故障收敛性（自愈性设计） • 是否具有故障豁免性（免疫性设计） 集群的设计 · 挑战 Taobao Arch Team 8
- 9. • 实时性 (Real-time)：在延展性与实时性之间取得平衡 延展性与实时性的矛盾 • 高延展性往往以牺牲实时性作为代价 • 集群内的耗散增大了实时性的扰动概率 • 鱼和熊掌能否兼得？ 集群的设计 · 挑战 Taobao Arch Team 9
- 10. 集群的设计原则 • 简单 (Simplicity) • 无形 (Invisibility) • 去中心化 (Decentralized) Taobao Arch Team 10
- 11. • 简单 (Simplicity)：用相似的机制解决不同层面的问题 从自然科学看跨越尺度的世界 • 托伯列南国的图景( ) 自然界在不同尺度下遵循着高度相似的规律。 相似是指本质精髓的一致性，而细微的差别则体现为对不同 尺度的适应性演变。 • 牛顿力学 → 相对论 & 量子力学 解决不同尺度下的问题并不是要推翻适用于原有尺度的传统 理论，而是要找到一种可以包容传统学说的新理论。传统理 论只是其在旧有尺度下自然“退化”的一种近似。 技术的发展和演变不需要革命，需要的是包容过往并且实现 自然的过渡。 集群的设计 · 原则 Taobao Arch Team 11
- 12. 集群的设计 · 原则 Taobao Arch Team 13 • 无形 (Invisibility)：客户端感知不到集群的存在 不显著改变客户端与服务端现有的交互过程 • 降低客户端的复杂度 在客户端包含尽可能少的逻辑 (Dumb Client) • 集群机制的调整不用连带客户端升级
- 13. 集群的设计 · 原则 Taobao Arch Team 14 • 去中心化 (Decentralized)：跳出传统的C/S模型 ★ 点对点(P2P)网络的启示 • 彻底消除可靠性的单点瓶颈 • 网络流量及资源消耗（运算、存储）的自然均衡 • 任意尺度的网络割裂与聚合的自适应 • 更利于大尺度的延展 ☆ 同时也应认识到P2P的不足 • 全局可维性的削弱，安全性降低，大量连接的耗损
- 14. 集群的设计取舍 • 简单 (Simplicity) • 无形 (Invisibility) • 去中心化 (Decentralized) Taobao Arch Team 15
- 15. 集群的设计 · 取舍 Taobao Arch Team 16 • 简单 (Simplicity) ★ 基于自身发布机制的同步 Pros: 简单(机制重用)、可靠 Cons: 可同步的信息受限 ★ 基于RMI的同步 Pros: 可控性强 Cons: 较复杂 用相似的方式解决 不同尺度的问题
- 16. 集群的设计 · 取舍 Taobao Arch Team 17 • 无形 (Invisibility) ★ 客户端仅连接单个服务端 Pros: 客户端不涉及集群逻辑，改变较小 Cons: 服务端实现稍复杂 ★ 客户端连接多个服务端 Pros: 服务端实现简单 Cons: 可靠性低、性能压力大 客户端简单化
- 17. 集群的设计 · 取舍 Taobao Arch Team 18 • 去中心化 (Decentralized) ★ 全对等集群 Pros: 独立、灵活、去中心化 Cons: 复杂、稳定性风险 ★ 基于数据库的集群 Pros: 可靠、简单 Cons: 外部依赖、灵活性受限 为保证去中心化而 不得不牺牲简单性
- 18. 配置中心集群设计方案 • 跨尺度的机制复用 • 分布式路径幂等性 • 干细胞化节点设计 • 病毒式传播和生存 • 前瞻性的二维延展 Taobao Arch Team 19
- 19. 集群的设计 · 方案 Taobao Arch Team 20 • 跨尺度的机制复用：以不变应万变 复用传统的发布机制实现集群节点间的同步 使用标准的发布订阅机制交换节点地址 • com.taobao.config.serverlist 是一个标准的数据 可灵活堆叠的拓扑结构
- 20. 集群的设计 · 方案 Taobao Arch Team 21 • 分布式路径幂等性：在更大尺度上实现幂等性 分布式幂等性的关键：数据源头的惟一性 • 对集群中每一份惟一数据及其副本使用一致的标识 多路径幂等性的核心：用版本跟踪数据的更新 • 数据惟一标识必须在源头创建，不能在路径中变更 • 通过版本比较消除“时空相对性”的影响
- 21. 集群的设计 · 方案 Taobao Arch Team 22 • 干细胞化节点设计：每个节点完全对等并可随时替换 既可简单协同，亦可各司其职 • 域名所指向的节点承担“对外联络人”的角色 • 数据在不同节点的分工可自动均衡或人为配置 节点的分工与部署完全无关 • 部署过程无需任何配置，仅仅简单的启动节点即可 • 分工由全局抽象配置决定，不依赖具体的物理标识
- 22. 集群的设计 · 方案 Taobao Arch Team 23 • 病毒式传播和生存：像病毒一样快速传播、顽强生存 集群的诞生和成长（自组织、动态伸缩） • 两个孤立节点在发现彼此后自动聚合并升级为集群 • 新节点联络上任一成员节点后迅速传播至整个集群 集群的割裂与合并（局部自治、协同聚合） • 当集群被外因割裂时，每一个子集群均可独立运作 • 割裂的集群恢复互通后，自动聚合为一个完整集群
- 23. 集群的设计 · 方案 Taobao Arch Team 24 • 前瞻性的二维延展：针对短/中期延展需求采取不同对策 增加集群节点（短期内的延展方式，节点总数有限） • 客户端接入容量SF≈1，数据容量SF≈1，全推送耗时SF< <1 • 当节点数量> >1后，耗散将显著增加。（包括TCP连接开销） 增加堆叠层次（降低节点数量显著增加所产生的内部耗散） • 大幅度降低节点间TCP连接数，同步、校验、路由等消息量 • 以略微牺牲小部分实时性为代价。
- 24. 待解决的问题 • 持久数据的分布式存储 • 如何更有效的发现集群(Discovery) • 协同而非集中调度的负载均衡 • 分布式节点的管理和监控 • 跨地域数据中心的延展需求 Taobao Arch Team 25
- 25. 业界横向对比 • GlassFish Shoal • SAF·SAI (CLM Service) • Google PubSubHubbub Taobao Arch Team 26
Editor's Notes
- 延展性：单节点的TCP连接数上限 实时性：大量推送的高延迟
- 前瞻性：需要为未来1-3年的延展需求铺路。 热力学第二定律告诉我们，耗散是不可避免的。但耗散并不总是对系统有害，在开放的动态系统中，它是维持系统平衡的一个必要条件。 “自然界中的组织不应也不能通过中央管理得以维持；秩序只有通过自组织才能维持。自组织系统能够适应普遍的环境，即系统以热力学响应对环境中的变化作出反应， 此种响应使系统变得异常地柔韧且鲁棒，以抗衡外部的扰动。我们想指出，自组织系统比传统人类技术优越，传统人类技术仔细地回避复杂性，分层地管理几乎所有的技术过程。” ——《确定性的终结》（The End of Certainty），伊利亚·普利高津 Factor > 1 的典型例子：RAID-0，容量线性延展的同时，额外获得了性能的显著提升
- 【注解】 故障的抵御性：针对一些已知和未知的故障可能性，作出正确的处理或修正。 故障的收敛性：故障发生后，随着节点的扩散和时间的推移，其影响在逐步减小，甚至完全消除。（自愈） ·内秉性收敛：数据交互模型的幂等性（以配置中心本身机制为例）、数据传输路径的无关性（例如TCP/IP的路由迂回） ·主动式收敛：周期性数据校验和修正 故障的豁免性：设计本身具备对某些常见类型故障或缺陷的天然抵御能力。这是可靠性设计的最高境界。 ·例如：虚拟机的封闭沙盒模型、Microsoft Singularity的程序验证机制。
- ·托伯列南国的图景告诉我们，自然界在不同尺度下遵循着高度相似的规律。相似是指本质精髓的一致性，而细微的差别则体现为对不同尺的适应性演变。 ·从牛顿力学到相对论&量子力学的发展所给予我们的启示：解决不同尺度下的问题并不是要推翻适用于原有尺度的传统理论，而是要找到一种可以包容传统学说的新理论。传统理论只是它在旧有尺度下自然“退化”的一种近似形态。技术的发展和演变不需要革命，需要的是包容过往并且实现自然的过渡。 ·举华为的例子：革命性的架构往往是空中楼阁，几乎没有条件落地。我们需要的是可以在现有架构下平稳过渡的“君主立宪制”。
- 因由：客户端的代码稳定性需要、升级的繁琐性 BTW，顺带提及：通配符机制从客户端的剥离，变为纯服务端实现的特性。
- 顺便介绍：纯P2P网络 和 混合P2P网络
- 【案例】对数据库的依赖可能导致第三方数据库成为容灾机制的关键依赖。 稳定性风险，特指需要一定的时间检验整套机制的稳定性，而非机制本身存在稳定性缺陷。
- 【案例】对数据库的依赖可能导致第三方数据库成为容灾机制的关键依赖。 稳定性风险，特指需要一定的时间检验整套机制的稳定性，而非机制本身存在稳定性缺陷。
- 【案例】对数据库的依赖可能导致第三方数据库成为容灾机制的关键依赖。 稳定性风险，特指需要一定的时间检验整套机制的稳定性，而非机制本身存在稳定性缺陷。
- Discovery的实现目前是采用以唯一或少量域名作为集群的接入点，在机制上依赖于预先固定配置的DNS，并且无法实现子网内多个独立集群。这也是支付宝使用配置中心时遇到的一个问题。 跨地域数据中心的特点： ·广域数据和局域数据的结合（后者数量远超过前者）：需要将目前的“发布式”同步机制变为“订阅式”同步，以实现按需同步。这样，局域数据无需扩散至整个集群，可以有效降低超大尺度延展时的存储和同步负担。