More Related Content
Similar to Config Server 1.3 - 从一到多的跨越 (17)
Config Server 1.3 - 从一到多的跨越
- 6. • 延展性 (Scalability):构筑有前瞻性的可延展架构
延展过程中面临的问题
• “水平延展” v.s. “垂直延展”
• 耗散:路由转发、数据同步、数据校正……
延展性的度量:Scalability Factor = Δ收益 / Δ投入
• 可接受:Factor 略小于 1 (正面因素),Factor 略大于1 (负面因素)
• 优秀: Factor > 1 (正面因素),Factor < 1 (负面因素)
• 理想: Factor >
> 1 (正面因素),Factor <
< 1 (负面因素)
集群的设计 · 挑战
Taobao Arch Team 6
- 11. • 简单 (Simplicity):用相似的机制解决不同层面的问题
从自然科学看跨越尺度的世界
• 托伯列南国的图景( )
自然界在不同尺度下遵循着高度相似的规律。
相似是指本质精髓的一致性,而细微的差别则体现为对不同
尺度的适应性演变。
• 牛顿力学 → 相对论 & 量子力学
解决不同尺度下的问题并不是要推翻适用于原有尺度的传统
理论,而是要找到一种可以包容传统学说的新理论。传统理
论只是其在旧有尺度下自然“退化”的一种近似。
技术的发展和演变不需要革命,需要的是包容过往并且实现
自然的过渡。
集群的设计 · 原则
Taobao Arch Team 11
- 12. 集群的设计 · 原则
Taobao Arch Team 13
• 无形 (Invisibility):客户端感知不到集群的存在
不显著改变客户端与服务端现有的交互过程
• 降低客户端的复杂度
在客户端包含尽可能少的逻辑 (Dumb Client)
• 集群机制的调整不用连带客户端升级
- 13. 集群的设计 · 原则
Taobao Arch Team 14
• 去中心化 (Decentralized):跳出传统的C/S模型
★ 点对点(P2P)网络的启示
• 彻底消除可靠性的单点瓶颈
• 网络流量及资源消耗(运算、存储)的自然均衡
• 任意尺度的网络割裂与聚合的自适应
• 更利于大尺度的延展
☆ 同时也应认识到P2P的不足
• 全局可维性的削弱,安全性降低,大量连接的耗损
- 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: 外部依赖、灵活性受限
为保证去中心化而
不得不牺牲简单性
- 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连接数,同步、校验、路由等消息量
• 以略微牺牲小部分实时性为代价。
Editor's Notes
- 延展性:单节点的TCP连接数上限
实时性:大量推送的高延迟
- 前瞻性:需要为未来1-3年的延展需求铺路。
热力学第二定律告诉我们,耗散是不可避免的。但耗散并不总是对系统有害,在开放的动态系统中,它是维持系统平衡的一个必要条件。
“自然界中的组织不应也不能通过中央管理得以维持;秩序只有通过自组织才能维持。自组织系统能够适应普遍的环境,即系统以热力学响应对环境中的变化作出反应, 此种响应使系统变得异常地柔韧且鲁棒,以抗衡外部的扰动。我们想指出,自组织系统比传统人类技术优越,传统人类技术仔细地回避复杂性,分层地管理几乎所有的技术过程。”
——《确定性的终结》(The End of Certainty),伊利亚·普利高津
Factor > 1 的典型例子:RAID-0,容量线性延展的同时,额外获得了性能的显著提升
- 【注解】
故障的抵御性:针对一些已知和未知的故障可能性,作出正确的处理或修正。
故障的收敛性:故障发生后,随着节点的扩散和时间的推移,其影响在逐步减小,甚至完全消除。(自愈)
·内秉性收敛:数据交互模型的幂等性(以配置中心本身机制为例)、数据传输路径的无关性(例如TCP/IP的路由迂回)
·主动式收敛:周期性数据校验和修正
故障的豁免性:设计本身具备对某些常见类型故障或缺陷的天然抵御能力。这是可靠性设计的最高境界。
·例如:虚拟机的封闭沙盒模型、Microsoft Singularity的程序验证机制。
- ·托伯列南国的图景告诉我们,自然界在不同尺度下遵循着高度相似的规律。相似是指本质精髓的一致性,而细微的差别则体现为对不同尺的适应性演变。
·从牛顿力学到相对论&量子力学的发展所给予我们的启示:解决不同尺度下的问题并不是要推翻适用于原有尺度的传统理论,而是要找到一种可以包容传统学说的新理论。传统理论只是它在旧有尺度下自然“退化”的一种近似形态。技术的发展和演变不需要革命,需要的是包容过往并且实现自然的过渡。
·举华为的例子:革命性的架构往往是空中楼阁,几乎没有条件落地。我们需要的是可以在现有架构下平稳过渡的“君主立宪制”。
- 因由:客户端的代码稳定性需要、升级的繁琐性
BTW,顺带提及:通配符机制从客户端的剥离,变为纯服务端实现的特性。
- 顺便介绍:纯P2P网络 和 混合P2P网络
- 【案例】对数据库的依赖可能导致第三方数据库成为容灾机制的关键依赖。
稳定性风险,特指需要一定的时间检验整套机制的稳定性,而非机制本身存在稳定性缺陷。
- 【案例】对数据库的依赖可能导致第三方数据库成为容灾机制的关键依赖。
稳定性风险,特指需要一定的时间检验整套机制的稳定性,而非机制本身存在稳定性缺陷。
- 【案例】对数据库的依赖可能导致第三方数据库成为容灾机制的关键依赖。
稳定性风险,特指需要一定的时间检验整套机制的稳定性,而非机制本身存在稳定性缺陷。
- Discovery的实现目前是采用以唯一或少量域名作为集群的接入点,在机制上依赖于预先固定配置的DNS,并且无法实现子网内多个独立集群。这也是支付宝使用配置中心时遇到的一个问题。
跨地域数据中心的特点:
·广域数据和局域数据的结合(后者数量远超过前者):需要将目前的“发布式”同步机制变为“订阅式”同步,以实现按需同步。这样,局域数据无需扩散至整个集群,可以有效降低超大尺度延展时的存储和同步负担。