XIAOSUO 记录个人学习的足迹

摘要：Request-scoped context 在 Go 服务中，每个传入的请求都在其自己的goroutine 中处理。请求处理程序通常启动额外的 goroutine 来访问其他后端，如数据库和 RPC服务。处理请求的 goroutine 通常需要访问特定于请求(request-specific context)的值，例如最终用户的身份、授权令牌和请求的截止日期(deadline)。当一个请求被取消或超时时，处理该请求的所有 goroutine 都应该快速退出(fail fast)，这样系统就可以回收它们正在使用的任何资源。 Go 1.7 引入一个 context 包，它使得跨 API 边界的请求范围元数据、取消信号和截止日期很容易传递给处理请求所涉及的所有 goroutine(显示传递)。 核心接口： 如何将 context 集成到 API 中 在将 context 集成到 API 中时，要记住的最重要的一点是，它的作用域是请求级别 的。例如，沿单个数据库查询存在是有意义的，但沿数据库对象存在则没有意义。 目前有两种方法可以将 context 对象集成到 API 中： The first parameter of a function call：首参数传递 context 对象，比如，参考 net 包 Dialer.DialContext。此函数执行正常的 Dial 操作，但可以通过 context 对象取消函数调用。 Optional config on a request structure：在第一个 request 对象中携带一个可选的 context 对象。例如 net/http 库的 Request.WithContext，通过携带给定的 context 对象，返回一个新的 Request 对象。 Do not store Contexts inside a struct type 使用 context 的一个很好的心智模型是它应该在程序中流动，应该贯穿你的代码。这通常意味着您不希望将其存储在结构体之中。它从一个函数传递到另一个函数，并根据需要进行扩展。理想情况下，每个请求都会创建一个 context 对象，并在请求结束时过期。 不存储上下文的一个例外是，当您需要将它放入一个结构中时，该结构纯粹用作通过通道传递的消息。如下例所示。 type …… 阅读全文

摘要：channels 是一种类型安全的消息队列，充当两个 goroutine 之间的管道，将通过它同步的进行任意资源的交换。chan 控制 goroutines 交互的能力从而创建了 Go 同步机制。当创建的 chan 没有容量时，称为无缓冲通道。反过来，使用容量创建的 chan 称为缓冲通道。 要了解通过 chan 交互的 goroutine 的同步行为是什么，我们需要知道通道的类型和状态。根据我们使用的是无缓冲通道还是缓冲通道，场景会有所不同，所以让我们单独讨论每个场景。 Unbuffered Channels ch := make(chan struct{}) 无缓冲 chan 没有容量，因此进行任何交换前需要两个 goroutine 同时准备好。当 goroutine 试图将一个资源发送到一个无缓冲的通道并且没有goroutine 等待接收该资源时，该通道将锁住发送 goroutine 并使其等待。当 goroutine 尝试从无缓冲通道接收，并且没有 goroutine 等待发送资源时，该通道将锁住接收 goroutine 并使其等待。 无缓冲信道的本质是保证同步。 func main() { c:= make(chan string) var wg sync.WaitGroup wg.Add(2) go func() { defer wg.Done() c - `foo` } go func() { defer wg.Done() time.Sleep(time.Second * 1) printIn(`Message` + -c) }() wg.Wait() } 第一个 goroutine 在发送消息 foo 之后被阻塞，因为还没有接收者准备好。规范中对这种行为进行了很好的解释： Receive 先于 Send 发生。 好处: 100% 保证能收到。 代价: 延迟时间未知。 Buffered Channels buffered channel 具有容量，因此其行为可能有点不同。当 goroutine 试图将资源发送到缓冲通道，而该通道已满时，该通道将锁住 goroutine并使其等待缓冲区可用。如果通道中有空间，发送可以立即进行，goroutine 可以继续。当goroutine 试图从缓冲通道接收数…… 阅读全文

