本文由『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部署文件等的自动生成节省了我们大量时间，也避免了业务开发中的错误。
