spring boot分布式教程（spring boot使用nacos作为配置中心实践）

本文目录

• spring boot使用nacos作为配置中心实践
• 如何使用MongoDB+Springboot实现分布式ID
• SpringBoot接入轻量级分布式日志框架（GrayLog）
• 如何利用Spring Boot集成Hazelcast实现分布式集群服务

spring boot使用nacos作为配置中心实践

本文主要介绍自己将nacos作为spring boot的配置中心的实践过程，希望对有需求的小伙伴提供一些帮助。
通过nacos实现配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。

在linux系统中可以通过以下命令安装 docker-compse：

使用如下命令创建部署文件 nacos-standalone-mysql-8.yaml ：

文件内容如下：

使用如下命令启动nacos：

使用下面的命令可以查看启动日志：

***隐藏网址***
登录用户名：nacos
登录密码：nacos

可以去maven中央仓库查找 nacos-config-spring-boot-starter 最新依赖，这里使用的最新依赖。

将spring boot项目中原有的配置放到nacos中，如下图所示：

在 application.yaml 文件中配置 Nacos server 的地址：

使用 @NacosPropertySource 加载nacos中 dataId = "spring-boot-demo.yaml" 的配置文件，并开启自动更新：

通过 Nacos 的 @NacosValue 注解设置属性值。

***隐藏网址***

使用spring boot整合nacos的配置管理还是挺简单的，总体来说就只有三步：
1、引入 nacos-config-spring-boot-starter 依赖
2、在配置文件中设置nacos的地址
3、在启动类上使用注解@NacosPropertySource 指定nacos中配置的 Data ID

1、在 application.yaml 配置文件中指定nacos中配置的 Data ID 不会生效，需要通过注解 @NacosPropertySource 指定才能生效。
2、 nacos-config-spring-boot-starter:0.2.7 依赖最高支持 spring boot 2.3.x ，如果使用 spring boot 2.4.x 将会报如下错误：

如何使用MongoDB+Springboot实现分布式ID

MongoDB的ObjectId设计成轻量型的，不同的机器都能用全局唯一的同种方法方便地生成它。MongoDB 从一开始就设计用来作为分布式数据库，处理多个节点是一个核心要求。使其在分片环境中要容易生成得多。
它的格式：
mongo.png
前4 个字节是从标准纪元开始的时间戳，单位为秒。时间戳，与随后的5 个字节组合起来，提供了秒级别的唯一性。由于时间戳在前，这意味着ObjectId 大致会按照插入的顺序排列。这对于某些方面很有用，如将其作为索引提高效率。这4 个字节也隐含了文档创建的时间。绝大多数客户端类库都会公开一个方法从ObjectId 获取这个信息。
接下来的3 字节是所在主机的唯一标识符。通常是机器主机名的散列值。这样就可以确保不同主机生成不同的ObjectId，不产生冲突。
为了确保在同一台机器上并发的多个进程产生的ObjectId 是唯一的，接下来的两字节来自产生ObjectId 的进程标识符（PID）。
前9 字节保证了同一秒钟不同机器不同进程产生的ObjectId 是唯一的。
后3 字节就是一个自动增加的计数器，确保相同进程同一秒产生的ObjectId 也是不一样的。同一秒钟最多允许每个进程拥有2563（16 777 216）个不同的ObjectId。

SpringBoot接入轻量级分布式日志框架（GrayLog）

在文章正式开始之前，我分享下我以前负责过的一个系统，它的架构如下：

每次当我查问题的时候，我都能把问题初步定位在 逻辑层 ，但为了能给业务方交代，我需要 给证据 业务方面（日志信息就是铁证）。

一个请求肯定是被这8台机器内的某一台处理，但具体是哪一台，我不知道。所以，我需要上每台机器上 grep 一把日志，然后才能找出对应的日志证明我的分析。

有的时候，可能 接入层 也需要一起参与进去，就排查一个问题，人都傻了了（翻看日志的时间占用了太久了）。

后来啊，看了同事的骚操作（在 item2 编写脚本： 快速登录堡垒机 （免去输入账号和密码信息），根据应用服务器数量来切割窗口并且切换到对应的日志目录）。说白了就是 一键登录 多台应用服务器。嗯，这查日志的速度比起以前又快了好多。

再后来，公司运维侧又主力推在 Web页面 上登录应用服务器（ 自动登录堡垒机 ），这能省去编写脚本（ 支持批量操作 ）。但从当时的体验上，没有问题 item2 访问得流畅（总感觉卡卡的）。

不过还有问题，因为我们在很多时候是不知道在 info / warn / error 哪个文件下。很多时候只能一个一个文件去查，虽然说可以直接查 通配符 一把查，如果日志过大，带来停顿时间也挺烦的。

