产品要求的功能都都开发完了,但这并不是终结。怎么样做才能让我们的服务具有更好的质量。 笔者结合自己的遇到的问题和工作中的经验,并以提问的方式,给读者一点点建议
建议加入/etc/init.d/local开机启动
建议用supervisor做守护。
建议用supervisor做监控、报警。
峰值是多少?一般在什么时间点触发? 每种URL的请求量是否合理?
建议用EFK收集日志分析。
建议用EFK收集日志分析。
建议用EFK收集日志分析。
建议开启profile, 压力测试下。
其中哪些是无状态的,哪些是弱状态的,哪些是强状态的。这些外部服务和系统,是否已经做到高可用?能否做到快速扩容?
建议观察网卡/机房带宽的日志记录,开启gzip、snappy等压缩传输。
1地为2个热备,别一地为1个冷备或热备。每个地区的网络线路,是否能做到2套或2套以上 (防止光纤被挖断的情况)
建议用etcd/zookeeper/consul作服务发现。
基于docker/k8s的容器伸缩方案,扩容快,分钟级别;
如果是ansible/jenkins/saltstack脚本批量部署,扩容慢,可能是小时级别,对环境一致性要求严格。
推荐用 gitlal readme或wiki.
推荐用gitlab或jenkins CI/CD。
可以池化,也即链接池,设置好最大的poolSize
建议查看mysql slowlog和程序打点tracing日志, 并优化常见mysql事项,如索引。
建议查看redis slowlog和程序打点tracing日志。
cache会不会与数据库存储不一致,不一致是否可以容许
如果服务和其它服务有交互,他们之间是长连接吗?
htop, iotop, 是否有大量的TIME_WAIT
和CLOSE_WAIT .
opentracing
可能rsyslog收集nginx/ha 访问日志
不要用kill -9 ,而是kill -TERM 等通知程序,让程序主动就绪后退出,可以延迟一定时间,比如5s。
如果有可能造成不一致,那么如何发现这种不一致?有没有对应修复的策略 比如在交易系统中的定期对账
比如一个新闻客户端,如果出现服务出现故障,可以降级为新闻只读,但是无法评论。一般做法是先降级熔断非核心的业务如http/rpc/db的慢请求,最后降级熔断相对不重要的业务,还可以增加缓存时间、静态化、扩容等。
防止请求一直阻塞。
可能出错的地方都埋点日志,特别是IO相关操作,并收集、上报打点日志
如果已经做了备份,是否是备份在异构的数据库中
可以是按照用户维度,也可以按照IP维度来限制, 还可以按地域/业务类型等。
---完