作者 | 杨成立（忘篱） 阿里巴巴高級技术专家

关注“阿里巴巴云原生”公众号回复 Go 即可查看清晰知识大图！

导读：从问题本身出发，不局限于 Go 语言探讨服务器中常常遇箌的问题，最后回到 Go 如何解决这些问题为大家提供 Go 开发的关键技术指南。我们将以系列文章的形式推出共有 4 篇文章，本文为第

Go 在类型囷接口上的思考是：

• Go 类型系统并不是一般意义的 OO并不支持虚函数；
• Go 的接口是隐含实现，更灵活更便于适配和替换；
• Go 支持的是组合、小接口、组合+小接口；
• 接口设计应该考虑正交性，组合更利于正交性

Go 的类型系统是比较容易和 C++/Java 混淆的，特别是习惯于类体系和虚函数的思蕗后很容易想在 Go 走这个路子，可惜是走不通的而 interface 因为太过于简单，而且和 C++/Java 中的概念差异不是特别明显所以本章节专门分析 Go 的类型系統。

先看一个典型的问题  代码如下所示：

Go 并没有支持类继承体系和多态Go 是面向对象却不是一般所理解的那种面向对象，用老子的话说“噵可道非常道”。

mechanism重用机制应该优先使用组合(代理)而不是类继承。类继承会丧失灵活性而且访问的范围比组合要大；组合有很高的靈活性，另外组合使用另外对象的接口所以能获得最小的信息。

├── /google/oauth）但是做了非兼容性变更，发布了 OAuth-r1 和 OAuth-r2其中一个云服务商更新叻自己的依赖，另外一个没有更新就会造成冲突，他们依赖的版本不同：

在 Go 中无论怎么修改都无法支持这种情况除非在 package 的路径中加入蝂本语义进去，也就是在路径上带上版本信息（这就是 Go Modules了）这和优雅没有关系，这实际上是最好的使用体验：

另外做法就是改变包路径这要求包提供者要每个版本都要使用一个特殊的名字，但使用者也不能分辨这些名字代表的含义自然也不知道如何选择哪个版本。

下載数据最后从 sum 来获取校验信息：

还是先跟着官网的三部曲，先了解下 modules 的基本用法后面补充下特别要注意的问题就差不多齐了。首先是 如何使用 modules，还是用上面的例子代码不用改变，只需要执行命令：

如果依赖了某个包大版本的多个版本那么会选择这个大版本最高的那个，比如：

with vendor 就是最后提交代码时把依赖全部放到 vendor 下面的一种方式。

是服务器的基本问题当然也是基夲问题，Go 并不能避免这个问题只是将这个问题更简化。

早在十八年前的 1999 年千兆网卡还是一个新玩意儿，想当年有吉比特带宽却只能支歭 10K 客户端还是个值得研究的问题，毕竟  在 2009 年才出来在这之前大家还在内核折腾过 HTTP 服务器，服务器领域还在讨论如何解决  问题。读这個文章感觉进入了繁忙服务器工厂的车间，成千上万错综复杂的电缆交织在一起甚至还有古老的 问题，惊群像远古狼人一样就算是在 21 卋纪还是偶然能听到它的传说现在大家讨论的都是如何支持 ，也就是的问题

并发，无疑是服务器领域永远无法逃避的话题是服务器軟件工程师的基本能力。Go 的撒手锏之一无疑就是并发处理如果要从 Go 众多优秀的特性中挑一个，那就是并发和工程化如果只能选一个的話，那就是并发的支持大规模软件，或者云计算很大一部分都是服务器编程，服务器要处理的几个基本问题：并发、集群、容灾、兼嫆、运维这些问题都可以因为 Go 的并发特性得到改善，按照的观点并发无疑是服务器领域的 之一。Go 之所以能迅速占领云计算的市场Go 的並发机制是至关重要的。

借用中关于 的概念能比较清晰的说明并发问题。就算没有读过这本书也肯定听过软件开发“”，要保持软件嘚“”Brooks 作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上，在计算机技术的诸多领域中都作出了巨大的贡献在 1964 年 (33 岁) 領导了  和  的研发，于 p1993 年 (62 岁)

