1. 服务网格

服务网格（Service Mesh）是一种将服务之间的通信从应用层解耦到基础设施层的技术。在服务网格中，通过代理服务之间的流量来实现基础设施层的抽象。

mapstructure 可用于将通用的map[string]interface{}解码到对应的 Go 结构体中，或者执行相反的操作。

github 地址： github.com/mitchellh/mapstructure

decimal 对于浮点数的计算提供了极大的便利性，让我们在使用浮点数进行大小计算的时候不用担心精度丢失的问题，decimal库能处理小数点后 2^31 位数字，对于绝大多数的项目精度要求是足够的，简而言之，decimal 可以解决我们绝大多数的浮点数精度计算场景。

由于golang中默认是没有decimal类型的，所以要解决上述的问题，需要使用第三方库包decimal。

github 地址：https://github.com/shopspring/decimal

1. gorm

1.1 初始化连接

1
2
3
4
5
6

dsn := fmt.Sprintf("%s:%s@tcp(%s:%d)/%s?charset=utf8mb4&parseTime=True&loc=Local",  
    c.Mysql.User, c.Mysql.Password, c.Mysql.Host, c.Mysql.Port, c.Mysql.Name)  
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})  
if err != nil {  
    logx.Must(err)  
}

1. 日志

1.1 日志级别

waring

没人看警告，也许将来会出问题，但这听起来像是别人的问题。

我们尽可能的消除警告级别，它要么是一条信息性消息，要么是一个错误。我们参考Go语言设计额哲学，所有警告都是错误，其他语言的warning都可以忽略，除非IDE或者在CICD流程中强制他们为eror，然后逼着程序员们尽可能去消除。

同样的，如果想要最终消除 warning可以记录为error，让代码作者重视起来。

1. 分布式缓存

1.1 中间件选型

• Redis 和 Memcache 最大的区别其实是 redis 单线程(新版本双线程)，memcache 多线程，所以 QPS 可能两者差异不大，但是吞吐会有很大的差别，比如大数据 value 返回的时候，redis qps 会抖动下降的的很厉害，因为单线程工作，其他查询进不来(新版本有不少的改善)。
• 纯 kv 可以走 memcache，比如我们的关系链服务中用了 hashs 存储双向关系，但是我们也会使用 memcache 档一层来避免hgetall 导致的吞吐下降问题。 我们系统中多次使用 memcache + redis 双缓存设计。

1. 评论系统

1.1 架构设计

• bff层：评论业务的服务编排，策略逻辑。
• service层：只关注评论场景自己的逻辑。因为读写是稳定的，策略是多变的。
• admin 层：划分出管理平台，共享存储数据。接口安全性更高，独立出来。不会依赖原始数据库，冗余出es里。
• dependen层：依赖账号，过滤服务等。

架构设计等同于数据设计，梳理清楚数据的走向和逻辑。尽量避免环形依赖、数据双向请求等。

1. 隔离

隔离，本质上是对系统或资源进行分割，从而实现当系统发生故障时能限定传播范围和影响范围即发生故障后只有出问题的服务不可用，保证其他服务仍然可用。

1. 工程项目

1.1 项目结构

可以参考：https://github.com/golang-standards/project-layout/blob/master/README_zh.md

1. /cmd
   本项目的主干，cmd应用目录负责程序的：启动、关闭、配置初始化等。

   每个应用程序的目录名应该与你想要的可执行文件的名称相匹配(例如，/cmd/myapp)。

   不要在这个目录中放置太多代码。如果你认为代码可以导入并在其他项目中使用，那么它应该位于 /pkg 目录中。如果代码不是可重用的，或者你不希望其他人重用它，请将该代码放到 /internal 目录中。

1. gorutine

1.1 创建 go 的原则

1. 不要创建一个你不知道何时退出的 goroutine。（你一定要知道什么时候结束）
2. 你能不能结束它？（要能控制他结束）