问题描述 在nacos服务注册时，发现注册的服务全是容器虚拟IP，并不是可以通讯的内网IP。 问题原因 开启了user namespace，将系统用户映射到docker容器里，使其不再使用root权限。由于开启了user namespace，所以docker容器不能再共享net namespace即docker网络不能再使用host模式，只能用bridge模式。此时服务容器便有了一个虚拟ip，一般该ip在docker0的网段（默认为172）之下。所以服务注册时便使用这个ip进行注册。 解决方案 第一种（不推荐） 为服务设置IP,在服务的配置文件bootstrap.yml中，配置： spring: cloud: nacos: discovery: ip: 10.1.1.
为什么要使用第三方登录器？和官方登录器相比有什么优点？ 由于官方登录器的一些长期缺陷，Dayz玩家社区开发出了便于使用的第三方登录器。和官方登录器相比，第三方登录器有以下两大优点： 1. 服务器列表下载速度非常快，通常只需要几秒即可刷新出所有服务器（包括一些你用官方登录器找不到，但其他人能搜到的服）。 2. 支持一键加入服务器，带mod的服务器，只需点击加入，自动帮助用户订阅下载并加载该服务器所需的所有mod。 下载地址 官网 https://dayzsalauncher.com 国内 https://cloud.qccq.cc/index.php/s/AzXEkyFeakgjF2t 使用方法 下载安装完成后，先打开steam，保持steam好友在线，
在Spring Cloud Gateway中，读取Get请求的参数并非一件很难的事，但是读取Post请求的请求体(body)也并非一件简单事。 说明 Spring官方虽然提供了预言类： ReadBodyPredicateFactory (谓词工厂)、ModifyRequestBodyGatewayFilterFactory (过滤器工厂)， 但仍然是 bate 版，并没有直接实现获取 request body 的 filter，所以如果想要读取request body，需要参考以上两个预言类，自行实现filter。 实现方式 首先，实现一个CacheRequestBodyFilter用来将request body读取出来并存到exchange的自定义属性中: package ltd.lemontech.contractor.gateway.
使用docker部署前端时，如果使用了静态资源压缩，则需要在nginx的配置中开启gzip： server { listen 80; server_name localhost; gzip on; gzip_static on; # 需要http_gzip_static_module 模块 gzip_min_length 1k; gzip_comp_level 4; gzip_proxied any; gzip_types text/plain
Rancher密码忘记了可以通过命令重置： docker exec -it <rancher容器id> reset-password 执行命令就可以看到重置后的密码了，拿到密码登陆后再修改即可。
问题 在NextCloud后台设置连接OnlyOffice时一切正常，并且域名为https， NextCloud域名和OnlyOffice域名均使用nginx代理（使用了宝塔，方便管理），OnlyOffice只对外映射了80端口，证书使用了nginx配置，但是在打开文档时会报错： Refused to frame 'http://office.xxx.com' because itviolates the following Content Security Policy directive: "frame-src 'self' https://demo.
熔断降级 什么是熔断降级 由于调用关系的复杂性，如果调用链路中的某个资源出现了不稳定，最终会导致请求发生堆积。这个问题和 Hystrix 里面描述的问题是一样的。 Sentinel 和 Hystrix 的原则是一致的: 当调用链路中某个资源出现不稳定，例如，表现为 timeout，异常比例升高的时候，则对这个资源的调用进行限制，并让请求快速失败，避免影响到其它的资源，最终产生雪崩的效果。 熔断降级设计理念 在限制的手段上，Sentinel 和 Hystrix 采取了完全不一样的方法。 Hystrix 通过线程池的方式，来对依赖(在我们的概念中对应资源)进行了隔离。这样做的好处是资源和资源之间做到了最彻底的隔离。缺点是除了增加了线程切换的成本，
🍬A set of tools that keep Java sweet. 官网： 👉 https://hutool.cn/ 👈 📚简介 Hutool是一个小而全的Java工具类库，通过静态方法封装，降低相关API的学习成本，提高工作效率，使Java拥有函数式语言般的优雅，让Java语言也可以“甜甜的”。 Hutool中的工具方法来自每个用户的精雕细琢，它涵盖了Java开发底层代码中的方方面面，它既是大型项目开发中解决小问题的利器，也是小型项目中的效率担当； Hutool是项目中“util”包友好的替代，它节省了开发人员对项目中公用类和公用工具方法的封装时间，使开发专注于业务，同时可以最大限度的避免封装不完善带来的bug。 🍺Hutool如何改变我们的coding方式 Hutool的目标是使用一个工具方法代替一段复杂代码，从而最大限度的避免“复制粘贴”
传统项目处理配置的问题 没有「配置中心」的传统项目中，我们是怎么处理各类配置参数问题的： 1. 静态化配置 大多数在项目配置写在例如 application.propertie，然后将各类 参数配置、应用配置、环境配置、安全配置、业务配置 都写到这个文件里。当项目代码逻辑中需要使用配置的时候，就从这个配置文件中读取。这种做法虽然简单，但如果参数需要修改，就非常的不灵活，甚至需要重启运行中的项目才能生效。 2. 配置文件无法区分环境。 由于配置文件是放在项目中的，但是我们项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置参数理论上都是不同的，所以我们在配置文件中根据不同环境配置不同的参数，这些都是手动维护，
为什么需要服务注册与发现 * 如下图，当 A用户服务调用B订单服务时，一般情况下会使用 httputils 请求 B服务的 IP:port (http://192.168.0.200:8080/xxx) 即可。但是当 B订单服务的网络信息（IP等）发生改变则A对应服务的代码配置也要做对应的修改，增加服务间的耦合性和运维部署的复杂性。 * 如下图， 当A用户服务调用B订单服务时，为了保证B服务（服务提供方）的高可用，我们会对B服务部署多份，然后通过NGINX 反向代理，提供统一的服务地址 。 我们需要根据每个B服务节点的信息，实时维护nginx
