Posts

Golang 并发模型 & Goroutine 详解 💡 并发不是并行，并发关乎结构，并行关乎执行 操作系统的基本调度与执行单元是进程(process) 操作系统的最小调度单位是线程-线程可作为执行单元可被独立调度到处理器上运行 **CSP( Communicationing Sequential Processes，通信顺序进程)**并发模型 Tony Hoare 的 CSP 模型旨在简化并发程序的编写，让并发程序的编写与编写顺序程序一样简单。Tony Hoare 认为输入输出应该是基本的编程原语，数据处理逻辑(也就是 CSP中的 P)只需调用输入原语获取数据，顺序地处理数据，并将结果数据通过输出原语输出就可以了。因此，在 Tony Hoare 眼中，一个符合 CSP 模型的并发程序应该是一组通过输入输出原语连接起来的 P 的集合。 从这个角度来看，CSP理论不仅是一个并发参考模型，也是一种并发程序的程序组织方法。它的组合思想与 Go 的设计哲学不谋而合。 Tony Hoare 的 CSP 理论中的 P，也就是“Process(进程)”，是一个抽象概念，它代表任何顺序处理逻辑的封装，它获取输入数据(或从其他 P 的输出获取)，并生产出可以被其他 P 消费的输出数据。这里我们可以简单看下 CSP 通信模型的示意图: 注意了，这里的 P 并不一定与操作系统的进程或线程划等号。在 Go 中，与“Process”对 应的是 goroutine。 为了实现 CSP 并发模型中的输入和输出原语，Go 还引入了 goroutine(P)之间的通信原语channel。goroutine 可以从 channel 获取输入数据， 再将处理后得到的结果数据通过 channel 输出。通过 channel 将 goroutine(P)组合连 接在一起，让设计和编写大型并发系统变得更加简单和清晰，我们再也不用为那些传统共 享内存并发模型中的问题而伤脑筋了。 Goroutine 的优势 资源占用小，每个 goroutine 的初始栈大小仅为 2k; 由 Go 运行时而不是操作系统调度，goroutine 上下文切换在用户层完成，开销更小; 在语言层面而不是通过标准库提供。goroutine 由go关键字创建，一退出就会被回收或 销毁，开发体验更佳 语言内置 channel 作为 goroutine 间通信原语，为并发设计提供了强大支撑。 Goroutine 调度器 一个 Go 程序对于操作系统来说只是一个用户层程序，操作系统眼中只有线程，它甚至不知道有一种叫 Goroutine 的事物存在。所以，Goroutine 的调度全要靠 Go 自己完成。那么，实现 Go 程序内 Goroutine 之间“公平”竞争“CPU”资源的任务，就落到了Go 运行时(runtime)头上了。要知道在一个 Go 程序中，除了用户层代码，剩下的就是Go 运行时了。 于是，Goroutine 的调度问题就演变为，Go 运行时如何将程序内的众多 Goroutine，按照一定算法调度到“CPU”资源上运行的问题了。 💡 可是，在操作系统层面，线程竞争的“CPU”资源是真实的物理 CPU，但在 Go 程序层 面，各个 Goroutine 要竞争的“CPU”资源又是什么呢? Go 程序是用户层程序，它本身就是整体运行在一个或多个操作系统线程上的。所以这个答案就出来了: Goroutine 们要竞争的“CPU”资源就是操作系统线程。这样，Goroutine调度器的任务也就明确了: 将 Goroutine 按照一定算法放到不同的操作系统线程中去执行。 ...

聊聊登录认证这件事 这里介绍的是减少登录页面的编写的方法，比如一个公司中有A，B, C 三个系统，对于用户来说希望是我只需要登录（认证）一次就可以访问A，B，C三个系统，而不是进到A系统在A中登录（认证）一次，进到B系统又要在B中登录（认证）一次，进到C系统还要在C中登录（认证）一次，这样一方面会有重复的编码（A，B，C系统的登录页面逻辑），另一方面对用户来说也是非常不友好。 请区别于对系统中的资源的权限校验 关于LDAP 轻量级目录访问协议 (LDAP) 是一种使应用程序可以快速查询用户信息的协议。 “什么是目录服务？” 目录服务是一个特殊的数据库，用来保存描述性的、基于属性的详细信息，支持过滤功能。 是动态的，灵活的，易扩展的。 如：人员组织管理，电话簿，地址簿。 LDAP介绍 LDAP（Light Directory Access Portocol），它是基于 X.500 标准的轻量级目录访问协议。 目录是一个为查询、浏览和搜索而优化的数据库，它成树状结构组织数据，类似文件目录一样。 目录数据库和关系数据库不同，它有优异的读性能，但写性能差，并且没有事务处理、回滚等复杂功能，不适于存储修改频繁的数据。所以目录天生是用来查询的，就好象它的名字一样。 LDAP目录服务是由目录数据库和一套访问协议组成的系统。 LDAP 登录流程 ...

