网站建设的步骤图片过程,佛山百度seo代理,seo网站优化专家,wordpress 个人照片导读#xff1a;服务治理目前越来越被企业建设所重视#xff0c;特别现在云原生#xff0c;微服务等各种技术被更多的企业所应用#xff0c;本文内容是百度小程序团队基于大模型服务治理实战经验的一些总结#xff0c;同时结合当前较火的分布式开源kv产品etcd#xff0c;… 导读服务治理目前越来越被企业建设所重视特别现在云原生微服务等各种技术被更多的企业所应用本文内容是百度小程序团队基于大模型服务治理实战经验的一些总结同时结合当前较火的分布式开源kv产品etcd不仅会深入剖析ectd两大核心技术Raft与boltdb的实现原理也会披露服务治理真实实践的经验希望帮助大家在服务治理的道路上获得更多帮助。 一、服务治理概念介绍
服务治理是IT治理的一部分它关注服务生命周期中的相关要素其重点环节包括服务注册和发现、服务平滑升级、流量监控、流量管控、故障定位、安全性等。 需要框架源码的朋友可以看我个人简介联系我。推荐分布式架构源码 服务是需要治理的但是治理是需要成本的如果一个服务的业务逻辑简单运行流程清晰出现问题也能及时定位和回滚那么该服务治理的成本可能非常低甚至只需要人工处理就行但是在复杂业务中服务的提供者和服务的使用者可能分别运行在不同的进程中甚至在不同的物理节点上并由不同的团队开发和维护。团队协作和服务协同都需要进行大量的协调工作。协调工作越多复杂度越高这样就有了服务治理的需求通过建设统一的服务治理平台就可以有有效的提升业务的服务治理能力包括协同的规范化、实时监控不断优化调用链路的效率以及辅助降低依赖复杂度规避风险等。在大型业务系统中服务治理已经是技术架构中必不可缺的一部分也是整个业务系统最重要的基础设施之一。 上图是网上流传的netflix的服务拓扑图图中密密麻麻的白色小点就是netflix的服务节点节点之间的连线表明服务之间有调用节点和连线构成了复杂的服务调用链如此庞大的应用系统必须要通过一个强力的服务治理平台来进行管理。
服务治理本质上是对服务生命周期的管控因而服务治理平台的核心需求就是如何解决服务生命周期中的痛点问题其包括以下几个方面
1、注册和发现
服务调用方在调用服务之前必须要得到服务提供方的地址也就是调用方需要通过一种方式“发现“服务提供方这就是服务发现。而要完成服务发现就需要将服务提供方的信息存储到某个载体这个存储的动作即是”服务注册“而存储的载体则称为”服务注册中心“。在任何一个服务治理平台中注册中心是必不可少的一个模块。服务注册和发现是服务治理中最基础的功能在服务生命周期中它负责服务的初始环节。
2、流量监控 在服务注册发现之后就是服务的调用大量的服务调用形成了流量。流量监控就是对众多服务间的调用关系、状态的清晰掌控。其主要包括了调用拓扑关系、调用追踪、日志、监控告警等服务治理通过调用拓扑来整体监控服务调用关系通过建立监控体系来快速发现、定位问题从而在整体上感知业务系统的运行状况。在服务生命周期中流量监控负责服务的运行态感知。
3、流量调度 在业务系统运行过程中经常会有比如促销、秒杀、明星绯闻等热点问题或者机房断网、断电、系统大范围升级等突发事件带来业务系统中局部服务的流量突增突降这样就需要对服务的流量进行调度和管理。流量管理包括两个方面从微观的单个服务来说就是服务调用过程的管理包括在何时采用何种均衡负载策略、路由策略以及熔断限流策略这些策略统称为调用策略从宏观上来说就是流量分发的管理可以根据某些流量特征和流量占比进行灰度发布、蓝绿发布等这些称为流量分发策略。服务调用策略、流量分发策略都需要通过流量监控收集的调用数据进行分析从而制定出决策然后在服务治理平台上落地。流量调度负责服务的运行态管理。
4、服务控制 流量调度的策略如何在服务的提供方和调用方生效可以重启生效也可以在运行态实时生效这就是看服务治理平台对服务的控制力度服务治理平台在充分建设服务治理能力后能实时把服务治理的策略向服务进行分发并立即生效。
5、服务安全 每个服务都承载自身的业务职责一些业务敏感的服务需要对其他服务的访问进行认证与鉴权也就是安全问题。
本文把拥有成千上万的服务称之为大型应用系统该系统的特征是大量的服务、大量的服务实例、以及海量的服务调用服务治理平台在管理这类业务系统的服务时需要面对以下巨大的挑战
1. 高可靠性 大型业务系统海量的服务调用错综复杂的调用关系对服务的可靠性要求很高很多基层的服务都要求99.99%的可靠性因而维护这些服务的服务治理平台其可靠性的要求也非常高而要达到这么高的可靠性服务治理平台本身也需要做到多级部署、多地热备、降级隔离、平滑上线等方案。
2. 高性能 在保证可靠性的前提下服务治理还必须有很高的性能比如在监控数据中快速准确的感知到某个服务的出现了单点故障从而能够将流量分发到该服务的其他进程上去。如果业务系统的服务数不多调用量不高那么监控数据量也不会很大服务的单点故障很容易就能查到但是在实时的海量调用数据中一些常规的查询手段要花费大量的时间等感知到单点故障时可能已经造成了不可挽回的业务损失。所以性能是考量服务治理平台治理能力的一项重要指标如何保证高性能高速的存储、多级缓存、线性部署都是必不可少的。
3. 高扩展 高扩展包含两个方面大型应用系统的服务可能是由多个团队在开发运维其水平和技术能力也是参差不齐的因而服务治理平台需要提供兼容和扩展的能力通过扩展性尽可能的把不同的服务治理起来同时在业务系统服务量增长时服务治理平台也应该具备同步扩展的能力来保证其高可靠和高性能。
面对海量服务的治理挑战服务治理平台也需要有一个强大好用的存储工具来应对etcd就是一个不错的选择。
二、etcd介绍
2.1 etcd发展背景与相关竞品介绍
2013年CoreOS创业团队在构建一款开源轻量级的操作系统ContainerLinux时为了应对用户服务多副本之间协调的问题自研开发的一款用于配置共享和服务发现的高可用KV分布式存储组件——ETCD。
下面我们也针对Zookeeper和Consul两个选型做了一下对比
· ZooKeeper ZooKeeper从高可用性数据一致性功能这三个方面而言是完全符合需求的但CoreOS还是坚持自研etcd的原因总结有以下两点
1. ZooKeeper不支持通过API安全地变更成员需要人工修改节点配置并重启进程.如果操作有误有可能导致脑裂等线上故障同时CoreOS对适配云环境集群规模的平滑调整运行时配置的在线变更都是有期望目标的这方面ZooKeeper的维护成本比较高。
高负载读写性能ZooKeeper在大规模的实例连接情况下性能表现并不佳。
etcd名字是由“/etc”文件夹和”d”分布式系统组成。“/etc”文件夹是用来存储单系统配置数据的而“etcd”用于存储大规模分布式系统的配置数据etcd集群可提供高稳定性高可靠性高伸缩性和高性能的分布式KV存储服务。etcd是基于复制状态机实现的由Raft一致性模块日志模块基于boltdb持久化存储的状态机组成可应用于分布式系统的配置管理服务发现分布式一致性等等。
ZooKeeper与etcd一样可解决分布式系统一致性和元数据存储等问题但是etcd相较于ZooKeeper有以下几点优势
1. 动态集群成员关系重新配置
2. 高负载下稳定的读写能力
3. 多版本并发控制数据模型
4. 可靠的键监控
5. Lease(租约)原语将连接和会话分离
6. 分布式锁保证API安全性
7. ZooKeeper使用自己的RPC协议使用受限而etcd客户端协议是基于gRPC的可支持多种语言。
· Consul
Consul与etcd解决的是不同的问题etcd用于分布式一致性KV存储而Consul侧重于端到端的服务发现它提供了内置的健康检查失败检测和DNS服务等等另外Consul通过RESTfulHTTPAPIs提供KV存储能力.但是当KV使用量达到百万级时会出现高延迟和内存压力等问题。
一致性算法方面etcd、Consul基于Raft算法实现数据复制ZooKeeper则是基于Zab算法实现。Raft算法由Leader选举日志同步安全性组成而Zab协议则由Leader选举、发现、同步、广播组成。
分布式CAP方面etcd、Consul和ZooKeeper都是CP系统发生网络分区时无法写入新数据。
下表是针对三者的关键能力做了一下对比分析: 2.2 etcd核心技术介绍
基于Raft协议实现数据高可用和强一致性
早期数据存储服务引入多副本复制技术方案来解决单点问题但是无论是主从复制还是去中性化复制都存在一定的缺陷。主从复制运维困难且一致性与可用性难以兼顾去中心化复制存在各种写入冲突问题需要业务处理。而分布式一致性算法正是解决多副本复制存在问题的关键。分布式一致性算法又称为共识算法最早是基于复制状态机背景下提出来的。Paxos作为第一个共识算法过于复杂不容易理解难以在工程上落地。斯坦福大学的Diego提出的Raft算法通过将问题拆解为三个子问题易于理解降低了工程落地难度。这三个子问题是Leader选举日志复制安全性。
Leader选举
etcd(版本3.4)中Raft协议定义集群节点有4种状态Leader、Follower、Candidate、PreCandidate。
正常情况下Leader节点会按照心跳间隔时间定时广播心跳消息给Follower节点以维持Leader身份。Follower收到后回复心跳应答包消息给Leader。Leader都会带有一个任期号(term)任期表示从一次选举开始赢得选举的节点在该任期内担当Leader。任期号单调递增在Raft算法中充当逻辑时钟用于比较各个节点数据新旧识别过期Leader等等。
当Leader节点异常时Follower节点会接收Leader的心跳消息超时当超时时间大于竞选超时时间后会进入PreCandidate状态不自增任期号仅发起预投票(民意调查防止由于节点数据远远落后于其他节点而发起无效选举)获得大多数节点认可后进入Candidate状态.进入Candidate状态的节点会等待一个随机时间然后发起选举流程自增任期号投票给自己并向其他节点发送竞选投票信息。
当节点B收到节点A竞选消息后有2种情况
1. 节点B判断节点A的数据至少和自己一样新节点A任期号大于节点B任期号并且节点B未投票给其他候选者即可投票给节点A节点A获得集群大多数节点支持可成为新Leader。
2. 如果节点B也发起了选举并投票给自己那么它将拒绝投票给节点A。此时若没有节点可以得到大多数投票支持则只能等待竞选超时开启新一轮选举。 日志复制
Raft日志结构如下图所示 Raft日志由有序索引的一个个条目组成每个日志条目包含了任期号和提案内容.Leader通过维护两个字段来追踪各个Follower的进度信息.一个是NextIndex表示Leader发送给该Follower节点的下一个日志条目索引;另一个是MatchIndex表示该Follower节点已复制的最大日志条目索引。
本文以Client提交“helloworld”提案至接收到响应的整个流程为例简单介绍etcd日志复制流程
1. 当Leader接收到Client提交的提案信息后生成日志条目同时遍历各个Follower的日志进度生成对各个Follower追加日志的RPC消息
2. 通过网络模块将追加日志的RPC消息广播给各个Follower
3. Follower接收到追加日志消息并持久化之后回复Leader已复制最大日志条目索引即MatchIndex
4. Leader接收到Follower应答后更新对应Follower的MatchIndex
5. Leader根据各个Follower提交的MatchIndex信息计算出日志条目已提交索引位置该位置代表日志条目被一半以上节点持久化
6. Leader通过心跳告知各个Follower已提交日志索引位置
7. 当Client的提案被标识为已提交后Leader回复Client该提案通过。
通过以上流程Leader同步日志条目给各个Follower保证etcd集群的数据一致性。
安全性
etcd通过给选举和日志复制增加了一系列规则来保证Raft算法的安全性。
选举规则:
1. 一个任期号只能有一个Leader被选举Leader选举需要集群一半以上节点支持
2. 节点收到选举投票时如果候选者最新日志条目的任期号小于自己拒绝投票任期号相同但是日志比自己短同样拒绝投票。
日志复制规则:
1. Leader完全特性如果某个日志条目在某个任期号中已被提交则这个日志条目必然出现在更大任期号的所有Leader中
2. 只附加原则Leader只能追加日志条目不能删除已持久化的日志条目
3. 日志匹配特性Leader发送日志追加信息时会带上前一个日志条目的索引位置(用P表示)和任期号Follower接收到Leader的日志追加信息后会校验索引位置P的任期号与Leader是否一致一致才能追加。 boltdb存储技术
ectd的另一个核心技术是boltdb存储提供高效的b树的检索能力同时支持事务操作他是支撑etcd高性能读写的关键能力之一。
boltdb的实现参见了LMDB(LightningMemory-MappedDatabase)设计思路基于高效快速的内存映射数据库方案.基于B树的结构设计。数据文件设计上bolt使用一个单独的内存映射的文件实现一个写入时拷贝的B树这能让读取更快。而且BoltDB的载入时间很快特别是在从crash恢复的时候因为它不需要去通过读log其实它压根也没有去找到上次成功的事务它仅仅从两个B树的根节点读取ID。
文件存储设计
由于采用了单文件映射存储所以bolt对文件按指定长度进行分块处理每块存储不同的内容类型。默认使用4096字节的长度进行分块。每一块的开头有单独的pageid(int64)标识。
文件块的类型有以下几种 数据文件全景结构
说明 metapage固定在page0与page1位置 Pagesize大小固定在4096字节 bolt的文件写入采用了本地序小端序的模式比如16进制0x0827(2087)写入的内容为2708000000000000
单文件方案的优势就是不需要做文件的合并删除等操作只需要在原文件上追加扩展长度就可以了。
查询设计
boltdb提供了非常高效的查询能力可以先看一下它的对象设计 从对象设计上boltdb在加载时会先loadmeta数据进内存然后根据bucket来定位数据块所在的位置然后再根据key的值来定位branchnode的位置然后定位到叶子值节点。
我们以查询为例来讲解一下下面是一个基本的查询示例代码
tx, err : db.Begin(true) // 开启事务if err ! nil {return}b : tx.Bucket([]byte(MyBucket)) // 根据名称查询bucketv : b.Get([]byte(answer20)) // 根据key进行查询 fmt.Println(string(v))tx.Commit()
对应上面的代码下面的序列图可以更详细的了解一次查询的操作流程 上面最关键的代码就是search方法下面是主要的代码片断已添加了注释说明方便阅读。
func (c *Cursor) search(key []byte, pgid pgid) {p, n : c.bucket.pageNode(pgid)if p ! nil (p.flags(branchPageFlag|leafPageFlag)) 0 {panic(fmt.Sprintf(invalid page type: %d: %x, p.id, p.flags))}// 把当前查询节点(page,node)压入栈e : elemRef{page: p, node: n}c.stack append(c.stack, e)// If were on a leaf page/node then find the specific node.if e.isLeaf() {c.nsearch(key)return}// if node cached seach by nodes inodes fieldif n ! nil {c.searchNode(key, n)return}// recursively to load branch page and call search child node againc.searchPage(key, p)
}
三、百度基于etcd打造大规模服务治理建设思路
3.1 具体的挑战
天路是百度小程序团队开发打造的面向大型业务服务治理需求的一套解决方案其目标之一就是打造成百度的服务治理规范样板。天路由注册中心、可视化管理平台、SDK框架、统一网关、tianlu-mesher五个部分组成目前已经接入了150产品线实例数已达数十万级别。随着接入平台的团队数增多、以及服务实例的快速增长大量团队间如何轻松的协作以及实现大规模服务治理平台的高可用、高性能一直是天路持续面临的挑战。
3.2 整体架构建设思路与方案
天路作为一个服务治理平台核心理念是为所有的服务提供便捷的调用统一的服务监控管理简化服务的开发和维护成本。我们从以下不同的方面思考基于etcd打造大规模服务治理平台高可用、高性能、高扩展、易用性。
· 高可用 考虑到etcd跨机房调用的高网络延时我们采用单机房部署同时我们也实现了主备集群切换的方案解决在单机房实例全部宕机的情况下etcd集群不可用的问题。 为了降低平台对etcd的强依赖我们做了etcd降级使用缓存的方案。在监控到etcd集群的性能无法支持当前平台的时候使用缓存存储实例数据能够让运维人员在恢复etcd之前系统不受影响正常运行etcd恢复之后切换回etcd集群继续工作。
· 高性能 etcd集群的kv查询性能很高qps能达到10000以上。为了解决在极端并发下的性能问题注册中心采用多级缓存提升查询效率降低对etcd的访问压力。 服务间调用使用直连的方式请求不需要经过注册中心进行转发调用基本没有时间损耗。
· 高扩展
考虑到将来服务实例数达到百万级别我们需要考虑架构的高扩展性。
· 易用性 用户通过可视化的管理平台可以查看已注册的服务也可通过管理平台实时更新服务治理策略的配置实时调整服务治理策略。 将调用日志接入trace平台用户可通过traceId在trace平台查到整个调用链的记录便于出错时进行快速的问题定位。 多语言 SDK支持多种rpc技术包括百度自研的rpc技术brpc和http jsonrpc协议等 架构方案图
3.3 关键的指标与运维目标
此外针对更好的实施服务治理平台的运维还需要以下的关键考核指标与运维要求。
关键指标
· 可用性达99.99以上
· 平响100ms以下。
运维目标 故障发现早
· 配置监控告警包括注册中心实例健康、etcd平响、内存和cpu监控。 故障处理快
· 自动处理通过noah的回调机制自动处理一些故障提高处理速度。
· 手动处理值班机制。
四、总结
服务治理目前越来越被企业建设所重视特别现在云原生微服务等各种技术被更多的企业所应用但是要真正在应用好融合好还是有非常多的挑战除了一套成熟的服务治理产品外包括团队整体对服务治理的认知技术经验的深淀遵循服务化的设计能力水平的能力等都会影响到最终的实施效果。本文也仅在服务治理产品选型上给大家一些启发希望在服务治理的道路上帮大家走得更好更稳。