系统一旦被问到业务问题，查日志的频率实在是太高了。于是我在某个Q规划的时候是想自己把日志信息写入到 搜索引擎 ，顺便学习下搜索引擎的知识。然后这个规划被组内的某个大佬看到了，在底下评论： 要不来试试Graylog ？

原来组内本身就在维护了一个 日志框架 ，只是我不知道...于是我接入了 Graylog 日志，工作效率杠杠提高了， 凭借这个事情吹了一个Q 。

自从接入了之后，我就没登录过应用服务器了，有次差点连 grep 都不会写了。

说起ELK，即便没用过肯定也听说过这玩意了，在后端是真的流行。这次austin接入一个比较轻量级的ELK框架： Graylog

这个框架我感觉蛮好用的，作为 使用方 接入起来 异常简单 （我估摸运维应该也挺简单的，很多用Graylog是直接发UDP到Server，不用在机器上装agent收集日志）

官方文档： ***隐藏网址***

据我了解，有相当多的企业使用它来 查看日志和业务监控告警 ，这篇文章我就直接让你们体验体验吧。

老样子，直接上docker-compose，如果一直跟着我的步伐，应该对着不陌生了。 docker-compose.yml 的内容其实我也是抄官网的，这里还是贴下吧（就不用你们翻了）

这个文件里唯一需要改动的就是 ip （本来的端口是 9000 的，我由于已经占用了 9000 端口了，所以我这里把端口改成了 9009 ，你们可以随意）

嗯，写完 docker-compose.yml 文件，直接 docker-compose up -d 它就启动起来咯。

启动以后，我们就可以通过 ip:port 访问对应的Graylog后台地址了，默认的账号和密码是 admin/admin

随后，我们配置下 inputs 的配置，找到 GELF UDP ，然后点击 Launch new input ，只需要填写 Title 字段，保存就完事了（其他不用动）。

嗯，到这里，我们的GrayLog设置就完成了。

还记得我们 austin 项目使用的日志框架吗？没错，就是logback。我们要把日志数据写入Graylog很简单，只需要两步：

1、引入依赖：

2、在 logback.xml 配置graylog相关的信息：

在这个配置信息里，唯一要改的也只是 ip 的地址，到这里接入就完毕了，我们再打开控制台，就能看到日志的信息啦。

懂点GrayLog查询语法：这块我日常来来去去其实就用几个，我来展示下我平时用的吧。如果觉得不够，再去官网文档捞一把就完事了： ***隐藏网址***

1、根据字段精确查询： full_message:"13788888888"

2、查询错误日志信息： level_name:"ERROR"

3、组合多字段查询： level_name:"INFO" AND full_message:"13788888888"

在接入的时候，仔细的小伙伴可能会发现我这边在Input的时候选择的是 GELF ，然后在引入Maven依赖的时候也有 GELF 的字样。那 GELF 是啥意思呢？

这块在官网也有给出对应的解释： The Graylog Extended Log Format (GELF) is a log format that avoids the shortcomings of classic plain syslog

详细资料： ***隐藏网址***

GELF 是一种日志格式，能避免传统意义上的 syslogs 的一些问题，而我们引入的Maven依赖则是把日志格式化成 GELF 格式然后append到GrayLog上。

前几天有个老哥在GitHub给我提了个 pull request 关于 swagger 的，我昨天把他 merge 了，也升级了下 swagger 的版本。

之前我没用过 swagger 类似的文档工具，就这次 pull request 我也去体验了下 swagger 。

在初次的体验感觉是不错的：它能把项目的所有接口的 文档信息 都能在一个页面上 统一管理 ，并且就能直接通过 样例参数 直接发送请求。通过注解的方式来进行编写文档，也不用担心代码改了然后忘了更新文档这事。

但是，后来我配置好对应的参数信息文档，再在 swagger-ui 体验了下， 发现是真滴丑 ，看到这 ui 我还是阶段性放弃吧。

swagger 的竞品还有好几个，我看 ui 貌似都要比 swagger 好看。不过，austin项目的 主要接口就只有一个 ，我作为熟练掌握的 markdown 工程师能轻松胜任文档工作，就没再继续体验别的竞品了。

如何利用Spring Boot集成Hazelcast实现分布式集群服务

创建一个默认名为hazelcast-instance的HazelcastInstance实例；
使用默认的组播发现模式，组播传播地址默认为：224.2.2.3，如果想修改信息或修改为TCP模式可通过setNetworkConfig()接口设置相关信息；
创建一个名为dev，访问密码为dev-pass的group保障节点加入，如果想修改组，可通过setGroupConfig()接口设置相关信息；
创建了一个名为instruments的分布式map数据结构，并设置了该map的最大容量200／逐出策略LRU／有效期20000ms等信息，当集群启动后，我们可以在任一成员节点上通过HazelcastInstance读写该map。
资料整理自：黑少微服务商店