系统技术架构

系统架构致力于为服务提供技术解决方案、以便更加健壮、可维护、可扩展、可测试、提供高性能、高可用的技术方案。

1681437555140

服务治理

服务注册、服务发现、限流、熔断、超时控制、健康检查、负载均衡、动态扩容

网络通信协议

HTTP、GRPC、TCP、FIX

中间件

消息队列、数据中间件、缓存中间件、HTTP Router解析、Params Parse、Auth等

订阅广播系统

消息发布\订阅、事件广播系统

内存存储系统

内存保存、获取、TTL

配置管理

业务、系统配置动态更新

日志收集

业务日志、运行日志收集

性能指标

系统性能指标、业务指标上报

异常监控

运行时异常捕获监控、收集、报警

开发流程

统一开发环境、开发、编码规范等

Golang 栈微服务架构规划图

1681402160662

流程规范

编码规范

编码风格原则

清晰：代码的目的和原来对读者来说是清晰的
简单：代码以最简单的方式完成其目标
简明：代码具有较高的信噪比
可维护: 编写的代码可以很容易维护
一致性：代码与更广泛的谷歌代码库风格一致

工具

gofmt：代码格式化标准
goimports：模块导入风格格式化
govet：代码安全异常检测
golangci-lint：代码风格检测，包括编码约定、性能、复杂性等

Goland 配置

Setting---> tools---> Action As Save 1681289390271

代码规范

uber-go-style-guide： https://github.com/uber-go/guide/blob/master/style.md
google-code-style：https://google.github.io/styleguide/go/

目录规范

Protobuf规范

本文为编写 .proto 文件提供了一份规范指引。通过遵守这些规范约定，可以使 message 定义以及相关的类保持一致性，项目更具维护性，同时也将更易于阅读。为了更好的统一，避免产生兼容问题，统一使用proto3 版本。

文件管理

Protobuf 文件管理通常有俩种模式：

1、独立统一仓库管理
2、定义到项目

文件结构

文件作用域

文件的作用域是指：主要规范指导合适应该使用一个新的.proto文件。

文件编码风格

.proto文件编写风格规范依据官方指南为标准。

其中如下几点必须按照以下规范执行

Package

Options

Service

Message

标识符

在消息定义中，每个字段都有唯一的一个数字标识符。这些标识符是用来在消息的二进制格式中识别各个字段的，一旦开始使用就不能够再改变。注：[1,15]之内的标识号在编码的时候会占用一个字节。[16,2047]之内的标识号则占用2个字节。所以应该为那些频繁出现的消息元素保留 [1,15]之内的标识号。切记：要为将来有可能添加的、频繁出现的标识号预留一些标识号。

ref：https://protobuf.dev/programming-guides/style/

git 规范

延续公司现行规范

分支管理

三个基准分支： master、release、dev

1681369253806

分支流程运用

1681369430071

jira项目流程规范

单元测试标准

单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类、超类、抽象类等中的方法。单元测试就是软件开发中对最小单位进行正确性检验的测试工作。

不同地方对单元测试有的定义可能会有所不同，但有一些基本共识：

单元测试是比较底层的，关注代码的局部而不是整体。
单元测试是开发人员在写代码时候写的。
单元测试需要比其他测试运行得快。

意义

提高代码质量 。代码测试都是为了帮助开发人员发现问题从而解决问题，提高代码质量。
尽早发现问题 。问题越早发现，解决的难度和成本就越低。
保证重构正确性 。随着功能的增加，重构（修改老代码）几乎是无法避免的。很多时候我们不敢重构的原因，就是担心其它模块因为依赖它而不工作。有了单元测试，只要在改完代码后运行一下单测就知道改动对整个系统的影响了，从而可以让我们放心的重构代码。
简化调试过程 。单元测试让我们可以轻松地知道是哪一部分代码出了问题。
简化集成过程 。由于各个单元已经被测试，在集成过程中进行的后续测试会更加容易。
优化代码设计 。编写测试用例会迫使开发人员仔细思考代码的设计和必须完成的工作，有利于开发人员加深对代码功能的理解，从而形成更合理的设计和结构。
单元测试是最好的文档 。单元测试覆盖了接口的所有使用方法，是最好的示例代码。而真正的文档包括注释很有可能和代码不同步，并且看不懂。