摘要：Share Memory By Communicating 传统的线程模型(通常在编写 Java、C++ 和Python 程序时使用)程序员在线程之间通信需要使用共享内存。通常，共享数据结构由锁保护，线程将争用这些锁来访问数据。在某些情况下，通过使用线程安全的数据结构(如Python的Queue)，这会变得更容易。 Go 的并发原语 goroutines 和 channels 为构造并发软件提供了一种优雅而独特的方法。Go 没有显式地使用锁来协调对共享数据的访问，而是鼓励使用 chan 在 goroutine 之间传递对数据的引用。这种方法确保在给定的时间只有一个goroutine 可以访问数据。 Do not communicate by sharing memory; instead, share memory by communicating. Detecting Race Conditions With Go data race 是两个或多个 goroutine 访问同一个资源(如变量或数据结构)，并尝试对该资源进行读写而不考虑其他 goroutine。这种类型的代码可以创建您见过的最疯狂和最随机的 bug。通常需要大量的日志记录和运气才能找到这些类型的bug。 早在6月份的Go 1.1中，Go 工具引入了一个 race detector。竞争检测器是在构建过程中内置到程序中的代码。然后，一旦你的程序运行，它就能够检测并报告它发现的任何竞争条件。它非常酷，并且在识别罪魁祸首的代码方面做了令人难以置信的工作。 var Wait sync.WaitGroup var Counter int = 0 func main() { for routine := 1; routine = 2; routine++ { Wait.Add(1) go Rountine(rountine) } Wait.Wait() fmt.Print(Final Counter: %d\n, Counter) } func Rountine(id int) { for count := 0; count 2; count++ { value := Counter value++ Counter = value } Wait.Done() }…… 阅读全文

摘要：需要阅读https://golang.org/ref/mem 如何保证在一个 goroutine 中看到在另一个 goroutine 修改的变量的值，如果程序中修改数据时有其他 goroutine 同时读取，那么必须将读取串行化。为了串行化访问，请使用 channel 或其他同步原语，例如 sync 和 sync/atomic 来保护数据。 在一个 goroutine 中，读和写一定是按照程序中的顺序执行的。即编译器和处理器只有在不会改变这个 goroutine 的行为时才可能修改读和写的执行顺序。由于重排，不同的goroutine 可能会看到不同的执行顺序。例如，一个goroutine 执行 a = 1;b = 2;，另一个 goroutine 可能看到 b 在 a 之前更新。 Memory Reordering 用户写下的代码，先要编译成汇编代码，也就是各种指令，包括读写内存的指令。CPU 的设计者们，为了榨干 CPU 的性能，无所不用其极，各种手段都用上了，你可能听过不少，像流水线、分支预测等等。其中，为了提高读写内存的效率，会对读写指令进行重新排列，这就是所谓的 内存重排，英文为 MemoryReordering。 这一部分说的是 CPU 重排，其实还有编译器重排。比如: 但是，如果这时有另外一个线程同时干了这么一件事：x=0 在多核心场景下,没有办法轻易地判断两段程序是“等价”的。 现代 CPU 为了“抚平” 内核、内存、硬盘之间的速度差异，搞出了各种策略，例如三级缓存等。为了让 (2) 不必等待 (1) 的执行“效果”可见之后才能执行，我们可以把 (1) 的效果保存到 store buffer： 先执行 (1) 和 (3)，将他们直接写入 store buffer，接着执行 (2) 和 (4)。“奇迹”要发生了：(2) 看了下 store buffer，并没有发现有 B 的值，于是从 Memory 读出了 0，(4) 同样从 Memory 读出了 0。最后，打印出了 00。 因此，对于多线程的程序，所有的 CPU 都会提供“锁”支持，称之为 barrier，或者 fence。它要求：barrier 指令要求所有对内存的操作都必须要“扩散”到 memory 之后才能继续执行其他对 memory 的操作。因此，我们可以用高级点的 atomic com…… 阅读全文

