女娲：阿里云分布式一致性协同服务架构详解
摘要：在11月24日阿里云·云栖社区组织的飞天系列培训上，来自阿里云女娲团队的存储专家朱云锋分享了《女娲：阿里云高性能、高可扩展的分布式一致性协同服务》。
他的演讲内容主要分为四个方面：分布式协同服务背景、女娲服务架构以及技术演进、典型女娲服务应用场景分享、全球化架构下的女娲进化，下面是本次分享内容整理。
点击查看回顾视频
分布式协同服务背景
分布式协同服务
在大规模云计算场景中，为保障数据分布式一致性，数量众多的计算节点往往依赖分布式协同服务来同步对共享资源的互斥访问，或者依赖分布式协同服务的消息通知功能来协调各自之间动作，使众多节点作为一个整体完成一项工作。
作为云计算分布式系统的核心，在设计分布式协同服务之初需要考虑互斥性、消息通知和扩展性三个方面的问题：
互斥：分布式协同服务应使分布式系统具备互斥属性以实现共享全局资源的独占性，并且确保互斥性之下共享资源的可用性。同时在实现、协议层面上实现互斥的分布式一致性，使所有的计算节点对某个共享资源的独占情况达成共识，
 消息通知：分布式协同服务的消息通知功能应该保证消息通知事件的次数，同时支持高吞吐和低延迟的特性以及确保数据状态的最终一致性。
