最近看到一篇新闻: 英超再现恐怖食物链!20强相生相克 今年用了14轮，对于足球和英超感兴趣的读者一定了解，所谓食物链是指A队胜过B队，B队胜过C队,……，N队也胜过A队，截止到英超第14轮，根据所有的队伍的胜负关系，一条最大的食物链已经形成，英超20队都加入到这个食物链中，相生相克。
我看到这篇新闻的时候，有一点点程序员的不由自主的想法，能否通过算法检查目前最大的食物链，以及能否将食物链罗列出来？这也算是算法解决实际问题的一个很好的例子吧。
平滑的基于权重的轮询算法
轮询算法是非常常用的一种调度/负载均衡的算法。依照百度百科上的解释:
Round-Robin，轮询调度，通信中信道调度的一种策略，该调度策略使用户轮流使用共享资源，不会考虑瞬时信道条件。从相同数量无线资源（相同调度时间段）被分配给每条通信链路的角度讲，轮询调度可以被视为公平调度。然而，从提供相同服务质量给所有通信链路的角度而言，轮询调度是不公平的，此时，必须为带有较差信道条件的通信链路分配更多无线资源（更多时间）。此外，由于轮询调度在调度过程中不考虑瞬时信道条件，因此它将导致较低的整体系统性能，但与最大载干比调度相比，在各通信链路间具有更为均衡的服务质量。
更广泛的轮询调度应用在广度的服务调度上面，尤其在面向服务或者是面向微服务的架构中，比可以在很多知名的软件中看到它的身影，比如LVS、Nginx、Dubblo等。但是正如上面的百度百科中的介绍一样，轮询调度有一个很大的问题，那就是它认为所有的服务的性能都是一样的，每个服务器都被公平的调度，在服务器的性能有显著差别的环境中，性能比较差的服务器被调度了相同的次数，这不是我们所期望的。所以本文要介绍的是加权的轮询算法，轮询算法可以看成是加权的轮询算法的一个特例，在这种情况下，每个服务器的权重都是一样的。
本文介绍了Nginx和LVS的两种算法，比较了它们的优缺点，并提供了一个通用的 Go 语言实现的加权轮询算法库： weighted,可以用在负载均衡/调度/微服务网关等场合。
2016年Web框架性能基准
TechEmpower最近发布了他们的第13轮的web框架的性能测试，得到了一些有价值的测试结果。
由于年初前一轮的测试遭遇到了硬件的瓶颈，微软 Azure 和 ServerCentral 分别提供了云主机和物理主机环境，所以第13轮的测试是在新的测试环境中进行的，所以你把这轮的测试结果和以前的测试进行比较的话可能不太合适。
- ServerCentral
- 物理机环境,由 ServerCentral提供。 Dell R910 (4x 10-Core E7-4850 CPUs) 为应用服务器; Dell R420 (2x 4-Core E5-2406 CPUs) 为数据库服务器; 10G网络
- Azure
- 云测试主机由 Microsoft Azure D3v2 实例提供; 10网络
[译]Scala Collection的性能
这是翻译自 Li Haoyi 的 Benchmarking Scala Collections。
Li Haoyi 的背景了解Scala的人都知道，虽然Scala的官方文档对集合框架的性能提供了定性的分析，但是Li Haoyi的这篇文章定量的比较了各个框架类的性能，非常有参考意义，也便于你更好的正确的选择 Scala 集合中的类。
这篇文章从经验的角度深入研究了Scala集合库的运行特性。你也许已经看到了很多的从实现的角度介绍Scala集合库的文章(inheritance hierarchies, CanBuildFrom, 等等),但是很少有人写这些集合运行时的行为特性。
List比Vector快，还是Vector比List快？使用未装箱的数组存储基本类型可以节省多少内存？什么时候你会执行一些性能的技巧，比如预分配大小的数组、使用while-loop取代foreach调用等，这些技巧真的有效么？声明var l: List还是val b: mutable.Buffer？这篇文章会给你答案。
微服务的反模式和陷阱
前几天我写了篇读书笔记: 《产品级微服务的八大原则》，介绍了Uber的SRE工程师 Susan J. Fowler 的免费书: Microservices in Production,文中提出了一个微服务成功与否的唯一标准就是可用性，非常有实践意义。但是这本书偏向于从 SRE （site reliability engineer）的视角看待微服务，对于开发工程师 (SWE, software engineer)来说，更关注的是如何正确地从单体程序重构到微服务架构，或者从头设计微服务架构， 这篇读书笔记主要就是介绍这方面的实践和经验。
Oreilly 的 的这本免费小书 Microservices AntiPatterns and Pitfalls由经验丰富的 Mark Richards 编写。书中将反模式(AntiPattern)定义为"起初看起来很美好，做到最后麻烦不断的实践模式"，而将陷阱(Pitfall)定义为“起初看起来就不是一个好的设计”，书中列举了微服务开发中几种常见的反模式和陷阱，这些经验非常的接地气.他还提供了视频教程。
[译]Go 1.8 新特性
译自 tylerchr 的 What's Coming in Go 1.8。
随着Go 1.8 新特性的开发工作已经冻结，Go 1.8 将在2017年2月左右发布，现在让我们看一些在Go 1.8更有趣的API的改变。
优雅地实现 TCP 压缩传输
集群式、负载均衡的RPC框架 rpcx支持多种的序列化库，可以有效的减少消息体的大小，但是对于字符串或者图片的字节slice，明显还可以进一步的压缩，正如fasthttp作者valyala在他的新的开源项目httpteleport中描述的： 通过1G的带宽传输10G的数据 (夸张)。
为了在RPC的传输中减少传输的数据大小，我在不影响rpcx整体框架的基础上，参考了httpteleport的实现，对net.TCPConn进行了封装，实现了压缩/解压缩功能的net.Conn，可以有效的减少带宽，节省公司在带宽上的花费， 以下就是具体的实现。
vscode 快捷键参考
Visual Code 1.7.1发布了，vscode team提供了一个pdf版本的快捷键指南，可以打印出来备用。
Go的函数参数总是传值
依照Go的FQA, 函数的参数传递总是传值的(pass-by-value)：
As in all languages in the C family, everything in Go is passed by value. That is, a function always gets a copy of the thing being passed, as if there were an assignment statement assigning the value to the parameter. For instance, passing an int value to a function makes a copy of the int, and passing a pointer value makes a copy of the pointer, but not the data it points to. (See a later section for a discussion of how this affects method receivers.)
Map and slice values behave like pointers: they are descriptors that contain pointers to the underlying map or slice data. Copying a map or slice value doesn't copy the data it points to. Copying an interface value makes a copy of the thing stored in the interface value. If the interface value holds a struct, copying the interface value makes a copy of the struct. If the interface value holds a pointer, copying the interface value makes a copy of the pointer, but again not the data it points to.