摘要：Processes and Threads 操作系统会为该应用程序创建一个进程。作为一个应用程序，它像一个为所有资源而运行的容器。这些资源包括内存地址空间、文件句柄、设备和线程。 线程是操作系统调度的一种执行路径，用于在处理器执行我们在函数中编写的代码。一个进程从一个线程开始，即主线程，当该线程终止时，进程终止。这是因为主线程是应用程序的原点。然后，主线程可以依次启动更多的线程，而这些线程可以启动更多的线程。 无论线程属于哪个进程，操作系统都会安排线程在可用处理器上运行。每个操作系统都有自己的算法来做出这些决定。 Goroutines and Parallelism Go 语言层面支持的 go 关键字，可以快速的让一个函数创建为 goroutine，我们可以认为 main 函数就是作为 goroutine 执行的。操作系统调度线程在可用处理器上运行，Go运行时调度 goroutines 在绑定到单个操作系统线程的逻辑处理器中运行(P)。即使使用这个单一的逻辑处理器和操作系统线程，也可以调度数十万 goroutine 以惊人的效率和性能并发运行。 并发不是并行。并行是指两个或多个线程同时在不同的处理器执行代码。如果将运行时配置为使用多个逻辑处理器，则调度程序将在这些逻辑处理器之间分配 goroutine，这将导致 goroutine 在不同的操作系统线程上运行。但是，要获得真正的并行性，您需要在具有多个物理处理器的计算机上运行程序。否则，goroutines 将针对单个物理处理器并发运行，即使 Go 运行时使用多个逻辑处理器。 Keep yourself busy or do the work yourself 比如我们想监听一个端口，但并不知道它什么时候返回，我们可能会使用一个select来永远阻塞，如下代码： func main() { http.HandleFunc(/, func(w http.ResponseWriter, r *http.Request)) { fmt.FprintIn(w, Hello, GrpherCon SG) } go func() { if(err := http.listenAndServe(:8080, nil); err != nil) { log.Fatal(err) } }() sele…… 阅读全文

摘要：Error error类型是go语言的一种内置类型，使用的时候不用特定去import,他本质上是一个接口 //http://golang.org/pkg/builtin/#error type error interface{ Error() string //Error()是每一个订制的error对象需要填充的错误消息,可以理解成是一个字段Error } 我们经常使用 errors.New() 来返回一个 error 对象。 //http://golang.org/src/pkg/errors/errors.go type errorString struct { s String } func (e *errorString) Error() string { return e.s } 基础库中有大量自定义的error，如bufio //http://golang.org/src/pkg/bufio/bufio.go var { ErrInvalidUnreadByte = errors.New(bufio: invalid use of UnreadByte) ErrInvalidUnreadRune = errors.New(bufio: invalid use of UnreadRune) ErrBufferFull = errors.New(bufio: Buffer full) ErrNegativeCount = errors.New(bufio: negative count) } errors.New()返回的是内部errorString对象的指针 //http://golang.org/src/pkg/errors/errors.go //New returns an error that formats as the given text func New(text string) error { return errorString{text} } Error vs Exception 各个语言的演进历史： C：单返回值，一般通过传递指针作为入参，返回值为 int 表示成功还是失败。 C++：引入了 exception，但是无法知道被调用方会抛出什么异常 Java：引入了 checked exception…… 阅读全文

摘要：前面介绍了 DDD 分层架构，同时也提到了微服务架构模型其实还有好多种，不知道你注意到了没？这些架构模型在我们的实际应用中都具有很高的借鉴价值。 那么今天我们就把 DDD 分层架构、整洁架构、六边形架构这三种架构模型放到一起，对比分析，看看如何利用好它们，帮助我们设计出高内聚低耦合的中台以及微服务架构。 整洁架构 整洁架构又名“洋葱架构”。为什么叫它洋葱架构？看看下面这张图你就明白了。整洁架构... 阅读全文

摘要：前面我们讲了 DDD 的一些重要概念以及领域模型的设计理念。今天我们来聊聊“DDD 分层架构”。微服务架构模型有好多种，例如整洁架构、CQRS 和六边形架构等等。每种架构模式虽然提出的时代和背景不同，但其核心理念都是为了设计出“高内聚低耦合”的架构，轻松实现架构演进。而 DDD 分层架构的出现，使架构边界变得越来越清晰，它在微服务架构模型中，占有非常重要的位置。那 DDD 分层架构到底长什么样？DDD 分层架构如何推动架构演进？我们该怎么转向 DDD 分层架构？这就是我们这一讲重点要解决的问题。 阅读全文

摘要：在事件风暴（EventStorming）时，我们发现除了命令和操作等业务行为以外，还有一种非常重要的事件，这种事件发生后通常会导致进一步的业务操作，在 DDD中这种事件被称为领域事件。这只是最简单的定义，并不能让我们真正理解它。那到底什么是领域事件？领域事件的技术实现机制是怎样的？今天，我们就重点解决这两个大的问题。 领域事件 领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件。一... 阅读全文

摘要：我们先回顾下上一讲，在事件风暴中，我们会根据一些业务操作和行为找出实体（Entity）或值对象（ValueObject），进而将业务关联紧密的实体和值对象进行组合，构成聚合，再根据业务语义将多个聚合划定到同一个限界上下文（BoundedContext）中，并在限界上下文内完成领域建模。 那你知道为什么要在限界上下文和实体之间增加聚合和聚合根这两个概念吗？它们的作用是什么？怎么设计聚合？这就是我... 阅读全文