理论原则

快。单元测试是回归测试，可以在开发过程的任何时候运行，因此运行速度必须快
一致性 。代码没有改变的情况下，每次运行得结果应该保持确定且一致
原子性 。结果只有两种情况：Pass / Fail
用例独立 。执行顺序不影响；用例间没有状态共享或者依赖关系；用例没有副作用（执行前后环境状态一致）
单一职责 。一个用例只负责一个场景
隔离。功能可能依赖于数据库、web 访问、环境变量、系统时间等；一个单元可能依赖于另一部分代码，用例应该解除这些依赖
可读性 。用例的名称、变量名等应该具有可读性，直接表现出该测试的目标
自动化 。单元测试需要全自动执行。测试程序不应该有用户输入；测试结果应该能直接被电脑获取，不应该由人来判断。

类型

Go的测试可以分为白盒测试和黑盒测试。

白盒测试： 将测试和生产代码放在同一个Go包中，这使我们可以同时测试Go包中可导出和不可导出的标识符。当我们编写的单元测试需要访问Go包中不可导出的变量、函数和方法时，就需要编写白盒测试用例。
黑盒测试： 将测试和生产代码放在不同的Go包中。这时，我们仅可以测试Go包的可导出标识符。这意味着我们的测试包将无法访问生产代码中的任何内部函数、变量或常量。

规范

单元测试文件名命名规范为 example_test.go,通常情况下，需要将测试文件和源代码放在同一个包内
测试用例的函数名称必须以 Test 、Benchmark 开头，例如：TestExample、BenchmarkExample
每个测试函数都必须导入 testing 包。测试函数的命名类似 func TestName(t *testing.T)，入参必须是 *testing.T
测试必须要有断言，没有断言的测试是无效的

用途	常用框架
测试框架	testing、testify, goconvery
mock框架	gomock、gomonkey

代码结构示例

├── go.mod
├── go.sum
├── logic
│   ├── login_pwd.go
│   ├── login_pwd_test.go
│   ├── handler
│   │   ├── heartbeat_handler.go
│   │   └── heartbeat_handler_test.go
│   └── init.go
├── main.go
├── readme.md

静态代码检测

工具

静态代码检测实现的工具主要是:golangci-lint。

实现

静态代码检测实现的方式有以下几种：

1、本地开发环境，其中包括本地命令行、编辑器插件、pre-commit等

2、gitlab runner 流水线

错误代码

日志规范

组件规范

Golang依赖包管理

三种包管理机制

~~1、go path:不推荐~~

~~2、go vendor:不推荐~~

3、go module: Golang 官方默认包管理机制

依赖包调试

调试依赖包，可以在go.mod 文件使用replace来修改依赖包，如下：

replace (
    github.com/google/uuid v1.1.1 => ../uuid
)

类型

1、公有包

2、私有包

私有包建立的作用是封装或者开发的可重用于公司级别或者跨项目级别的模块组件，一般的解决方案是通过gitlab 私有仓库进行管理

ref:https://go.dev/ref/mod#go-mod-file-retract

开发环境建设

开发人员在日常开发中可以不依赖测试环境的基础组件，可一键启动本地独立开发环境，搭建一套独立的微服务环境，比如存储组件、消息队列组件、其他服务化组件、网关组件等。

解决的问题

1、开发人员快速配置、搭建本地环境

2、开发运行环境标准化

3、集成所有服务项目，开发环境不存在服务间依赖的影响

4、快速进行首次服务启动需要的基础数据进行迁移

dduo518 / hexo-blog

Golang 栈基础技术架构总结 #70