appserver

drf_yasg 文档https配置 参考 django 配置 settings.py USE_X_FORWARDED_HOST = True SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') nginx 配置 加入X-Forwarded-Proto在配置中 proxy_set_header X-Forwarded-Proto https /etc/nginx/conf.d/app_server.conf location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_set_header Host $http_host; proxy_redirect off; if (!-f $request_filename) { proxy_pass http://app_server; break; } } 来源： oschina 链接： https://my.oschina.net/tplinuxhyh/blog/3217837

3 月，跳不动了？>>> 和外部联调一直是令人困扰的问题，尤其是一些基础环境配置导致的问题。笔者在一次偶然情况下解决了一个调用外网服务概率性失败的问题。在此将排查过程发出来，希望读者遇到此问题的时候，能够知道如何入手。 起因 笔者的新系统上线，需要PE执行操作。但是负责操作的PE确和另一个开发在互相纠缠，让笔者等了半个小时之久。本着加速系统上线的想法，就想着能不能帮他们快速处理掉问题，好让笔者早点发完回去coding。 一打听，这个问题竟然扯了3个月之久，问题现象如下: 每个client都会以将近1/2的概率失败,而且报错都为: 着手排查 和appserver开发以及对应的PE交流发现，appserver和nginx之间是短连接，由于是socketTimeOutException，于是能够排除appserver和nginx建立连接之间的问题。去nginx上排查日志，发现一个奇异的现象，如下图所示: 所有的appserver都是调用一台nginx一直成功，而调用另一台nginx大概率失败。而两台nginx机器的配置一模一样，还有一个奇怪的点是，只有在调用出问题的对端服务器时才会失败，其它业务没有任何影响，如下图所示: 由于这两个诡异的现象导致开发和PE争执不下，按照第一个现象一台nginx好一台nginx报错那么第二台nginx有问题是合理的推断，所以开发要求换nginx。

3 月，跳不动了？>>> 和外部联调一直是令人困扰的问题，尤其是一些基础环境配置导致的问题。笔者在一次偶然情况下解决了一个调用外网服务概率性失败的问题。在此将排查过程发出来，希望读者遇到此问题的时候，能够知道如何入手。 起因 笔者的新系统上线，需要PE执行操作。但是负责操作的PE确和另一个开发在互相纠缠，让笔者等了半个小时之久。本着加速系统上线的想法，就想着能不能帮他们快速处理掉问题，好让笔者早点发完回去coding。 一打听，这个问题竟然扯了3个月之久，问题现象如下: 每个client都会以将近1/2的概率失败,而且报错都为: 着手排查 和appserver开发以及对应的PE交流发现，appserver和nginx之间是短连接，由于是socketTimeOutException，于是能够排除appserver和nginx建立连接之间的问题。去nginx上排查日志，发现一个奇异的现象，如下图所示: 所有的appserver都是调用一台nginx一直成功，而调用另一台nginx大概率失败。而两台nginx机器的配置一模一样，还有一个奇怪的点是，只有在调用出问题的对端服务器时才会失败，其它业务没有任何影响，如下图所示: 由于这两个诡异的现象导致开发和PE争执不下，按照第一个现象一台nginx好一台nginx报错那么第二台nginx有问题是合理的推断，所以开发要求换nginx。

1、引入SpringBoot Web依赖 2、修改启动类App.java 3、创建测试类和测试方法 4、运行启动类 5、浏览器访问测试 来源： oschina 链接： https://my.oschina.net/u/173975/blog/3190008

1. 在云端添加测试设备 打开之前教程新建的LWM2M产品，进入设备管理界面新建真实设备，设备标识符要填写NB模组的IMEI号，可以使用如下命令查看： AT+CGSN=1 测试结果如下： +CGSN:867725038317248 OK 获取到IMEI号之后创建设备： 创建之后会自动进入调试界面，接下来开始调试。 2. NB模组使用LWM2M直接对接华为云 BC35-G模组可以直接对接华为云平台，步骤如下。 设置自动注册模式 使用该命令设置模组开机后自动注册到华为云平台： AT+QREGSWT=1 设置CDP服务器ip和端口 使用该命令设置服务器的ip和端口： AT+NCDP=49.4.85.232,5683 华为云平台LWM2M对接信息可以在平台上查看： 重启模组 第一步设置了模组开机自动连接云平台，所以使用如下命令重启模组： AT+NRB 复位后可以看到设备已经上线： 在串口助手中可以看到，模组返回信息如下： +QLWEVTIND:0 +QLWEVTIND:3 这两个信息表示 设备成功注册，IoT平台已观察到对象19，当模块报告此消息时，数据可以发送到 IoT 平台。 模组向华为云平台发送数据 使用如下指令向华为云平台发送数据，模拟亮度值上报： AT+QLWULDATA=3,000006 在云端可以看到模组上报的数据： 模组接收华为云平台下发数据 在华为云平台点击下发命令“on