Unix 体系结构 内核：从严格意义来说，可将操作系统（内核）定义为一种软件，它控制计算机硬件资源，提供程序运行环境。 shell: 是一个命令行解释器，它读取用户输入，然后执行命令。 函数 系统调用通常提供一种最小的接口，而库函数通常提供比较复杂的功能。 系统调用：内核的接口。各种版本的Unix实现都提供良好定义、数量有限、直接进入内核的入口点，这些入口点称为系统调用 公用库函数：封装一些功能，库函数可能会包含很多的系统调用 登录 /etc/passwd口令文件中保存这用户的登录相关信息。 由七个以冒号分隔的字段组成：登录名、加密口令、数字用户ID、数字组ID、注释字段、起始目录（/home/sar）、shell程序（/bin/ksh）。 1 2 登录名 加密口令 数字用户ID 数字组ID 注释字段 起始目录 shell程序 root x 0 0 root /root /bin/bash ...

Unix高级编程之文件和目录 文件类型 普通文件（regular file） 这是最常用的文件类型，这种文件包含了某种形式的数据。例如文本文件、二进制可执行文件等等。 不管文件是何种格式，其用途如何，对于 Unix 文件系统对此类文件的管理是完全一致的。 对普通文件内容的解释由处理该文件的应用程序进行。 目录文件（directory file） 这种文件包含了其他文件的名字以及指向与这些文件有关信息的指针。 对于一个目录文件具有读权限的任一进程都可以读取该目录的内容，但只有内核可以直接写目录文件。 块特殊文件（block special file） 这种类型的文件提供对设备（如磁盘）带缓冲的访问，每次访问以固定长度为单位进行。 字符特殊文件 （character special file） 这种类型的文件提供对设备不带缓冲的访问，每次访问的长度可变。系统中的所有设备要么是字符特殊文件，要么是块特殊文件。 FIFO 这种类型的文件用于进程间的通信，有时也称为命名管道（named pipe） 套接字（socket） 这种类型的文件用于进程间的网络通信。 也可用于在一台宿主机上进程之间的非网络通信。 符号链接（symbolic link） 这种类型的文件指向另一个文件。

Runtime：Golang 处理系统调用阻塞方式 当一个Goroutine由于执行 系统调用 而阻塞时，会将M从GPM中分离出去，然后P再找一个G和M重新执行，避免浪费CPU资源。 前言 什么是 runtime ​ runtime 描述了程序运行时候执行的软件/指令， 在每种语言有着不同的实现。可大可小，在 C 中，runtime 是库代码， 等同于 C runtime library，一系列 C 程序运行所需的函数，在Java中，runtime 还提供了 Java 程序运行所需的虚拟机等。 ​ 总而言之，runtime 是一个通用抽象的术语，指的是计算机程序运行的时候所需要的一切代码库，框架，平台等。 Go中的 runtime 在 Go 中， 有一个 runtime 库，其实现了垃圾回收，并发控制， 栈管理以及其他一些 Go 语言的关键特性。 runtime 库是每个 Go 程序的一部分，也就是说编译 Go 代码为机器代码时也会将其也编译进来。所以 Go 官方将其定位偏向类似于 C 语言中的库。Go 中的 runtime 不像 Java runtime （JRE， java runtime envirement ) 一样，jre 还会提供虚拟机， Java 程序要在 JRE 下 才能运行。 所以在 Go 语言中， runtime 只是提供支持语言特性的库的名称，也就是 Go 程序执行时候使用的库。 P的状态切换 ​ 从上图我们可以看出 P 执行系统调用时会执行 entersyscall() 函数（另还有一个类似的阻塞函数 entersyscallblock() ，注意两者的区别）。当系统调用执行完毕切换回去会执行 exitsyscall() 函数，下面我们看一下这两个函数的实现。 ...

