绅士jiejie的博客

Caused by: java.net.UnknownHostException: nacos

[check-update] get changed dataId error, code_ 403

源码启动nacos，nacos日志在哪看

nacos适配数据源的一些坑

Nacos适配神通数据库

源码运行Nacos

打包nacos源码报license_ 30 See RAT

连接远程的nacos，但是服务一直有连接本地nacos的报错日志

手动上传jenkins插件

Spring Cloud Gateway关闭admin监控

Failed to instantiate [io.seata.spring.annotation.GlobalTransactionScanner]

通过Actuator组件来直接做查询，接口如下：localhost:port/actuator/gateway/routes

spring cloud版本选择

首先抛出自定义异常这个思路是没啥问题的，至少比抛出UsernameNotFoundException来的自由些，因为在hideUserNotFoundExceptions属性默认为true的情况下，UsernameNotFoundException会被转换成BadCredentialsException，同时连异常信息都会被写成固定的Bad credentials了，部分源码参考如下：首先我们要先定义一个自定义异常类，参考如下：/** 1. @Author:jiejie 2. @Desc: 自

本文这里所说的异常，指的是下游服务主动抛出的业务异常，是由开发自己手动抛出的。因为被调用方有写了一个全局异常处理器，所以业务异常被抛出后，会被全局异常处理器捕获到，然后变成一个正常的响应对象，那么此时服务调用者其实收到的就是一个正常的返回对象了，那么自然不会做什么处理异常的逻辑，所以此时我这的做法就是先判断下远程调用响应回的对象中的响应码正不正确，一般来说没有抛异常，正常响应码都是200，那么加个判断，如果响应码不是200，就说明有异常出现，那么就加一个判断处理逻辑，拿到响应对象中的message，在服务

解决方法：把服务提供者的返回值类型由IPage转为Page，Page是IPage的实现类，二者同是mybatis-plus包下的对象，参考代码如下： IPage<SysUserVO> sysUserVOIPage = sysUserService.getUserPage(); Page<SysUserVO> sysUserVOPage = new Page<>(); BeanUtils.copyProperties(s.

解决思路：加入监听器，监听认证成功和认证失败的事件，然后做相应处理。实现参考代码新建一个组建类AuthenticationLoginEventListener，专门用来监听认证登陆事件，如下：@Componentpublic class AuthenticationLoginEventListener { /** * 登陆鉴权成功事件处理 * * @param event */ @EventListener public vo.

这个问题不是因为fegin发起的请求是新请求，所以会丢失请求头导致的，项目使用认证中心做统一认证，然后使用网关统一做鉴权和授权，下游的微服务不会涉及任何权限方面的校验。经过排查后，其实原因很简单，是因为之前用来测试的用户被禁用了，而认证中心引入了security，用户类都是实现了UserDetails接口的，所以UserDetails接口中的isEnabled()方法被重写，这个字段的赋值取自数据库中用户表的禁用/启用状态字段。解决方法重新启用用户就好了。这里分享下这个坑，希望能够帮到一些朋友，

网关做统一鉴权,不过有些接口是无需校验权限的，比如登陆，比如注册，同样的，作为用于前后端对接的文档接口，也是不需要设置鉴权的，所以要把这些接口路径都加入白名单中。整合后的swagger文档路径会有所不同，下面列出需要加入白名单的swagger文档相关路径，如下: - "/api/**/v2/api-docs" - "/swagger-resources/**" - "/doc.html" - "/favicon.ico" - "/webjars/*

示例代码： - id: auth-server uri: lb://auth-server predicates: - Path=/api/auth/** filters: - RewritePath=/api/auth/(?<segment>.*),/$\{segment} - AddRequestHeader=Client-Id,666然后在

跨域问题经常解决，本来以为这次也很简单，就是搞个跨域配置类，统一在网关处理就好了，像什么双重跨域这些问题早都处理过一次了，但后面发现跨域问题还是存在，一模一样的配置，为什么换个项目就不行了？带着以上的问题，我开始做对比，发现这个网关项目多引入了spring security这个安全框架依赖，同时也初步配置了一些安全框架所需的配置类，项目初起步，没必要分析这么深，所以我直接手起刀落，把spring security相关的东西都先删了，然后重启网关，发现跨域问题已经解决了。具体问题我没去分析，感觉太麻烦了，先