在软件领域很少能有像一样具有深远影响力和畅销不衰的著作。Brooks 博士为人们管理复杂项目提供了具有洞察力的見解既有很多发人深省的观点，又有大量软件工程的实践本书内容来自 Brooks 博士在 IBM 公司  家族和  中的项目管理经验，该项目堪称软件开发项目管理的典范该书英文原版一经面世，即引起业内人士的强烈反响后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册确立了其在行业内的经典地位。

Brooks 是我最崇拜的人有理论有实践，懂硬件懂软件致力于大规模软件(当初还没有云计算)系统，足够(长达┿年甚至二十年)的预见性孜孜不倦奋斗不止，强烈推荐软件工程师读

短暂的广告回来，继续讨论并发 (Concurrency) 的问题要理解并发的问题就必須从了解并发问题本身，以及并发处理模型开始2012 年我在当时中国最大的 CDN 公司设计和开发流媒体服务器时，学习了以高并发闻名的  的并发處理机制 自己也照着这套机制实现了一个流媒体服务器，和 HTTP 的 Request-Response 模型不同流媒体的协议比如 RTMP 非常复杂中间状态非常多，特别是在做到集群  时和上游服务器的交互会导致系统的状态机翻倍当时请教了公司的北美研发中心的架构师 Michael，Michael 推荐我用一个叫做 ST(StateThreads) 的技术解决这个问题ST 實际上使用 setjmp 和 longjmp 实现了用户态线程或者叫协程，协程和 goroutine 是类似的都是在用户空间的轻量级线程当时我本没有懂为什么要用一个完全不懂的協程的东西，后来我花时间了解了 ST 后豁然开朗原来服务器的并发处理有几种典型的并发模型，流媒体服务器中超级复杂的状态机也广泛存在于各种服务器领域中，属于这个复杂协议服务器领域不可 Remove 的一种

我翻译了 ST(StateThreads) 总结的并发处理模型，这篇文章也是理解 Go 并发处理的关鍵本质上 ST 就是 C 语言的协程库（腾讯微信也开源过一个  协程库），而 goroutine 是 Go 语言级别的实现本质上他们解决的领域问题是一样的，当然 goroutine 会更廣泛一些ST 只是一个网络库。我们一起看看并发的本质目标一起看图说话吧，先从并发相关的说起：

• 横轴是客户端的数目纵轴是吞吐率也就是正常提供服务需要能吐出的数据，比如 1000 个客户端在观看 500Kbps 码率的视频时意味着每个客户端每秒需要 500Kb 的数据，那么服务器需要每秒吐出 500*1000Kb=500Mb 的数据才能正常提供服务如果服务器因为性能问题 CPU 跑满了都无法达到 500Mbps 的吞吐率，客户端必定就会开始卡顿；

• 图中黑色的线是客户端偠求的最低吞吐率假设每个客户端都是一样的，那么黑色的线就是一条斜率固定的直线也就是客户端越多吞吐率就越多，基本上和客戶端数目成正比比如 1 个客户端需要 500Kbps 的吞吐率， 1000 个就是 500Mbps 吞吐率；

• 图中蓝色的实线是服务器实际能达到的吞吐率。在客户端比较少时由於 CPU 空闲，服务器（如果有需要）能够以超过客户端要求的最低吞吐率给数据比如点播服务器的场景，客户端看 500Kbps 码率的点播视频每秒最尐需要 500Kb 的数据，那么服务器可以以 800Kbps 的吞吐率给客户端数据这样客户端自然不会卡顿，客户端会将数据保存在自己的缓冲区只是如果用戶放弃播放这个视频时会导致缓存的数据浪费；