聊聊分布式事务 前言 ​ 随着业务的快速发展、业务复杂度越来越高，传统单体应用逐渐暴露出了一些问题，例如开发效率低、可维护性差、架构扩展性差、部署不灵活、健壮性差等等。 ​ 微服务架构是一个分布式的系统，按业务进行划分为独立的服务单元，解决单体系统的不足，同时也满足越来越复杂的业务需求。每个微服务仅关注于完成一件任务并很好地完成该任务。 微服务架构的特点 微服务架构的优势非常明显，在近些年迅猛发展。 将复杂的业务拆分成多个小的业务，能够达到更好的业务复用，有利于人员组织分工 服务独立部署，独立扩容，每个服务的修改和部署对其他服务没有影响 每个服务可以根据业务场景选取合适的编程语言和数据库 微服务有以上的优势，但是微服务也带来不少的新问题，例如： 服务数量众多，其测试、部署、监控等都变的更加困难。 单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂 系统微服务化后，原先是一个服务内部的本地数据库事务，被拆到了多个服务，需要在分布式环境下保证事务的一致性 上述的各项问题中，1、2都可以通过近几年涌现的各项微服务技术解决，例如Kubernetes提供了服务发现、服务治理等。 因此分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。 CAP 理论 一个分布式系统最多只能同时满足 一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 分布式事务方案 分布式事务模式常见的有XA、TCC、SAGA、可靠消息。 ...

Golang 并发编程最佳实践 Goroutine 定义 ​ Goroutines 是与其他函数或方法同时运行的函数或方法。Goroutines 可以被认为是轻量级线程。与线程相比，创建 Goroutine 的成本很小。因此，Go 应用程序通常会同时运行数千个 Goroutine。 Goroutines 相对于线程的优势 与线程相比，Goroutines 非常便宜。它们的堆栈大小只有几 kb，堆栈可以根据应用程序的需要增长和缩小，而在线程的情况下，堆栈大小必须指定并固定。 Goroutine 被多路复用到更少数量的 OS 线程。一个包含数千个 Goroutine 的程序中可能只有一个线程。如果该线程中的任何 Goroutine 阻塞等待用户输入，则创建另一个 OS 线程并将剩余的 Goroutine 移动到新的 OS 线程。所有这些都由运行时处理，我们作为程序员从这些复杂的细节中抽象出来，并获得了一个干净的 API 来处理并发性。 Goroutines 使用通道进行通信。通道通过设计防止在使用 Goroutine 访问共享内存时发生竞争条件。通道可以被认为是 Goroutine 进行通信的管道。 ...

Service Mesh 介绍 Service Mesh 是微服务时代的 TCP/IP 协议 ​ 一种控制应用程序的不同部分如何相互共享数据的方法。与其他用于管理此通信的系统不同，服务网格是内置于应用中的专用基础结构层。这个可见的基础结构层可以记录应用的不同部分的交互程度（或交互程度），因此随着应用的增长，优化通信和避免停机变得更加容易。 – redhat ​ Buoyant的CEO William Morgan，也就是Service Mesh这个词的发明人，对Service Mesh的定义： ​ 服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。 演化进程 时代0 开发人员想象中，不同服务间通信的方式，抽象表示如下： 时代1：原始通信时代 ​ 然而现实远比想象的复杂，在实际情况中，通信需要底层能够传输字节码和电子信号的物理层来完成，在TCP协议出现之前，服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题，因此服务实现中，除了业务逻辑外，还夹杂着对网络传输问题的处理逻辑。 ...

golang error 处理最佳实践 错误类型定义 Go 中error 类型是一个接口类型 1 2 3 type error interface { Error() string } 基本上，error 是实现该接口任何内容，它将错误消息作为字符串返回。 构造错误 ​ 可以使用 Go 的内置或包动态构造错误。 ​ 例如，以下函数使用包返回带有静态错误消息的新错误：errors fmt errors 1 2 3 4 5 6 7 package main import "errors" func DoSomething() error { return errors.New("something didn't work") } ​ 同样，该包可用于向错误添加动态数据。 ​ 例如：fmt int string error 1 2 3 4 5 6 7 8 9 10 package main import "fmt" func Divide(a, b int) (int, error) { if b == 0 { return 0, fmt.Errorf("can't divide '%d' by zero", a) } return a / b, nil } 请注意，当用于用格式动词包装另一个错误时，这将非常有用 fmt.Errorf %w 在上面的示例中，还有其他一些重要事项需要注意。 错误可以返回为nil ，它是 Go 中 error 的默认值或零值。这很重要，因为检查是确定是否遇到错误的惯用方法（替换您可能在其他编程语言中熟悉的 / 语句）。if err != nil 错误通常作为函数中的最后一个参数返回。因此，在上面的示例中，我们按该顺序返回 int和 nil 。 当我们返回错误时，函数返回的其他参数通常作为其默认的零值返回。函数的用户可能期望，如果返回非nil 错误，则返回的其他参数不相关。 最后，错误消息通常以小写形式编写，不以标点符号结尾。但是可以例外，例如，当包含专有名词，以大写字母开头的函数名称等。 ...