问题出在如果没有指定nacos的启动方式，所以可以查看到容器是成功运行的，但是却不能访问。解决方式：加上启动方式，比如单机启动，如下：docker run --env MODE=standalone -d -p 8848:8848 --name nacos nacos/nacos-server...

配置文件没写服务名，写上就好，如下：spring: application: name: admin

这里简单的说下步骤，首先在每个微服务(除了网关微服务)中都需要引入knife4j的微服务依赖，这个依赖是不包含API文档前端UI包的，因为由网关来做统一展示，依赖如下： <dependency> <groupId>com.github.xiaoymin</groupId> <artifactId>knife4j-micro-spring-boot-starter</artifactId> <.

网关作为整个微服务架构的门户，浏览器发起请求后，却发现，请求根本转发不到相应的微服务，走进关键的过滤器LoadBalancerClientFilter里，打上断点，发现请求根本没走到这步，推测是路由配置出错了，然后发现路由如下：这明显是路由配置写错了，所以没有生效，修改成如下：之后请求能够成功转发。...

在电商的业务场景中，下单和扣库存的操作是发生在订单服务和商品服务，所以下单的业务操作需要保证分布式事务,所以接下来我们引入Seata来完善我们的分布式事务问题。先下载Seata，地址如下：https://github.com/seata/seata/releases/v0.9.0/修改配置文件下载后解压，进入conf目录，调整下面的配置文件：registry.conf：nacos-config.txt：上述截图中的配置项的规则是service.vgroup_mapping.$ {

之前如果在单体项目中，想要保证数据的一致性，就需要使用到事务。事务是什么？事务指的就是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作都成功，要么所有的操作都被撤销。单机情况或者单服务的情况下，只要是一个服务能提供所有功能，哪怕是这个服务是多实例的，也可以使用本地事务来保证数据的一致性。但是微服务架构下，是由多个微服务协同合作，作为一个整体对外提供服务，虽然在用户看来，好像还是一个系统，没什么变化，但是对于开发者来说，引入了微服务架构，系统的复杂性也大大增加了，需要考虑的更全

在引入nacos前，先了解一下nacos的几个简单概念，如下：命名空间(Namespace)**，配置分组(Group)，配置集(Data ID)，其中命名空间和配置分组，主要可以用来做服务和环境的隔离，而配置集则主要用来抽离服务配置，比如说把一些公共的配置抽离成配置集，避免重复的写在每个nacos服务创建的配置中，由于用来测试的几个服务比较简单，所以就不抽离配置集了，下来演示一下，用命名空间来划分服务，用配置分组来划分环境的nacos配置中心使用场景。目前来说，每个服务的配置文件都需要在配置中心维护，

既然我们是站在分布式的角度去学习Spring Cloud Alibaba这个知识点，那么就要意识到分布式的一些问题，比如分布式间的进程通信，我们使用了基于http的fegin，分布式之间各服务的治理，我们采用了nacos，分布式之间的容错机制，我们引入了sentinel，那么此时针对这个分布式项目，我们突然要对某个服务改动它的某个配置项，不如链路追踪的采样比例要改小写，因为QPS太多了，又比如网关gateway的路由规则需要多添加一个filter等，目前我们的做法只能修改项目中的配置文件，然后提交代码，重新

由于项目引入了nacos作为配置中心，启动后项目报Application failed to connect to Nacos server: " " Action: Please check you异常。解决方法：在项目中加上nacos配置中心所需的bootstrap.yml文件即可。

首先要登录阿里云申请开通短信服务，如下：然后要申请AccessKey，这是访问阿里云API的密匙。接着再新增下短信相关的签名和模版，不过要经过审核，我第一次就审核失败了。。。尴尬等到审核成功后，就可以开始写代码了，直接参考阿里云给的文档即可。其实短信服务可以专门新建一个第三方服务，里面可以存放短信服务sms，文件存储服务oss等需要调用第三方接口的服务，不过这里就没搞那么麻烦，只是提供个建议，还是放在公共模块，了解下使用就好，在mall-common模块中新增sms依赖，如下：<!-