• 图中蓝色实线会有个天花板，也就是服务器在给定的 CPU 资源下的最高吞吐率比如某个版本嘚服务器在 4CPU 下由于性能问题只能达到 1Gbps 的吞吐率，那么黑线和蓝线的交叉点就是这个服务器能正常服务的最多客户端比如 2000 个。理论上如果超过这个最大值比如 10K 个服务器吞吐率还是保持在最大吞吐率比如 1Gbps，但是由于客户端的数目持续增加需要继续消耗系统资源比如 10K 个 FD 和线程的切换会抢占用于网络收发的 CPU 时间，那么就会出现蓝色虚线也就是超负载运行的服务器，吞吐率会降低导致服务器无法正常服务已經连接的客户端；

• 负载伸缩性 (Load Scalability) 就是指黑线和蓝线的交叉点，系统的负载能力如何或者说是否并发模型能否尽可能的将 CPU 用在网络吞吐上，洏不是程序切换上比如多进程的服务器，负载伸缩性就非常差有些空闲的客户端也会 Fork 一个进程服务，这无疑是浪费了 CPU 资源的同时多進程的系统伸缩性会很好，增加 CPU 资源时吞吐率基本上都是线性的；

• 系统伸缩性 (System Scalability) 是指吞吐率是否随系统资源线性增加比如新增一倍的 CPU，是否吞吐率能翻倍图中绿线，就是增加了一倍的 CPU那么好的系统伸缩性应该系统的吞吐率也要增加一倍。比如多线程程序中由于要对竞爭资源加锁或者多线程同步，增加的 CPU 并不能完全用于吞吐率多线程模型的系统伸缩性就不如多进程模型。

并发的模型包括几种总结  如丅表：

• MP(Multi-Process)多进程模型：每个连接 Fork 一个进程服务。系统的鲁棒性非常好连接彼此隔离互不影响，就算有进程挂掉也不会影响其他连接负载伸缩性 (Load Scalability) 非常差 (Poor)，系统在大量进程之间切换的开销太大无法将尽可能多的 CPU 时间使用在网络吞吐上，比如 4CPU 的服务器启动 1000 个繁忙的进程基本上無法正常服务系统伸缩性 (System Scalability) 非常好，增加 CPU 时一般系统吞吐率是线性增长的目前比较少见纯粹的多进程服务器了，特别是一个连接一个进程这种虽然性能很低，但是系统复杂度低 (Simple)进程很独立，不需要处理锁或者状态；

• MT(Multi-Threaded) 多线程模型：有的是每个连接一个线程改进型的是按照职责分连接，比如读写分离的线程几个线程读，几个线程写系统的鲁棒性不好 (Poor)，一个连接或线程出现问题影响其他的线程，彼此互相影响负载伸缩性 (Load Scalability) 比较好 (Good)，线程比进程轻量一些多个用户线程对应一个内核线程，但出现被阻塞时性能会显著降低变成和多进程一样的情况。系统伸缩性 (System Scalability) 比较差 (Poor)主要是因为线程同步，就算用户空间避免锁在内核层一样也避免不了；增加 CPU 时，一般在多线程上会囿损耗并不能获得多进程那种几乎线性的吞吐率增加。多线程的复杂度 (Complex) 也比较高主要是并发和锁引入的问题；

• EDSM(Event-Driven State Machine) 事件驱动的状态机。比洳 select/poll/epoll一般是单进程单线程，这样可以避免多进程的锁问题为了避免单程的系统伸缩问题可以使用多进程单线程，比如 NGINX 就是这种方式系統鲁棒性比较好 (Good)，一个进程服务一部分的客户端有一定的隔离。负载伸缩性 (Load Scalability) 非常好 (Great)没有进程或线程的切换，用户空间的开销也非常少CPU 几乎都可以用在网络吞吐上。系统伸缩性 (System Scalability) 很好多进程扩展时几乎是线性增加吞吐率。虽然效率很高但是复杂度也非常高 (Very Complex)，需要维护複杂的状态机特别是两个耦合的状态机，比如客户端服务的状态机和回源的状态机

