189 8069 5689
1、服务器编程：以前你如果使用C或者C++做的那些事情，用Go来做很合适，例如处理日志、数据打包、虚拟机处理、文件系统等。
成都创新互联-专业网站定制、快速模板网站建设、高性价比辽源网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式辽源网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖辽源地区。费用合理售后完善，十余年实体公司更值得信赖。
2、分布式系统、数据库代理器、中间件：例如Etcd。
3、网络编程：这一块目前应用最广，包括Web应用、API应用、下载应用，而且Go内置的net/http包基本上把我们平常用到的网络功能都实现了。
4、开发云平台：目前国外很多云平台在采用Go开发，我们所熟知的七牛云、华为云等等都有使用Go进行开发并且开源的成型的产品。
5、区块链：目前有一种说法，技术从业人员把Go语言称作为区块链行业的开发语言。如果大家学习区块链技术的话，就会发现现在有很多很多的区块链的系统和应用都是采用Go进行开发的，比如ehtereum是目前知名度最大的公链，再比如fabric是目前最知名的联盟链，两者都有go语言的版本，且go-ehtereum还是以太坊官方推荐的版本。
自1.0版发布以来，go语言引起了众多开发者的关注，并得到了广泛的应用。go语言简单、高效、并发的特点吸引了许多传统的语言开发人员，其数量也在不断增加。
使用 Go 语言开发的开源项目非常多。早期的 Go 语言开源项目只是通过 Go 语言与传统项目进行C语言库绑定实现，例如 Qt、Sqlite 等。
后期的很多项目都使用 Go 语言进行重新原生实现，这个过程相对于其他语言要简单一些，这也促成了大量使用 Go 语言原生开发项目的出现。
《Go 语言程序设计》（Mark Summerfield）电子书网盘下载免费在线阅读
资源链接：
链接:
提取码: kqzi
书名：Go 语言程序设计
作者：Mark Summerfield
译者：许式伟
豆瓣评分：6.9
出版社：人民邮电出版社
出版年份：2013-8-1
页数：354
内容简介：
国外最经典的Go语言著作，Go语言编程的先驱者Mark Summerfield的实践经验总结。
这是一本Go语言实战指南，帮你了解Go语言，按Go语言的方式思考，以及使用Go语言来编写高性能软件。
作者展示了如何编写充分利用Go语言突破性的特性和惯用法的代码，以及Go语言在其他语言之上所做的改进，并着重强调了Go语言的关键创新。
注重实践教学，每章都提供了多个经过精心设计的代码示例。
由国内第一个核心服务完全采用Go语言实现的团队——七牛团队核心成员翻译。
作者简介：
Mark Summerfield Qtrac公司创始人，独立的培训讲师、顾问、技术编辑，Go、Python、C++、Qt和PyQt方面的技术作家。他的著作包括Rapid GUI Programming with Python and Qt、C++ GUI Programming with Qt 4（与Jasmin Blanchette合著）、Programming in Python 3和Advanced Qt Programming等。
许式伟——七牛云存储CEO，开源爱好者，发布过十余个C++开源项目，拥有超过15年的C/C++开发经验。
吕桂华——七牛云存储联合创始人，拥有十余年的C/C++大型项目开发经验，也曾在Java和.NET平台上探索多年。
徐 立——七牛云存储首席布道师，前盛大创新院高级研究员。
何李石——七牛云存储布道师。
七牛云存储技术团队是国内第一个核心服务完全采用Go语言实现的团队。
在现代web开发中，系统鉴权服务已是基本标配模块，有些开发框架甚至内置了鉴权模块的实现，或者提供一些鉴权的工具类，然而鉴权的方式也分为多种，了解各种鉴权方式的特点及使用场景可以帮助我们构建更健壮的web系统。以下列出四种常见的鉴权方式，我们来认识一下：
HTTP 基本身份验证，允许客户端在标准的 HTTP 头中发送用户名和密码。服务端可以验证这些信息，并确认客户端是否有权访问服务。这样做的好处在于，这是一种非常容易理解且得到广泛支持的协议。问题在于，通过 HTTP 有很高的风险，因为用户名和密码并没有以安全的方式发送。任何中间方都可以看到 HTTP 头的信息并读取里面的数据。因此，HTTP 基本身份验证通常应该通过 HTTPS 进行通信。
当使用 HTTPS 时，客户端获得强有力的保证，它所通信的服务端就是客户端想要通信的服务端。它给予我们额外的保护，避免人们窃听客户端和服务端之间的通信，或篡改有效负载。
服务端需要管理自己的SSL证书，当需要管理多台机器时会出现问题。一些组织自己承担签发证书的过程，这是一个额外的行政和运营负担。管理这方面的自动化工具远不够成熟，使用它们后你会发现，需要自己处理的事情就不止证书签发了。自签名证书不容易撤销，因此需要对灾难情景有更多的考虑。看看你是否能够避免自签名，以避开所有的这些工作。
SSL 之上的流量不能被反向代理服务器（比如 Varnish 或 Squid）所缓存，这是使用 HTTPS 的另一个缺点。这意味着，如果你需要缓存信息，就不得不在服务端或客户端内部实现。你可以在负载均衡中把 Https 的请求转成 Http 的请求，然后在负载均衡之后就可以使用缓存了。
还需要考虑，如果我们已经在使用现成的 SSO 方案（比如包含用户名密码信息的 SAML），该怎么办。我们想要基本身份验证使用同一套认证信息，然后在同一个进程里颁发和撤销吗？让服务与实现 SSO 所使用的那个目录服务进行通信即可做到这一点。或者，我们可以在服务内部存储用户名和密码，但需要承担存在重复行为的风险。
注意：使用这种方法，服务器只知道客户端有用户名和密码。我们不知道这个信息是否来自我们期望的机器；它可能来自网络中的其他人。
HTTP 基本身份验证是一种简单但不那么安全的认证方式，不太建议用于公开的商业应用，在此便不再展开，我们关注以下几种认证方式。
http协议是一种无状态的协议，如果没有任何认证机制，服务端对任何客户端的请求都是无差别的。在Web2.0时代，为了加强B/S交互的安全性，衍生出了Session-Cookie鉴权机制，通过在服务端开启会话，客户端存储SessionID，在每次请求时通过cookie传输SessionID的形式实现服务端基本鉴权。
cookie是保存在本地终端的数据。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
cookie的组成有：名称(key)、值(value)、有效域(domain)、路径(域的路径，一般设置为全局:"")、失效时间、安全标志(指定后，cookie只有在使用SSL连接时才发送到服务器(https))。
Session的中文翻译是“会话”，当用户打开某个web应用时，便与web服务器产生一次session。服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为SessionID），如果已包含则说明以前已经为此客户端创建过Session，服务器就按照SessionID把这个Session检索出来使用（检索不到，会新建一个），如果客户端请求不包含SessionID，则为此客户端创建一个Session并且生成一个与此Session相关联的SessionID，SessionID的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个SessionID将被在本次响应中返回给客户端保存。
保存这个SessionID的方式可以采用Cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个Cookie的名字都是类似于SEEESIONID。但Cookie可以被人为的禁止，则必须有其他机制以便在Cookie被禁止时仍然能够把SessionID传递回服务器。
客户端第一次发送请求给服务器，此时服务器启动Session会话，产生一个唯一的SessionID，并通过Response的SetCookie返回给客户端，保存于客户端(一般为浏览器)，并与一个浏览器窗口对应着,由于HTTP协议的特性，这一次Request-Response
后连接就断开了。以后此客户端再发送请求给服务器的时候，就会在请求Request头中携带cookie,由于cookie中带有Key为sessionID的数据,所以服务器就知道这是刚才那个客户端。
正如我们前面所讨论的，如果担心用户名和密码被泄露，HTTP基本身份验证使用普通 HTTP 并不是非常明智的。传统的替代方式是使用HTTPS路由通信，但也有一些缺点。除了需要管理证书，HTTPS通信的开销使得服务器压力增加，而且通信难以被轻松地缓存。另外Session-Cookie机制也会有被客户限制的隐患，如果用户禁用Cookie则必须由其它方式实现鉴权。
所谓Token，即令牌。客户端需要鉴权访问私人信息时，会首次向服务端发送身份验证信息（如用户名、密码），服务端校验正确后会根据一定的加密算法生成Token令牌发放给客户端，此后客户端只需通过Token，服务端只需验证Token就可识别客户并进行交互，Token可存放于HTTP Header也可存放与Cookie。
以上为一个简单的Token鉴权过程。
关于Token机制，业界有一种叫JWT（JsonWebToken）的实现机制，下面我们来了解JWT。
JWT.io 对JSON Web Tokens进行了很好的介绍，
国内阮一峰的 《JSON Web Token 入门教程》 也讲得非常好懂，可以出门右拐了解一下。
简而言之，它是一个签名的JSON对象，可以执行一些有用的操作（例如，身份验证）。它是一组字串，分Header（头部）、Payload（负载）、Signature（签名）三部分，由'.'号连接，看起来就像下面这样：
用户发送认证信息给服务端后，服务端通过JWT生成规则，生成JWT字串作为Token发放给用户，用户以后每次访问都在HTTP Header携带JWT字串，已达到鉴权目的。由于其内部携带用户信息，部分使用者已经发现其安全隐患，但其安全度不至于太过容易破解，在移动应用中的鉴权机制使用较多，除此之外，一些分布式的微服务应用也通过JWT进行模块间的鉴权，还是有一定的使用场景的。
Go开源社区已有比较成熟的JWT包实现： jwt-go ，内附有JWT编解码的使用用例，还是很好懂的，感兴趣的可get来使用。在另一篇中也做了Go 使用JWT鉴权的示例： 《Go 鉴权（三）：JWT》 ,感兴趣可阅读以下，自己也在项目中实践一下。
OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。同时，任何第三方都可以使用OAUTH认证服务，任何服务提供商都可以实现自身的OAUTH认证服务，因而OAUTH是开放的。
OpenID Connect 是 OAuth 2.0 具体实现中的一个标准。它使用简单的 REST 调用，因为提高了其易用性。对于一个面向公众的网站，你或许可以使用Google、Facebook、Github等作为提供者，国内可以使用QQ、微信、淘宝等作为提供者。但对于内部系统，或对于数据需要有更多控制权的系统而言，你会希望有自己的内部身份提供者。
OAuth2.0有四种授权模式，具体可看阮一峰的 《理解OAuth2.0》 ,其内容非常详细且好理解。
我们这里说一下最完整的授权码模式：
以上为OAuth2.0的认证过程。
各大厂都有提供基于OAuth2.0的三方授权服务，如QQ、微信、淘宝等等，有需要可移步到各自的开放平台查看文档，大都有提供Go的接口实现；另你也可参考使用Go官方提供实现的包 ，里面包含多数热门的OAuth客户端。
推荐使用 这个开源项目，帮助你构建自己的OAuth服务
《学习Go语言》百度网盘pdf最新全集下载:
链接:
?pwd=je9c 提取码: je9c
简介：Google工程师亲授，从学习语言语法特性到函数式编程、并发编程等等。理论与实战结合，帮助快速掌握Go语言。通过研读标准库等经典代码设计模式，启发读者深刻理解Go语言的核心思维，进入Go语言开发的更高阶段。
目前websocket技术已经很成熟，选型Go语言，当然是为了节省成本以及它强大的高并发性能。我使用的是第三方开源的websocket库即gorilla/websocket。
由于我们线上推送的量不小，推送后端需要部署多节点保持高可用，所以需要自己做集群，具体架构方案如图：
Auth Service：鉴权服务，根据Token验证用户权限。
Collect Service：消息采集服务，负责收集业务系统消息，存入MongoDB后，发送给消息分发服务。
Dispatch Service：消息分发服务，根据路由规则分发至对应消息推送服务节点上。
Push Service：消息推送服务，通过websocket将消息推送给用户。
集群推送的关键点在于，web端与服务端建立长连接之后，具体跟哪个推送节点保持长连接的，如果我们能够找到对应的连接节点，那么我们就可以将消息推送出去。下面讲解一下集群的大致流程：
1. web端用户登录之后，带上token与后端推送服务（Push Service）保持长连接。
2. 推送服务收到连接请求之后，携带token去鉴权服务（Auth Service）验证此token权限，并返回用户ID。
3. 把返回的用户ID与长连接存入本地缓存，保持用户ID与长连接绑定关系。
4. 再将用户ID与本推送节点IP存入redis，建立用户（即长连接）与节点绑定关系，并设置失效时间。
5. 采集服务（Collect Service）收集业务消息，首先存入mongodb，然后将消息透传给分发服务（Dispatch Service）。
6. 分发服务收到消息之后，根据消息体中的用户ID，从redis中获取对应的推送服务节点IP，然后转发给对应的推送节点。
7. 推送服务节点收到消息之后，根据用户ID，从本地缓存中取出对应的长连接，将消息推送给客户端。
其他注意事项：
技术栈 gin+jwt
鉴权流程：
调用token生成方法GenerateToken生成token, 请求api时带上token参数即可
token计算逻辑：
总结：md5加密账号和密码参数，根据账号密码私钥过期时间和jwt header 分别计算hash256值，将值用.符号连接，再进行hash,结果就是token值
api 验证token: