前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >开发更高可用、高质量的服务的一些建议

开发更高可用、高质量的服务的一些建议

作者头像
sunsky
发布2020-08-20 16:10:52
6750
发布2020-08-20 16:10:52
举报
文章被收录于专栏:sunsky

1.引言

产品要求的功能都都开发完了,但这并不是终结。怎么样做才能让我们的服务具有更好的质量。 笔者结合自己的遇到的问题和工作中的经验,并以提问的方式,给读者一点点建议

2. 提问QA (重要性不分先后)

2.1 如果服务器重启,服务是否能自动拉起?

建议加入/etc/init.d/local开机启动

2.2 如果程序异常退出,服务是否能够自动拉起?

建议用supervisor做守护。

2.3 如果程序异常退出,能够自动拉起,那么你怎么知道服务是否发生了重启?

建议用supervisor做监控、报警。

2.4 如果是web服务,QPS是多少?每个URL的QPS是多少?

峰值是多少?一般在什么时间点触发? 每种URL的请求量是否合理?

建议用EFK收集日志分析。

2.5 如果是web服务,每个请求的响应时间是多少?TP90?TP99分别是多少?

建议用EFK收集日志分析。

2.6 异常请求(比如HTTP非200的比例是多少?)什么样的比例是合理的?为什么?

建议用EFK收集日志分析。

2.7 如果是多实例部署,那么整个系统的cpu、内存、并发QPS承载极限是多少?如果达到了极限,瓶颈在哪儿(木桶原理中所谓的短板)

建议开启profile, 压力测试下。

2.8 服务都有哪些依赖项(微服务/数据库/文件系统)

其中哪些是无状态的,哪些是弱状态的,哪些是强状态的。这些外部服务和系统,是否已经做到高可用?能否做到快速扩容?

2.9 服务消耗的带宽多少?是否有可能达到带宽上限。

建议观察网卡/机房带宽的日志记录,开启gzip、snappy等压缩传输。

2.10 服务在部署上,是否已经做到了二地三机房, 能否快速回滚,跨版本回滚?

1地为2个热备,别一地为1个冷备或热备。每个地区的网络线路,是否能做到2套或2套以上 (防止光纤被挖断的情况)

2.11 DNS/自动发现/配置中介服务是否能够对后端服务进行探活,自动修改服务机的可用列表

建议用etcd/zookeeper/consul作服务发现。

2.12 部署是否实现了自动化,如果服务需要紧急扩容,该怎么做?

基于docker/k8s的容器伸缩方案,扩容快,分钟级别;

如果是ansible/jenkins/saltstack脚本批量部署,扩容慢,可能是小时级别,对环境一致性要求严格。

2.13 文档是否完整,文档是否能与代码保持一致

推荐用 gitlal readme或wiki.

2.14 如果是比较复杂的业务系统,是否有完整的自动化测试脚本

推荐用gitlab或jenkins CI/CD。

2.15 如果使用了数据库,比如用到了Redis/MySQL

可以池化,也即链接池,设置好最大的poolSize

2.16 如果使用了Redis,每次Redis操作的耗时是多少?TP90?TP99?

建议查看mysql slowlog和程序打点tracing日志, 并优化常见mysql事项,如索引。

2.17 如果使用了MySQL,SQL是否做过审核、有无慢查询

建议查看redis slowlog和程序打点tracing日志。

2.18 如果使用了cache,cache的命中率是多少?

cache会不会与数据库存储不一致,不一致是否可以容许

2.19 如果使用了负载均衡,负载均衡与服务之间是长连接吗?

如果服务和其它服务有交互,他们之间是长连接吗?

2.20 服务所在机器CPU负载怎么样?连接数高吗?

htop, iotop, 是否有大量的TIME_WAITCLOSE_WAIT .

2.21 是否做了tracing

opentracing

2.22 是否记录了access log

可能rsyslog收集nginx/ha 访问日志

2.23 服务是否能够优雅退出?

不要用kill -9 ,而是kill -TERM 等通知程序,让程序主动就绪后退出,可以延迟一定时间,比如5s。

2.24 服务如果是异常退出,是否会造成数据不一致?

