锐客网

  1. 首页 > 生活百科 > it技术 > >

Go语言设计理念 go语言的设计思想

错误IT技术

Go 语言的错误处理机制是一个优秀的设计吗这个问题说来话长 ， 我先表达一下我的观点，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分为两类 ， 区别处理异常
在捕获到异常时，需要尽可能的保留第一现场的关键数据
以上仅为一家之言，抛砖引玉，希望对大家有所帮助 。
Go语言设计与实现（上）基本设计思路：
类型转换、类型断言、动态派发 。iface，eface 。
反射对象具有的方法：
编译优化：
内部实现：
实现 Context 接口有以下几个类型（空实现就忽略了）：
互斥锁的控制逻辑：
设计思路：
（以上为写被读阻塞，下面是读被写阻塞）
总结，读写锁的设计还是非常巧妙的：
设计思路：
WaitGroup 有三个暴露的函数:
部件：
设计思路：
结构：
Once 只暴露了一个方法：
实现：
三个关键点：
细节：
让多协程任务的开始执行时间可控（按顺序或归一） 。（Context 是控制结束时间）
设计思路： 通过一个锁和内置的 notifyList 队列实现，Wait() 会生成票据 ， 并将等待协程信息加入链表中，等待控制协程中发送信号通知一个（Signal()）或所有（Boardcast()）等待者（内部实现是通过票据通知的）来控制协程解除阻塞 。
暴露四个函数：
【Go语言设计理念 go语言的设计思想】 实现细节：
部件：
包： 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 团队实施了一个看起来比较稳定的设计草案，并且正以源到源翻译器原型的形式获得关注 。本文讲述的是泛型的最新设计，以及如何自己尝试泛型 。
例子
FIFO Stack
假设你要创建一个先进先出堆栈 。没有泛型，你可能会这样实现：
type Stack []interface{}func (s Stack) Peek() interface{} {
return s[len(s)-1]
}
func (s *Stack) Pop() {
*s = (*s)[:
len(*s)-1]
}
func (s *Stack) Push(value interface{}) {
*s =
append(*s, value)
}
但是 ， 这里存在一个问题：每当你 Peek 项时，都必须使用类型断言将其从 interface{} 转换为你需要的类型 。如果你的堆栈是 *MyObject 的堆栈，则意味着很多 s.Peek().(*MyObject)这样的代码 。这不仅让人眼花缭乱，而且还可能引发错误 。比如忘记 * 怎么办？或者如果您输入错误的类型怎么办？s.Push(MyObject{})` 可以顺利编译，而且你可能不会发现到自己的错误，直到它影响到你的整个服务为止 。
通常，使用 interface{} 是相对危险的 。使用更多受限制的类型总是更安全，因为可以在编译时而不是运行时发现问题 。
泛型通过允许类型具有类型参数来解决此问题：
type Stack(type T) []Tfunc (s Stack(T)) Peek() T {
return s[len(s)-1]
}
func (s *Stack(T)) Pop() {
*s = (*s)[:
len(*s)-1]
}
func (s *Stack(T)) Push(value T) {
*s =
append(*s, value)
}
这会向 Stack 添加一个类型参数，从而完全不需要 interface{} 。现在，当你使用 Peek() 时 ， 返回的值已经是原始类型，并且没有机会返回错误的值类型 。这种方式更安全，更容易使用 。（译注：就是看起来更丑陋 ， ^-^）
此外 ， 泛型代码通常更易于编译器优化，从而获得更好的性能（以二进制大小为代价） 。如果我们对上面的非泛型代码和泛型代码进行基准测试，我们可以看到区别：
type MyObject struct {
X
int
}
var sink MyObjectfunc BenchmarkGo1(b *testing.B) {
for i := 0; ib.N; i{
var s Stack
s.Push(MyObject{})
s.Push(MyObject{})
s.Pop()
sink = s.Peek().(MyObject)
}
}
func BenchmarkGo2(b *testing.B) {
for i := 0; ib.N; i{
var s Stack(MyObject)
s.Push(MyObject{})
s.Push(MyObject{})
s.Pop()
sink = s.Peek()
}
}
结果：
BenchmarkGo1BenchmarkGo1-161283752887.0 ns/op48 B/op2 allocs/opBenchmarkGo2BenchmarkGo2-162840647941.9 ns/op24 B/op2 allocs/op
在这种情况下 ， 我们分配更少的内存，同时泛型的速度是非泛型的两倍 。
合约（Contracts）
上面的堆栈示例适用于任何类型 。但是，在许多情况下，你需要编写仅适用于具有某些特征的类型的代码 。例如，你可能希望堆栈要求类型实现 String() 函数
Go语言设计理念的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于go语言的设计思想、Go语言设计理念的信息别忘了在本站进行查找喔 。

    推荐阅读


    上一篇：mysql 连接配置 mysql配置数据库连接

    下一篇：虚拟服务器端口号 虚拟服务器端口怎么看