189 8069 5689
Go语言由Google公司开发，并于2009年开源，相比Java/Python/C等语言，Go尤其擅长并发编程，性能堪比C语言，开发效率肩比Python，被誉为“21世纪的C语言”。
创新互联于2013年开始，先为河口等服务建站，河口等地企业，进行企业商务咨询服务。为河口企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
Go语言在云计算、大数据、微服务、高并发领域应用应用非常广泛。BAT大厂正在把Go作为新项目开发的首选语言。
Go语言能干什么?
1、服务端开发：以前你使用C或者C++做的那些事情，用Go来做很合适，例如日志处理、文件系统、监控系统等;
2、DevOps：运维生态中的Docker、K8s、prometheus、grafana、open-falcon等都是使用Go语言开发;
3、网络编程：大量优秀的Web框架如Echo、Gin、Iris、beego等，而且Go内置的 net/http包十分的优秀;
4、Paas云平台领域：Kubernetes和Docker Swarm等;
5、分布式存储领域：etcd、Groupcache、TiDB、Cockroachdb、Influxdb等;
6、区块链领域：区块链里面有两个明星项目以太坊和fabric都使用Go语言;
7、容器虚拟化：大名鼎鼎的Docker就是使用Go语言实现的;
8、爬虫及大数据：Go语言天生支持并发，所以十分适合编写分布式爬虫及大数据处理。
在前一小节中介绍了点亮第一个LED灯，这里我们准备进阶尝试下，输出第一段PWM波形。（PWM也就是脉宽调制，一种可调占空比的技术，得到的效果就是：如果用示波器测量引脚会发现有方波输出，而且高电平、低电平的时间是可调的。）
这里爪爪熊准备写成一个golang的库，并开源到github上，后续更新将直接更新到github中，如果你有兴趣可以和我联系。 github.com/dpawsbear/bear_rpi_go
我在很多的教程中都看到说树莓派的PWM（硬件）只有一个GPIO能够输出，就是 GPIO1 。这可是不小的打击，因为我想使用至少四个 PWM ，还是不死心，想通过硬件手册上找寻蛛丝马迹，看看究竟怎么回事。
手册上找寻东西稍等下讲述，这里先提供一种方法测试 树莓派3B 的 PWM 方法：用指令控制硬件PWM。
这里通过指令的方式掌握了基本的pwm设置技巧，决定去翻一下手册看看到底PWM怎么回事，这里因为没有 BCM2837 的手册，根据之前文章引用官网所说， BCM2835 和 BCM2837 应该是一样的。这里我们直接翻阅 BCM2835 的手册，直接找到 PWM 章节。找到了如下图：
图中可以看到在博通的命名规则中 GPIO 12、13、18、19、40、41、45、52、53 均可以作为PWM输出。但是只有两路PWM0 PWM1。根据我之前所学知识，不出意外应该是PWM0 和 PWM1可以输出不一样的占空比，但是频率应该是一样的。因为没有示波器，暂时不好测试。先找到下面对应图：
根据以上两个图对比可以发现如下规律：
对照上面的表可以看出从 BCM2837 中印出来的能够使用在PWM上的就这几个了。
为了验证个人猜想是否正确，这里先直接使用指令的模式，模拟配置下是否能够正常输出。
通过上面一系列指令模拟发现，（GPIO1、GPIO26）、（GPIO23、GPIO24）是绑定在一起的，调节任意一个，另外一个也会发生变化。也即是PWM0、PWM1虽然输出了两路，可以理解成两路其实都是连在一个输出口上。这里由于没有示波器或者逻辑分析仪这类设备（仅有一个LED灯），所以测试很简陋，下一步是使用示波器这类东西对频率以及信号稳定性进行下测试。
小节：树莓派具有四路硬件输出PWM能力，但是四路中只能输出两个独立（占空比独立）的PWM，同时四路输出的频率均是恒定的。
上面大概了解清楚了树莓派3B的PWM结构，接下来就是探究如何使用Go语言进行设置。
因为拿到了手册，这里我想直接操作寄存器的方式进行设置，也是顺便学习下Go语言处理寄存器的过程。首先需要拿到pwm 系列寄存器的基地址，但是翻了一圈手册，发现只有偏移，没有找到基地址。
经过了一段时间的努力后，决定写一个 树莓派3B golang包开源放在github上，只需要写相关程序进行调用就可以了，以下是相关demo（pwm）（在GPIO.12 上输出PWM波，放上LED灯会有呼吸灯的效果，具体多少频率还没有进行测试）
以下是demo(pwm) 源码
基本设计思路：
类型转换、类型断言、动态派发。iface，eface。
反射对象具有的方法：
编译优化：
内部实现：
实现 Context 接口有以下几个类型（空实现就忽略了）：
互斥锁的控制逻辑：
设计思路：
（以上为写被读阻塞，下面是读被写阻塞）
总结，读写锁的设计还是非常巧妙的：
设计思路：
WaitGroup 有三个暴露的函数:
部件：
设计思路：
结构：
Once 只暴露了一个方法：
实现：
三个关键点：
细节：
让多协程任务的开始执行时间可控（按顺序或归一）。（Context 是控制结束时间）
设计思路： 通过一个锁和内置的 notifyList 队列实现，Wait() 会生成票据，并将等待协程信息加入链表中，等待控制协程中发送信号通知一个（Signal()）或所有（Boardcast()）等待者（内部实现是通过票据通知的）来控制协程解除阻塞。
暴露四个函数：
实现细节：
部件：
包： golang.org/x/sync/errgroup
作用：开启 func() error 函数签名的协程，在同 Group 下协程并发执行过程并收集首次 err 错误。通过 Context 的传入，还可以控制在首次 err 出现时就终止组内各协程。
设计思路：
结构：
暴露的方法：
实现细节：
注意问题：
包： "golang.org/x/sync/semaphore"
作用：排队借资源（如钱，有借有还）的一种场景。此包相当于对底层信号量的一种暴露。
设计思路：有一定数量的资源 Weight，每一个 waiter 携带一个 channel 和要借的数量 n。通过队列排队执行借贷。
结构：
暴露方法：
细节：
部件：
细节：
包： "golang.org/x/sync/singleflight"
作用：防击穿。瞬时的相同请求只调用一次，response 被所有相同请求共享。
设计思路：按请求的 key 分组（一个 *call 是一个组，用 map 映射存储组），每个组只进行一次访问，组内每个协程会获得对应结果的一个拷贝。
结构：
逻辑：
细节：
部件：
如有错误，请批评指正。
这个问题说来话长，我先表达一下我的观点，Go语言从语法层面提供区分错误和异常的机制是很好的做法，比自己用单个返回值做值判断要方便很多。
上面看到很多知乎大牛把异常和错误混在一起说，有认为Go没有异常机制的，有认为Go纯粹只有异常机制的，我觉得这些观点都太片面了。
具体对于错误和异常的讨论，我转发一下前阵子写的一篇日志抛砖引玉吧。
============================
最近连续遇到朋友问我项目里错误和异常管理的事情，之前也多次跟团队强调过错误和异常管理的一些概念，所以趁今天有动力就赶紧写一篇Go语言项目错误和异常管理的经验分享。
首先我们要理清：什么是错误、什么是异常、为什么需要管理。然后才是怎样管理。
错误和异常从语言机制上面讲，就是error和panic的区别，放到别的语言也一样，别的语言没有error类型，但是有错误码之类的，没有panic，但是有throw之类的。
在语言层面它们是两种概念，导致的是两种不同的结果。如果程序遇到错误不处理，那么可能进一步的产生业务上的错误，比如给用户多扣钱了，或者进一步产生了异常；如果程序遇到异常不处理，那么结果就是进程异常退出。
在项目里面是不是应该处理所有的错误情况和捕捉所有的异常呢？我只能说，你可以这么做，但是估计效果不会太好。我的理由是：
如果所有东西都处理和记录，那么重要信息可能被淹没在信息的海洋里。
不应该处理的错误被处理了，很容易导出BUG暴露不出来，直到出现更严重错误的时候才暴露出问题，到时候排查就很困难了，因为已经不是错误的第一现场。
所以错误和异常最好能按一定的规则进行分类和管理，在第一时间能暴露错误和还原现场。
对于错误处理，Erlang有一个很好的概念叫速错，就是有错误第一时间暴露它。我们的项目从Erlang到Go一直是沿用这一设计原则。但是应用这个原则的前提是先得区分错误和异常这两个概念。
错误和异常上面已经提到了，从语言机制层面比较容易区分它们，但是语言取决于人为，什么情况下用错误表达，什么情况下用异常表达，就得有一套规则，否则很容易出现全部靠异常来做错误处理的情况，似乎Java项目特别容易出现这样的设计。
这里我先假想有这样一个业务：游戏玩家通过购买按钮，用铜钱购买宝石。
在实现这个业务的时候，程序逻辑会进一步分化成客户端逻辑和服务端逻辑，客户端逻辑又进一步因为设计方式的不同分化成两种结构：胖客户端结构、瘦客户端结构。
胖客户端结构，有更多的本地数据和懂得更多的业务逻辑，所以在胖客户端结构的应用中，以上的业务会实现成这样：客户端检查缓存中的铜钱数量，铜钱数量足够的时候购买按钮为可用的亮起状态，用户点击购买按钮后客户端发送购买请求到服务端；服务端收到请求后校验用户的铜钱数量，如果铜钱数量不足就抛出异常，终止请求过程并断开客户端的连接，如果铜钱数量足够就进一步完成宝石购买过程，这里不继续描述正常过程。
因为正常的客户端是有一步数据校验的过程的，所以当服务端收到不合理的请求（铜钱不足以购买宝石）时，抛出异常比返回错误更为合理，因为这个请求只可能来自两种客户端：外挂或者有BUG的客户端。如果不通过抛出异常来终止业务过程和断开客户端连接，那么程序的错误就很难被第一时间发现，攻击行为也很难被发现。
我们再回头看瘦客户端结构的设计，瘦客户端不会存有太多状态数据和用户数据也不清楚业务逻辑，所以客户端的设计会是这样：用户点击购买按钮，客户端发送购买请求；服务端收到请求后检查铜钱数量，数量不足就返回数量不足的错误码，数量足够就继续完成业务并返回成功信息；客户端收到服务端的处理结果后，在界面上做出反映。
在这种结构下，铜钱不足就变成了业务逻辑范围内的一种失败情况，但不能提升为异常，否则铜钱不足的用户一点购买按钮都会出错掉线。
所以，异常和错误在不同程序结构下是互相转换的，我们没办法一句话的给所有类型所有结构的程序一个统一的异常和错误分类规则。
但是，异常和错误的分类是有迹可循的。比如上面提到的痩客户端结构，铜钱不足是业务逻辑范围内的一种失败情况，它属于业务错误，再比如程序逻辑上尝试请求某个URL，最多三次，重试三次的过程中请求失败是错误，重试到第三次，失败就被提升为异常了。
所以我们可以这样来归类异常和错误：不会终止程序逻辑运行的归类为错误，会终止程序逻辑运行的归类为异常。
因为错误不会终止逻辑运行，所以错误是逻辑的一部分，比如上面提到的瘦客户端结构，铜钱不足的错误就是业务逻辑处理过程中需要考虑和处理的一个逻辑分支。而异常就是那些不应该出现在业务逻辑中的东西，比如上面提到的胖客户端结构，铜钱不足已经不是业务逻辑需要考虑的一部分了，所以它应该是一个异常。
错误和异常的分类需要通过一定的思维训练来强化分类能力，就类似于面向对象的设计方式一样的，技术实现就摆在那边，但是要用好需要不断的思维训练不断的归类和总结，以上提到的归类方式希望可以作为一个参考，期待大家能发现更多更有效的归类方式。
接下来我们讲一下速错和Go语言里面怎么做到速错。
速错我最早接触是在做的时候就体验到的，当然跟Erlang的速错不完全一致，那时候也没有那么高大上的一个名字，但是对待异常的理念是一样的。
在.NET项目开发的时候，有经验的程序员都应该知道，不能随便re-throw，就是catch错误再抛出，原因是异常的第一现场会被破坏，堆栈跟踪信息会丢失，因为外部最后拿到异常的堆栈跟踪信息，是最后那次throw的异常的堆栈跟踪信息；其次，不能随便try catch，随便catch很容易导出异常暴露不出来，升级为更严重的业务漏洞。
到了Erlang时期，大家学到了速错概念，简单来讲就是：让它挂。只有挂了你才会第一时间知道错误，但是Erlang的挂，只是Erlang进程的异常退出，不会导致整个Erlang节点退出，所以它挂的影响层面比较低。
在Go语言项目中，虽然有类似Erlang进程的Goroutine，但是Goroutine如果panic了，并且没有recover，那么整个Go进程就会异常退出。所以我们在Go语言项目中要应用速错的设计理念，就要对Goroutine做一定的管理。
在我们的游戏服务端项目中，我把Goroutine按挂掉后的结果分为两类：1、挂掉后不影响其他业务或功能的；2、挂掉后业务就无法正常进行的。
第一类Goroutine典型的有：处理各个玩家请求的Goroutine，因为每个玩家连接各自有一个Goroutine，所以挂掉了只会影响单个玩家，不会影响整体业务进行。
第二类Goroutine典型的有：数据库同步用的Goroutine，如果它挂了，数据就无法同步到数据库，游戏如果继续运行下去只会导致数据回档，还不如让整个游戏都异常退出。
这样一分类，就可以比较清楚哪些Goroutine该做recover处理，哪些不该做recover处理了。
那么在做recover处理时，要怎样才能尽量保留第一现场来帮组开发者排查问题原因呢？我们项目中通常是会在最外层的recover中把错误和堆栈跟踪信息记进日志，同时把关键的业务信息，比如：用户ID、来源IP、请求数据等也一起记录进去。
为此，我们还特地设计了一个库，用来格式化输出堆栈跟踪信息和对象信息，项目地址：funny/debug · GitHub
通篇写下来发现比我预期的长很多，所以这里我做一下归纳总结，帮组大家理解这篇文章所要表达的：
错误和异常需要分类和管理，不能一概而论
错误和异常的分类可以以是否终止业务过程作为标准
错误是业务过程的一部分，异常不是
不要随便捕获异常，更不要随便捕获再重新抛出异常
Go语言项目需要把Goroutine分为两类，区别处理异常
在捕获到异常时，需要尽可能的保留第一现场的关键数据
以上仅为一家之言，抛砖引玉，希望对大家有所帮助。
1、简单易学。
Go语言的作者本身就很懂C语言，所以同样Go语言也会有C语言的基因，所以对于程序员来说，Go语言天生就会让人很熟悉，容易上手。
2、并发性好。
Go语言天生支持并发，可以充分利用多核，轻松地使用并发。 这是Go语言最大的特点。
描述
Go的语法接近C语言，但对于变量的声明有所不同。Go支持垃圾回收功能。Go的并行模型是以东尼·霍尔的通信顺序进程（CSP）为基础，采取类似模型的其他语言包括Occam和Limbo，但它也具有Pi运算的特征，比如通道传输。
在1.8版本中开放插件（Plugin）的支持，这意味着现在能从Go中动态加载部分函数。
与C++相比，Go并不包括如枚举、异常处理、继承、泛型、断言、虚函数等功能，但增加了 切片(Slice) 型、并发、管道、垃圾回收、接口（Interface）等特性的语言级支持。