Go工程项目实践 毛剑

2020-03-01 155浏览

  • 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.ToolchainNAME:kratos - kratos toolUSAGE:kratos [global options] command [command options] [arguments...] “kratos new kratos-demo -o YourName -d YourPath --proto” Start the world！
  • 17.Configuration • 代码更改系统功能是一个冗长且复杂的 过程，往往还涉及Review、测试等流程， 但更改单个配置选项可能会对功能产生 重大影响，通常配置还未经测试； • 配置的目标： • 避免复杂 • 多样的配置 • 简单化努力 • 以基础设施 -> 面向用户进行转变； • 配置的必选项和可选项 • 配置的防御编程 • 权限和变更跟踪 • 配置的版本和应用对齐 • 安全的配置变更：逐步部署、回滚更改、 自动回滚
  • 18.
  • 19.