一个20年技术老兵的 2020 年度技术总结

大家好！我是 go-zero 作者 Kevin。充满惊吓的 2020 快要过去了，看到掘金上的技术人年度征文，忍不住文字记录一下艰辛而又充满收获的 2020 ✍️

疫情开始

春节假期疫情突然升级，我们面临着自身平台的转型升级。作为晓黑板CTO，有两个重点工作：

  • 保证大规模使用场景下平台的稳定性
  • 保证转型所需的新业务能够快速交付

团队压力巨大的同时也感受到了前所未有的战斗热情，养兵千日用兵一时，不经历战与火的洗礼，怎么知道团队的技术能力是否能够经受得住流量洪峰的考验。

战斗开始，迅速落实业务团队进行急需功能的开发，并行安排架构团队进行技术隐患排查、演练、攻关。

在大概两个月的时间里，我们基本一日三餐都在电脑桌前，困了就睡觉，醒来写代码（当然还有必要的开会），这真是人生一段非常难忘的特殊经历。。。

开始踩坑

随着所需功能的极速上线，我们马上开始了大规模压测，大坑如下：

  • 大量请求失败，然而服务端压力一切正常，一顿排查，发现原来是进到内网的请求被 nginx 转发时又打到外网了，而外网我们是启动了 WAF(Web Access Firewall)，WAF 会认为所有用户都来自我们内网的那些 IP，这“明显”是攻击嘛，于是 drop 了大量请求，由此，我们指定了规则：进到内网的请求不允许转发到外网。
  • 为了快速实现功能，有同学用 nodejs 实现了部分功能，部署到 k8s 集群里，流量一起来，nodejs pod 立马扛不住，再加上难以控制的内存泄露，让我们迅速决定不再允许使用 nodejs 做后端，使用 nodejs 纯属“意外”。
  • 某云厂商 oss 存储用的 LSM Tree 方式实现，在小文件突发增加时无法及时分裂，导致我们访问量大时出现两次 oss 访问故障。后来我们自己多申请了几个 bucket 来从代码层分散文件存储请求。

实战效果

经过前后一个月开发、压测和开学前演练，我们的系统基本满足开学需求了，接下来就是接受实战检验了。

开学第一天，我们遇到的第一个问题部分服务供应商无法承载流量压力，虽然我们之前盘算过，也充分交流过，但还是未能预料到洪峰流量的凶猛，服务商紧急增加资源得以解决。

然后我们消息分类服务的 ElasticSearch 集群压力过大，扩容的同时，发现调用代码未加熔断保护，直接把 ElasticSearch 集群压死了，里面加上熔断保护，几行代码就好了，自适应熔断保护工具包见 这里。

经过第一周的密集爆发式流量的考验，我们总体很稳定。为此还得到了有关部门的感谢信，相比友商，我们的服务稳定性还是相当不错的。后续服务稳定性上基本可以用波澜不惊来形容。至此，go-zero （虽然此时还不叫 go-zero）算是经受了充分的实战检验

赞 (0)

相关推荐