扩展性：在云计算场景下，随着自身业务规模的不断增加和集群规模的不断扩大，设计需要从架构上确保分布式协同服务的水平扩展性
典型的应用服务
分布式协同服务在云计算场景下的典型应用服务包括以下三类：
分布式锁服务：提供对共享资源的互斥抢占，支持支持Master election，Partition Locking等应用场景。
消息通知服务：主动推送对数据变更消息，支持Naming service，Publish &Subscribe等场景。
Meta存储服务：对轻量Meta元数据提供高可靠存储服务，支持Bootstrapping configuration，Job checkpoint等场景。
云计算与分布式协同系统
分布式协同服务对于云计算系统十分关键与重要，大多数云计算厂商选择了自主研发的方式来实现自己的分布式一致性系统。当前Google、阿里云、Yahoo、CoreOS等公司主流的分布式协同系统采用的核心算法大多来自Leslie Lamport于1989年提出的Paxos分布式一致性算法。
女娲服务架构以及技术演进
女娲是阿里云飞天系统核心基础模块之一，它在09年飞天建立之初即开始研发。目前女娲为飞天的业务系统提供了分布式锁、名字解析、Meta存储等一系列的分布式一致性服务。女娲产品在阿里云内部得到了广泛的应用，支撑着MaxCompute、ECS、TableStore、OSS等众多重量级云产品，同时对阿里集团菜鸟、蚂蚁等部分产品也提供服务化的分布式协同服务。
在飞天系统的架构上，飞天的分布式存储系统——盘古和分布式资源调度系统——伏羲直接支撑着ECS、OSS、TableStore等上层的云产品。而女娲作为提供分布式协同服务的基础模块，直接支持着盘古和伏羲模块。此外，因为对分布式系统中的名字解析这类服务的普遍需求，大量的上层云产品也在直接地使用女娲的分布式协同服务。
阿里设计飞天女娲的目标主要分为三个层次：
正确性：系统必须能够处理client和server机器上的线程的Hang，网络包大幅的延迟，机器时钟跳变等异常情形，以确保分布式锁的正确性。系统的消息通知服务必须确保数据、状态最终一致性，不漏下任何的通知。系统的存储数据服务则应是高可靠的，具备容错能力以容忍节点故障。
服务性能：从早期支持5k规模的分布集群到后开的10k规模，乃至今天更大规模的集群，服务性能一直是飞天女娲追求的目标。在典型的服务场景下，飞天女娲需要支持百万把分布式锁规模，并且确保锁当failover场景下切换时间在10s以内，同时飞天女娲还应该支撑万台集群中大规模高效消息通知服务，并且控制延迟在毫秒级别。
水平扩展性：飞天女娲应具备具备高水平扩展性。为支持业务的可持续发展，分布式协同服务在软件架构上必须基于用户资源水平扩展来支持后端物理存储，并且通过动态扩容的方式来快速提升消息通知以及分布式锁服务服务容量。
为了达到女娲的分布式协同服务的设计目标，女娲的服务架构从下至上被分为四层：
第一层——SDK层：SDK层是女娲分布式服务的第一层。各类应用基于女娲SDK来使用女娲分布式协同服务，包括分布式锁，名字解析，Meta存储等等服务，当然应用本身也可以使用RESTful API来直接使用女娲分布式系统服务。
第二层——Load Balancing层：直接处理各类client发来的服务请求。这一层整合了VIP，VIP server以及未来的DNS解决方案来实现访问流量的负载均衡，支持Proxy Layer并且实现了与业务无感的动态的扩容和缩容。
第三层——Proxy层：这一层是挂载在Load Balancing 层上的女娲代理层，提供了集群内成千上万客户端订阅行为的共享，并代理了客户端与女娲后端一致性call的连接，这是对女娲一致性服务的水平扩展。
第四层——Quorums层：这是女娲后端最核心的Consensus Core，里面包含的众多分布式一致性的Quorum，每个Quorum内部都是基于一致性算法实现的独立的分布式一致性系统，其请求都是依赖前台的Proxy的代理转发。
名字解析服务
女娲是基于消息通知来实现稳定、高效的名字解析服务。具体的服务流程如下：在这个服务中，女娲的客户端首先引入基于消息通知的缓存，这样极大地减少名字解析服务对后端无意义的、过多的访问压力。
从上层的业务方的角度来看，名字解析请求主要三种情况：
第一种情况，请求首先会在本地的缓冲中检查是否存在该Key值对应的Cache Item，如果不存在则会访问后端并用读取到的内容来更新本地缓存的Cache Item，同时将其状态置为New。
第二种情况，如果业务的名字解析请求在本地缓存中找到了该Key值对应的Cache Item，但其Status状态为old，那么请求仍会访问后端，然后读取并更新缓存以及Status状态。
第三种情况是最常见的，在缓存中存在Key值对应的Cache Item，并且Status状态为New，此时用户的请求会直接访问本地的缓存，然后返回给用户方。
简而言之，如果业务的service master在女娲后端中没有变化，所有女娲的client至多访问后端一次。因为正确性和实时性是名字解析服务测评中优先等级级最高的任务，因此客户端如何准实时地维护Cache值是十分重要的。这里女娲端会订阅本地缓存中所有Cache Item对应的Key值在女娲后端的变化情况。当收到后端对应Key值改变这个事件通知时，client会及时更改本地缓存中相应的Cache Item的Status状态为Old，以确保下次业务通过女娲client的名字解析接口来访问该Key值的时候，client最终会通过Status状态判断，再到后端读取最新的内容。
在女娲Client端引入了基于消息通知的分布式缓存来提供相对高效的名字解析服务适用于小规模、数百台的集群。但女娲上层业务的迅速增加，集群规模也在不断扩大，成千上万的女娲client对后端的数据库连接和订阅行为也会随之增加，这会导致单个订阅行为获得订阅反馈的延迟增加，从而影响到client获取最新订阅内容的时效性，最终对后端的连接压力造成了不小的挑战。
为此，女娲在Client与Quorum Server间引入无状态Proxy代理，支持集群内成千上万Client进程订阅行为共享，以及提供名字解析的二级缓存。其中Proxy针对每个Key，只会维持一份Cache Item，但它可以挂载多个感兴趣的Client。Client则定期与Proxy心跳，并带回Cache对应的改变事件，同时更新本地Cache状态。
分布式锁
女娲的分布式锁是基于解耦会话连接来实现健壮和高可扩展：
什么是会话？它是一致性系统中Client和Server间建立的活跃连接，是实现分布式锁的关键概念。事实上，正是基于session会话，女娲的分布式一致性系统实现了分布锁的生命周期以及所有权的维护机制。Client是基于自己的Session会话来分享分布式锁，分享成功后Server端会将这个分布式锁当前的Owner记录为这个client session。一旦session会话在client端过期，这意味着client会意识到分布式锁已经丢失。同样一旦session会话在server端过期，server端也会认为这个分布式锁被释放掉了，主动释放这个分布式锁所占用的资源，此时其他的client就会有机会来争夺这个资源。
Client需要和Quorum server做互相的定期心跳，更新session会话在client和server两端的生命日期以维护锁的所有权。Session生命日期维护机制必须要确保client端比server端先意识到session过期事件，否则这会导致多个client同时认为自己占据了同一分布式锁的严重的后果。这里如何将会话与连接解耦管理主要包括两个模块：
连接管理模块：负责建立Client与Server间长连接，并在连接异常时主动切换Server，并建立新的连接。
 会话管理模块：用于协商client与server之间会话的生命期，创建并删除session会话，并且基于定期心跳来维护Session在Client/Server两端的生命期。
