Go在微服务框架中有其独特的优势，至于优势在哪，自行google。
1、GoKit框架
这是一个工具包的集合，可以帮助攻城狮构建强大、可靠和可维护的微服务。提供了用于实现系统监控和弹性模式组件的库，例如日志、跟踪、限流、熔断等。
基于这个框架的应用程序架构由三个主要的部分组成：
传输层：用于网络通信，服务通常使用HTTP或者gRPC等网络传输协议，或者使用NATS等发布订阅系统相互通信。
接口层：是服务器和客户端的基本构建块。每个对外提供的接口方法都会定义为一个Endpoint，一遍在服务器和客户端之间进行网络通信，每个端点使用传输层通过HTTP或gRPC等具体通信模式对外提供服务
服务成：具体的业务逻辑实现
2、GoMicro框架
这是一个基于Go语言实现的插件化RPC微服务框架。提供了服务发现、负载均衡、同步传输、异步通信以及事件驱动等机制，尝试简化分布式系统之间的通信，让开发者更专注于自身业务逻辑的开发。
GoMicro的设计哲学是可插拔的架构理念，提供了可快速构建系统的组件，并且可以根据自身的需求对GoMicro提供的默认实现进行定制。所有插件都可在仓库github.com/micro/go-plugins 中找到。
Go作为Google2009年推出的语言，其被设计成一门应用于搭载 Web 服务器，存储集群或类似用途的巨型中央服务器的系统编程语言。
对于高性能分布式系统领域而言，Go 语言无疑比大多数其它语言有着更高的开发效率。它提供了海量并行的支持，这对于 游戏 服务端的开发而言是再好不过了。
到现在Go的开发已经是完全开放的，并且拥有一个活跃的社区。
=================================
哪些大公司在使用Go语言：
1、Google
这个不用多做介绍，作为开发Go语言的公司，当仁不让。Google基于Go有很多优秀的项目，比如：https://github.com/kubernetes/kubernetes ，大家也可以在Github上 https://github.com/google/ 查看更多Google的Go开源项目。
2、Facebook
Facebook也在用，为此他们还专门在Github上建立了一个开源组织facebookgo，大家可以通过 https://github.com/facebookgo 访问查看facebook开源的项目，比如著名的是平滑升级的grace。
3、腾讯
腾讯作为国内的大公司，还是敢于尝试的，尤其是Docker容器化这一块，他们在15年已经做了docker万台规模的实践，具体可以参考http://www.infoq.com/cn/articles/tencent-millions-scale-docker-application-practice
4、百度
目前所知的百度的使用是在运维这边，是百度运维的一个BFE项目，负责前端流量的接入。他们的负责人在2016年有分享，大家可以看下这个http://www.infoq.com/cn/presentations/application-of-golang-in-baidu-frontend
5、阿里
阿里巴巴具体的项目不太清楚，不过听说其系统部门、CDN等正在招Go方面的人。
6、京东
京东云消息推送系统、云存储，以及京东商城等都有使用Go做开发。
7、小米
小米对Golang的支持，莫过于运维监控系统的开源，也就是 http://open-falcon.com/
此外，小米互娱、小米商城、小米视频、小米生态链等团队都在使用Golang。
8、360
360对Golang的使用也不少，一个是开源的日志搜索系统Poseidon，托管在Github上，https://github.com/Qihoo360/poseidon
==================================
Go适合做什么？为何这么多人偏爱Go语言？
Go强大的开发团队
1、自由高效：组合的思想、无侵入式的接口
Go语言可以说是开发效率和运行效率二者的完美融合，天生的并发编程支持。Go语言支持当前所有的编程范式，包括过程式编程、面向对象编程以及函数式编程。程序员们可以各取所需、自由组合、想怎么玩就怎么玩。
2、强大的标准库
这包括互联网应用、系统编程和网络编程。Go里面的标准库基本上已经是非常稳定了，特别是我这里提到的三个，网络层、系统层的库非常实用。
3、部署方便：二进制文件、Copy部署
我相信这一点是很多人选择Go的最大理由，因为部署太方便了，所以现在也有很多人用Go开发运维程序。
4、简单的并发
它包含了降低心智的并发和简易的数据同步，我觉得这是Go最大的特色。之所以写正确的并发、容错和可扩展的程序如此之难，是因为我们用了错误的工具和错误的抽象，Go可以说这一块做的相当简单。
5、稳定性
Go拥有强大的编译检查、严格的编码规范和完整的软件生命周期工具，具有很强的稳定性，稳定压倒一切。那么为什么Go相比于其他程序会更稳定呢？这是因为Go提供了软件生命周期（开发、测试、部署、维护等等）的各个环节的工具，如go tool、gofmt、go test。
================================
我们为什么选择GO语言
选择GO语言，主要是基于两方面的考虑
1. 执行性能 缩短API的响应时长，解决批量请求访问超时的问题。在Uwork的业务场景下，一次API批量请求，往往会涉及对另外接口服务的多次调用，而在之前的PHP实现模式下，要做到并行调用是非常困难的，串行处理却不能从根本上提高处理性能。而GO语言不一样，通过协程可以方便的实现API的并行处理，达到处理效率的最大化。 依赖Golang的高性能HTTP Server，提升系统吞吐能力，由PHP的数百级别提升到数千里甚至过万级别。
2. 开发效率 GO语言使用起来简单、代码描述效率高、编码规范统一、上手快。 通过少量的代码，即可实现框架的标准化，并以统一的规范快速构建API业务逻辑。 能快速的构建各种通用组件和公共类库，进一步提升开发效率，实现特定场景下的功能量产。
Go语言近两年的发展速度还是非常快的，一方面Go语言有强大的行业背书，另一方面Go语言在设计时充分考虑了当前的编程环境，加强了大数据量、高并发等应用场景的处理能力，强调编程语言自身对于处理性能的追求，相信Go语言在未来大数据和人工智能相关技术逐渐落地应用的背景下，会有一个较为广阔的发展空间。
这个问题说来话长，我先表达一下我的观点，Go语言从语法层面提供区分错误和异常的机制是很好的做法，比自己用单个返回值做值判断要方便很多。上面看到很多知乎大牛把异常和错误混在一起说，有认为Go没有异常机制的，有认为Go纯粹只有异常机制的，我觉得这些观点都太片面了。
具体对于错误和异常的讨论，我转发一下前阵子写的一篇日志抛砖引玉吧。
============================
最近连续遇到朋友问我项目里错误和异常管理的事情，之前也多次跟团队强调过错误和异常管理的一些概念，所以趁今天有动力就赶紧写一篇Go语言项目错误和异常管理的经验分享。
首先我们要理清：什么是错误、什么是异常、为什么需要管理。然后才是怎样管理。
错误和异常从语言机制上面讲，就是error和panic的区别，放到别的语言也一样，别的语言没有error类型，但是有错误码之类的，没有panic，但是有throw之类的。
在语言层面它们是两种概念，导致的是两种不同的结果。如果程序遇到错误不处理，那么可能进一步的产生业务上的错误，比如给用户多扣钱了，或者进一步产生了异常；如果程序遇到异常不处理，那么结果就是进程异常退出。
在项目里面是不是应该处理所有的错误情况和捕捉所有的异常呢？我只能说，你可以这么做，但是估计效果不会太好。我的理由是：
如果所有东西都处理和记录，那么重要信息可能被淹没在信息的海洋里。
不应该处理的错误被处理了，很容易导出BUG暴露不出来，直到出现更严重错误的时候才暴露出问题，到时候排查就很困难了，因为已经不是错误的第一现场。
所以错误和异常最好能按一定的规则进行分类和管理，在第一时间能暴露错误和还原现场。
对于错误处理，Erlang有一个很好的概念叫速错，就是有错误第一时间暴露它。我们的项目从Erlang到Go一直是沿用这一设计原则。但是应用这个原则的前提是先得区分错误和异常这两个概念。
错误和异常上面已经提到了，从语言机制层面比较容易区分它们，但是语言取决于人为，什么情况下用错误表达，什么情况下用异常表达，就得有一套规则，否则很容易出现全部靠异常来做错误处理的情况，似乎Java项目特别容易出现这样的设计。
这里我先假想有这样一个业务：游戏玩家通过购买按钮，用铜钱购买宝石。
在实现这个业务的时候，程序逻辑会进一步分化成客户端逻辑和服务端逻辑，客户端逻辑又进一步因为设计方式的不同分化成两种结构：胖客户端结构、瘦客户端结构。
胖客户端结构，有更多的本地数据和懂得更多的业务逻辑，所以在胖客户端结构的应用中，以上的业务会实现成这样：客户端检查缓存中的铜钱数量，铜钱数量足够的时候购买按钮为可用的亮起状态，用户点击购买按钮后客户端发送购买请求到服务端；服务端收到请求后校验用户的铜钱数量，如果铜钱数量不足就抛出异常，终止请求过程并断开客户端的连接，如果铜钱数量足够就进一步完成宝石购买过程，这里不继续描述正常过程。
因为正常的客户端是有一步数据校验的过程的，所以当服务端收到不合理的请求（铜钱不足以购买宝石）时，抛出异常比返回错误更为合理，因为这个请求只可能来自两种客户端：外挂或者有BUG的客户端。如果不通过抛出异常来终止业务过程和断开客户端连接，那么程序的错误就很难被第一时间发现，攻击行为也很难被发现。
我们再回头看瘦客户端结构的设计，瘦客户端不会存有太多状态数据和用户数据也不清楚业务逻辑，所以客户端的设计会是这样：用户点击购买按钮，客户端发送购买请求；服务端收到请求后检查铜钱数量，数量不足就返回数量不足的错误码，数量足够就继续完成业务并返回成功信息；客户端收到服务端的处理结果后，在界面上做出反映。
在这种结构下，铜钱不足就变成了业务逻辑范围内的一种失败情况，但不能提升为异常，否则铜钱不足的用户一点购买按钮都会出错掉线。
所以，异常和错误在不同程序结构下是互相转换的，我们没办法一句话的给所有类型所有结构的程序一个统一的异常和错误分类规则。
但是，异常和错误的分类是有迹可循的。比如上面提到的痩客户端结构，铜钱不足是业务逻辑范围内的一种失败情况，它属于业务错误，再比如程序逻辑上尝试请求某个URL，最多三次，重试三次的过程中请求失败是错误，重试到第三次，失败就被提升为异常了。
所以我们可以这样来归类异常和错误：不会终止程序逻辑运行的归类为错误，会终止程序逻辑运行的归类为异常。
因为错误不会终止逻辑运行，所以错误是逻辑的一部分，比如上面提到的瘦客户端结构，铜钱不足的错误就是业务逻辑处理过程中需要考虑和处理的一个逻辑分支。而异常就是那些不应该出现在业务逻辑中的东西，比如上面提到的胖客户端结构，铜钱不足已经不是业务逻辑需要考虑的一部分了，所以它应该是一个异常。
错误和异常的分类需要通过一定的思维训练来强化分类能力，就类似于面向对象的设计方式一样的，技术实现就摆在那边，但是要用好需要不断的思维训练不断的归类和总结，以上提到的归类方式希望可以作为一个参考，期待大家能发现更多更有效的归类方式。
接下来我们讲一下速错和Go语言里面怎么做到速错。
速错我最早接触是在做http://ASP.NET的时候就体验到的，当然跟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分为两类，区别处理异常
在捕获到异常时，需要尽可能的保留第一现场的关键数据
以上仅为一家之言，抛砖引玉，希望对大家有所帮助。