如果有可能造成不一致,那么如何发现这种不一致?有没有对应修复的策略 比如在交易系统中的定期对账

2.25 这个服务中,哪些部分是最核心的,是否能做熔断降级处理

比如一个新闻客户端,如果出现服务出现故障,可以降级为新闻只读,但是无法评论。一般做法是先降级熔断非核心的业务如http/rpc/db的慢请求,最后降级熔断相对不重要的业务,还可以增加缓存时间、静态化、扩容等。

2.26 如果是API服务,有没有对请求做超时处理

防止请求一直阻塞。

2.27 如果调用方是client或APP,那么是否在client或APP中,埋有探针,以便日后分析排障

可能出错的地方都埋点日志,特别是IO相关操作,并收集、上报打点日志

2.28 数据库有没有定期备份?

如果已经做了备份,是否是备份在异构的数据库中

2.29 如果是API服务,是否有请求频率限制

可以是按照用户维度,也可以按照IP维度来限制, 还可以按地域/业务类型等。

---完

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2019-07-04 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1.引言
  • 2. 提问QA (重要性不分先后)
    • 2.1 如果服务器重启,服务是否能自动拉起?
      • 2.2 如果程序异常退出,服务是否能够自动拉起?
        • 2.3 如果程序异常退出,能够自动拉起,那么你怎么知道服务是否发生了重启?
          • 2.4 如果是web服务,QPS是多少?每个URL的QPS是多少?
            • 2.5 如果是web服务,每个请求的响应时间是多少?TP90?TP99分别是多少?
              • 2.6 异常请求(比如HTTP非200的比例是多少?)什么样的比例是合理的?为什么?
                • 2.7 如果是多实例部署,那么整个系统的cpu、内存、并发QPS承载极限是多少?如果达到了极限,瓶颈在哪儿(木桶原理中所谓的短板)
                  • 2.8 服务都有哪些依赖项(微服务/数据库/文件系统)
                    • 2.9 服务消耗的带宽多少?是否有可能达到带宽上限。
                      • 2.10 服务在部署上,是否已经做到了二地三机房, 能否快速回滚,跨版本回滚?
                        • 2.11 DNS/自动发现/配置中介服务是否能够对后端服务进行探活,自动修改服务机的可用列表
                          • 2.12 部署是否实现了自动化,如果服务需要紧急扩容,该怎么做?
                            • 2.13 文档是否完整,文档是否能与代码保持一致
                              • 2.14 如果是比较复杂的业务系统,是否有完整的自动化测试脚本
                                • 2.15 如果使用了数据库,比如用到了Redis/MySQL
                                  • 2.16 如果使用了Redis,每次Redis操作的耗时是多少?TP90?TP99?
                                    • 2.17 如果使用了MySQL,SQL是否做过审核、有无慢查询
                                      • 2.18 如果使用了cache,cache的命中率是多少?
                                        • 2.19 如果使用了负载均衡,负载均衡与服务之间是长连接吗?
                                          • 2.20 服务所在机器CPU负载怎么样?连接数高吗?
                                            • 2.21 是否做了tracing
                                              • 2.22 是否记录了access log
                                                • 2.23 服务是否能够优雅退出?
                                                  • 2.24 服务如果是异常退出,是否会造成数据不一致?
                                                    • 2.25 这个服务中,哪些部分是最核心的,是否能做熔断降级处理
                                                      • 2.26 如果是API服务,有没有对请求做超时处理
                                                        • 2.27 如果调用方是client或APP,那么是否在client或APP中,埋有探针,以便日后分析排障
                                                          • 2.28 数据库有没有定期备份?
                                                            • 2.29 如果是API服务,是否有请求频率限制
                                                            相关产品与服务
                                                            云数据库 Redis®
                                                            腾讯云数据库 Redis®(TencentDB for Redis®)是腾讯云打造的兼容 Redis 协议的缓存和存储服务。丰富的数据结构能帮助您完成不同类型的业务场景开发。支持主从热备,提供自动容灾切换、数据备份、故障迁移、实例监控、在线扩容、数据回档等全套的数据库服务。
                                                            领券
                                                            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档