原文: Golang调度器源码分析, 作者: 无心之祸
[译]Go 调度器: M, P 和 G
这是另一篇关于Go调度器(scheduler)的文章。 原文: GO SCHEDULER: MS, PS & GS by Uber工程师 Povilas。
网上已经有很多关于Go调度器的文章了， 比如Golang调度器源码分析,多看一些，可以加深记忆，也可以对比查看文章中是否有不准确的地方,更全面的了解Go的调度器。
我决定深入了解Go的内部机制， 因为很长时间没人写关于Go scheduler的文章了， 我觉得这是一个很有趣的知识点，所以让我们开始吧。
[转]Spring 5 新功能：函数式 Web 框架
英文原文：New in Spring 5: Functional Web Framework by
中文翻译: Spring 5 新功能：函数式 Web 框架 by 开源中国
就像在昨天Juergen发布的博客的一样，Spring 5.0框架第二个里程碑版本中介绍了一个新的函数式web框架。在这篇文章中，我将更详细的介绍这个框架。
紧记该函数式web框架是在Spring5.0第一个里程碑版本基础上构建的。并且我们依旧提供基于注解的请求处理（例如@Controller,@RequestMapping)，关于基于注解的请求处理部分的相关信息请查阅关于Spring5.0第一个里程碑版本的博客。
Go HTTP Redirect的知识点总结
HTTP 规范中定义了返回码为 3xx 代表客户端需要做一些额外的工作来完成请求，大部分3xx用来做转发(redirect)。
状态码的详细说明可以参照规范或者 wikipedia、维基百科, 以下是代码的简短介绍。
- 300 Multiple Choices: 返回多个可供选择的资源
- 301 Moved Permanently: 请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一
- 302 Found: 请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求,HTTP 1.0中的意义是
Moved Temporarily,但是很多浏览器的实现是按照303的处实现的，所以HTTP 1.1中增加了 303和307的状态码来区分不同的行为 - 303 See Other (since HTTP/1.1): 对应当前请求的响应可以在另一个URI上被找到，而且客户端应当采用GET的方式访问那个资源
- 304 Not Modified (RFC 7232): 请求的资源没有改变
- 305 Use Proxy (since HTTP/1.1): 被请求的资源必须通过指定的代理才能被访问
- 306 Switch Proxy: 在最新版的规范中，306状态码已经不再被使用
- 307 Temporary Redirect (since HTTP/1.1): 请求的资源现在临时从不同的URI响应请求,和303不同，它还是使用原先的Method
- 308 Permanent Redirect (RFC 7538): 请求的资源已永久移动到新位置,并且新请求的Method不能改变
Go 的 http 库在实现的过程中也在不断的完成和修改其中的Bug,在 1.8版本中解决了前面版本中实现的问题 (你可以在 Go issues中搜索 redirect 来查看相关的issue)。 本文梳理了 Go 中 Redirect 的相关知识，以便你在遇到转发的问题时心中有数。
gRPC的那些事 - interceptor
gRPC-Go 增加了拦截器(interceptor)的功能， 就像Java Servlet中的 filter一样，可以对RPC的请求和响应进行拦截处理，而且既可以在客户端进行拦截，也可以对服务器端进行拦截。
利用拦截器，可以对gRPC进行扩展，利用社区的力量将gRPC发展壮大，也可以让开发者更灵活地处理gRPC流程中的业务逻辑。下面列出了利用拦截器实现的一些功能框架：
Go Web 框架性能比拼 2017 春季版
谁是最快的Go Web框架?, 这是我去年发布的Go web 框架的评测。现在一年过去了，有些框架因为缺乏维护而被放弃了，又有新的轮子被创造出来，既有的轮子也在不停的演化升级，来去之间，Go的版本也已经升级的1.8了。 青年节前， kirillDanshin提了一个issue,希望能更新最新的测试结果，现在这篇文章就记录了最新的测试结果。
gRPC的那些事 - streaming
gRPC是一个高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。 gRPC提供了一种简单的方法来精确地定义服务和为iOS、Android和后台支持服务自动生成可靠性很强的客户端功能库。 客户端充分利用高级流和链接功能，从而有助于节省带宽、降低的TCP链接次数、节省CPU使用、和电池寿命。
gRPC具有以下重要特征：
强大的IDL特性 RPC使用ProtoBuf来定义服务，ProtoBuf是由Google开发的一种数据序列化协议，性能出众，得到了广泛的应用。
支持多种语言 支持C++、Java、Go、Python、Ruby、C#、Node.js、Android Java、Objective-C、PHP等编程语言。 3.基于HTTP/2标准设计
gRPC已经应用在Google的云服务和对外提供的API中。
gRPC开发起来非常的简单，你可以阅读 一个 helloworld 的例子来了解它的基本开发流程 (本系列文章以Go语言的开发为例)。
最基本的开发步骤是定义 proto 文件， 定义请求 Request 和 响应 Response 的格式，然后定义一个服务 Service， Service可以包含多个方法。
基本的gRPC开发很多文章都介绍过了，官方也有相关的文档，这个系列的文章也就不介绍这些基础的开发，而是想通过代码演示gRPC更深入的开发。 作为这个系列的第一篇文章，想和大家分享一下gRPC流式开发的知识。
gRPC的流可以分为三类， 客户端流式发送、服务器流式返回以及客户端／服务器同时流式处理, 也就是单向流和双向流。 下面针对这三种情况分别通过例子介绍。
[转]gRPC服务发现&负载均衡
原文出处: gRPC服务发现&负载均衡, 作者: softfn。
文章中的代码可能有问题，修订后的代码可以参考: wwcd/grpc-lb
构建高可用、高性能的通信服务，通常采用服务注册与发现、负载均衡和容错处理等机制实现。根据负载均衡实现所在的位置不同，通常可分为以下三种解决方案：
