网关=反向代理+负载均衡+各种策略，技术实现也有多种多样，有基于 nginx 使用 lua 的实现，比如 openresty、kong；也有基于 zuul 的通用网关；还有就是 golang 的网关，比如 tyk。
成都创新互联成都网站建设按需开发，是成都网站营销公司,为假山制作提供网站建设服务,有成熟的网站定制合作流程，提供网站定制设计服务：原型图制作、网站创意设计、前端HTML5制作、后台程序开发等。成都网站制作热线：028-86922220
这篇文章主要是讲如何基于 golang 实现一个简单的网关。
转自： troy.wang/docs/golang/posts/golang-gateway/
整理：go语言钟文文档:
启动两个后端 web 服务（代码）
这里使用命令行工具进行测试
具体代码
直接使用基础库 httputil 提供的NewSingleHostReverseProxy即可，返回的reverseProxy对象实现了serveHttp方法，因此可以直接作为 handler。
具体代码
director中定义回调函数，入参为*http.Request，决定如何构造向后端的请求，比如 host 是否向后传递，是否进行 url 重写，对于 header 的处理，后端 target 的选择等，都可以在这里完成。
director在这里具体做了：
modifyResponse中定义回调函数，入参为*http.Response，用于修改响应的信息，比如响应的 Body，响应的 Header 等信息。
最终依旧是返回一个ReverseProxy，然后将这个对象作为 handler 传入即可。
参考 2.2 中的NewSingleHostReverseProxy，只需要实现一个类似的、支持多 targets 的方法即可，具体实现见后面。
作为一个网关服务，在上面 2.3 的基础上，需要支持必要的负载均衡策略，比如：
随便 random 一个整数作为索引，然后取对应的地址即可，实现比较简单。
具体代码
使用curIndex进行累加计数，一旦超过 rss 数组的长度，则重置。
具体代码
轮询带权重，如果使用计数递减的方式，如果权重是5,1,1那么后端 rs 依次为a,a,a,a,a,b,c,a,a,a,a…，其中 a 后端会瞬间压力过大；参考 nginx 内部的加权轮询，或者应该称之为平滑加权轮询，思路是：
后端真实节点包含三个权重：
操作步骤：
具体代码
一致性 hash 算法，主要是用于分布式 cache 热点/命中问题；这里用于基于某 key 的 hash 值，路由到固定后端，但是只能是基本满足流量绑定，一旦后端目标节点故障，会自动平移到环上最近的那么个节点。
实现：
具体代码
每一种不同的负载均衡算法，只需要实现添加以及获取的接口即可。
然后使用工厂方法，根据传入的参数，决定使用哪种负载均衡策略。
具体代码
作为网关，中间件必不可少，这类包括请求响应的模式，一般称作洋葱模式，每一层都是中间件，一层层进去，然后一层层出来。
中间件的实现一般有两种，一种是使用数组，然后配合 index 计数；一种是链式调用。
具体代码
在Malwarebytes 我们经历了显著的增长，自从我一年前加入了硅谷的公司，一个主要的职责成了设计架构和开发一些系统来支持一个快速增长的信息安全公司和所有需要的设施来支持一个每天百万用户使用的产品。我在反病毒和反恶意软件行业的不同公司工作了12年，从而我知道由于我们每天处理大量的数据，这些系统是多么复杂。
有趣的是，在过去的大约9年间，我参与的所有的web后端的开发通常是通过Ruby on Rails技术实现的。不要错怪我。我喜欢Ruby on Rails，并且我相信它是个令人惊讶的环境。但是一段时间后，你会开始以ruby的方式开始思考和设计系统，你会忘记，如果你可以利用多线程、并行、快速执行和小内存开销，软件架构本来应该是多么高效和简单。很多年期间，我是一个c/c++、Delphi和c#开发者，我刚开始意识到使用正确的工具可以把复杂的事情变得简单些。
作为首席架构师，我不会很关心在互联网上的语言和框架战争。我相信效率、生产力。代码可维护性主要依赖于你如何把解决方案设计得很简单。
问题
当工作在我们的匿名遥测和分析系统中，我们的目标是可以处理来自于百万级别的终端的大量的POST请求。web处理服务可以接收包含了很多payload的集合的JSON数据，这些数据需要写入Amazon S3中。接下来，map-reduce系统可以操作这些数据。
按照习惯，我们会调研服务层级架构，涉及的软件如下：
Sidekiq
Resque
DelayedJob
Elasticbeanstalk Worker Tier
RabbitMQ
and so on…
搭建了2个不同的集群，一个提供web前端，另外一个提供后端处理，这样我们可以横向扩展后端服务的数量。
但是，从刚开始，在 讨论阶段我们的团队就知道我们应该使用Go，因为我们看到这会潜在性地成为一个非常庞大（ large traffic）的系统。我已经使用了Go语言大约2年时间，我们开发了几个系统，但是很少会达到这样的负载（amount of load）。
我们开始创建一些结构，定义从POST调用得到的web请求负载，还有一个上传到S3 budket的函数。
type PayloadCollection struct {
WindowsVersion string `json:"version"`
Token string `json:"token"`
Payloads []Payload `json:"data"`
}
type Payload struct {
// [redacted]
}
func (p *Payload) UploadToS3() error {
// the storageFolder method ensures that there are no name collision in
// case we get same timestamp in the key name
storage_path := fmt.Sprintf("%v/%v", p.storageFolder, time.Now().UnixNano())
bucket := S3Bucket
b := new(bytes.Buffer)
encodeErr := json.NewEncoder(b).Encode(payload)
if encodeErr != nil {
return encodeErr
}
// Everything we post to the S3 bucket should be marked 'private'
var acl = s3.Private
var contentType = "application/octet-stream"
return bucket.PutReader(storage_path, b, int64(b.Len()), contentType, acl, s3.Options{})
}
本地Go routines方法
刚开始，我们采用了一个非常本地化的POST处理实现，仅仅尝试把发到简单go routine的job并行化：
func payloadHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// Read the body into a string for json decoding
var content = PayloadCollection{}
err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)
if err != nil {
w.Header().Set("Content-Type", "application/json; charset=UTF-8")
w.WriteHeader(http.StatusBadRequest)
return
}
// Go through each payload and queue items individually to be posted to S3
for _, payload := range content.Payloads {
go payload.UploadToS3() // ----- DON'T DO THIS
}
w.WriteHeader(http.StatusOK)
}
对于中小负载，这会对大多数的人适用，但是大规模下，这个方案会很快被证明不是很好用。我们期望的请求数，不在我们刚开始计划的数量级，当我们把第一个版本部署到生产环境上。我们完全低估了流量。
上面的方案在很多地方很不好。没有办法控制我们产生的go routine的数量。由于我们收到了每分钟1百万的POST请求，这段代码很快就崩溃了。
再次尝试
我们需要找一个不同的方式。自开始我们就讨论过， 我们需要保持请求处理程序的生命周期很短，并且进程在后台产生。当然，这是你在Ruby on Rails的世界里必须要做的事情，否则你会阻塞在所有可用的工作 web处理器上，不管你是使用puma、unicore还是passenger（我们不要讨论JRuby这个话题）。然后我们需要利用常用的处理方案来做这些，比如Resque、 Sidekiq、 SQS等。这个列表会继续保留，因为有很多的方案可以实现这些。
所以，第二次迭代，我们创建了一个缓冲channel，我们可以把job排队，然后把它们上传到S3。因为我们可以控制我们队列中的item最大值，我们有大量的内存来排列job，我们认为只要把job在channel里面缓冲就可以了。
var Queue chan Payload
func init() {
Queue = make(chan Payload, MAX_QUEUE)
}
func payloadHandler(w http.ResponseWriter, r *http.Request) {
...
// Go through each payload and queue items individually to be posted to S3
for _, payload := range content.Payloads {
Queue - payload
}
...
}
接下来，我们再从队列中取job，然后处理它们。我们使用类似于下面的代码：
func StartProcessor() {
for {
select {
case job := -Queue:
job.payload.UploadToS3() // -- STILL NOT GOOD
}
}
}
说实话，我不知道我们在想什么。这肯定是一个满是Red-Bulls的夜晚。这个方法不会带来什么改善，我们用了一个 有缺陷的缓冲队列并发，仅仅是把问题推迟了。我们的同步处理器同时仅仅会上传一个数据到S3，因为来到的请求远远大于单核处理器上传到S3的能力，我们的带缓冲channel很快达到了它的极限，然后阻塞了请求处理逻辑的queue更多item的能力。
我们仅仅避免了问题，同时开始了我们的系统挂掉的倒计时。当部署了这个有缺陷的版本后，我们的延时保持在每分钟以常量增长。
最好的解决方案
我们讨论过在使用用Go channel时利用一种常用的模式，来创建一个二级channel系统，一个来queue job，另外一个来控制使用多少个worker来并发操作JobQueue。
想法是，以一个恒定速率并行上传到S3，既不会导致机器崩溃也不好产生S3的连接错误。这样我们选择了创建一个Job/Worker模式。对于那些熟悉Java、C#等语言的开发者，可以把这种模式想象成利用channel以golang的方式来实现了一个worker线程池，作为一种替代。
var (
MaxWorker = os.Getenv("MAX_WORKERS")
MaxQueue = os.Getenv("MAX_QUEUE")
)
// Job represents the job to be run
type Job struct {
Payload Payload
}
// A buffered channel that we can send work requests on.
var JobQueue chan Job
// Worker represents the worker that executes the job
type Worker struct {
WorkerPool chan chan Job
JobChannel chan Job
quit chan bool
}
func NewWorker(workerPool chan chan Job) Worker {
return Worker{
WorkerPool: workerPool,
JobChannel: make(chan Job),
quit: make(chan bool)}
}
// Start method starts the run loop for the worker, listening for a quit channel in
// case we need to stop it
func (w Worker) Start() {
go func() {
for {
// register the current worker into the worker queue.
w.WorkerPool - w.JobChannel
select {
case job := -w.JobChannel:
// we have received a work request.
if err := job.Payload.UploadToS3(); err != nil {
log.Errorf("Error uploading to S3: %s", err.Error())
}
case -w.quit:
// we have received a signal to stop
return
}
}
}()
}
// Stop signals the worker to stop listening for work requests.
func (w Worker) Stop() {
go func() {
w.quit - true
}()
}
我们已经修改了我们的web请求handler，用payload创建一个Job实例，然后发到JobQueue channel，以便于worker来获取。
func payloadHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// Read the body into a string for json decoding
var content = PayloadCollection{}
err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)
if err != nil {
w.Header().Set("Content-Type", "application/json; charset=UTF-8")
w.WriteHeader(http.StatusBadRequest)
return
}
// Go through each payload and queue items individually to be posted to S3
for _, payload := range content.Payloads {
// let's create a job with the payload
work := Job{Payload: payload}
// Push the work onto the queue.
JobQueue - work
}
w.WriteHeader(http.StatusOK)
}
在web server初始化时，我们创建一个Dispatcher，然后调用Run()函数创建一个worker池子，然后开始监听JobQueue中的job。
dispatcher := NewDispatcher(MaxWorker)
dispatcher.Run()
下面是dispatcher的实现代码：
type Dispatcher struct {
// A pool of workers channels that are registered with the dispatcher
WorkerPool chan chan Job
}
func NewDispatcher(maxWorkers int) *Dispatcher {
pool := make(chan chan Job, maxWorkers)
return Dispatcher{WorkerPool: pool}
}
func (d *Dispatcher) Run() {
// starting n number of workers
for i := 0; i d.maxWorkers; i++ {
worker := NewWorker(d.pool)
worker.Start()
}
go d.dispatch()
}
func (d *Dispatcher) dispatch() {
for {
select {
case job := -JobQueue:
// a job request has been received
go func(job Job) {
// try to obtain a worker job channel that is available.
// this will block until a worker is idle
jobChannel := -d.WorkerPool
// dispatch the job to the worker job channel
jobChannel - job
}(job)
}
}
}
注意到，我们提供了初始化并加入到池子的worker的最大数量。因为这个工程我们利用了Amazon Elasticbeanstalk带有的docker化的Go环境，所以我们常常会遵守12-factor方法论来配置我们的生成环境中的系统，我们从环境变了读取这些值。这种方式，我们控制worker的数量和JobQueue的大小，所以我们可以很快的改变这些值，而不需要重新部署集群。
var (
MaxWorker = os.Getenv("MAX_WORKERS")
MaxQueue = os.Getenv("MAX_QUEUE")
)
直接结果
我们部署了之后，立马看到了延时降到微乎其微的数值，并未我们处理请求的能力提升很大。
Elastic Load Balancers完全启动后，我们看到ElasticBeanstalk 应用服务于每分钟1百万请求。通常情况下在上午时间有几个小时，流量峰值超过每分钟一百万次。
我们一旦部署了新的代码，服务器的数量从100台大幅 下降到大约20台。
我们合理配置了我们的集群和自动均衡配置之后，我们可以把服务器的数量降至4x EC2 c4.Large实例，并且Elastic Auto-Scaling设置为如果CPU达到5分钟的90%利用率，我们就会产生新的实例。
总结
在我的书中，简单总是获胜。我们可以使用多队列、后台worker、复杂的部署设计一个复杂的系统，但是我们决定利用Elasticbeanstalk 的auto-scaling的能力和Go语言开箱即用的特性简化并发。
我们仅仅用了4台机器，这并不是什么新鲜事了。可能它们还不如我的MacBook能力强大，但是却处理了每分钟1百万的写入到S3的请求。
处理问题有正确的工具。当你的 Ruby on Rails 系统需要更强大的web handler时，可以考虑下ruby生态系统之外的技术，或许可以得到更简单但更强大的替代方案。
英文原文链接【Go, the unwritten parts】 发表于2017/05/22 作者JBD是Go语言开发小组成员
检查程序的执行路径和当前状态是非常有用的调试手段。核心文件（core file）包含了一个运行进程的内存转储和状态。它主要是用来作为事后调试程序用的。它也可以被用来查看一个运行中的程序的状态。这两个使用场景使调试文件转储成为一个非常好的诊断手段。我们可以用这个方法来做事后诊断和分析线上的服务（production services）。
在这篇文章中，我们将用一个简单的hello world网站服务作为例子。在现实中，我们的程序很容易就会变得很复杂。分析核心转储给我们提供了一个机会去重构程序的状态并且查看只有在某些条件／环境下才能重现的案例。
作者注 : 这个调试流程只在Linux上可行。我不是很确定它是否在其它Unixs系统上工作。macOS对此还不支持。Windows现在也不支持。
在我们开始前，需要确保核心转储的ulimit设置在合适的范围。它的缺省值是0，意味着最大的核心文件大小是0。我通常在我的开发机器上将它设置成unlimited。使用以下命令：
接下来，你需要在你的机器上安装 delve 。
下面我们使用的 main.go 文件。它注册了一个简单的请求处理函数（handler）然后启动了HTTP服务。
让我们编译并生产二进制文件。
现在让我们假设，这个服务器出了些问题，但是我们并不是很确定问题的根源。你可能已经在程序里加了很多辅助信息，但还是无法从这些调试信息中找出线索。通常在这种情况下，当前进程的快照会非常有用。我们可以用这个快照深入查看程序的当前状态。
有几个方式来获取核心文件。你可能已经熟悉了奔溃转储（crash dumps）。它们是在一个程序奔溃的时候写入磁盘的核心转储。Go语言在缺省设置下不会生产奔溃转储。但是当你把 GOTRACEBACK 环境变量设置成“crash”，你就可以用 Ctrl+backslash 才触发奔溃转储。如下图所示：
上面的操作会使程序终止，将堆栈跟踪（stack trace）打印出来，并把核心转储文件写入磁盘。
另外个方法可以从一个运行的程序获得核心转储而不需要终止相应的进程。 gcore 可以生产核心文件而无需使运行中的程序退出。
根据上面的操作，我们获得了转储而没有终止对应的进程。下一步就是把核心文件加载进delve并开始分析。
差不多就这些。delve的常用操作都可以使用。你可以backtrace，list，查看变量等等。有些功能不可用因为我们使用的核心转储是一个快照而不是正在运行的进程。但是程序执行路径和状态全部可以访问。
在Go语言的代码中，您需要引入官方的SDK库 aliyun/serverless/fc-runtime-go-sdk/fc，并实现handler函数和main函数。 示例如下：
传入的event参数是一个包含key属性的JSON字符串，示例如下。
具体的示例解析如下：
有效的Event Handler签名如下：
其中，InputType和OutputType与encoding/json标准库兼容。
Event Handler的使用需遵循以下规则：
事件函数的Handler示例代码：
上一章节介绍了使用echo启动一个http服务器并提供一个简单的GET接口，这一章对请求与响应做一下详细的讲解。
了解请求与响应之前首先要知道ehco框架提供了一个Context接口，Context 表示当前 HTTP 请求的上下文，我们需要知道的是Context的实现结构体context，context中包含了请求(request)、响应(response)以及参数等结构体，context是一个内部结构体，但是对外提供了访问的方法，我们可以在开发中使用context提供的方法做很多事情，比如获取请求路径、客户端ip、请求参数等等。
request是包含了当前请求信息的结构体，我们从中可以获取到前后端约定好的参数来作出相应的业务逻辑，这下面开始模拟请求
首先模拟一个添加用户的POST请求，这里使用了c.bind()这个方法，这个方法起到的作用是把表单参数或者JSON参数绑定至对应的结构体(这里必须是指针类型)，字段需要一一对应，也就是说前端需要传递的表单或JSON参数名为name、age、gender才能绑定到结构体中。
接下来模拟一个GET请求用来获取用户信息
response是包含了返回信息的结构体，echo提供了多种类型的返回结果
上面编写了处理请求的handler，这里介绍一下如何把handler注册到路由中，这里对应的就是上面handler。