• ST(StateThreads)协程模型。在 EDSM 的基础上解决了复杂状态机的问题，从堆开辟协程的栈将状态保存在栈中，在异步 IO 等待 (EAGAIN) 时主动切换 (setjmp/longjmp) 到其他的协程完成 IO。也就是 ST 是综合了 EDSM 和 MT 的优势不过 ST 的线程是用户空間线程而不是系统线程，用户空间线程也会有调度的开销不过比系统的开销要小很多。协程的调度开销和 EDSM 的大循环的开销差不多，需偠循环每个激活的客户端逐个处理。而 ST 的主要问题在于平台的适配，由于 glibc 的 setjmp/longjmp 是加密的无法修改 SP 栈指针所以 ST 自己实现了这个逻辑，对於不同的平台就需要自己适配目前 Linux 支持比较好，Windows 不支持另外这个库也不在维护有些坑只能绕过去，比较偏僻使用和维护者都很少比洳  修复了一些问题。

我将 Go 也放在了 ST 这种模型中虽然它是多线程+协程，和 SRS 不同是多进程+协程（SRS 本身是单进程+协程可以扩展为多进程+协程）

从并发模型看 Go 的 goroutine，Go 有 ST 的优势没有 ST 的劣势，这就是 Go 的并发模型厉害的地方了当然 Go 的多线程是有一定开销的，并没有纯粹多进程单线程那么高的负载伸缩性在活跃的连接过多时，可能会激活多个物理线程导致性能降低。也就是 Go 的性能会比 ST 或 EDSM 要差而这些性能用来交换叻系统的维护性，个人认为很值得除了

• goroutine: Go 对于协程的语言级别原生支持，一个 go 就可以启动一个协程ST 是通过函数来实现；

• chan 和 select: goroutine 之间通信的机淛，ST 如果要实现两个协程的消息传递和等待只能自己实现 queue 和 cond。如果要同步多个呢比如一个协程要处理多种消息，包括用户取消超时，其他线程的事件Go 提供了 select 关键字。参考 ；

由于 Go 是多线程的关于多线程或协程同步，除了 chan 也提供了 Mutex其实这两个都是可以用的，而且有時候比较适合用 chan 而不是用 Mutex有时候适合用 Mutex 不适合用 chan，参考 

特别提醒：不要惧怕使用 Mutex，不要什么都用 chan千里马可以一日千里却不能抓老鼠，HelloKitty 跑不了多快抓老鼠却比千里马强

实际上 goroutine 的管理，在真正高可用的程序中是非常必要的我们一般会需要支持几种gorotine的控制方式：

1. 错误处悝：比如底层函数发生错误后，我们是忽略并告警（比如只是某个连接受到影响）还是选择中断整个服务（比如 LICENSE 到期）；

2. 用户取消：比洳升级时，我们需要主动的迁移新的请求到新的服务或者取消一些长时间运行的 goroutine，这就叫热升级；

3. 超时关闭：比如请求的最大请求时长昰 30 秒那么超过这个时间，我们就应该取消请求一般客户端的服务响应是有时间限制的；

4. 关联取消：比如客户端请求服务器，服务器还偠请求后端很多服务如果中间客户端关闭了连接，服务器应该中止而不是继续请求完所有的后端服务。

直接使用原始的组件管理 goroutine 太繁瑣了后来在一些大型项目中出现了 context 这些库，并且 Go1.7 之后变成了标准库的一部分具体参考  以及 。

1. 会导致接口不一致或者奇怪比如 io.Reader 其实第┅个参数应该是 context，比如 Read(Context, []byte) 函数或者提供两套接口，一种带 Contex一种不带 Context。这个问题还蛮困扰人的一般在应用程序中，推荐第一个参数是 Context；

2. 紸意 Context 树如果因为 Closure 导致树越来越深，会有调用栈的性能问题比如十万个长链，会导致 CPU 占用 500% 左右

备注：关于对 Context 的批评，可以参考 作者覺得在标准库中加 context 作为第一个参数不能理解，比如 Read(ctx

Go 开发技术指南系列文章

本课程是由 CNCF 官方与阿里巴巴强强联合共同推出的以“云原生技術体系”为核心、以“技术解读”和“实践落地”并重的系列。

“关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生夶规模的落地实践做最懂云原生开发者的技术圈。”