Golang Project Layout 最佳实践 鲍勃叔叔干净的架构（Uncle Bob） 依赖规则 同心圆代表软件的不同领域。 一般来说，你走得越远，软件的层次就越高。外圈是机制。内圈是政策。 ​ 使这个架构工作的最重要的规则是依赖规则。这条规则说源代码依赖只能指向内部。内圈中的任何人都无法对外圈中的事物一无所知。特别是，在外圈中声明的事物的名称不能被内圈中的代码提及。这包括函数、类。变量或任何其他命名的软件实体。 ...

golang var、:=、new、make区别及使用 ​ go里面的几大变量“类型”(不严谨，只是个人在使用的时候常用到的结构的一个划分) （1） 值类型： int， string， struct 等 （2） 引用类型：主要是 map, slice,chan 这三个引用（make创建内存的） （3）指针类型：*int64， *struct等 var vs := ​ 对于值类型的变量，我们通过var 声明(包括结构体)，系统会默认为他分配内存空间，并赋该类型的零值。 如下，我们声明一个int类型变量i，输出为0。 1 2 var i int fmt.Println(i) // i = 0 (类型零值) var和:=之间实际上存在差异，采用:=允许重新声明变量。 与常规变量声明不同，:=声明可以重新声明变量，前提是它们最初在同一块中以相同类型声明，并且至少有一个非空白变量是新的。因此，重新声明只能出现在多变量短声明中。 重新声明不引入新变量；它只是为原始值分配一个新值。 1 2 3 4 field1, offset := nextField(str, 0) field2, offset := nextField(str, offset) // 重新声明偏移量(可重入) a, a := 1, 2 // 非法：如果在别处声明了 a，则双重声明 a 或没有新变量 所以我会说:=运算符不是纯粹的声明，而是更像声明和分配。不允许在顶层重新声明，因此也不允许短声明。另一个原因可能是语法简单。type在 Go 中，所有顶级表单都以var 或 func 开头。 建议：重复声明的变量用 :=，比如 err 的声明，使用的值或全局变量（不推荐大量使用）用 var， 如 var fields []string ...

程序配置服务和热更新 前言 ​ 在开发过程中，因为不同环境中有不同的配置，所以往往一个项目要同时保存着不同环境的配置文件（dev，test，staging，prd）等。如果没有一个方便简洁的管理这些配置文件方式，排查问题也会变的麻烦。接下来介绍几种我所经历的几种配置文件管理方案 git 分支管理 ​ 顾名思义就是利用 git 的分支来管理不同环境的配置，比如dev分支就是对应存放这dev的配置文件。 优点 分支管理更符合开发的代码习惯，只关心本分支的代码和配置 缺点 不符合git-flow流程，如果test配置有改动，那么就要直接编辑test分支代码，而不是从dev分支合并过去。排查配置相关问题不友善 一份配置文件就一个分支，维护代价太大，有些舍本琢末了。 热更新方案无 所有配置文件都放在项目下 ​ 这种方式就是把所有的配置文件集中放在项目下的某个目录，用环境变量的方式去加载指定的配置文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 package main func main(){ switch env{ case:"dev": load("dev.config") case:"test": load("test.config") ... default: load("local.config") } } 优点 配置统一集中管理，修改方便 缺点 配置文件过多容易使项目结构变的“难看”，判断依赖过多，不优雅。 无法做到热更新，配置更改需要重新发布代码 热更新方案无 配置中心 ​ 将配置文件都放到三方的服务中保管，比如nacos、Apollo等配置中心 nacos：https://nacos.io/zh-cn/docs/what-is-nacos.html Apollo：https://www.apolloconfig.com/#/zh/README 优点 集中化管理配置，配置文件“不落地” 有相关 sdk 调用，支持热更新等高级功能 缺点 要维护一个高可用的 三方服务 增加了维护成本 热更新方案 需要另外编码去开发 ...

