这是我参与「第五届青训营 」伴学笔记创作活动的第 2 天
课堂零碎收获整理
本节课主要收获了golang的goroutine与线程的理解
同时也加深了对后端架构设计的分析
这部分笔记主要是记录自己的阅读理解
Goroutine与线程
- 线程：用户态，轻量级线程，栈是MB级别
- 协程：内核态，线程跑多个协程，栈是KB级别
Go依赖管理演进
Go的依赖管理主要经历了三个阶段，分别是GOPATH=>Go Vendor=>Go Module
GOPATH
无法对package进行版本管理，我们可能在开发中会遇到同一个package的不同版本
Go Vendor
Go Vendor通过每个项目引入一份依赖的副本，解决了多个项目需要同一个package依赖的冲突问题
但是我们无法控制依赖的版本，更新项目又可能出现依赖冲突，导致编译出错
正是如此，就有了第三个依赖管理，Go Module
Go Module
- 通过go.mod文件管理依赖包版本
- 通过go get / go mod指令工具管理依赖包
Go Module的终极目标是定义版本规则和管理项目依赖关系
依赖管理三要素
- 配置文件，描述依赖 => go.mod
- 中心仓库管理依赖 => Proxy
- 本地工具 => go get / mod
测试
测试一般分为回归测试、集成测试和单元测试，从上到下，覆盖率逐层变大，成本却逐层降低
单元测试
主要包括输入、输出和测试单元。
这里要重点说一下单元的概念，单元包括了接口、函数、模块等内容
单元测试具有如下优点：
- 保证质量，不会破坏原有代码的正确性
- 提升效率，可以快速定位和修复问题
基准测试
基准测试是指测试一段程序的运行性能及耗费CPU的程度。
使用方法类似于单元测试
分层结构
- 数据层：数据Model，外部数据的增删改查（curd！）
- 逻辑层：业务entity，处理核心业务逻辑输出
- 视图层：视图view，处理和外部的交互逻辑
Reponsitory 数据层
数据层关联了底层数据模型，也就是这里的model，封装外部数据的增删改查。
数据层面向逻辑层，对service层透明，屏蔽下游数据差异，也就是不管下游是文件还是数据库或微服务，对service层的接口模型是不变的
Service 逻辑层
逻辑层处理核心业务逻辑，计算打包业务的实体entity
Controller 视图层
视图层负责处理和外部的交互逻辑，以view的形式返回给客户端
举个例子，我们会对请求结果封装成json，以api形式访问
个人理解
我在使用分布式框架的时候遇到了数据层、逻辑层和视图层，在应用方面，数据层应当是直接对数据库进行操作，将操作结果打包发送给逻辑层，逻辑层进行适当的处理（这里可以对接多个api），然后把整理好的数据发送到视图层，视图层将会对数据进行最后的整理，比如组成json，然后发送给客户端。
