同Eureka一样，SOFARegistry 是蚂蚁金服开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来，随着蚂蚁金服的业务发展，注册中心架构已经演进至第五代。目前 SOFARegistry 不仅全面服务于蚂蚁金服的自有业务，还随着蚂蚁金融科技服务众多合作伙伴，同时也兼容开源生态。SOFARegistry 采用 AP 架构，支持秒级时效性推送，同时采用分层架构支持无限水平扩展。
服务注册中心分为四个角色，客户端（Client）、会话服务器（SessionServer）、数据服务器（DataServer）、元数据服务器（MetaServer），每个角色司职不同能力组合后共同提供对外服务能力。
Client
客户端：提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。
SessionServer：9603
会话服务器：提供客户端接入能力，接受客户端的服务发布及服务订阅请求，并作为一个中间层将发布数据转发 DataServer 存储。SessionServer 可无限扩展以支持海量客户端连接。
DataServer：9622
数据服务器：负责存储客户端发布数据，数据存储按照数据 ID 进行一致性 hash 分片存储，支持多副本备份，保证数据高可用。DataServer 可无限扩展以支持海量数据量。
MetaServer：9615
元数据服务器：负责维护集群 SessionSer
Kitex为 字节跳动 内部的 Golang 微服务 RPC 框架，具有 高性能 、 强可扩展 的特点，在字节内部已广泛使用。如果对微服务性能有要求，又希望定制扩展融入自己的治理体系，Kitex 会是一个不错的选择。
这次我们可以从 官方示例 中的 easy_note 这个demo 开始分析，因为它基本展示了 Kitex 的基本使用方法。
下面图例为官方在 demo 中展示的架构图，通过简单的分析可得, note , user 通过 注册中心 (Etcd) 进行注册 ， api 通过 注册中心 来发现 note , user 两个 rpc 服务, 并进行业务处理。
从 kitex-examples/hello 这个最简单示例分析，从 cloudwego/kitex 的快速上手可知，这里用了最简单的 直链 来链接 server 和 client。而这次的 easy_note 中使用了 注册中心 来作为 服务之间的 桥梁 (middleware), 为什么不使用之前的方式而是使用了注册中心？
我们搜索一下注册中心的作用，可知: 服务注册中心的主要作用就是「服务的注册」和「服务的发现」
我们将服务交给注册中心管理，虽然可以避免处理复杂的手动管理，我们也许需要还要考虑更多问题，例如：
这次目标之一就是来解析解析服务是如何在服务启动时进行 注册 ( Register ) 这个操作的, 这次我们从 easy_note/cmd/user 这个服务开始分析, 因为它是被 注册 进入 Etcd 的服务之一。
我们从其中的 main.go 开始下手，以下的内容是经过简化后的文件，是实现配置服务，启动服务的文件
由注释可知 WithRegister() 为配置 注册信息 的函数 ，那为什么直接就看这个函数呢？
一是因为主要配置注册的主要逻辑在其中，二是因为 With... 的函数结构都是大同小异，十分相似的。
再然后我们进入 kitex/server/option.go ，先看看 di.Push(fmt.Sprintf("WithRegistry(%T)", r)) 这一行，
这个 *util.Slice 是什么 ？进去看看？
进入 kitex/pkg/utils/slice.go , 我发现它很简短。但是它好眼熟，它好像是一个非常常见的数据结构 —— Stack (栈) ！
在这个文件之下有它的 slice__test.go 文件 ，看到这里的朋友可以去试验一下是否这个 Slice 和我的想法是否一致，大家看文章是要思考的嘛！最好可以动动手！
我们再进入 o.Registry = r 这一行，可以得知 Options 用于初始化 server， Option 用于配置 Options (我觉得这种命名方式很巧妙，我感觉基本达到了 见名知意 的作用)，里面东西很多，我们今天只看 Register 部分
到了这里我们可以暂停思考一下，到达这一步是怎么个过程呢？是通过 main.go/user.NewServer(） 的方法进来的。
那 NewServer() 的作用是什么？是用于配置初始化服务器的 可选参数 ，
配置完了参数什么时候生效呢 ( Register 是什么时候发生的呢) ？其实配置的实现就在 main.go NewServer() 的下一句， Run() !
进入Run方法的实现，可以得知 register 是发生在 server 启动成功后 的，停止也是会向 Etcd 进行注销操作的 (大家可以在同文件的 Stop() 中查看)
至此 服务完成了向 Etcd 的注册，我忽略了许多其他细节，这些细节也很有意思，希望大家可以自己试着探索
这次文章其实向大家分析了如何配置服务，以及向注册中心进行注册的方法和时机。
虽然省略了许多细节，但是通过这篇文章可以学到什么呢？
在之前提到的OpenResty/Nginx的负载均衡当中，当服务器启动之后，upstream中的上游服务器就是固定死的了，做不到动态的变更。这里面说到的变更，其实更多指的是增加机器。因为当上游服务器不可用时，upstream会自动将服务器摘除，但是当新增服务器时，upstream就做不到了。传统的负载均衡办法，就是能是修改配置，然后重启服务。下面介绍一下动态负载均衡的方式，一种是通过动态重启服务；另外一种是通过代码的方式动态拉取服务器列表。
Consul是一个分布式服务注册与发现系统。这里面使用Consul来管理上游服务器，当服务器启动时将其注册到注册中心去，当服务关闭时从注册中心列表中剔除。这里面需要注意一点的是：当上游服务器关闭时，Consul本身不会自动从列表中剔除，而是需要在服务器关闭前主动向Consul发起删除服务。
Consul有以下特性：
通过Consul可以获取到upstream中的上游服务器列表，下面要做的事情就是生成upstream中的模板了。这里就需要用到Consul-templete，它可以使用HTTP长轮询实现变更触发和配置更改。从而可以根据Consul服务器列表动态生成配置文件，然后去重新启动OpenResty/Nginx即可。
Consul+Consul-templete 就如上面所说的，是一种监听服务器列表变更，然后动态生成upstream模板，重启服务器。
Consul-Server
笔者使用的是MAC，下面所进行的操作都是基于MAC系统的。首先需要安装Consul如下：
安装完成之后，可以通过如下命令启动Consul服务：
启动完成之后，可以通过如下地址：localhost:8500/ui。访问Consul的Web界面：
可以使用HTTP的方式向Consul注册一个服务：
Consul-template
Consul-template的作用是生成upstream配置模板，安装命令如下：
然后在nginx.conf同级目录下创建moguhu_server.ctmpl
重启OpenResty脚本如下：reboot.sh
然后nginx.conf配置如下:
上游服务器
上游服务器upstream中使用的是Spring Boot实现的，其核心代码如下所示：
笔者在实验时，Consul版本的问题，造成在JVM停止时，没有执行删除服务的操作。因此附上下面的pom依赖
测试验证
1、启动Consul
2、启动Consul-template
3、启动2台upstream服务器
然后你会发现在nginx.conf的同级目录下生成了moguhu_server.conf文件，内容如下：
当手动停掉一台服务器时，配置又会变更为如下：
此时reboot.sh脚本会自动触发执行，如下所示：
上面的方式实现动态负载均衡在配置较多的时候会有一些问题，比如配置较多时，OpenResty重启的速度就会变慢。所以通过Lua脚本的方式可以规避掉重启这一步骤。
使用Lua实现时，与上面的组件相比Consul-templete就不需要了。通过Consul的 http://127.0.0.1:8500/v1/catalog/service/moguhu_server 接口就可以获取到服务的列表，如下所示：
这一方式当中主要就是OpenResty里面的相关配置。
OpenResty 配置
upstreams.lua
nginx.conf
上面通过balancer_by_lua_block去动态的设置了，upstream的服务器列表。然后启动OpenResty就可以了。
参考：《亿级流量网站架构核心技术》
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）