原文: HTTP Response Snippets for Go by Alex Edwards.
受 Rails layouts and rendering启发, 我觉得写一个关于Go HTTP Response的代码片段集合是一个不错的主意， 它可以用来说明Go web应用程序中通用的HTTP Response的使用。
编写地道的Go代码
在阅读本文之前，我先推荐你阅读官方的 Effective Go文档，或者是中文翻译版: 高效Go编程，它提供了很多编写标准而高效的Go代码指导，本文不会再重复介绍这些内容。
最地道的Go代码就是Go的标准库的代码，你有空的时候可以多看看Google的工程师是如何实现的。
本文仅作为一个参考，如果你有好的建议和意见，欢迎添加评论。
如何在长城后面go get一些库
国内的Go开发已然蔚然成风，但是Go开发者比较痛苦的是，golang.org网站以及其它的一些相关的开发网站被GFW屏蔽了。下载Go开发包海容易些，国内有一些镜像站点，或者通过一些代理也能访问，但是下载一些开发库的时候，这些库可能直接或者间接引用了 ｀golang.org/x/...｀等依赖库， 通过go get命令确没有办法下载下来。
我原先在Comcast，这是一家外企，在国内有vpn可以直接访问这些网站，所以以前没有觉得go get是一个问题，看到大家被GFW弄的焦头烂额的时候也没觉得是一件大事情，现在换到国内的互联网企业，切切实实的感觉到GFW的威力。首先是google.com, golang.org等网站被屏蔽掉了，其次 go get 一些库如golangorg/x/net失败。
[]T 还是 []*T, 这是一个问题
在编程语言深入讨论中，经常被大家提起也是争论最多的讨论之一就是按值(by value)还是按引用传递(by reference， by pointer)，你可以在C/C++或者Java的社区经常看到这样的讨论，也会看到很多这样的面试题。
对于Go语言，严格意义上来讲，只有一种传递，也就是按值传递(by value)。当一个变量当作参数传递的时候，会创建一个变量的副本，然后传递给函数或者方法，你可以看到这个副本的地址和变量的地址是不一样的。
当变量当做指针被传递的时候，一个新的指针被创建，它指向变量指向的同样的内存地址，所以你可以将这个指针看成原始变量指针的副本。当这样理解的时候，我们就可以理解成Go总是创建一个副本按值转递，只不过这个副本有时候是变量的副本，有时候是变量指针的副本。
这是Go语言中你理解后续问题的基础。
但是Go语言的情况比较复杂，我们什么时候选择 T 作为参数类型，什么时候选择 *T作为参数类型？ []T是传递的指针还是值？选择[]T还是[]*T? 哪些类型复制和传递的时候会创建副本？什么情况下会发生副本创建？
本文将详细介绍Go语言的变量的副本创建还是变量指针的副本创建的case以及各种类型在这些case的情况。
一个有特色的有限状态机
gofsm是一个简单、小巧而又特色的有限状态机（FSM）。
github已经有了很多状态机的实现，比如文末列出的一些，还为什么要再发明轮子呢？
原因在于这些状态机有一个特点，就是一个状态机维护一个对象的状态，这样一个状态机就和一个具体的图像实例关联在一起，在有些情况下，这没有什么问题，而且是很好的设计，而且比较符合状态机的定义。但是在有些情况下，当我们需要维护成千上百个对象的时候，需要创建成千上百个状态机对象，这其实是很大的浪费，因为在大部分情况下，对象本身自己会维护/保持自己当前的状态，我们只需把对象当前的状态传递给一个共用的状态机就可以了，也就是gofsm本身是“stateless”，本身它包维护一个或者多个对象的状态，所有需要的输入由调用者输入，它只负责状态的转换的逻辑，所以它的实现非常的简洁实用，这是创建gofsm的一个目的。
第二个原因它提供了Moore和Mealy两种状态机的统一接口，并且提供了UML状态机风格的Action处理，以程序员更熟悉的方式处理状态的改变。
第三个原因，当我们谈论起状态机的时候，我们总会画一个状态转换图，大家可以根据这这张图进行讨论、设计、实现和验证状态的迁移。但是对于代码来说，实现真的和你的设计是一致的吗，你怎么保证？gofsm提供了一个简单的方法，那就是它可以输出图片或者pdf文件，你可以利用输出的状态机图和你的设计进行比较，看看实现和设计是否一致。
调试利器：dump goroutine 的 stacktrace
Stack trace是指堆栈回溯信息，在当前时间，以当前方法的执行点开始，回溯调用它的方法的方法的执行点，然后继续回溯，这样就可以跟踪整个方法的调用,大家比较熟悉的是JDK所带的jstack工具，可以把Java的所有线程的stack trace都打印出来。
它有什么用呢？用处非常的大，当应用出现一些状况的时候，比如某个模块不执行， 锁竞争、CPU占用非常高等问题， 又没有足够的log信息可以分析，那么可以查看stack trace信息，看看线程都被阻塞或者运行在那些代码上，然后定位问题所在。
对于Go开发的程序，有没有类似jstack这样的利器呢，目前我还没有看到，但是我们可以通过其它途径也很方便的输出goroutine的stack trace信息。
本文介绍了几种方法，尤其是最后介绍的方法比较有用。
使用算法检测英超中的食物链
最近看到一篇新闻: 英超再现恐怖食物链!20强相生相克 今年用了14轮，对于足球和英超感兴趣的读者一定了解，所谓食物链是指A队胜过B队，B队胜过C队,……，N队也胜过A队，截止到英超第14轮，根据所有的队伍的胜负关系，一条最大的食物链已经形成，英超20队都加入到这个食物链中，相生相克。
我看到这篇新闻的时候，有一点点程序员的不由自主的想法，能否通过算法检查目前最大的食物链，以及能否将食物链罗列出来？这也算是算法解决实际问题的一个很好的例子吧。
平滑的基于权重的轮询算法
轮询算法是非常常用的一种调度/负载均衡的算法。依照百度百科上的解释:
Round-Robin，轮询调度，通信中信道调度的一种策略，该调度策略使用户轮流使用共享资源，不会考虑瞬时信道条件。从相同数量无线资源（相同调度时间段）被分配给每条通信链路的角度讲，轮询调度可以被视为公平调度。然而，从提供相同服务质量给所有通信链路的角度而言，轮询调度是不公平的，此时，必须为带有较差信道条件的通信链路分配更多无线资源（更多时间）。此外，由于轮询调度在调度过程中不考虑瞬时信道条件，因此它将导致较低的整体系统性能，但与最大载干比调度相比，在各通信链路间具有更为均衡的服务质量。
更广泛的轮询调度应用在广度的服务调度上面，尤其在面向服务或者是面向微服务的架构中，比可以在很多知名的软件中看到它的身影，比如LVS、Nginx、Dubblo等。但是正如上面的百度百科中的介绍一样，轮询调度有一个很大的问题，那就是它认为所有的服务的性能都是一样的，每个服务器都被公平的调度，在服务器的性能有显著差别的环境中，性能比较差的服务器被调度了相同的次数，这不是我们所期望的。所以本文要介绍的是加权的轮询算法，轮询算法可以看成是加权的轮询算法的一个特例，在这种情况下，每个服务器的权重都是一样的。
本文介绍了Nginx和LVS的两种算法，比较了它们的优缺点，并提供了一个通用的 Go 语言实现的加权轮询算法库： weighted,可以用在负载均衡/调度/微服务网关等场合。
微服务的反模式和陷阱
前几天我写了篇读书笔记: 《产品级微服务的八大原则》，介绍了Uber的SRE工程师 Susan J. Fowler 的免费书: Microservices in Production,文中提出了一个微服务成功与否的唯一标准就是可用性，非常有实践意义。但是这本书偏向于从 SRE （site reliability engineer）的视角看待微服务，对于开发工程师 (SWE, software engineer)来说，更关注的是如何正确地从单体程序重构到微服务架构，或者从头设计微服务架构， 这篇读书笔记主要就是介绍这方面的实践和经验。
Oreilly 的 的这本免费小书 Microservices AntiPatterns and Pitfalls由经验丰富的 Mark Richards 编写。书中将反模式(AntiPattern)定义为"起初看起来很美好，做到最后麻烦不断的实践模式"，而将陷阱(Pitfall)定义为“起初看起来就不是一个好的设计”，书中列举了微服务开发中几种常见的反模式和陷阱，这些经验非常的接地气.他还提供了视频教程。
