Go工程项目实践 毛剑

Razor

2019/10/19 发布于 技术 分类

文字内容
1. Go工程化实践 毛剑 架构师
2. 自我介绍
3. 目录 • • • • Layout Unittest Toolchain Configuration
4. Layout • 一个Gitlab的project里可以放置多个微 服务的app;也可以按照Gitlab的group 里建立多个project,每个project对应 一个app; • 多app的方式,app目录内的每个微服务 按照自己的全局唯一名称,比如 “account.service.vip”来建立目录, 如:account/vip/*; • 和app平级的目录pkg存放业务有关的公 共库(非基础框架库);
5. Layout • 微服务中的app里服务分为4类: interface、service、job、admin; • interface:对外的网关服务,接受来自 用户的请求,比如暴露了HTTP接口; • service:对内的微服务,仅接受来自内 部其他服务或者网关的请求,比如暴露 了gRPC接口; • admin:区别于service,更多是面向运 营测的服务,通常数据权限更高; • job:定时任务或者是流失任务处理的服 务; • ecode属于这一个单一业务里可以共享 的错误码,也可以有类似pkg公共库;
6. Layout • app目录下有api、cmd、configs、 internal目录,目录里一般还会放置 README、CHANGELOG、OWNERS; • api:放置api定义(protobuf),以及 对应的生成的client代码,基于pb生成 的swagger.json; • cmd:放服务的入口main函数; • configs:放服务所需要的配置文件,比 如database.yaml、redis.yaml、 application.yaml; • internal:是为了避免有同业务下有人跨 目录引用了内部的model、dao等内部 struct;
7. Layout “A little copying is better than a little dependency.” – Rob Pike
8. Layout
9. Layout • model:放对应“存储层”的结构体, 是对存储的一一隐射; • dao:数据读写层,数据库和缓存全部 在这层统一处理,包括cache miss处理; • service:组合各种数据访问来构建业务 逻辑; • server:依赖pb定义的服务作为入参, 提供快捷的启动服务全局方法;
10. Unittest • 小型测试带来优秀的代码质量、良好的 异常处理、优雅的错误报告;大中型测 试会带来整体产品质量和数据验证; • 不同类型的项目,对测试的需求不同, 总体上有一个经验法则,即70/20/10原 则:70%是小型测试,20%是中型测试, 10%是大型测试; • 如果一个项目是面向用户的,拥有较高 的集成度,或者用户接口比较复杂,他 们就应该有更多的中型和大型测试;如 果是基础平台或者面向数据的项目,例 如索引或网络爬虫,则最好有大量的小 型测试,中型测试和大型测试的数量要 求会少很多;
11. Unittest “自动化实现的,用于验证一个单独函数 或独立功能模块的代码是否按照预期工作, 着重于典型功能性问题、数据损坏、错误 条件和大小差一错误(译注:大小差一 (off-by-one)错误是一类常见的程序设 计错误)等方面的验证” - 《Google软件测试之道》 单元测试的基本要求: • • • • 快速 环境一致 任意顺序 并行
12. Unittest 基于 docker-compose 实现跨平台跨语言 环境的容器依赖管理方案,以解决运行 unittest场景下的 (mysql, redis, mc)容器 依赖问题; • • • • • • 本地安装Docker 无侵入式的环境初始化 快速重置环境 随时随地运行(不依赖外部服务) 语义式API声明资源 真实外部依赖,而非in-process模拟
13. Unittest • 正确的对容器内服务进行健康检测,避 免unittest启动时候资源还未ready; • 应该交由app自己来初始化数据,比如 db的scheme,初始的sql数据等,为了 满足测试的一致性,在每次结束后,都 会销毁容器;
14. Unittest • 在单元测试开始前,导入封装好的 testing库,方便启动和销毁容器; • 对于service的单元测试,使用gomock 等库把dao mock掉,所以在设计包的 时候,应该面向抽象编程; • 在本地执行依赖Docker,在CI环境里执 行Unittest,需要考虑在物理机里的 Docker网络,或者在Docker里再次启 动一个Docker;
15. Toolchain • 工具大于约束/文档; • project:构建了针对项目初 始化Layout模板; • api:api工具集,提供 gRPC/HTTP debug工具、 protobuf协议生成、文档生 成工具; • cache:cache操作工具集, 提供mc和redis读写的模板 代码、cache miss处理代码; • test:启动依赖资源交互式 命令行、mock代码生成
16. Toolchain NAME: kratos - kratos tool USAGE: kratos [global options] command [command options] [arguments...] “kratos new kratos-demo -o YourName -d YourPath --proto” Start the world!
17. Configuration • 代码更改系统功能是一个冗长且复杂的 过程,往往还涉及Review、测试等流程, 但更改单个配置选项可能会对功能产生 重大影响,通常配置还未经测试; • 配置的目标: • 避免复杂 • 多样的配置 • 简单化努力 • 以基础设施 -> 面向用户进行转变; • 配置的必选项和可选项 • 配置的防御编程 • 权限和变更跟踪 • 配置的版本和应用对齐 • 安全的配置变更:逐步部署、回滚更改、 自动回滚