关于golang:一个20年技术老兵的-2020-年度技术总结

7次阅读

共计 2573 个字符,预计需要花费 7 分钟才能阅读完成。

大家好!我是 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)算是禁受了充沛的实战测验 ????

走向开源

7 月份在跟团体技术通道老师的交换过程中失去了充沛的必定,团体开源通道推动和帮忙我把底层微服务撑持框架对外开源。

在 8.7 日深夜,我实现了 github 代码的第一次提交,此时文档仅有我长期写进去的一页 readme,为啥只有一页 readme 就抉择开源了呢?我感觉万事开头难,如果决定把文档都写完再开源进去的话,可能这事就搁置了,所以还是先让球滚起来吧!

一经开源,社区立马给了咱们比拟热烈的反馈,更推动了咱们去疾速实现文档。咱们在一个周末就补充了大量的应用文档,提供了比拟残缺的示例 shorturlbookstore。前面大部分开发者都通过这两个例子感触到了 go-zero 的便捷和工程效率。感激大家给了咱们很多对示例的改良意见。

8 月 16 日,go 夜读的分享 零碎的讲述了 go-zero 背地的故事和设计思考,取得了很多观众的留言认可。至今仍然有不少人针对这个视频给我踊跃的反馈。感激大家的认可!

8 月 24 日,gocn 的 报道,让 gopherchina 社区第一次大规模的理解了 go-zero。社区开始有大量 gopher 的退出,微信群人数迅速增长。

9 月开始,go-zero 屡次呈现在 github Go 语言日榜月榜顶部,如图:

日榜 月榜

同时不少家公司将 go-zero 用于生产,并跟我反馈上线后始终安稳运行,其中不乏日活过百万的平台。

10 月取得了 gitee 最有价值我的项目(GVP),并接着取得了开源中国年度 最佳人气我的项目奖项。

11 月 22 日,我在 gopherchina 大会做了『云原生 go-zero 微服务框架的设计思考』的主题分享,现场氛围十分热烈,据说门口堵满了进不来了,取得了很多资深开发者的认可,知乎评论见 这里,其中提到的我的年龄不对哈????,局部现场图如下:

分享 观众

12 月 20 日,应邀参加腾讯云开发者大会,做了『转型之后 – 面对流量洪峰,微服务架构如何进行弹性设计?』的分享,如下:

开始 纲要

在掘金发了 20+ 篇 go-zero 系列文章,跟用户具体分享了微服务框架设计的原理和实现,详见 这里。

社区的认可

近 3000 人的微信社区,每天热烈的技术探讨和用户之间的互相帮忙,曾经造成了良好的社区气氛。咱们也从中取得很多的用户反馈,为咱们进一步增强 go-zero 指明了方向!????

github star 失常每月增长 1000 左右,均匀每天 33+ stars,当初 4700+,增长曲线如下:

再次复盘

  1. 用户到底想要什么样的框架?

    • 首先,可能写更少代码解决业务需要。更少的代码意味着更快的产出,更少的 bug。
    • 其次,框架是否稳固,有没通过实战测验。毕竟很少人违心当小白鼠的。
    • 再次,社区是否沉闷,遇到问题是否可能疾速失去解决。
  2. 用户为什么喜爱 go-zero?

    • 全面的微服务治理能力
    • 内置 goctl 工具帮忙用户尽可能只关注业务代码
    • go-zero 通过了咱们线上海量并发实战测验
    • 沉闷的社区,用户的相互解答,go-zero 团队的及时跟进

2021 年技术瞻望

  • 研发团队工程效率带上新台阶,冀望让大家产出更高的同时也能有更好的能力晋升
  • 冀望进一步增强 go-zero 的工程效率晋升,让开发者编写更少的代码(业务代码)就能领有稳固的微服务零碎
  • 一个小指标:一年一万星 ????

我的项目地址

https://github.com/tal-tech/go-zero

欢送大家应用 go-zero 并 star 反对咱们!????

致谢

真心感激始终反对咱们的大佬们,以及泛滥应用 go-zero 的 gopher 们,之所以不列名单,切实是帮忙过咱们的人太多了,惟恐一不小心就脱漏了某位大佬 ????

我的项目地址:
https://github.com/tal-tech/go-zero

正文完
 0