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. 你能不能结束它？（要能控制他结束）

1. error

Go的处理异常逻辑是不引入exception，支持多参数返回，所以你很容易的在函数签名中带上实现了error interface的对象，交由调用者来判定。

如果一个函数返回了(value，eror)，你不能对这个value做任何假设，必须先判定error。唯一可以忽略error的是，如果你连value也不关心。

1. gRPC

1.1 特性

• 多语言：语言中立，支持多种语言。
• 轻量级、高性能：序列化支持 PB(Protocol Buffer)和 JSON，PB 是一种语言无关的高性能序列化框架。
• 可插拔：扩展插件。
• IDL（约束）：基于文件定义服务，通过 proto3 工具生成指定语言的数据结构、服务端接口以及客户端 Stub。
• 基于标准的 HTTP2 设计，支持双向流、消息头压缩、单 TCP 的多路复用、服务端推送等特性，这些特性使得 gRPC 在移动端设备上更加省电和节省网络流量。
• 流：Streaming API。
• 阻塞式和非阻塞式：支持异步和同步处理在客户端和服务端间交互的消息序列。
• 元数据交换：常见的横切关注点，如认证或跟踪，依赖数据交换。
• 标准化状态码：客户端通常以有限的方式响应 API 调用返回的错误。

1. 微服务概览

1.1 单体架构

最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变的无法完成。

应对的思路：化繁为简，分而治之。

国内把tiktok限制的死死的，如果想看外面的世界，需要借助这个项目：https://github.com/Semporia/TikTok-Unlock。

需要自备的东西：1. Shadowrocket 2. 梯子节点 3. 美区appstore账号。

1. 操作流程

1.1 先降级tiktok版本

推荐 TikTok 21.1.0，如果不降级，高版本很可能不成功。