为什么要引入RocketMQ？使用消息中间件，最主要的几大作用是异步，削峰填谷，解耦。项目中有个业务逻辑是这样的，用户下单完成后，系统需要发下单成功的短信给用户，而下单成功的操作和发短信的操作并不是强耦合的，或者说作为开发，我要求发短信的耗时不能延长下单的响应时间，影响用户体验，所以我要把下单操作和发短信操作解耦，如果用的是还是原来的fegin框架实现远程通信，是做不到业务解耦的，所以这里需要引入消息中间件，完成业务异步和解耦的设计。而消息中间件也是多种多样，有Kafka，RabbitMQ，Rocke.

Zipkin提供了可插拔数据存储方式:In-Memory、MySql、Cassandra 以及 Elasticsearch。这里演示一下使用MySql实现ZipKin数据持久化，毕竟数据库对一个系统来说是肯定会有的，而Elasticsearch就不一定了，没必要专门为了持久化ZipKin数据而引入Elasticsearch，有点大材小用了，当然了，如果本来就有Elasticsearch，那么也可以使用Elasticsearch，避免建库建表的操作。首先创建一个库ZipKin，然后运行一下脚本，初始化Zi

由于是每个服务都需要链路追踪，所以把Sleuth的依赖加入到公共模块mall-common中，如下： <!--链路追踪 Sleuth--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId>

一个系统被拆分成多个微服务，而一个完整的业务逻辑，可能会需要多个微服务相互配合才能完成，相比起之前的单体服务，那时单体服务的一个请求，对应的可能是微服务架构下的一条完整调用链。但服务之间是跨机器甚至是跨地区的，也很有可能是不同的语言开发的，所以这种架构形式也会引发如下一些问题:如何快速发现问题?如何判断故障影响范围?如何梳理服务依赖以及依赖的合理性?如何分析链路性能问题以及实时容量规划?其实可以想想，之前单体服务服务时，我们是通过日志排查问题，那现在采用微服务架构就不能通过日志排查问题了？归根

之前分别把单个服务接入Sentinel，然后在Sentinel控制台上配置各种规则来为微服务做容错，此时已经整合进了网关组件，网关作为整个服务端的门户，把限流的功能统一抽取，放在网关，会是比较正常的逻辑。接下来就是Gateway整合Sentinel，在mall-common项目的pom.xml文件下加入如下依赖：<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spr

全局过滤器的作用全局过滤器作用于所有路由, 无需配置。通过全局过滤器可以实现对权限的统一校验，安全性验证等功能。其实内置的全局过滤器已经可以完成大部分的功能，但是对于企业开发的一些业务功能处理，比如说鉴权等，就还是需要开发自定义一个全局过滤器来实现的。接下来简单实现一个全局过滤器，去校验所有请求的请求参数中是否包含“token”，如果不包含请求参数“token”则不转发路由，否则执行正常的逻辑。一样找个内置的全局过滤器来做参考，如RouteToRequestUrlFilter，然后可以发现自定义全.

从专栏的第二十四篇博客可以知道，请求被路由到微服务之前以及微服务响应请求回网关之前，都会经过一连串的过滤器。过滤器的主要作用就是在请求的传递过程中,对请求和响应做一些手脚。在Gateway中, Filter的生命周期只有两个，PRE 和 POST，PRE这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。 POST这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端

上篇博客简单的了解了下路由规则中的各个参数的含义，其中断言是能够决定了能否执行路由，在什么条件什么条件下才会进行路由转发。SpringCloud Gateway包括许多内置的断言工厂，所有这些断言都与HTTP请求的不同属性匹配。 一般情况下，内置的断言工厂基本能够满足开发需求，不过如果有些业务逻辑比较特殊，那么我们也可以自定义路由断言工厂，在网关做统一判断。如何自定义路由断言工厂？这里分享下思路，由于SpringCloud Gateway有许多内置的断言工厂，随便找到一个内置的断言工厂，看看它是怎么

这个方法在整合spring cloud gateway组件进入项目时，是很有用的。如果给项目引入了网关，那就代表着大多数甚至是全部请求都需要由网关来路由转发，那就需要编写对应的路由规则。那么怎么知道我们的路由规则写的对不对，如果通过网关访问微服务接口无法正常响应，怎么排查，此时需要找到路由后的真实路径，然后就可以知道是不是路由规则写错了。怎么找到路由后的真实路径？这里不建议加配置，改源码，打日志什么的，直接源码打断点，查看参数值，毕竟网关整合也只是网关正常上线才需要调试，不需要专门打出日志，改源