go-zero解读与最佳实践(上)

.container .card .information strong · · 370 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

本文有『Go开源说』第三期 go-zero 直播内容修改整理而成,视频内容较长,拆分成上下篇,本文内容有所删减和重构。

大家好,很高兴来到“GO开源说” 跟大家分享开源项目背后的一些故事、设计思想以及使用方法,今天分享的项目是 go-zero,一个集成了各种工程实践的 web 和 rpc 框架。我是Kevin,go-zero 作者,我的 github id 是 kevwan

go-zero 概览

go-zero 虽然是20年8月7号才开源,但是已经经过线上大规模检验了,也是我近20年工程经验的积累,开源后得到社区的积极反馈,在5个多月的时间里,获得了5.9k star。多次登顶github Go语言日榜、周榜、月榜榜首,并获得了gitee最有价值项目(GVP),开源中国年度最佳人气项目。同时微信社区极为活跃,3000+人的社区群,go-zero爱好者们一起交流go-zero使用心得和讨论使用过程中的问题。

star

下图中间三层是 go-zero 内建支持的服务治理相关组件,基本涵盖了微服务治理主要的能力,而且是基本不需要开发者自己配置的,默认方案已经是经过大规模线上项目调优的。

arch

微服务系统设计中的痛点

1. 微服务系统如何拆分?

  • 先粗后细,不要过细,切忌一个接口一个服务
  • 横向拆分,而非纵向,我们尽量不要超过三层调用
  • 单向调用,严禁循环调用
  • 禁止接口类型透传,在不同的层之间不要共享同一个数据定义,避免一处修改,影响其它
  • 没有依赖关系的串行调用改为并行,可以通过 core/mr 包降低响应延迟而不增加系统负载

    mr

2. 如何保障高并发高可用?

  • 良好的数据边界

    数据边界是微服务拆分的核心,不同的服务之间不要显示共享数据,而应该通过 rpc 共享。

  • 高效的缓存管理

    服务能否支撑高并发,缓存很关键。缓存机制不光要设计好,还需要通过工具尽可能让业务开发人员避免出错,因为缓存代码的编写有相当的难度,goctl 很好的生成了自动管理缓存的代码。

  • 优雅的熔断降载保护

    微服务系统一般都是由大量服务共同组合而成的,服务多了自然会有某个服务出现故障的风险,我们不能让某个服务的故障导致整个系统不可用,这就是服务雪崩,要避免雪崩,我们就需要有效隔离有故障的服务,从而降级可用。熔断和降载是防止服务雪崩的最有效手段之一。

  • 弹性伸缩能力

    对于高并发的系统来说,突发流量洪峰的情况下,系统需要能够及时水平扩容,go-zero 的自适应降载可以很好的配合 kubernetes 集群的自动水平伸缩能力。

  • 清晰的资源使用定义

    要想让系统保持稳定,我们一定要对资源使用做清晰的定义,比如我们到底在什么时候考虑扩充资源,是资源占用率达到了50%还是70%,必须对系统资源的使用状况有足够清晰的定义。

  • 高效的监控报警

    我在团队内部一直强调:没有度量就没有优化。我们必须对系统有高效的监控和及时的报警机制。这样才能让我们对整个系统的运行状态有足够的了解。

大型微服务项目从何下手?

overview

微服务系统大体上看起来如上图,但是我们并不是一定要业务一开始就上微服务,我们看看一个典型的微服务系统是怎么进化而来的,下面粗略的讲解一下大型微服务系统的进化过程。

  • 从单体服务开始

    项目刚开始,我们不要一味的追求技术的先进性,因为大部分项目是走不到高并发的那一天的,我们需要的是第一时间满足业务。

  • 业务优先,技术支撑

    我在团队里讲:架构是从业务中来,到业务中去。任何脱离了业务的技术都是自嗨,我们需要把满足业务需要作为第一优先级,技术需要支撑业务现在和可预期发展的需要即可。当然,有满足自身业务的现成的框架和最佳实践那是最好了,但不要让技术栈过于复杂,避免重心从业务转移到技术本身来。

  • 服务指标监控

    随着业务的发展,我们可能需要对技术做一定的升级和改造了,但是我们一直强调:没有度量就没有优化。所以我们需要及时加上对整个服务的关键指标的监控,从而让我们在了解系统的前提下进行必要的改造。

  • 数据拆分+缓存管理

    当业务发展到一定程度之后,基于监控,我们发现服务必须要做拆分了。那么我们第一步要做的是先把数据拆分清楚,数据拆分后,我们就可以加上对应的缓存管理,从而保障数据层面的稳定性。

  • 服务拆分

    相对于数据拆分,服务的拆分相对是比较容易的,基于拆分好的数据,对应出上层的服务,因为服务是无状态的,所以这个拆分就比较容易。

  • 支撑系统建设

    随着业务的发展,日常的系统维护工作就显得比较繁琐和容易出错了。此时,我们需要建设支撑系统,如何部署新服务,如何更新老服务,是不是要上 kubernetes,等等。

  • 自动化+工程建设

    当业务发展到一定程度,工程效率就是一个很大的问题了。goctl 就是为了解决自动化和工程效率问题而生,其中内置的 api, rpc, model, Dockerfile, k8s部署文件等的自动生成节省了我们大量时间,也避免了业务开发中的错误。

go-zero 组件剖析 + go-zero 最佳实践(待续)

如果你想要更好的了解 go-zero 项目,欢迎前往官方网站上学习具体的示例。

视频回放地址

https://www.bilibili.com/video/BV1Jy4y127Xu

项目地址

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

欢迎使用 go-zero 并 star 支持我们!

go-zero 系列文章见『微服务实践』公众号

有疑问加站长微信联系(非本文作者)

本文来自:Segmentfault

感谢作者:.container .card .information strong

查看原文:go-zero解读与最佳实践(上)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

370 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传