邢台做wap网站,wordpress游戏系统模型,产品网站建设,网站挣钱方式前面历史文章中我们有说过关于微服务的注册和发现#xff0c;并以 etcd 作为简单例子简单阐述了关于服务注册和发现的应用
那么日常工作中#xff0c;你已经使用了服务注册和发现的哪些模式呢#xff1f;
服务注册和发现的作用
首先#xff0c;简单说明一下服务注册和发…前面历史文章中我们有说过关于微服务的注册和发现并以 etcd 作为简单例子简单阐述了关于服务注册和发现的应用
那么日常工作中你已经使用了服务注册和发现的哪些模式呢
服务注册和发现的作用
首先简单说明一下服务注册和发现的作用
他可以屏蔽和解耦多个服务之间的依赖还可以让我们对微服务进行动态管理
怎么理解呢
还记得一开始我们都是在开发单体应用的时候一个应用包含了多个功能他们耦合在一起例如有订单管理租户管理账户管理等 演变到微服务的时候这些专一的功能就单独拎出来成为一个微服务有自己独立的数据库自己的一套系统这个时候就有订单微服务租户微服务账户管理微服务等 那么以前是一个单体应用咱们内部干啥都方便需要啥直接说就好反正我们都生活在一起
可是演进到微服务的时候每一个专一的功能都是一个独立的个体可能是生活在同一个区域的不同单元楼了
多个服务之间自然需要进行通信这个时候就需要用到服务的注册和发现这里存放动态的每一个服务的应用名对应的地址和端口
我们知道一个服务去与另外一个服务进行通信的时候需要知道对方的 ip 和 端口 以及沟通好对应的协议
微服务之间通信我们通常使用 RPC 进行通信golang 通常用 gRPC 来进行处理
例如有 3 个服务服务 A服务 B服务 C
服务 A 如果将 服务 B 的 ip 地址和端口写到自己服务代码里面
那么有一天服务 B 的环境发生了变化那么 服务 A 岂不是依赖服务 B 的功能就不可用了这也太死了
因此引入服务注册和发现中心之后服务 A 完全无需关心服务 B 的地址和端口只需要通过服务名去找服务注册和发现中心获取即可哪怕服务 B 的地址如何变幻服务 A 总能请求到正确的服务 B 服务注册和发现的模式一般有两种
客户端模式
客户端模式又叫直连模式
见名知意直连自然是点到点的直连
服务 A 直接通过 ip 和 port 去请求服务 B只不过服务 A 需要去一个叫做服务注册和发现中心的地方去获取服务 B 的地址信息再进行建立连接
例如我们可以理解为是这样的流程 可以看到像这种直连的方式
服务 A 需要在代码中去编写代码与服务注册和发现中心交互 且需要自写算法来进行负载均衡到节点的任意一个服务 B 上咱们初期一般是对每个服务部署了 3 个应用在环境中
对于技术栈是一样的团队中可以将该部分提取抽象出来做成一个公共库提供给各个团队使用即可相当于对于各个团队来说直接调用公共库中的方法传入具体的应用名即可按照算法获取到应用对应的地址简单高效项目初期我们使用的就是客户端模式的服务注册和发现
当然这种方式如果切换到别的技术栈别的编程语言的话就不适用了因此从这里我们可以看到客户端模式是需要修改咱们仓库代码的也就是说对代码有侵入性对于跨平台的话不太友好例如 golang 的公共库java 没有办法使用这个应该很容易理解
服务端模式
服务端模式又叫做代理模式
同理见名知意既然是代理那么自然是要通过代理隐藏某些信息
此处是否会想到正向代理和反向代理呢如果想了解和确认他们都是啥可以查看文末的文章链接
对于代理模式来说还是服务 A 去请求 服务 B 的情况这个种模式就不需要我们去修改代码了
服务 A 只需要去请求一个统一的域名自然域名会被 DNS 解析成具体的 ip请求到代理服务后代理服务根据我们请求的内容去进行分发到不同的服务上如果这个代理服务后面的服务 B 有多个实例的话那么就可以在代理服务上设置对于每一个实例的权重进行分发来达到负载均衡的目的
看到这里有没有看上去好像是在说 nginx 反向代理一样
没错此处的代理可以理解成一个反向代理他是隐藏了关于服务端的细节的此处 服务 A 属于客户端服务 B 输出服务端 此处我们就可以看到这种模式实际上对于跨平台就非常友好了不管你的应用是什么语言写的只要能进行网络通信那么问题不大
但是弊端也是非常明显的因为我们微服务之间的通信不是直连的而是通过了一个代理服务那这个代理服务自然会成为通信过程中影响性能的一环
从主机环境迁移到 k8s 环境中如何使用服务注册和发现
上述服务注册和发现的两种模式你们使用哪种模式更多呢
以前我们使用的是客户端模式现在我们直接使用 k8s 自身的能力
我们知道在 k8s 中咱们部署一个服务咱们自然是会给这个服务部署一个 Service既然是 Service 我们就会给他指定 Port
对于一个 Deploy 咱们部署 多个 pod 的时候当外部请求到该 Service 的时候k8s 中自身的负载均衡算法就会将请求转到具体的 endpoint 上最后流量也就会达到一个具体的 pod 上
那么问题来了外部是如何请求到服务内部的
目前简单做法是外部请求一个指定的域名请求到 k8s 环境之后通过 ingressRoute 匹配具体的路由进而转发到对应的 Service最终请求到具体的 pod 对于 ingressRoute 的用法还有很多此处就不赘述了
当然这个是对外提供域名的情况可以这样做那么微服务之间内部通信的话如何进行服务注册和发现呢
目前的做法还比较 low部署服务的时候其中我们会部署一个 ConifgMap暂时记录叫做 discovery 吧 对于服务来说就是一个配置文件里面存放的就是每一个服务名和自己的 Service 和端口 的对应关系
那么微服务之间通信的话直接去读取这个 ConfigMap 就可以能够与服务名对应的 Service 来进行通信了
可以看出这个时候有一个弊端的如果某个服务的端口发生了变化没有及时去更新这个 discovery COnfigMap 的话就会出现功能异常的情况
这一点弊端其实暂时也是可以避免和接受的
其实关于在 k8s 中环境中对于服务的注册和发现会有更好的选择例如之后我们可以将这件事件放到 NACOS 里面处理当然关于 NACOS 的内容就不在这里过多赘述了
感谢阅读欢迎交流点个赞关注一波 再走吧
欢迎点赞关注收藏
朋友们你的支持和鼓励是我坚持分享提高质量的动力 好了本次就到这里
技术是开放的我们的心态更应是开放的。拥抱变化向阳而生努力向前行。
我是阿兵云原生欢迎点赞关注收藏下次见~
文中提到的技术点感兴趣的可以查看这些文章
服务注册与发现之ETCD 简单理解正向代理和反向代理 【k8s 系列】k8s 学习二十七 - 6k8s 自身原理之 Service 【k8s 系列】k8s 学习十九service 2 暴露服务的 3种 方式 【k8s 系列】k8s 学习十三Service 基础 【k8s 系列】k8s 学习二十五-2Deployment 升级应用 【k8s 系列】k8s 学习二十五-3Deployment 升级应用2
可以进入地址进行体验和学习https://xxetb.xet.tech/s/3lucCI