NoClassDefFoundError 和 ClassNotFoundException 什么区别？ 是什么导致它们被抛出？ 如何解决？ 在修改现有代码以包含新的jar文件时，我经常遇到这些throwables。 我在客户端和服务器端都通过Webstart分发了一个Java应用程序。 我遇到的可能原因： 客户端代码未包含在 build.xml 中的软件包 我们正在使用的新jar缺少运行时类路径 版本与先前的jar冲突 今天，当我遇到这些问题时，我采取了走错一步的方法来使事情顺利进行。 我需要更多的清晰度和理解。 #1楼 NoClassDefFoundError 基本上是一个链接错误。 当您尝试实例化一个对象时会发生这种情况（静态地使用“ new”），而在编译过程中则找不到该对象。 ClassNotFoundException 更通用，是当您尝试使用不存在的类时的运行时异常。 例如，您在函数中具有接受接口的参数，并且有人传入实现该接口的类，但您无权访问该类。 它还介绍了动态类加载的情况，例如使用 loadClass() 或 Class.forName() 。 #2楼 与Java API规范的区别如下。 对于 ClassNotFoundException ： 当应用程序尝试使用其字符串名称通过其字符串名称加载类时抛出： 类 Class 的 forName 方法。 类

本文对于初学 nginx 是有一定帮助的，目的在于解决初学 nginx 的一些难点，因为我也只是个后端开发，nginx 一般是运维在维护。 nginx 可以做哪些事呢 做代理：现在基本都是前后端分离开发，前端会单独启动一个服务，在开发的时候我们可以使用 vue 的代理功能，但部署的时候就需要使用 nginx 的代理了，不然访问就跨域了； 做缓存：对于前端的一些图片，样式和脚本文件，一般不会经常变化，这时可以使用 nginx 的缓存功能； 负载均衡：nginx 支持负载均衡功能，可以将流量分发到多台服务； 文件上传：nginx 自带有文件上传模块，之前公司有用过 ssl 认证和数据压缩 会有一些什么难点 location 的匹配规则不清楚 nginx 指令的意思 ，常用哪些指令 root，index，rewrite，proxy_pass ，alias 没有匹配到路径时，去哪里找问题 当配置文件特别复杂时，如何分模块配置 当使用 https 时，证书如何弄 写在开头的话 nginx 每一条语句后面必须加分号 nginx 用于对每一个请求进行拦截，然后做相应处理 可以把 nginx 当成一个语言来看，它也有变量，分支，循环等功能 重点关注 location 的匹配规则，其它都只是些指令，弄清楚意思就可以了 基本操作 nginx -s reload # 重新加载配置 nginx -s

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 解Bug之路-记一次调用外网服务概率性失败问题的排查 前言 和外部联调一直是令人困扰的问题，尤其是一些基础环境配置导致的问题。笔者在一次偶然情况下解决了一个调用外网服务概率性失败的问题。在此将排查过程发出来，希望读者遇到此问题的时候，能够知道如何入手。 起因 笔者的新系统上线，需要PE执行操作。但是负责操作的PE确和另一个开发在互相纠缠，让笔者等了半个小时之久。本着加速系统上线的想法，就想着能不能帮他们快速处理掉问题，好让笔者早点发完回去coding。一打听，这个问题竟然扯了3个月之久，问题现象如下: 每个client都会以将近1/2的概率失败,而且报错都为: java.net.SocketTimeoutException: Read timed out 着手排查 和appserver开发以及对应的PE交流发现，appserver和nginx之间是短连接，由于是socketTimeOutException,于是能够排除appserver和nginx建立连接之间的问题。去nginx上排查日志，发现一个奇异的现象，如下图所示: 所有的appserver都是调用一台nginx一直成功，而调用另一台nginx大概率失败。而两台nginx机器的配置一模一样，还有一个奇怪的点是,只有在调用出问题的对端服务器时才会失败