项目简介 | 胡宇辉

[TOC]

从毕业到现在，差不多已经工作三年了，在招商一直从事的是接入平台的开发，解决原有网关在可靠性、稳定性、效率、扩展性上的不足。为了锻炼自己的编码能力，多动手，现在想参照京东京麦TCP网关(链接：http://www.linkedkeeper.com/detail/blog.action?bid=1065 )，用erlang语言重写一遍，用来激励自己主动学习用吧。关于京东京麦的资料介绍也比较少，权且就按照他们所描述的自我猜测来模拟实现吧。

什么是api网关？

网上说api网关的文章很多，大家可以自己去参考，我觉得这篇文章不错： https://mp.weixin.qq.com/s/RuN5RfQfksQZRPACloqHEg 。
我这三年工作的，其实也差不多是一个网关，不过功能没有文章中说的那么丰富，不同的业务场景和公司技术投入的前提下，能有效解决公司业务瓶颈就好了。所以参考做网关的话，能做到什么样就看自己的投入了，实现的过程中就是学习的过程，架构不是设计出来的，是在演变中实现出来的。

为什么需要网关？

其实从刚毕业之初，我也没搞清楚，为什么需要一个网关来做一个数据通道，因为从学校，书本里我们基本都是接触到的是c/s模式，即client端通过tcp协议connect后端server，整个数据通道就已经打通了，即如下图所示：
client-serve

但是上诉直连的模式，仔细想想有很多需要改进的地方，这也是为什么需要一个接入系统的原因，主要分为以下几点：
1、一般来说，server服务器都是部署在公司内部机房的，处于安全考虑，很多情况下，其并不希望外部client知道它具体的ip，port或者部署模式。一般情况下，公司机房内部的server都会存在白名单，只允许白名单内的机器对其进行网络访问。

2、抛却安全网络访问权限的限制，如果让server端直接对接外部成千上万的client连接过来的tcp连接，那有一个问题是逃不掉的，即优雅正确处理c10k问题（链接：https://segmentfault.com/a/1190000007240744 ）。这样一来，每个后台server就必须花费部分精力在处理同样的大量链接的情况，造成了公司开发人员的资源浪费。好的系统接入应该是只要求后台server关注于具体业务逻辑处理即可，如下图所示：
n_client-1_serve

3、同样的，对于客户端来说，当后台server的功能细分后，即客户端享受的服务功能并非后台一个server就能提供的，那么client端则就需要去连接不同的后台server。如果每个server都有自己的一套接入方式，比如connect成功后，有一系列握手过程，例如邮件发送smtp等。这种情况客户端也就需要根据他需要享受的不同的服务去以不同的方式去创建不同的socket，这个工作量对于客户端来说，也是很痛苦的，如下图所示：
1_client_n_serve

4、不同协议的转发。比如说，client是采用http的协议发送数据包过来，而后端server是处理tcp协议的。那么原始直连的方式是解决不了不同协议的接入。这个概念就是代理、网关、隧道等区别，可自行查询其区别。

既然直连模式有上诉一些痛点需要我们解决，这些痛点是我们可以加入一个接入网关来一定程度上得以解决的，如下图所示：
uap
通过上诉接入模式，server端的部署就可以对客户端屏蔽了，客户端完全无感知server的存在；同样的，客户端只需要做到他们按照统一接入网关规定的接入方式连上统一接入网关即可，不需要考虑其他的接入模式。所有的c10k问题，http接入，tcp接入，websocket接入等都可以在统一接入网关来做。或者更多的，例如流控，服务升降级，不同协议的互相转化等，数据包统计等功能。

##网关需要做到什么？
加入网关后，就跟加入消息队列一样，带来了好处，同样也会带来不足之处，可以参考链接：https://mp.weixin.qq.com/s/KgdDnlr97-t7wZZFcJo2yA 。总的来说，就是加了一层访问，网络通讯就多了一次，未知的因素就多了一些。所以网关必须要做到，性能上有保障，网关一定要健壮，不能随意就dump掉，随时都可以提供服务，即要做到：高性能，高稳定性，可扩展等特性。

##网关tcp协议内容
网关使用什么协议是需要针对不同的业务场景，最好由公司统一设计出一个统一的数据交换协议，基本模式都是header+body的模式，其中header中包含了网关需要的某些字段，body则是具体业务逻辑所需要关心的。我就准备随意从互联网上找一份协议模式来实现吧，其proto文件描述为

message TcpProtocol 
{
    required string version         = 1;    //接口版本号
    required string deviceId        = 2;    //设备uuid
    required uint32 cmd             = 3;    //请求接口命令字
    required uint64 seq             = 4;    //请求序列号，保障唯一性，建议使用uuid
    required uint32 format          = 5;    //请求1，应答2，通知3，响应4
    required uint32 flag            = 6;    //body部分的加密方式：1 rsa加密 2 aes_cbc加密
    required string platform        = 7;    //mobile-ios mobile-android pc-windows pc-mac
    required string platformVersion = 8;    //客户端版本号
    required string token           = 9;    //客户端凭证
    required string appKey          = 10;   //客户端key
    required string timeStamp       = 11;   //时间戳
    required string sign            = 12;   //签名 md5((body base64)++(timeStamp))

    required uint32 bodyLen         = 13;   //body长度
    optional bytes body             = 14;   //请求数据
}