如何用服务器做网站,网站开发经验教训,张家港seo建站,软件开发的六大步骤CAP理论 加州大学终身教授与著名计算机科学家Eric Allen Brewer在90年代末提出了CAP理论#xff0c;理论断言任一个基于网络的分布式系统#xff0c;最多只能满足“数据一致性”、“可用性”、“分区容错性”三要素中的两个要素。 该理论后被MIT证明可行#xff0c;故架构师… CAP理论 加州大学终身教授与著名计算机科学家Eric Allen Brewer在90年代末提出了CAP理论理论断言任一个基于网络的分布式系统最多只能满足“数据一致性”、“可用性”、“分区容错性”三要素中的两个要素。 该理论后被MIT证明可行故架构师无需将精力浪费在如何设计能满足三者的完美分布式系统而是应该进行取舍。 CAP理论也即被捧为“分布式系统设计”的重要评分标准其包含下述三项定义 Consistency(一致性)集群中所有节点在同一时刻可见同样的值。Availability(可用性)健康的节点在限时内可返回可靠的结果。Partition tolerance(分区容错性)集群中某些节点失联后集群仍可继续服务。 那为什么一个系统只能同时满足三要素中的两个要素呢我们来看看下面例子 1.首先使分布式系统满足“分区容错性”要素 当上海、台北服务器共用数据存储时上海数据中心存储的宕机将造成台北服务器也不可用拓扑图如下。 如何来满足分区容错性我们可在各数据中心分别建存储机制在各数据中心存储进行写操作的同时触发存储同步保障数据中心间存储数据同步。 故当任一数据中心存储宕机也不会造成其它数据中心的存储读写操作如下图所示 2.满足“分区容错性”的前提下“一致性”“可用性”两者只可选其一假定当前两地存储中的数据为“版本1”此时上海与台北数据中心网络中断存储间无法同步。然后上海服务器将数据版本更新为“版本2”由于同步受阻台北数据中心仍保存数据版本“版本1”如下图所示 “台北服务器向台北分区存储进行查询”这一动作在CAP理论模型下只能满足下述情况之一 CP保障“一致性”放弃“可用性” 等待网络恢复正常上海存储将“版本2”同步至台北存储台北存储将满足“一致性”的数据“版本2”返回给服务器。 由于网络恢复时间的不确定性请求可能会超时违反“可用性”限时的条件。 AP保障“可用性”放弃“一致性” 台北存储在“可用性”高响应的驱动下将过期数据“版本1”返回给服务器。 由于返回的“版本1”与最新数据“版本2”不一致违反了“一致性”。 CAP理论小结 无论CPAP还是CA在CAP理论驱动下的系统都以SLAService Level Agreement为系统最终评估基准。目前SLA 5个9乃至6个9的系统都会以AP设计为重略微放弃一致性来换取系统的“活”。 目前主流的分布式系统设计理论BASEBasically Available 基本可用Soft State 软状态Eventual Consistency 最终一致性则是对CAP中AP理论的扩展通过实现“最终一致性”来保障SLA的同时确保信息准确。 基于BASE理论设计的主要的产品则为主流NoSQL数据库包括CassandraMongoDBRedis, CouchDB等。 故在AP模型稳定的情况下SLA指标中能有几个9与Consistency一致性的算法实现密切相关下面我们来看一下“一致性算法” 一致性算法Raft 20世纪80年代开始一致性算法的研究就没有停止过主流的实现则依赖共享内存Shared memory和消息传递Messages passing。直至21世纪的今天基于“消息传递”为一致性算法实现的系统占到了绝大多数。 微软研究院首席科学家、2013年图林奖获得者LeslieLamport于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法Paxos。该算法的典型应用场景为分布式数据库在一个多节点的分布式系统中“使用一致性算法”保证每个节点执行相同的命令序列确保每个节点的状态一致。 Google的分布式锁服务ChubbyApache的分布式服务框架ZooKeeper都是基于Paxos算法进行的实现。Paxos也是类似算法中最为可靠与广知的但Paxos算法的流程复杂与实现困难导致世界级产品数量极少。 2013年来自Stanford大学的DiegoOngaro、John Ousterhout发布论文“In Search of an Understandable Consensus Algorithm”公布了的新的分布式协议研究称为Raft它是一个为真实世界应用建立的协议主要注重协议的落地性和可理解性。 时至今日Raft的易实现性使其成为与Paxos同级别的一致性算法在Raft的Github官网上已发布了十多种Raft一致性算法的实现生态圈日渐强大。详细信息可见https://raft.github.io/ 主流的服务发现框架EtcdConsul等都是基于Raft一致性算法实现的。Google开源的容器集群管理Kubernetes作为Docker生态圈中重要一员也是基于Raft来管理一致性的。 Raft算法拆解后主要包含三大功能各功能运作的完整流程也可参考Raft可视化网站让我们通过生动的图形来了解Raft算法的秘密吧 网址 http://thesecretlivesofdata.com/raft/ 1. Leader选取 Raft服务集群中有3个角色LeaderCandidate与Follower。Leader则会统一管理Follower与自己的状态机同步。 Raft使用心跳机制来触发选举Leader。在没有Leader的情况下在Follower默认的“选举计时器”150毫秒到300毫秒超时超时后将会推举自己为Candidate当大多数n/21 节点同意后将会升级为Leader。然后Leader与Follower间使用心跳进行状态维护只要心跳是在“心跳计时器”超时范围内Leader状态则可永久保持。 在Raft算法内只会存在一个Leader与多个Follower集群维护单个数服务器。 *在极端多Follower“选举计时器”同时超时多Candidate同时出现的情况下则以收到其他Follower推举回应同时重置“选举计时器”的时间点来决定最终Leader。 Leader选举的流程如下图来自Stanford论文 2. 日志复制、同步 Leader角色负责日志同步流程如下 当Leader收到客户端信息则先写入本地日志文件同时将信息发给其他Follower。当大多数Follower保存至本地成功则回复Leader成功Leader获取大多数Follower回复后提交本地写入的日志并则通知客户端收到信息。 如Follower有丢包或者奔溃Leader将进行重试来保障一致性。所以数据的最终提交、状态机的维护将由Leader决定。Leader会保障多数节点写入信息来进行最终提交。 如下图所示Leader上最后写入的x-4未被提交则是由于仅有Leader与1/4的Follower共2/5的节点写入此日志。而x-5则有Leader与1/2的Follower共3/5 (n/21)节点写入此日志Leader发现大多数节点3/5已写入信息成功做了最终提交。 3. 安全性 Leader作为Raft集群的控制核心也存在奔溃的可能。此时则集群中任意Follower可推举自己为Candidate。Raft的安全性保障当Follower如没有获得当前完整Committed entries见上图时则无法成为Candidate。此安全性举动保障了数据的可靠性不会丢数据。 如要保障新选举的Leader不会将过期脏数据同步至Follower。安全性检查会在做数据的提交时也检查当前Leader所要提交的数据至少有一个存储在大部分Follower上。 当新Leader在工作的同时老Leader突然恢复工作。Raft的安全性保障使用Term号的方式使老Leader发出的过期Term号对所有Follower都不生效。保障了老Leader不会触发错误同步直至降级为Follower。 Raft一致性算法小结 Raft通过算法实现强一致性。但是其单一Leader节点的设计在写操作量大的情况下会造成单点写瓶颈。故使用场景为读操作大于写操作的对一致性要求高的系统。 服务发现框架Consul介绍 Consul为Hashicorp公司使用Go语言编写的开源项目其核心是基于RaftCAP一致性算法与GossipBASE最终一致性算法进行实现的。基于Raft与Gossip的Consul集群可保障Consul Server集群服务端间的数据一致性同步Consul Server集群与集群间、Consul Agent客户端与Agent间的数据最终一致性同步。 *Gossip最终一致性算法尝试解决的问题是在一个有界网络中每个节点都随机地与其他节点通信经过一番杂乱无章的通信最终所有节点的状态都会达成一致。Gossip具有“去中心化的特点”也天然具有分布式容错虽然无法保证在某个时刻所有节点状态一致但可以保证在”最终“所有节点一致。 Consul的特色非常适合融入当前互联网公司的微服务架构可轻松覆盖多种操作系统。官方已经发布的Consul客户端支持Mac OS X、FreeBSD、Linux、Solaris、Windows等多种操作系统发布在这些操作系统上的Restful API都可轻松接入Consul集群。 Consul产品开源的同时也提供了多种语言的接入SDK包括GoPythonPhpScalaJavaErLangRubyNode.js.NETPerl等大大降低了开发人员的接入工时。 下图为Consul在多数据中心部署的架构图单数据中心内使用Raft算法保障服务端一致性同时使用Gossip协议进行跨数据中心WAN Gossip同步与客户端间LAN Gossip同步。 两种一致性算法结合使用的Consul集群可保证各个节点的数据一致。 .NET API服务如何接入Consul服务发现框架 首先将Consul以服务端模式部署在至少3台总台数为单数服务器上然后在.NET API部署服务器上安装Consul Agent模式。 由于.NET API多运行于Windows服务器上可使用nssm.exehttp://www.nssm.cc/来进行从命令行至windows服务的包装保障跨Windows会话的安全性。 服务端启动脚本需使用-ui-dir来指定UI项目路径 Consul agent -server -bootstrap-expect 2 -data-dir D:\TGOP\ServiceDiscovery\ConsulData -nodeTGOP-Consul-Server1 -bind172.16.11.211 -dcShanghai-DC1 -client172.16.11.211 -ui-dir./UI Agent端启动脚本仅需加入指定Consul服务端集群 Consul agent -data-dir D:\TGOP\ServiceDiscovery\ConsulData -nodeTGOP-Consul-Agent-LucasPC -bind127.0.0.1 -dcShanghai-DC1 -client127.0.0.1 -join tgop-apistore.vipabc.com Consul服务端与Agent端启动后可通过http://consulserver:8500/ui 地址进行Consul集群健康状态管理。 .NET API服务发布与发现的SDK接入方法 通过Nuget包管理器还原并安装Consul.NET SDK安装包当前版本为7.0.5。使用SDK安装包中提供的ConsulClient.Agent.ServiceRegister方法进行“服务注册”可使用的默认Agent地址为http://127.0.0.1:8500/ 核心方法如下 TaskWriteResult ServiceRegister(AgentServiceRegistration service, CancellationToken ct null); 使用ConsulClient.Agent. ServiceDeregister方法进行“服务注销” TaskWriteResult ServiceDeregister(string serviceID, CancellationToken ct null); 使用ConsulClient.Health.Service方法进行“服务发现”将会返回符合要求的服务列表后通过主流负载均衡算法进行最终服务筛选完成服务发现流程。 TaskQueryResultServiceEntry[] Service(string service, string tag, bool passingOnly, CancellationToken ct null); 在.NET API启动与退出时集成Consul.NET SDK相应的注册与注销方法完成服务自注册。在.NET API需要与其他API进行通讯时使用服务发现方法完成地址查询后发起Restful HTTP请求完成API调用。 进行服务注册时需通过AgentServiceRegistration.AgentServiceCheck类型将心跳HTTP的接口信息心跳间隔信息等同时递交注册ConsulAgent将会以配置好的间隔对服务进行心跳检查来保障任意Agent进行“服务发现”时获取的注册API为可用的。 Consul服务发现框架集成小结 在Consul集群基础设施部署完毕相应SDK语言包成熟的基础上用户开发的Restful API可轻松接入集群。Consul的核心架构于一致性算法的基石上各服务节点的信息可靠性、可用性得到高保障服务与服务之间可无障碍进行沟通形成微服务网。 参考文献 https://en.wikipedia.org/wiki/Eric_Brewer_(scientist) https://en.wikipedia.org/wiki/CAP_theorem http://www.julianbrowne.com/article/viewer/brewers-cap-theorem https://en.wikipedia.org/wiki/Raft_(computer_science) https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf https://en.wikipedia.org/wiki/Paxos_(computer_science) https://en.wikipedia.org/wiki/Gossip https://raft.github.io/ http://thesecretlivesofdata.com/raft/ https://www.consul.io/docs/internals/architecture.html https://www.nuget.org/packages/Consul 相关文章: Consul入门使用C# 和Consul进行分布式系统协调Consul 服务注册与服务发现搭建consul 集群 原文地址http://www.rcgus.com/gyys377188451/2352438.html.NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
