Go语言类库中，有两个官方的服务器框架，一个HTTP，一个是RPC。使用这个两个框架，已经能解决大部分的问题，但是，也有一些需求，这些框架是不够的，这篇文章，我们先分析一下HTTP 和 RPC服务器的特点, 然后结合这两个服务器的特点，我实现了一个新的服务器，这个服务器非常适合客户端和服务器端有大量交互的情况。 HTTP服务器的特点： HTTP的请求 和 响应的周期如下： 对于一个HTTP 长连接，一个请求必须等到一个响应完成后，才能进行下一个请求。这就是http协议最本质的特点，是串行化的。而这个特点保证了http协议的简洁性，一个请求中间不会插入其他的请求干扰，这样不需要去对应请求和响应。但是，同时也有个弱点，那就是不适合做大量的请求。举个实际中我们遇到的例子，我们要把大量的中国客户的订单送入英国的交易所，交易所的接口是http协议的，从中国到英国，一次http的请求到响应至少需要 300ms左右，这样一秒一个连只能发送3个，就算是开十个线程发送（接口对线程总数是有**的），1s 也只能是30个。而最高峰的时候，我们可能1s 要发送1万个订单，那采用http协议就不能满足我们的要求了（这个可以通过fix协议解决）。 当然，http可以解决批量提交的需求，只要增加一个批量提交的接口就可以了。但是，这样的实现方式不够自然，而且增加了额外的接口。 RPC服务的特点： PRC服务器克服了http服务器串流模型，可以并发的提交请求。请求响应的周期图如下： RPC服务，已经可以客服http服务器的串流的劣势，可以批量提交大量的数据。在局域网的中测试，1s钟可以实现3万次左右的请求。而相同的条件下，http在局域网中，只能实现1500次左右的请求，真实环境下面，延时严重，http性能会急剧下降。在两个不同的机房中，有百兆带宽相连，实际测试rpc请求是两万次左右，http是 500次左右，而且http占用很多头部的带宽。 RPC的一个核心特点是类似一次函数调用。这样一个请求 只能 对应于 一个响应。在某些情下，这似乎是不够的。举个实际的例子，我要获取一个报价的行情数据，这个时候，类似一个MessageQueue，服务器会不断的push数据给客户端。也就是一次请求，会有多次返回，持续不断的返回。 当然，RPC的一个非常重要的优势是，你不需要知道怎么去解析数据，你可以当做网络是空气，完全像写本地调用函数一样去调用rpc的函数。 异步服务器： 因为暂时我没有很好的名字来命名这个服务器，所以暂时就叫做异步服务器吧，这个服务器的特点类似一个界面程序的消息体系。我们不断的吧鼠标键盘等各种事件提交给界面程序，界面程序根据消息的类型，参数做出相应的处理。所以，我们就叫做异步服务器吧。经典的金融服务器都是异步服务器，处理机制都类似界面的消息循环机制，比如国内期货最常用的ctp交易系统，还有就是银行间，交易所和银行之间，经常用的一个协议叫做 fix，也是这样的架构。请求是一种消息，响应也是一种消息。请求响应的时序图如下： msg1 请求之后，有两个响应，Resp1 ， resp2， msg2 有一个响应 resp3. 借鉴了rpc的特点，请求和响应都自动编码，写服务器不再为编码而烦恼，同时也不需要为是否要压缩而头痛。现在提供三种方式，gob , json, protocolbuffer. 并且可以 设置是否启用压缩的，以及压缩的格式。我 们把客户端和服务器的交互抽象为一个消息系统，先来看看客户端客户端调用： 1: client, err := NewClient("http://localhost:8080", jar, "gob", "gzip") 2: if err != nil { 3: log.Println(err)
4: return 5: }
6: defer client.Close()
7: req := NewRequest("hello", "jack", func(call *Call, status int) { 8: log.Println(call, call.Resp, status)
9: })
10: client.Go(req)
11: req2 := NewRequest("hello", "禁用词语", func(call *Call, status int) { 12: log.Println(call, call.Resp, status)
13: })
14: client.Go(req2)
15: //wait for all req is done 16: client.Wait()
1-6行，我们建立了一个到服务器的连接，注意，我们这个服务器底层是用http包实现的。jar 是用来管理session的，这里暂时忽略，gob是编码，gzip是压缩格式。可以动态设置各种编码和压缩格式。 7-13行，NewRequest 的第一个参数是消息的类型（我建议再后面的版本中，改成NewMessage， Client.GO 改成 client.Send），叫做hello, 详细类型为了方便查看也打印，我采用字符串的格式。后面是消息的参数，可以是任何的go的结构，变量。每个请求对应一个回调函数，处理响应的消息，响应的消息保存在 call.Resp 里面，如果status == StatusDone ， 表示请求结束了，服务器不会响应任何消息了，status == StatusUpdate ，说明，还会有下一个消息过来。 16行 Wait函数，其实就是一个消息循环函数，不断的从服务器端读取消息，对应到某个请求的回调函数里面。类似event loop 我们在Client里面加入心跳函数，保证能检查到链接损坏的情况，如果连接损坏，会自动结束消息循环，错误处理是一个服务器非常重要的一环。 然后我们再来看看服务器端的实现： 1: func helloWorld(w *ResponseWriter, r *Request) {
2: resp := w.Resp
3: resp.MsgType = MsgTString
4: //表示我已经没有其他数据包了，这个请求已经结束了 5: resp.Done = true
6: //向客户端发送请求 7: w.WriteResponse(resp, "hello: " r.GetBody().(string)) 8: }
第7行中，r.GetBody() 获取的到是上面NewRequest 中的第二个参数。 这样就是一个最简单的hello world 程序。要实现一个实战有用的服务器，的细节当然还有很多，主要的是流量控制。比如，一个用户写错程序了，错误的发起了10万个请求，服务器端不能开个10万个go进行处理，这样的话，会直接拖垮服务器，我们给每个用户设置了一个并发处理数目，最多这个用户可以并发处理多少个请求。还有一个比较重要的，对服务器来说，就是服务器服务的量的**。我们会实时监控 cpu 内存，io的使用情况，当发现使用到某个限额的时候，服务会拒绝接受连接（事先要对性能进行测试）这些都是为了防止服务器过载 ，而实际中的服务器，这个问题其实是很常见的。 实例：可靠消息通知系统。 可靠消息通知系统实际上是一个非常常见的系统。最常用的一个例子就是数据库的master slave 模式。master里面的事件要非常可靠的通知到slave，中间不能有任何的丢失。还有一种比如交易系统中，我们会调用银行或者交易所的接口，银行在交易成功后会给我们一个通知，这个通知的消息必须可靠的被通知到目标，不能有任何的丢失。在我们的系统中，行情数据的复制也是不能有任何数据丢失的情景，为了保证A 服务器 和 B服务器有相同的行情，在从A服务器的消息要被B服务器准确的接收。当然，你也可以做一个聊天系统，这个聊天系统不会丢失任何消息。 那么如何实现这个系统呢，首先，为了保证不在内存中丢失消息，那么消息必须写盘，并且为了检测消息是否丢失，必须给消息编号。消息写盘也可以用我们开发的事务日志系统，如果消息非常的大量，那么还需要批量提交模式（Group Commit）。大部分情况下，消息丢失不是因为服务器崩溃，而且网络意外中断，这些中断往往时间很短，在1分钟以内，所以，有必要在内存中缓存部分的消息，如果网络中断，客户端再次请求时，发送当时的消息序号，这样就可以补全网络中断丢失的数据。如果时间太长了，内存中的数据不够补了，那么首先要从消息源数据库中下载历史消息，然后再接受实时的消息。整体的思路就是这样的，在这里，我们就看看我们的消息通知系统的实时广播部分的设计。 1. 消息广播基本流程： 订阅 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
