本文有『Go开源说』第三期 go-zero 直播内容修改整理而成,视频内容较长,拆分成上下篇,本文内容有所删减和重构。
大家好,很高兴来到“GO开源说” 跟大家分享开源项目背后的一些故事、设计思想以及使用方法,今天分享的项目是 go-zero,一个集成了各种工程实践的 web 和 rpc 框架。我是Kevin,go-zero 作者,我的 github id 是 kevwan。
go-zero 虽然是20年8月7号才开源,但是已经经过线上大规模检验了,也是我近20年工程经验的积累,开源后得到社区的积极反馈,在5个多月的时间里,获得了5.9k star。多次登顶github Go语言日榜、周榜、月榜榜首,并获得了gitee最有价值项目(GVP),开源中国年度最佳人气项目。同时微信社区极为活跃,3000+人的社区群,go-zero爱好者们一起交流go-zero使用心得和讨论使用过程中的问题。
下图中间三层是 go-zero 内建支持的服务治理相关组件,基本涵盖了微服务治理主要的能力,而且是基本不需要开发者自己配置的,默认方案已经是经过大规模线上项目调优的。
数据边界是微服务拆分的核心,不同的服务之间不要显示共享数据,而应该通过 rpc 共享。
服务能否支撑高并发,缓存很关键。缓存机制不光要设计好,还需要通过工具尽可能让业务开发人员避免出错,因为缓存代码的编写有相当的难度,goctl 很好的生成了自动管理缓存的代码。
微服务系统一般都是由大量服务共同组合而成的,服务多了自然会有某个服务出现故障的风险,我们不能让某个服务的故障导致整个系统不可用,这就是服务雪崩,要避免雪崩,我们就需要有效隔离有故障的服务,从而降级可用。熔断和降载是防止服务雪崩的最有效手段之一。
对于高并发的系统来说,突发流量洪峰的情况下,系统需要能够及时水平扩容,go-zero 的自适应降载可以很好的配合 kubernetes 集群的自动水平伸缩能力。
要想让系统保持稳定,我们一定要对资源使用做清晰的定义,比如我们到底在什么时候考虑扩充资源,是资源占用率达到了50%还是70%,必须对系统资源的使用状况有足够清晰的定义。
我在团队内部一直强调:没有度量就没有优化。我们必须对系统有高效的监控和及时的报警机制。这样才能让我们对整个系统的运行状态有足够的了解。
微服务系统大体上看起来如上图,但是我们并不是一定要业务一开始就上微服务,我们看看一个典型的微服务系统是怎么进化而来的,下面粗略的讲解一下大型微服务系统的进化过程。
项目刚开始,我们不要一味的追求技术的先进性,因为大部分项目是走不到高并发的那一天的,我们需要的是第一时间满足业务。
我在团队里讲:架构是从业务中来,到业务中去。任何脱离了业务的技术都是自嗨,我们需要把满足业务需要作为第一优先级,技术需要支撑业务现在和可预期发展的需要即可。当然,有满足自身业务的现成的框架和最佳实践那是最好了,但不要让技术栈过于复杂,避免重心从业务转移到技术本身来。
随着业务的发展,我们可能需要对技术做一定的升级和改造了,但是我们一直强调:没有度量就没有优化。所以我们需要及时加上对整个服务的关键指标的监控,从而让我们在了解系统的前提下进行必要的改造。
当业务发展到一定程度之后,基于监控,我们发现服务必须要做拆分了。那么我们第一步要做的是先把数据拆分清楚,数据拆分后,我们就可以加上对应的缓存管理,从而保障数据层面的稳定性。
相对于数据拆分,服务的拆分相对是比较容易的,基于拆分好的数据,对应出上层的服务,因为服务是无状态的,所以这个拆分就比较容易。
随着业务的发展,日常的系统维护工作就显得比较繁琐和容易出错了。此时,我们需要建设支撑系统,如何部署新服务,如何更新老服务,是不是要上 kubernetes,等等。
当业务发展到一定程度,工程效率就是一个很大的问题了。goctl 就是为了解决自动化和工程效率问题而生,其中内置的 api, rpc, model, Dockerfile, k8s部署文件等的自动生成节省了我们大量时间,也避免了业务开发中的错误。
如果你想要更好的了解 go-zero 项目,欢迎前往官方网站上学习具体的示例。
https://www.bilibili.com/video/BV1Jy4y127Xu
https://github.com/tal-tech/go-zero
欢迎使用 go-zero 并 star 支持我们!
go-zero 系列文章见『微服务实践』公众号