详细设计 comment-service 专注在评论数据处理(认真想下 Separation of Concerns 关注点分离，职责更清晰)。我们一开始是 comment-service 和 comment 是一层，业务耦合和功能耦合在一起，非常不利于迭代，当然在设计层面可以考虑目录结构进行拆分，但是架构层次来说，迭代隔离也是好的。 读的核心逻辑…

评论系统架构设计 这节课程是结合实际业务场景，来做系统架构设计。 架构设计 做架构设计前，需要深度理解产品的业务背景，才能做出更好的设计与抽象，而不是简单的翻译需求。 例如视频评论系统，就可以抽象出通用的评论功能，从而实现评论平台，接入到各种业务形态：文章评论、漫画评论等。 核心功能 发布评论: 支持回复楼层、楼中楼。 读取评论: 按照时间、热度排…

配置分类 环境变量(配置) 在部署、运行时能获取到的信息，没必要放到配置文件里。可通过K8S注入到容器或者物理机，供kit 库读取使用。 Region：区域 Zone：可用区 Cluster：集群 Environment：环境，由集群本身决定，而不是取决于应用 Color：染色信息，可用于分发流量，实现多租户 Discovery：注册中心？课程没说…

API 定义文件放在哪？ 放在当前项目 使用时，需要import此项目，造成API和源码绑定，不好单独管理权限。 放在当前项目，并通过CI自动同步到API大仓——B站的方案 为了统一检索和规范 API，B站内部建立了一个统一的 bapis 仓库，整合所有对内对外 API。 参考 https://github.com/googleapis/googl…

背景 项目里存放了部署到测试环境的k8s资源定义文件，这部分文件需要提交到一个资源定义文件集中仓库，给运维部署到生产环境用。但这部分文件可能会改动，例如存放的项目配置文件就是以configmap的形式在k8s中使用，如果更改项目配置，就需要同步提交到集中仓库。 最开始，这部分工作是人工手动完成的，但是一份文件保存在多个地方，就可能出现不同步的问题，…

前言 之前将流水线脚本所有内容都放到项目里，使用一段时间后，发现存在一些问题。 不好维护，当我发现流水线可以优化，需要做些调整的时候，需要在群里跟所有人说，要怎么怎么改。很麻烦，而且不能保证所有项目都会去更新，导致有的基础设施就需要做兼容，例如我封装的基础镜像。 新项目需要使用流水线时，可能出现随便找个脚本抄过来用，而那个脚本并不保证是最新的。 G…

工程项目结构 序言 go工程的项目结构多种多样，不同的框架对应不同的结构，即使是同一个框架，也有可能出现不同的结构。我个人感觉目前go很年轻，处于百花齐放的时代。而不像java，早已形成业界标准，主流框架spring全家桶，你想要的它都有。基本不用纠结项目结构，只需照着来就行。这对刚从java转到go的同学造成很大的困扰，不知道怎么写符合业界标注，…

前言 在微服务框架kratos中，通过中间件对请求进行扩展处理。有点像java里的servlet，也是用的责任链实现的，但实现方式很巧妙，这里详细说一下。 具体实现 处理顺序 ┌───────────────────┐ │MIDDLEWARE 1 │ │ ┌────────────────┐│ │ │MIDDLEWARE 2 ││ │ │ ┌───…

error type: 错误定义与判断 Sentinel Error 哨兵错误，就是定义一些包级别的错误变量，然后在调用的时候外部包可以直接对比变量进行判定，在标准库当中大量的使用了这种方式。例如下方 io 库中定义的错误。 // EOF is the error returned by Read when no more input is ava…

背景 在测试error.is时，发现一个奇怪的现象，同时使用fmt.Printf和println，输出顺序无法保证，也就是可能存在异步输出。 err := errors.New("standard error") myError := MyError{1, "my error"} if errors.Is(e…