xxxxxxxxxxxx
]]>为了解决这些问题,人们研究出了多种发布策略,下面我们一一介绍。
蓝绿部署
所谓蓝绿部署,是指同时运行两个版本的应用,如上图所示,蓝绿部署的时候,并不停止掉老版本,而是直接部署一套新版本,等新版本运行起来后,再将流量切换到新版本上。但是蓝绿部署要求在升级过程中,同时运行两套程序,对硬件的要求就是日常所需的二倍,比如日常运行时,需要10台服务器支撑业务,那么使用蓝绿部署,你就需要购置二十台服务器。
滚动发布
滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。
所谓滚动升级,就是在升级过程中,并不一下子启动所有新版本,是先启动一台新版本,再停止一台老版本,然后再启动一台新版本,再停止一台老版本,直到升级完成,这样的话,如果日常需要10台服务器,那么升级过程中也就只需要11台就行了。
但是滚动升级有一个问题,在开始滚动升级后,流量会直接流向已经启动起来的新版本,但是这个时候,新版本是不一定可用的,比如需要进一步的测试才能确认。那么在滚动升级期间,整个系统就处于非常不稳定的状态,如果发现了问题,也比较难以确定是新版本还是老版本造成的问题。
为了解决这个问题,我们需要为滚动升级实现流量控制能力。
灰度发布
灰度发布也叫金丝雀发布,起源是,矿井工人发现,金丝雀对瓦斯气体很敏感,矿工会在下井之前,先放一只金丝雀到井中,如果金丝雀不叫了,就代表瓦斯浓度高。
在灰度发布开始后,先启动一个新版本应用,但是并不直接将流量切过来,而是测试人员对新版本进行线上测试,启动的这个新版本应用,就是我们的金丝雀。如果没有问题,那么可以将少量的用户流量导入到新版本上,然后再对新版本做运行状态观察,收集各种运行时数据,如果此时对新旧版本做各种数据对比,就是所谓的A/B测试。
当确认新版本运行良好后,再逐步将更多的流量导入到新版本上,在此期间,还可以不断地调整新旧两个版本的运行的服务器副本数量,以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上,最后关闭剩下的老版本服务,完成灰度发布。
如果在灰度发布过程中(灰度期)发现了新版本有问题,就应该立即将流量切回老版本上,这样,就会将负面影响控制在最小范围内。
蓝绿发布,对硬件成本要求高,对新版本应用的可用性低,出现问题时可测试性高滚动发布,对硬件成本要求低,但是对新版本应用的可用性要求高,出现问题时可测试性低(流量都指向新版本应用,可能会有干扰)灰度发布,对硬件成本要求低,对新版本应用的可用性要求也低,出现问题时可测试性高(进行了流量控制,干扰会降低)
]]>
location ~* ^(/v3*|/swagger-ui/*){ proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; #proxy_set_header Host $host:$server_port; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port $server_port; proxy_pass http://ip:port;}
]]>
您可以按照以下步骤来配置 MySQL 数据库的内存大小:
打开 MySQL 的配置文件 my.cnf。该文件通常位于 /etc/my.cnf 或 /etc/mysql/my.cnf 目录下。
在配置文件中找到 [mysqld] 段落。
在 [mysqld] 段落中添加或修改以下行来设置缓冲池大小(以指定大小为例):
innodb_buffer_pool_size = 2G
这将设置 InnoDB 缓冲池的大小为 2GB。您可以根据服务器的可用内存和实际需求来调整该值。
保存并关闭配置文件。
重新启动 MySQL 服务,使配置生效;
请注意,修改 MySQL 配置文件之前,建议先备份原始配置文件,以防止意外情况发生。
此外,除了缓冲池之外,还可以对其他参数进行调整,以根据您的需求优化数据库的性能和资源使用。对于特定的工作负载和服务器配置,可能需要进行进一步的调优和配置。
如果您不熟悉 MySQL 配置和调优,建议参考 MySQL 官方文档或咨询有经验的数据库管理员或开发人员,以获取更具体和个性化的建议。
]]>打开终端或登录到 CentOS 系统。
使用以下命令查看当前已启用的开机启动项:
systemctl list-unit-files --type=service --state=enabled
这将显示已启用的服务列表,其中包括开机启动的服务。
如果您只想查看特定服务是否在开机时启动,可以使用以下命令:
systemctl is-enabled <service-name>
将 <service-name>
替换为您要检查的服务名称。
该命令将返回以下三个值之一:
enabled
:表示服务已启用并将在开机时自动启动。disabled
:表示服务已禁用,不会在开机时自动启动。masked
:表示服务被屏蔽,不会在开机时自动启动。通过查看返回的值,您可以确定特定服务是否在开机时启动。
请注意,执行上述命令可能需要管理员权限,您可能需要使用 sudo
前缀以获得足够的权限来执行这些命令。
在使用APIV3接口时,由于回调报文是以密文的形式发送的,那么用户在接收到密文后需进行解密才可以得到明文的业务数据。但进行解密时是需要获取到回调报文对应商户号设置的APIV3Key才可以进行解密,由于收到的回调报文是密文无法直接得知对应关系来获取APIV3Key。
如果用户是一个商户号对应一个回调通知地址的话那还比较好能够直接得知对应关系,但是在拥有多个商户号且回调通知地址均是同一个的情况下,很多用户都不知道如何去区分回调归属于哪个商户号,那么也就无法获取到对应的APIV3key来解密导致无法开展后续的业务流程,往往会耗费很多时间还无法解决问题。
其实这里微信侧是有提供一个标识来区分回调报文归属于哪个商户号的。
在收到的回调报文HTTP头部Wechatpay-Serial中有包含微信支付平台证书序列号,且每个商户号自身的微信支付平台证书序列号都是微信侧唯一的,在这个前提下,那么方法就来了。
首先统一把所有商户号的微信支付平台证书序列号和商户号都进行对应存储起来,在收到回调报文时通过HTTP头部Wechatpay-Serial中的微信支付平台证书序列号与现有已经存储好的微信支付平台证书序列号进行对比就可以得到回调对应的商户号从获取到对应的APIV3Key来进行解密了。
下载地址 https://github.com/wechatpay-apiv3/CertificateDownloader
以window电脑为例,本地要有jdk环境,cmd命令行启动。
官网上有参数的说明,即:
java -jar CertificateDownloader-1.2.0-jar-with-dependencies.jar -k 微信支付V3ApiKey -m 商户号 -f apiclient_key.pem路径 -s 商户平台证书序列号 -o 生成路径
如图蓝色部分就是平台证书的序列号,这个信息需要自己维护到支付配置中去
且这个平台证书序列号使用期限为5年
问题背景df -h
发现磁盘空间满了。
解决思路
使用du -sh * | sort -rh | head -10
找到空间占用大的目录或文件,查看问题原因。
2.1 可能的原因
程序运行一直报错导致日志文件过大
项目数量多导致日志文件数量大;
2.2 解决方案
程序问题,查看日志修复 Bug 即可解决。
日志文件数量大,解决方案是挂载新的磁盘。
将原目录复制到新目录下: cp -r /data/logs /new_data
权限设置:chown -R www:www /new_data/logs
删除原目录:rm -rf /data/logs
添加软连接:ln -s /new_data/logs /data/logs
3. 可能的问题
在删除目录到创建软连接的过程中,很大可能会有数据丢失。
如果是频繁更新的重要数据文件目录的话,上述方法是不可取的。
为了数据的完整性,可用以下流程:
添加软连接:ln -s /data/logs /new_data/logs
将原目录移动到新的数据盘:mv /data/logs/new_data/logs_old
创建新的软连接:ln -s /new_data/logs_old /data/logs
原文作者:Darwin
转自链接:https://learnku.com/articles/75877
版权声明:著作权归作者所有。商业转载请联系作者获得授权,非商业转载请保留以上作者信息和原文链接。