错误提示:
./configure: error: the HTTP rewrite module requires the PCRE library.
解决办法:
- 安装 pcre-devel 与 openssl-devel
- yum -y install pcre-devel openssl openssl-devel
- ./configure –prefix=/usr/local/nginx
- make
- make install
错误提示:
./configure: error: the HTTP rewrite module requires the PCRE library.
解决办法:
新建了一个仓库之后,把本地仓库进行关联提交、拉取的时候,出现了如下错误:
ankobot@DESKTOP-9IUDMKP MINGW64 /e/workspace/firmware_upload/firmware_upload (master)
$ git pull
fatal: refusing to merge unrelated histories
在你操作命令后面加 –allow-unrelated-histories
例如:
git merge master --allow-unrelated-histories
$ git pull --allow-unrelated-histories
CONFLICT (add/add): Merge conflict in .gitignore
Auto-merging .gitignore
Automatic merge failed; fix conflicts and then commit the result.
我这里由于使用了官方的 .gitignore 自动合并失败,需要手动合并之后再进行 add、commit 即可
如果你是git pull或者git push报fatal: refusing to merge unrelated histories
同理:
git pull origin master –allow-unrelated-histories / git pull –allow-unrelated-histories
等等,就是这样完美的解决!
查了一下,原来com.fasterxml.jackson搞的鬼,我的问题是实体类有一个属性叫UDID,但是接口返回的JSON变成了小写udid。
使用@JsonProperty(“UDID”)注解可以完美解决调这个问题,例子:
@JsonProperty("UDID") private String UDID;
放在geter方法同样有效:
@JsonProperty("UDID") public String getUDID() { return UDID; }
建议是放在geter方法上,如果放在属性上,它会出现两个UDID,一个是大写的,一个小写的。
那么放在方法上呢,就不会出现这个问题。
我用到的配置,贴个记录
logging: level: root: info file: path: ./log/${server.port} pattern: file: '%d{yyyy/MM/dd HH:mm:ss.SSS} %clr(%-5level) [%magenta(%thread)] %cyan(%logger{15}) : %msg%n' console: '%d{yyyy/MM/dd HH:mm:ss.SSS} %clr(%-5level) [%magenta(%thread)] %cyan(%logger{15}) : %msg%n'
百分号格式化解释:
配置参数:
logging.level设置日志级别。我们可以使用TARCE , DEBUG , INFO , WARN , ERROR , FATAL , OFF 。可以使用root级别和package级别来控制日志的输入级别。创建一个具有以下依赖关系的应用程序。
Spring Boot 默认把日志输入到console,如果我们要把日志输入到文件中,需要配置logging.file 或者logging.path属性性。logging.file属性用来定义文件名。他不仅仅可以配置文件名,也可以路径+文件名。
配置logging.path或者logging.path属性将日志输出到文件夹中。logging.path属性用来定义日志文件路径。
通过设置logging.patter.console属性我们能改变输出到console的日志样式。日志样式包括时间,日志级别,线程名,日志名以及消息。我们可以按我们的喜好改变日志样式
改变文件中的日志样式我们需要设置logging.pattern.file属性。首先通过logging.file或logging.path属性,把日志记录到文件中。
应用程序升级面临最大挑战是新旧业务切换,将软件从测试的最后阶段带到生产环境,同时要保证系统不间断提供服务。
长期以来,业务升级渐渐形成了几个发布策略:蓝绿发布、灰度发布和滚动发布,目的是尽可能避免因发布导致的流量丢失或服务不可用问题。
一、 蓝绿发布
项目逻辑上分为AB组,在项目系统时,首先把A组从负载均衡中摘除,进行新版本的部署。B组仍然继续提供服务。
当A组升级完毕,负载均衡重新接入A组,再把B组从负载列表中摘除,进行新版本的部署。A组重新提供服务。
最后,B组也升级完成,负载均衡重新接入B组,此时,AB组版本都已经升级完成,并且都对外提供服务。
蓝绿发布在早期物理服务器时代,还是比较昂贵的,由于云计算普及,成本也大大降低。
灰度发布只升级部分服务,即让一部分用户继续用老版本,一部分用户开始用新版本,如果用户对新版本没什么意见,那么逐步扩大范围,把所有用户都迁移到新版本上面来。
灰度发布是通过切换线上并存版本之间的路由权重,逐步从一个版本切换为另一个版本的过程。
滚动发布是指每次只升级一个或多个服务,升级完成后加入生产环境,不断执行这个过程,直到集群中的全部旧版本升级新版本。
综上所述,三种方式均可以做到平滑式升级,在升级过程中服务仍然保持服务的连续性,升级对外界是无感知的。那生产上选择哪种部署方法最合适呢?这取决于哪种方法最适合你的业务和技术需求。如果你们运维自动化能力储备不够,肯定是越简单越好,建议蓝绿发布,如果业务对用户依赖很强,建议灰度发布。如果是K8S平台,滚动更新是现成的方案,建议先直接使用。
近期评论