摘要:背景基于负载均衡的服务调用基于负载均衡的服务相互调用指的是通过基于等负载均衡软件来构建一个负载均衡服务,所有的服务调用都通过负载均衡器从负载均衡的这种模式下其实有两个主要的问题一是中心化,整个系统都基于负载均衡器,负载均衡就相当于整个业务的
背景 基于负载均衡的服务调用
基于负载均衡的服务相互调用指的是通过基于Lvs、Haproxy、Nginx等负载均衡软件来构建一个负载均衡服务,所有的服务调用都通过负载均衡器
从负载均衡的这种模式下其实有两个主要的问题:
一是中心化,整个系统都基于负载均衡器,负载均衡就相当于整个业务的中心,虽然我们可以通过一些高可用手段来保证,但其实内部流量通常是巨大的,很容易出现性能瓶颈
二是增加了一次TCP交互
当然也有很多好处,比如可以做一些负载均衡、长链接维护、分布式跟踪等,这不是本文重点
基于注册中心的服务调用
所有的服务都启动后都通过注册中心来注册自己,同时把注册中心里面的服务信息拉回本地,后续调用,就直接检查本地的服务和节点信息来进行服务节点的调用
每个服务节点都会来注册中心进行服务注册,那数据如何在服务端进行保存呢,其实就是注册表,其实等同于windows 里面的注册表,每个服务都来注册,把自己的信息上报上来,然后注册中心吧注册表,返回给client端,那服务之间就知道要调用服务的节点啦
微服务注册注册中心通常会大量的服务注册, 那不能每次客户端来请求的时候,服务端都返回全量的数据,在数据传输的设计中,通常会有一种增量同步,其实在注册中心中也类似
注册中心通过将最近的服务变更事件保存在一个事件队列中,后续每次客户端拉取只返回增量数据,这样服务端的忘了压力就会小很多
增量数据有一个问题就是,如果客户端错过啦某些事件,比如事件队列满了,则客户端与注册中心的注册表就会不一致, 所以eureka里面引入了一个hashcode的概念,通过比对hashcode是否相同, 如果不同则客户端需要重新全量拉取
系统整体上分为两个端:客户端(Client)和注册中心(Server)
Server: 提供服务注册和获取注册表的接口, 同时本地把保存服务和节点的对应信息,变更事件写入eventQueue
Client: 调用server接口进行服务注册, 同时调用注册表拉取接口进行注册表拉取,保存懂啊LocalRegistry
Server端的服务注册表里面的服务和节点的信息,我通过Application和lease来维护
Application: 代表一个应用,里面会包含服务对应的节点信息
Lease: 维护一个节点的信息,比如心跳信息
服务端注册表结构体Registry主要包含三部分信息: lock(读写锁)、apps(应用对应信息)、eventQueue(事件队列)
Lock: 注册中心是典型的读多写少的应用,server端注册表可能同时提供给N个服务进行读取,所以这里采用读写锁
apps: 保存应用对应的信息, 其实后面写完发现,没必要使用,只使用基础的map就可以搞定
eventQueue: 每次注册表变更都写入事件到里面
// Registry 注册表 type Registry struct { lock sync.RWMutex apps sync.Map duration time.Duration eventQueue *EventQueue }注册表服务注册
注册流程主要分为下面几部分:
从注册表获取对应的应用Application
调用Application的add接口添加节点
为节点创建一个Lease
保存节点信息到Application.Node里
将事件写入到eventQueue
// Registr 注册服务 func (r *Registry) Registr(name, node string) bool { r.lock.Lock() defer r.lock.Unlock() app := r.getApp(name) if app == nil { app = NewApplication(name) r.apps.Store(name, app) } if lease, ok := app.add(node, r.duration); ok { r.eventQueue.Push(&Event{lease: lease, action: ADD}) return true } return false }注册表拉取
全量拉取通过all接口拉取全量的返回的是服务对应的节点切片
增量拉取通过details接口返回增量的变更事件和服务端注册表的hashcode
// all 全量拉取 func (r *Registry) all() map[string][]string { r.lock.RLock() defer r.lock.RUnlock() apps := make(map[string][]string) r.apps.Range(func(k, v interface{}) bool { name, app := k.(string), v.(*Application) nodes := []string{} for key := range app.Node { nodes = append(nodes, key) } apps[name] = nodes return true }) return apps } // details 增量拉取 func (r *Registry) details() []*Event { r.lock.RLock() defer r.lock.RUnlock() events := []*Event{} for { event := r.eventQueue.Pop() if event == nil { break } events = append(events, event) } return events }hashcode
hashcode是一个一致性的保证,eureka里面主要是通过拼接所有的服务名称和节点的个数来生成的一个字符串,这里我们也采用这种方式,
func (r *Registry) hashCode() string { r.lock.RLock() defer r.lock.RUnlock() hashCodes := []string{} r.apps.Range(func(_, value interface{}) bool { app := value.(*Application) hashCodes = append(hashCodes, app.HashCode()) return true }) sort.Sort(sort.StringSlice(hashCodes)) return strings.Join(hashCodes, "|") }客户端注册表 数据结构
客户端本地注册表其实就比较简单了,只需要存储服务和节点的对应信息即可
// LocalRegistry 本地注册表 type LocalRegistry struct { lock sync.RWMutex apps map[string][]string }客户端逻辑架构
启动流程: 启动时客户端首先调用注册接口进行自我注册,然后调用poll拉取全量注册表
func (c *Client) start() { c.wg.Add(1) c.registr() c.poll() go c.loop() }
主循环
func (c *Client) loop() { timer := time.NewTimer(time.Second) for { // 从服务的拉取增量事件,details内部会直接应用,然后返回服务端返回的注册表的hashcode respHashCode := c.details() localHashCode := c.registry.hashCode() // 如果发现本地和服务的的注册表的hashcode不同,则全量拉取 if respHashCode != localHashCode { fmt.Printf("client app %s node %s poll hashcode: %s ", c.App, c.Name, respHashCode) c.poll() } select { case <-timer.C: timer.Reset(time.Second) case <-c.done: c.wg.Done() return } } }验证逻辑
func main() { // 生成服务端 server := NewServer("aliyun", time.Second) // 注册两个test服务的节点 clientOne := NewClient("test", "1.1.1.1:9090", server) clientOne.start() clientTwo := NewClient("test", "1.1.1.2:9090", server) clientTwo.start() // 注册两个hello服务的节点 clientThree := NewClient("hello", "1.1.1.3:9090", server) clientThree.start() clientFour := NewClient("hello", "1.1.1.4:9090", server) clientFour.start() time.Sleep(time.Second * 3) // 验证每个服务节点的注册表的hashcode是否一致 println(clientOne.details()) println(clientTwo.details()) println(clientThree.details()) println(clientFour.details()) println(clientTwo.details() == clientOne.details()) println(clientThree.details() == clientFour.details()) println(clientOne.details() == clientFour.details()) clientOne.stop() clientTwo.stop() clientThree.stop() clientFour.stop() }
通过结果我们可以看出,节点增量拉取了注册表,同时如果发现与本地的hashcode不同就进行全量拉取,并最终达成一致
lr event add 1.1.1.3:9090 hello lr event add 1.1.1.4:9090 hello lr event add client app hello node 1.1.1.4:9090 poll hashcode: hello_2|test_2 1.1.1.1:9090 test lr event add 1.1.1.2:9090 test client app test node 1.1.1.1:9090 poll hashcode: hello_2|test_2 client app test node 1.1.1.2:9090 poll hashcode: hello_2|test_2 client app hello node 1.1.1.3:9090 poll hashcode: hello_2|test_2 hello_2|test_2 hello_2|test_2 hello_2|test_2 hello_2|test_2 true true true总结
微服务注册中心注册表的这种实现机制,到这基本上就明白了,注册中心 通过增量、全量、hashcode三种机制来保证客户端与注册中心的注册表的同步
其实一个工业级的注册中心还是很麻烦的,比如注册表中那个事件队列,我现在的实现只有一个节点能获取增量,其他的都会通过hashcode来触发全量拉取,后续文章里面会相信介绍下,这块缓存和定时器来实现增量数据的打包
其实在go里面大家注册中心都是基于etcd、consul直接watch去做的,基本上可以完成eureka服务的8/9十的功能,但是当需要与公司现有的java做集成,可能就需要eureaka这种注册中心了
未完待续
关注公共号: 布衣码农
更多精彩内容可以查看www.sreguide.com
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/34950.html
摘要:背景基于负载均衡的服务调用基于负载均衡的服务相互调用指的是通过基于等负载均衡软件来构建一个负载均衡服务,所有的服务调用都通过负载均衡器从负载均衡的这种模式下其实有两个主要的问题一是中心化,整个系统都基于负载均衡器,负载均衡就相当于整个业背景 基于负载均衡的服务调用 showImg(https://user-gold-cdn.xitu.io/2019/5/23/16ae29255c5f47b1...
摘要:先来说第种类型,即远程通信的,看的源码,调用过程大致内容就是将通过远程通信将信息传递给服务器端,服务器端接收到该信息后,找到对应的本地,然后通过反射执行相应的方法,将方法的返回值再通过远程通信将结果传递给客户端。 showImg(https://segmentfault.com/img/remote/1460000015285374?w=640&h=363); 上图是服务消费的主过程:...
摘要:总体介绍在互联网金融行业一百多亿其实也算不上大平台,也就是二级阵营吧,其实每次的架构升级都是随着业务重大推进而伴随的,在前一代系统架构上遇到的问题,业务开发过程中积累一些优秀的开发案例,在下一代系统开发中就会大力推进架构升级。 回想起从公司成立敲出的第一行代码算起到现在也快三年了,平台的技术架构,技术体系也算是经历了四次比较重大的升级转化(目前第四代架构体系正在进行中),临近年底也想抽...
摘要:总体介绍在互联网金融行业一百多亿其实也算不上大平台,也就是二级阵营吧,其实每次的架构升级都是随着业务重大推进而伴随的,在前一代系统架构上遇到的问题,业务开发过程中积累一些优秀的开发案例,在下一代系统开发中就会大力推进架构升级。 回想起从公司成立敲出的第一行代码算起到现在也快三年了,平台的技术架构,技术体系也算是经历了四次比较重大的升级转化(目前第四代架构体系正在进行中),临近年底也想抽...
摘要:为了解决这一系列问题,微博从年开发了语言的框架,并基于此完成了服务化改造。这些经历之下微博也积累了一套服务治理型的服务化体系。的版,所要解决的是微博平台内部服务之间的调用,因此协议时,其实并没有考虑到跨语言的问题,用的是对比较友好的。 showImg(https://segmentfault.com/img/remote/1460000012601596?w=1080&h=606); ...
阅读 2908·2021-11-23 09:51
阅读 479·2021-10-14 09:43
阅读 494·2021-09-14 17:57
阅读 1936·2021-09-06 15:01
阅读 2988·2021-09-06 15:00
阅读 2260·2019-08-30 15:54
阅读 2439·2019-08-30 13:58
阅读 1614·2019-08-29 13:18