java个⼈博客系统完整源码下载（含数据库⽂件）
【实例截图】
⽂件：（访问密码：551685）
以下内容⽆关：
-------------------------------------------分割线---------------------------------------------
前不久，在3⽉20号，Nacos 2.0.0 正式发布了！我简单看了下官⽅的介绍，可能nacos未来逐渐会成为各⼤公司作为服务治理和配置中⼼的主要中间件。
Nacos 简介：⼀个更易于构建云原⽣应⽤的动态服务发现、配置管理和服务管理平台。
通俗点讲，Nacos 就是⼀把微服务双剑：注册中⼼ + 配置中⼼，由阿⾥巴巴于 2018 年开源。
⼀图看清naocs
Nacos 1.X ⼤致分为5层， 分别是接⼊、通信、功能、同步和持久化。
⼀句话总结，⼼跳多，⽆效查询多，⼼跳续约感知变化慢，连接消耗⼤，资源空耗严重。
1、 ⼼跳数量多，导致TPS居⾼不下
通过⼼跳续约，当服务规模上升时，特别是类似Dubbo的接⼝级服务较多时，⼼跳及配置元数据的轮询数量众多，导致集TPS很⾼，系统资源⾼度空耗。
2、 通过⼼跳续约感知服务变化，时延长
⼼跳续约需要达到超时时间才会移除并通知订阅者，默认为15s，时延较长，时效性差。若改短超时时间，当⽹络抖动时，会频繁触发变更推送，对客户端服务端都有更⼤损耗。
3、 UDP推送不可靠，导致QPS居⾼不下
由于UDP不可靠，因此客户端测需要每隔⼀段时间进⾏对账查询，保证客户端缓存的服务列表的状态正
确，当订阅客户端规模上升时，集QPS很⾼，但⼤多数服务列表其实不会频繁改变，造成⽆效查询，从⽽存在资源空耗。
4、基于HTTP短连接模型，TIME_WAIT状态连接过多
HTTP短连接模型，每次客户端请求都会创建和销毁TCP链接，TCP协议销毁的链接状态是WAIT_TIME，完全释放还需要⼀定时间，当TPS和QPS较⾼时，服务端和客户端可能有⼤量的WAIT_TIME状态链接，从⽽会导致connect time out错误或者Cannot assign requested address 的问题。
5、配置模块的30秒长轮询 引起的频繁GC
配置模块使⽤HTTP短连接阻塞模型来模拟长连接通信，但是由于并⾮真实的长连接模型，因此每30秒需要进⾏⼀次请求和数据的上下⽂切换，每⼀次切换都有引起造成⼀次内存浪费，从⽽导致服务端频繁GC。
connect下载Nacos 2.0 架构最主要的变化就是增加了对长连接的⽀持，gRPC 和 Rsocket 实现了长连接 RPC 调⽤和推送能⼒。
虽然Nacos2.0的在架构层次上并未做太⼤的变化，但是具体的模型细节却有不⼩的改动，依旧使⽤注册
服务的流程
优点
1、 客户端不再需要定时发送实例⼼跳，只需要有⼀个维持连接可⽤keepalive消息即可。重复TPS可以⼤幅降低。
2、 TCP连接断开可以被快速感知到，提升反应速度。
3、 长连接的流式推送，⽐UDP更加可靠；nio的机制具有更⾼的吞吐量，⽽且由于可靠推送，可以加长客户端⽤于对账服务列表的时间，甚⾄删除相关的请求。重复的⽆效QPS可以⼤幅降低。
4、 长连接避免频繁连接开销，可以⼤幅缓解TIME_ WAIT问题。
5、 真实的长连接，解决配置模块GC问题。
6、 更细粒度的同步内容，减少服务节点间的通信压⼒。
缺点
没有银弹的⽅案，新架构也会引⼊⼀些新问题
1、 内部结构复杂度上升，管理连接状态，连接的负载均衡需要管理。
2、 数据由原来的⽆状态，变为与连接绑定的有状态数据，流程链路更长。
3、 RPC协议的观测性不如HTTP。即使gRPC基于HTTP2.0Stream实现，仍然不如直接使⽤HTTP协议来的直观。
简单分享下Nacos 2.X 的后期规划吧。主要分为⽂档、质量和Roadmap。
在⽂档和质量⽅⾯，Nacos 1.X都做的不是很好。⽂档内容较少，仅有简单使⽤⽂档；和版本有⼀定脱节，更新不及时；没有对技术内容的说明，参与贡献难度⾼。代码质量及测试质量也不是很⾼，虽然已经使⽤checkstyle进⾏了codeStyle的校验以及开启了社区协作review。但是这还远远不够。Nacos 2.X将会逐步更新、细化官⽹使⽤⽂档；通过电⼦书对技术细节进⾏解析；通过Github展⽰技术⽅案，促进讨论及贡献；并且对代码进⾏⼤量重构及UT和IT的治理⼯作，在未来将Benchmark也会开源出来，⽅便给开源⽤户进⾏压测。
⽽RoadMap⽅⾯， Nacos 2.X 会对项⽬做⼤幅度的重构，完成初步插件化，并对刚才2.0架构的⼀些缺点，如负载均衡，可观测性进⾏提升。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。