后台开发积累(2019 年)

感觉只是做了一点微小的工作

Posted by pandaychen on November 4, 2019

背景

如何提升后台服务的可靠性,如何提升后台服务的吞吐量(性能),如何避免重复造轮子,工作中需要经常带着这些问题去思考。 本文我想结合自己的遇到的问题,聊聊如何完成后台开发的工作,介绍一些工作中遇到的经验。

基础篇

  • 需求对齐,确定方案,避免无效工作
  • 阶段总结,及时调整

升级和扩容篇

  • 系统如何做到不停机在线扩容?扩容后负载均衡方式会改变吗?如果 LB 算法采用一致性 hash 的话,扩容后,后台负载的表现如何?
  • 升级能够不影响用户使用吗?(如 Kubernetes 的蓝绿升级、滚动部署等)

测试

  • 测试环境能够尽量模拟现网场景
  • 测试尽量充分
  • 边界测试

安全

  • 系统的认证如何实现?
  • 数据传输使用的加密协议是什么?
  • SSL 单向认证还是双向认证?是需要自签证书还是收费证书?

后台服务之稳定性

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

服务发现与负载均衡

  • 系统中哪些服务需要具备服务发现的能力

队列

  • 使用队列的目的,暂存一些数据,削峰,排队
  • kakfa 是个不错的选择

存储 Redis 篇

  • 如果使用了 Redis,每次 Redis 操作的耗时是多少?对于大批量操作的场景,Redis 有使用 Pipeline 做优化吗?Redis 集群是否有考虑不兼容的操作方式?如何实现高性能的等价操作?
  • Redis 集群的内存用量大小,有无监控?
  • Redis 前面是否需要多加一层本地 Cache,直接在服务本地处理(如限制某个 token 一定时间只能使用一次,一个用户一天只能投一次票等等)

存储之 Mysql 篇

  • 使用 Id 作为自增主键,建议使用 bigint 类型,使用 int(10) 存在溢出的风险
  • 同步数据时,尽量采用增量式更新数据的方法,即将需要的字段取出,作为 key,比对新数据和旧数据中,不同的情况下才更新,这样可以尽可能的减少不必要的数据库更新
  • 使用 Innodb 做引擎时,需要注意,大批量数据插入 / 修改时,如果数据库设计不当,会导致 innodb 写失败(默认 50s 的超时),所以在 Mysql 前多加缓存(如 Redis、本地 Cache)才是王道

后台服务实现(gPRC/HTTP/TCP)

  • gRPC、HTTP 的客户端是否需要加入重试机制?
  • gRPC、HTTP 的客户端是否需要保持长连接(避免连接建立导致的消耗,如 TLS 等)

日志篇

  • 日志分级,详细的日志,日志格式(uber 的 zap 日志库是一个非常优秀的实践)

单例非服务进程高可用

工具

转载请注明出处,本文采用 CC4.0 协议授权