sync.Once 的用法 ​ 在多数情况下，sync.Once 被用于控制变量的初始化，这个变量的读写通常遵循单例模式，满足这三个条件： 当且仅当第一次读某个变量时，进行初始化（写操作） 变量被初始化过程中，所有读都被阻塞（读操作；当变量初始化完成后，读操作继续进行） 变量仅初始化一次，初始化完成后驻留在内存里 实例化一次客户端 ​ 在标准库中不乏有大量 sync.Once 的使用案例，在 strings 包中 replace.go 里实现字符串批量替换功能时，需要预编译生成替换规则，即采用不同的替换算法并创建相关算法实例，因 strings.Replacer 实现是线程安全且支持规则复用，在第一次解析替换规则并创建对应算法实例后，可以并发的进行字符串替换操作，避免多次解析替换规则浪费资源。 先看一下 strings.Replacer 的结构定义： 1 2 3 4 5 6 // source: strings/replace.go type Replacer struct { once sync.Once // guards buildOnce method r replacer oldnew []string } ​ 这里定义了 once sync.Once 用来控制 r replacer 替换算法初始化，当我们使用 strings.NewReplacer 创建 strings.Replacer 时，这里采用惰性算法，并没有在这时进行 build 解析替换规则并创建对应算法实例，而是在执行替换时( Replacer.Replace 和 Replacer.WriteString)进行的, r.once.Do(r.buildOnce) 使用 sync.Once 的 Do 方法保证只有在首次执行时才会执行 buildOnce 方法，而在 buildOnce 中调用 build 解析替换规则并创建对应算法实例，在 buildOnce 中进行赋值。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 // source: strings/replace.go func NewReplacer(oldnew ...string) *Replacer { if len(oldnew)%2 == 1 { panic("strings.NewReplacer: odd argument count") } return &Replacer{oldnew: append([]string(nil), oldnew...)} } func (r *Replacer) buildOnce() { r.r = r.build() r.oldnew = nil } func (b *Replacer) build() replacer { .... } func (r *Replacer) Replace(s string) string { r.once.Do(r.buildOnce) return r.r.Replace(s) } func (r *Replacer) WriteString(w io.Writer, s string) (n int, err error) { r.once.Do(r.buildOnce) return r.r.WriteString(w, s) } ​ 简单来说，once.Do 中的函数只会执行一次，并保证 once.Do 返回时，传入 Do 的函数已经执行完成。多个 goroutine 同时执行 once.Do 的时候，可以保证抢占到 once.Do 执行权的 goroutine 执行完 once.Do 后，其他 goroutine 才能得到返回。 ​ once.Do 接收一个函数作为参数，该函数不接受任何参数，不返回任何参数。具体做什么由使用方决定，错误处理也由使用方控制，对函数初始化的结果也由使用方进行保存。 ...

golang go get 私有库解决方案 注意：go get 只支持 https协议的库路径 ‼️ 前言 ​ 在我们开发过程中会自己封装一些工具库，在某个项目中使用。但是如果有别的项目想使用你封装的库，那么此时你就需要将工具库封装为一个go module，给其它项目导入。一般公司内部的库是不对外开放的，这时候就需要搭建代理去拉取私有仓库 原理架构图 ...

聊聊链路追踪 OpenTracing 什么是 Tracing 对 Tracing 的定义是，在软件工程中，Tracing 指使用特定的日志记录程序的执行信息，与之相近的还有两个概念，它们分别是 Logging 和 Metrics。 Logging：用于记录离散的事件，包含程序执行到某一点或某一阶段的详细信息。 Metrics：可聚合的数据，且通常是固定类型的时序数据，包括 Counter、Gauge、Histogram 等。 Tracing：记录单个请求的处理流程，其中包括服务调用和处理时长等信息。 同时这三种定义相交的情况也比较常见。 Logging & Metrics：可聚合的事件。例如分析某对象存储的 Nginx 日志，统计某段时间内 GET、PUT、DELETE、OPTIONS 操作的总数。 Metrics & Tracing：单个请求中的可计量数据。例如 SQL 执行总时长、gRPC 调用总次数。 Tracing & Logging：请求阶段的标签数据。例如在 Tracing 的信息中标记详细的错误原因。 针对每种分析需求，我们都有非常强大的集中式分析工具。 Logging：ELK，近几年势头最猛的日志分析服务，无须多言。 Metrics：Prometheus，第二个加入 CNCF 的开源项目，非常好用。 Tracing：OpenTracing 和 Jaeger，Jaeger 是 Uber 开源的一个兼容 OpenTracing 标准的分布式追踪服务。目前 Jaeger 也加入了 CNCF。 原理 ​ 分布式追踪系统大体分为三个部分，数据采集、数据持久化、数据展示。数据采集是指在代码中埋点，设置请求中要上报的阶段，以及设置当前记录的阶段隶属于哪个上级阶段。数据持久化则是指将上报的数据落盘存储，例如 Jaeger 就支持多种存储后端，可选用 Cassandra 或者 Elasticsearch。数据展示则是前端根据 Trace ID 查询与之关联的请求阶段，并在界面上呈现。 上图是一个请求的流程例子，请求从客户端发出，到达负载均衡，再依次进行认证、计费，最后取到目标资源。 请求过程被采集之后，会以上图的形式呈现，横坐标是时间，圆角矩形是请求的执行的各个阶段。 ...