直连式配置中心
上一篇文章介绍了 Spring Cloud
中的分布式配置组件 Config
,每个服务节点可以从Config Server
拉取外部配置信息。但是似乎还有一个悬而未决的问题,那就是当服务节点数量非常庞大的时候,我们不可能一台一台服务器挨个去手工触发刷新,这时候就需要一个可以号令武林的角色出场,由它代替我们做批量刷新的事儿。
帮派组织架构
- 帮主:仍然是我们的 Github 服务器(后面会讲到其他存放属性文件的方式),存放所有的配置项信息
- 传功长老:Config 组件,从 Github 那里获取资源文件,并保存一份放到本地。
- 小弟:众多服务节点,从传功长老那里获取帮主的指令
Config Server 的工作模式
Config Server 主要有两种工作模式:
- 效忠帮主 在这个模式下,
Config Server
只会从Github
或者数据库获取配置信息 Github 方案:如果 Github 是公共仓库,那就不需要配置用户名和密码。如果是私有仓库,要把登录用的用户名和密码写到配置文件里面,当然密码可以通过加密方式存储,然后系统启动的时候使用密钥进行解密 - Database 方案,需要额外指定
spring.profiles.active=jdbc
切换到 db 方案,并指定数据源自立门户 帮主?什么帮主?我就是帮主,Github 被我一脚踢开,Config 组件自己说了算,直接从本地路径读取资源文件采用这种方式,需要指定spring.profiles.active=native
开启功能,然后指定本地文件存储路径为了简化配置,我们的课程采用第一种模式管理配置文件,也就是 Github 公共仓库。在项目配置中非常简单,只用指定 Github 地址就可以,例如spring.cloud.config.server.git.uri=https://github.com/xxxxx/config-repo.git
在企业应用中,有时也会有多个项目共同使用一个 Github repo 的情况,这时候就需要将不同项目的资源文件放到不同目录下,使用如下配置,给你的服务指定一个独立的目录存放配置文件spring.cloud.config.server.git.search-paths=/{appName}
直连式方案的利弊
优点:从部署结构上来讲相当简单,组件间依赖也少
缺点:可用性不能得到保障,假如 Config 节点宕机会产生较大影响。由于需要将在客户端启动的时候指定 Config 地址,即便这里使用 DNS 地址(比如域名等非 IP 形式),如果域名发生变化仍然需要在客户端重新配置 Config 地址。
配置文件动态刷新
斧头帮决定来一次整风运动,调动小弟们的积极性,要做到帮主随叫随到(是帮主叫你,不是他自己随叫随到),我们来看看怎么推广。
很简单,这个过程分 3 个步骤进行:
- 发送刷新请求 我们选定一个服务节点,通过 POST 请求访问节点下的/actuator/refresh 路径,这时节点会发送一个刷新请求到 Config 服务器
- 拉取文件 Config 服务器会访问 Github 获取最新的内容,并把配置信息文件下载到本地
- 获取更新内容 接着服务节点从 Config 那里拿到变更内容,并将变动的属性配置到各个类中。
在第三步骤里还有个小前提,假如一个类中有需要进行运行期替换操作的属性,那就要把@RefreshScope 注解加到这个类上,这样运行期参数修改才会在这个类上面生效。在上面那个 case “里, /actuator/refresh”就像帮主发给小弟的对讲机,只要一声令下就得前来报到。但是要使用这个对讲机还得先了解一下它的配置。
什么是 Actuator
Actuator 是一个轻巧的监控组件,通过 REST 接口的方式可以供外部调用,访问服务节点下的 “/actuator”路径可以查看当前开放的服务。
Actuator 也是一个相当贴心的组件,当你引入 Spring Cloud
的其他组件依赖到 pom 中以后(比如 Config 或 BUS),这部分组件会通过 Actuator Endpoint
将自己的核心服务提供出去(比如 Config 和 BUS 的 refresh 功能)。假如同学们访问 /actuator
后只能看到 health
和 info
这两个服务,那是因为 Actuator 的服务包含很多 “机密” 信息,为了安全考虑,默认只暴露几个无关痛痒的接口。我们可以通过改动默认配置项让它暴露指定的接口,为了方便演示,本课程中我们采用以下配置让Actuator “暴露所有服务,这样你就可以通过 /actuator”路径查看当前可用的服务了。management.endpoints.web.exposure.include=*
消息总线BUS
接下来,让我们继续 “总线式架构” 的展望,看看 Spring Cloud
中哪个组件可以担当号令武林的角色。
号令武林
武林至尊 宝刀屠龙
号令武林 莫敢不从
BUS- 消息总线,从这个 “总” 字就可以看出身份地位不一般,它代理了这个号令武林的角色,将消息变更发送给所有的服务节点。
在微服务架构的系统中,通常我们会使用消息代理来构建一个 Topic,让所有服务节点监听这个主题,当生产者向 Topic 中发送变更的时候,这个主题产生的消息会被所有实例所消费,这就是消息总线的工作模式,也就是我们熟悉的 “发布- 订阅” 模型。
其实广义的消息总线不单指代这种 “发布- 订阅” 的模式,也可以代指分布式服务间进行通信、消息分发的 单播 模式,甚至有的公司既不使用 HTTP 也不用 RPC 来构建微服务,完全靠消息总线来做服务调用。比如银行的一些老系统就是采用总线型架构,在不同服务节点之间做消息分发。
Spring Cloud
中 BUS
的职责范围就相对小了很多,因为还有一个 Stream
组件代理了大部分的消息中间件通信服务,因此 BUS “ ”在实际应用中大多是为了应对 消息广播 的场景,比如和 Config
一同搭配使用推送配置信息。
我们先来看下官网对 BUS 定位的描述:
Spring Cloud Bus links nodes of a distributed system with a lightweight message
broker. This can then be used to broadcast state changes (e.g. configuration
changes) or other management instructions.
不同于其他 Spring Cloud
组件洋洋洒洒的大篇功能描述,Spring 官网对 BUS 的应用场景
寥寥数笔,总结一下它的应用范围就是:广播状态更改,例如配置变更或者其他的管理指
令。
总线式架构的完整流程
下面我们揭开总线式架构的完整面纱:
白底红框那三个和 BUS 有关系的步骤:
-
MQ/Kafka BUS
是一个调用封装,它背后还是需要依赖消息中间件来完成底层的消息分发,实际项目中最常用的两个中间件分别是RabbitMQ
和Kafka
-
BUS
作为对接上游应用和下游中间件系统的中间层,当接到刷新请求的时候,通知底层中间件向所有服务节点推送消息 -
Refresh
在Config
章节中我们通过Refresh
请求来刷新配置,那么对于总线式架构的Refresh 请求来说,有两个需要解决的问题:谁来发起变更 - 是由服务节点,还是由 Config Server 发起变更请求?
小结
本文带大家了解了 BUS + Config 结合的总线式消息推送模型,后续我们将继续对 BUS 展
开深入的学习。
BUS 底层依赖了 Stream 来广播消息,真正实现与消息代理进行交互的实际上是 Stream,它才是站在 BUS 背后的男人。
学习 Tips:Spring Cloud 各个组件之间常有相互依赖的关系,比如 Feign 和 Ribbon 还有Hystrix 搭配,BUS 和 Stream,Config 和 BUS,整个 Spring Cloud 各组件配合的天衣无缝浑然一体,秉承了 Spring “ ”家族 全家桶 式的设计思想。回想过去十多年来层出不穷的开源框架,能走到今天依然在 Java 企业级开发领域呼风唤雨的也只有 Spring 了,从最初的IOC+AOP,到 MVC+全家桶组件库,再到 SpringBoot,现在又是 SpringCloud,Spring一直是 Java 领域的弄潮儿,这种生命力和创新精神真的是相当厉害。文章来源:https://www.toymoban.com/news/detail-831913.html
本文已收录至我的个人网站:程序员波特,主要记录Java相关技术系列教程,共享电子书、Java学习路线、视频教程、简历模板和面试题等学习资源,让想要学习的你,不再迷茫。文章来源地址https://www.toymoban.com/news/detail-831913.html
到了这里,关于消息总线在微服务中的应用的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!