个人技术分享

Sentinel 与 Nacos的整合不仅强化了微服务的流量控制能力，还实现了配置的集中化、动态化管理，是提升系统稳定性和运维效率的关键措施，对于构建高可用、易维护的微服务架构具有深远的意义。

三者不能同时存在。CP：由于网络分片的存在，如果要保证强一致性就不能写，此时不满足可用性AP：由于网络分片的存在，如果要保证可用性，能读也能写，就不能保证强一致性。

早期微服务跨集群调用 使用的是Eureka 和RestTemplate，这种写法虽然可以解决服务之间的调用问题 ,但是随着服务的增多，实例变动，早期的写法相当于把请求方式，请求地址，参数写死了，耦合度太高，参数非常多的情况使用起来不方便。

作用与一切进入的网关的请求和服务器响应。与GatewayFilter作用一致，区别在于GatewayFilter通过配置定义，处理逻辑是固定的。而GlobalFilter的逻辑需要自己写代码实现，比较灵活。例如，验证请求参数中，权限是否为admin，若是，放行。

综上所述，SOA和微服务在服务粒度、通信方式、交付要求、应用场景以及服务管理和部署等方面存在显著差异。这些差异使得两者在各自适合的场景中发挥着不同的优势。SOA（面向服务的架构）与微服务之间的区别可以从多个维度进行分析。

微服务的开发模式和单体服务差异比较大，对设计、开发、测试、运维等研发流程的各个阶段都提出了新的挑战。微服务拆分确实会带来很多实实在在的收益，但同时在开发、测试、运维等多个方面也带来了很多挑战。特别是在业务发展初期，团队人员不多，对微服务周边技术和基础设施的积累不够，贸然采取微服务架构，不仅无法带来预期的收益，还可能严重阻碍业务的快速迭代，严重时甚至可能变成一个灾难。那么我们该在什么样的时机引入微服务呢？今天我们就来看下微服务的挑战和微服务化的具体时机。

构建Spring Boot与Dubbo集成：以Nacos为注册中心

Nacos简介以及安装部署

构建Spring Boot与Dubbo集成：以Nacos为注册中心

由于实现还未封装用户信息，所以为null。 下面我们来使用**远程调用**用户服务的接口，然后封装一下用户信息返回即可。

Nacos简介以及安装部署

通过构建高效可扩展的服务网关，可以更好地满足复杂系统的需求，提升整体系统的性能与可靠性，为企业级应用的发展提供有力支持。随着微服务架构的流行，网关微服务作为微服务架构中的重要组成部分，扮演着连接客户端与后端微服务的关键角色。利用负载均衡算法，实现对后端微服务的流量分发，避免单个微服务节点过载，同时通过流量控制机制，限制并发请求，保护后端服务的稳定性。通过弹性伸缩的方式，根据系统负载自动调整网关微服务实例数量，提高系统的可用性和稳定性，同时支持水平扩展，满足业务快速发展的需求。#### c. 监控与日志。

在order-service中加入同样配置，测试order在调用userservice是否优先选择本地集群,把order-service放在HZ，user-service两个分支一个在HZ，一个在SH。测试结果 : 在杭州集群的order-service只调用了在杭州集群的user-service而未调用在上海集群的user-service。修改user-service的yml配置文件 order-service同理 把user-service服务发现到nacos。

单体应用（monolith application）就是将应用程序的所有功能都打包成一个独立的单元，可以是 JAR、WAR、EAR 或其它归档格式。随着业务需求的快速发展变化，敏捷性、灵活性和可扩展性需求不断增长，迫切需要一种更加快速高效的软件交付方式。微服务就是一种可以满足这种需求的软件架构风格。单体应用被分解成多个更小的服务，每个服务有自己的归档文件，单独部署，然后共同组成一个应用程序。这里的“微”不是针对代码行数而言，而是说服务的范围限定到单个功能。

前面 5 讲我围绕稳定性、技术债务和大项目管理分享了一些过往的经验与思考，从今天开始，我会用两讲的时间，围绕“架构设计与系统演进”与你分享我的经验。这几方面是我认为技术 Leader 在技术工作上一定要做好并且极为重要的，从八二法则上看，它们也是我认为值得花 80% 的精力去做好的，而你能否做好这几点会影响团队未来的发展。

AI大模型下的微服务会有什么？

d. 线程池提供了任务调度和管理的能力，比如设置核心线程数、最大线程数、队列容量等，这样可以更精细地控制任务的执行行为。大家都知道，在我们实际开发过程中，我们经常会遇到一些耗时的业务和逻辑，比如说要上传什么大文件，又或者是大文件的数据处理。，可以复用线程，减少资源消耗。线程池中的线程可以被重复使用，而不是每次执行异步任务时都创建新的线程。，这不是一个真正的线程池，因为它为每个任务创建一个新的线程。我们看到Async内，只有一个参数value，这个value的设置来确定异步线程指定线程池的名字。

当我们写了一个A接口，这个接口需要调用B接口，但是B接口需要包含请求头内容，比如需要用户信息、用户id等内容，由于不在同一个线程中，使用去获取数据是无法获取的，这个时候需要手动将信息放置请求头中。

在order-service中加入同样配置，测试order在调用userservice是否优先选择本地集群,把order-service放在HZ，user-service两个分支一个在HZ，一个在SH。测试结果 : 在杭州集群的order-service只调用了在杭州集群的user-service而未调用在上海集群的user-service。修改user-service的yml配置文件 order-service同理 把user-service服务发现到nacos。

微服务架构是一个分布式系统，由多个独立的服务组成，每个服务可能运行在不同的容器、虚拟机或物理机上，那么在生产环境中我们需要随时监控服务的状态，以应对各种突发情况，比如：内存爆满，CPU标高等等。Prometheus作为一种开源的监控和告警系统，天生就是为分布式系统设计的。它能够轻松地收集、存储和查询各个微服务的监控数据，为微服务架构提供全面的监控能力。Prometheus（普罗米修斯）是一个最初在SoundCloud上构建的监控系统。自2012年成为社区开源项目，拥有非常活跃的开发人员和用户社区。