飞天女娲在Client与Server之间引入了无状态的Proxy层。它代理至后端Servers的连接，并聚合了客户端的访问请求，从根本上减轻了后端的连接压力。这样在client和Quorum后端实际上就多了一层连接管理，这里Proxy扮演着网络中类似交换机的角色，当client发出的心跳包因为故障而无法发送时，这时client会自动更换Proxy代理，这样就能更好地处理Master Failover场景，增强系统的健壮性。
水平扩展
为了支持水平扩展性，女娲参照了传统的Partition分区并基于物理上多个Consensu Core划分成多个Partition分区，并引入逻辑Domain概念，通过Proxy代理层做逻辑Domain至物理Consensus Core的映射。
引入区域化的System Quorum来管理全局的逻辑Domain至物理Consensus Core的映射关系
支持动态增加物理Consensus Core，扩容一致性服务能力。
飞天女娲的服务化演进
飞天女娲的服务化演进：
显著节约：女娲分布式协同系统能显著降低系统部署成本
RESTful APIs：给业务方提供十分友好的接入方式
理清与业务的边界，最专业的人运维最熟悉的系统
典型女娲服务应用场景分享
大规模分布式场景下全局一致的高效全局信息更新机制
大规模分布式跨区域部署的业务往往面临着全局信息更新的需求，并且需要保证在一定条件下高效地一致地更新，比如阿里巴巴，eBay，Amazon等国际性电商平台在全局性业务表中数据的更新。以电商的全局业务表为例，这里的问题包括以下三种：
跨区域下更新效率的问题：跨区域电商平台路由的数据很大，跨区域场景下更新业务表的效率会比较低，会导致跨境电商平台因为多个数据更新导致其不可服务时间增大。
跨区域场景下数据不一致问题：跨区域场景下新版本的路由表主要是通过管控中心去推送到各个区域的分布式环境系统中，管控中心是这个区域的一个网络链路，物理距离，区域接受到路由数据的更新也是动态的，而更新过程总服务还得延续，所有就有可能出现不同区域基于不同版本路由的数据来服务电商用户，这会导致电商平台本身在
跨区域场景下全局状态同步更新的问题：当这些数据被更新，并被推送到各个应用之后，业务应用完成了自己的路由数据更新，它会主动向管控中心的系统发送更新完成的确认信息。由此管控中心可以确认全局数据更新是完整的。但是因为各区域更新路由表存在快慢差异，有些区域的应用服务可能因为发生了故障而无法完成新版本路由数据的更新，甚至有些区域的应用会假死一段时间，导致系统更新了却没有办法把更新后的状态反馈给管控中心。
针对更新效率问题，每个区域的会分别有个分布式缓存系统来缓存多个版本的全局信息数据。每个区域还会有女娲分布式协同服务系统，来存储全局数据中的Meta信息，这样就可以将原来跨平台的全局数据更新问题转化为全局数据中Meta信息的更新问题。针对全局信息更新的状态同步问题，依据女娲分布式协同服务中session在client和server两端协商及能够确保Server端比Client端后意识到Session过期的维护机制，是可以支持全局信息更新状态同步的。管控中心能够区域部署女娲分布式协同系统来获取当前全局状态更新的信息。最后针对全局数据更新的一致性，区域数据不能出现新旧版本共存这类问题。这里女娲在新旧版本之间引入一个兼容的过渡版本，具体实现，也是留给读者们去思考
为超大规模集群提供分布式协同服务。
这里主要的难点是动态和高可扩展。这里的解决方案是基于分布式系统中解耦连接管理和基于消息通知的分布式缓存的机制，通过在中间引入一个Proxy代理层来代理客户端与后端的连接，聚合一些访问请求，更关键的是基于Proxy层，引入了对后端资源分配的概念，从而在软件的架构上支持后端物理层基于用户资源的水平扩展。
支持负载均衡的在线服务
支持负载均衡的在线服务，平滑实现在线扩容、缩容的轻量级在线服务管理组件。现在的很多云产品服务均会有多个应用的server在提供服务，这里对server进行负载均和动态的扩容缩容是这类云产品服务的刚性需求。基于女娲分布式协同服务可以很多打包解决这些问题。每个应用服务的server均会将自己的服务地址注册到该业务服务在女娲系统下的制定目录，然后应用服务server会与女娲保持定期的在线心跳，以确保当前server是正常的，否则女娲会主动剔除其服务地址。
全球化架构下的女娲进化
随着全球化的趋势逐渐增强，这对分布式系统跨地域连接也提出了更高的要求。为此阿里正不断地完善和发展飞天操作系统，以实现飞天系统的全球化部署，与此同时作为飞天系统中提供一致性协同服务的女娲模块也在不断地进化。
飞天系统的全球化部署
当前阿里云飞天操作系统已经实现了全球化部署，在欧洲、美国、中东、澳洲等多地都提供了云服务，并且整个全球化进程还在不断提速中。另外一个背景是飞天女娲分布式协同服务支撑的上层各类应用和业务也存在跨区域的部署和运维等前台需求。
跨区域业务部署对一致性场景的述求
跨区域业务部署对一致性场景的述求主要分为以下三种场景:
Global Lock：支持跨地域部署，并提供跨地域场景下的分布式锁服务，以为业务方解决业务跨区域同步互斥的需求。
Global Meta：提供Meta存储场景，具备扩展性更高的存储和性能，解决业务刚需的跨区域可用性问题。
Meta of Meta：解决跨地域业务系统不可避免的数据本地化、数据流通合规约束，这需要在Meta数据之上提供一个全局的Meta管理，确保数据合规。
跨区域一致性协同服务的思考点
跨区域部署一致性协同服务并非是一个简单的事情，它在技术上存在很多挑战，比如：
保证区域数据同步，尤其在大流量下保证Latency。
支持跨区域的高效强一致性读取。
在大数据无法估算情况下保证跨区域系统的稳定性。
 使已有的区域本地化数据在跨区域一致性系统中平滑上下线。
总结
女娲（Nuwa）是阿里云飞天系统底层核心模块之一，从2009年飞天建立起开始自主开发。女娲对基于飞天的系统提供一致性、分布式锁、消息通知等服务，在阿里云内部支持着MaxCompute、ECS、TableStore、OSS等重量级云产品，并且与有类似功能的开源软件相比，女娲在性能，可扩展性和可运维性上有明显优势。在全球化的架构下，阿里将不断完善和发展女娲，使其提供更优质的一致性服务。