洪海（孤星）阿里巴巴高级技术专家：大家好，我来自阿里巴巴，我的花名叫孤星，名字叫洪海，在阿里巴巴有5、6年，我做的事情都是没有脸的，前面大家做的事情都是有脸的。我做的事情叫网络，大家都在上面跑，但大家都看不到我。这是一个简单的介绍，在加入淘宝大概快6年了，这段时间，我比较单一，他们玩得比较多一点，我就只干一件事情，我们整个手淘的移动网关从无到有开始，今年很多产品开始已经有好几年双11，在YY、以及网络、网络优化有一些心得。这是我今天讲的内容的大纲，做得比较粗糙一点。

首先我介绍一下我们整个手淘的移动网络产品矩阵，下面具体产品的介绍。

在移动网络时代我们需要解决的一些问题。刚才大家也提到的很多端上要解决的问题，直播要解决的问题，在网络这一层是怎么看的，下面是四个方面，在PC时代，大家打开电脑，打开浏览器，打开浏览器就要浏览网站，但关闭浏览器时就无法与用户进行沟通，但在移动的时候，APP随时随地在在线，终端的数量急速暴涨，这是与PC时代完全不一样的，我们如何承接住海量的终端设备，尤其对于超级接口而言，终端的数量非常巨大。

第二，网络体验，在正棒的应用网络当中，数据交换当中存在这个问题，为什么会这样？首先第一个背景是来自运营商，大家知道运营商在过去的时代，从两级到三级到四级的过程当中，不同的运营商的通信技术在网络本身是比较差的，在PC时代我们固定在一个网络环境下使用有限或WIFI网络的接入，但特点是稳定，从来没有抖动过，带宽很高，在不同的网络支持的第一带宽，移动场景下大家的使用习惯完全不同的，大家可以在高速的情况下使用手机APP，可以在人群密集的商圈里使用APP，可以在一些信号比较弱的旅游景点、山区使用。这时候带来一个问题，在这么差的网络下，如何将用户的体验做起来，能够将这个网络做得更好，这是我们面临的第二个问题。

第三个问题是直播，在移动端不仅直播这一件事情，拿着手持设备在线的时候，我们需要时时刻刻跟朋友和这些合作伙伴沟通，让其互动形态由一个固定的办公场所转移到随时随地可以发生的情况，互动形态的变化，对网络技术提出了新的挑战。

第四个问题，大家经常在各个论坛上看到网络安全，因为办公场所的固定，安全问题是比较确定性的，而在移动网络中，大家会在各个移动场所下接入各个不同的WIFI，甚至会出现更高级的基站劫持的安全事件，那大量的信息安全就会泄露出来。

我们在建设移动的网络服务需要解决这四大方向的问题，那我们是怎么去做这件事情的，我们介绍一下我们的产品体系。

大家看到这是手淘的移动网络产品矩阵，如ACCS云通道服务，这是上面所有的基础服务，在这个服务上面，我们将前面提到的几个核心问题在这个基础通道上全部解决了，第一是在这个通道上构建了一个能够支持海量的长连接的一个接入网关，我们在上面构建了自有的加密协议，在保证优质的网络体验的同时能够提供一个安全的通道，并且这个通道实现了双功能，上面的应用网关和移动发挥更大的作用，以实现业务形态的各种需求。左上角是我们的应用网关，有三个产品：

一个是API网关，API网关构建一个标准的格式，通过集中式的管控，它能够将公共性的问题解决掉，专注于业务的逻辑。下面是MASS群发网关，这是消息推送的核心引擎最后一个同步网关，有一个邮件，有一个同步系统，它是用来解决插量数据的更新问题。

在移动时代更重要的是推送，AGOO是我们的推送服务，这下面是我们的一个移动配置网关，移动配置网关，大家在做服务端开发会有配置的变更，在服务器是可控环境下，推送是比较简单的，到移动时代，手机APP需要在特定的条件下，甚至在特定的版本里打开或关闭时，这时遇到一些问题，是如何准确、及时地送到客户端。这是我们目前做的一些事情。

下面我会一一向大家介绍下面的场景。

首先，我们在ACCS的云通道服务，刚才我们也提到过，我们最主要的几个问题，第一是海量的长连接，如何去提高这件事情？ACCS通道的第一个是AServer，在这个产品上进行深度的优化，占比很低，在同等数量上支撑更多的连接，并且实现了自己的Slight-SSL加密协议，相对于传统的SPS的泄密性能提高了3倍，在同样的硬件配置条件下，我们可以跑3倍的流量，而且在这个接入层的网关上，我们在过去的几年，从过去的HV1.1向2.2（音）过渡，如何做这些选择？是因为过许的淘宝大部分曾经是在HP的协议上，大量的流量都是HV的请求，天然会有一个很好的兼容，就可以快速地向所有的传统HP流量都跑到新的流量上。第二是双向通信，它做了主动推送能力，所以我们做了这样一个技术的选择。我们做了海量的长连接，如何提供一个双向通讯？ACCS提供了核心的服务，第一是管理了所有的在线服务，第二是状态设备，接入或离开网端时，在线状态实时更新。再是分发网关和接入网关，这样就提供了一个向后端业务提供的开放的服务能力，所有的服务可以通过整个通道体系上下行其信息，而这些所有的复杂消息的到达率、时延、加密的传输、接入层的调入都交给了中间的通讯服务来解决，这是前面一张图提到的后面的运用网关和腾讯服务都假设到ACCS通道之上的。

大家可以看到在上面有一个比较特殊的调度服务，这个调度服务是我们自己设计的一个新的调度系统，后面我会专门讲一下这一块，跟我们过去在PC互联网利用DNS（音）解析是不同的，这里会说一下为什么我们会选择这样一个。

这是简单的技术指标，这是我们的IOS、安卓的到达率和时延。

刚才我们提到了，我们构建这套系统，建立了通用的双向通讯能力，在里面管理着所有设备和其在线状态，提供双向通讯，只要做过服务端的同学都知道一个很重要的问题，关于容灾的问题，在过去，DMS（音）提供了一个广域的调度能力，当它出现问题时会将流量切走，NDS需要保持一个固定的状态，因为中间缓存会缓存IP地址，造成IP是无法实时感应到的，切走危险的流量这件事情的时间比较长，在网关上支持了一个重定向的能力，我们是双向的双重保障，可以将危险的流量切走，我们从网关下发将有问题的机房流量切走。另外，我们的这个调度服务有所不同的是，它不是一个标准的NDS协议之外，可以添加很多的业务需求，我们在APP上有用户说他遇到了一个问题，这个问题是什么，我们无法定位，像阿里的机房集群规模很大，如何在海量的数据里查询单个问题，这很困难。调度服务可以做到非常强的业务控制，可以将特定版本调到特定的接入层和机器上，那在运维和问题上都能够得到比较好的解决。这可以使得流量的切换是秒级的，问题一旦发生，配置下去，所有的流量都会快速地切走。这是整个ACCS的通道，它在底下构筑了一个基础服务，我们在一个城市里，要先修一条“路”，我们修了这条“路”，要保持交通顺畅，需要一根“指挥棒”，在此基础上，你要搬货，不能人拿着一个沉重的货物到处走，需要汽车，但每一种货物的汽车是不一样的，上面提到了一些应用网关。

首先介绍一个我们的API网关，它比较传统，比较简单，是传统的UI，我们为什么做这件事情？首先是这样的，如果说仍然像过去一样，我们是一个分散的网关，大家用不同的UI格式去反馈，每一个请求到了不同的机器让，需要每个业务团队去构建其运维、监控以及各种各样的安全防控体系，这里带来的问题是要进行分散，这里使得编程的模式保持一致性，统一的网关起的作用是通用性集中到这个网关上，进行缓存服务、限流、安全的风控监测、风控保护，都可以其中在统一的网关上面，大家可以看到。那构建一个网关，最初的时候经历了一个很变态的过程，因为这个网关是一个JAVA，需要编写代码，阿里有一个框架是DOUBLE和ABC（音），所有都会到这个网关上进行编程，这是无法忍受的，持续下去的话，集团在上面编程，是不可持续的，所以我们做的第一件事情是动态发布，我们可以发布一个接口，并且正确地调用后面发布出来的服务，这是第一件事情。当你有几千台、上万台机器的时候，每年收到的成本账单，下一年估算的时候，你心里就会发毛，于是我们在此基础上实现了一个新的指点模式，从ACCS直接就到业务端上，将整个技术实现转化成一个容器内的微服务，放在的业务方的服务器上，并进行交互，在这个直连模式完成之后，整个网关数千台的成本全部消失了。

在经历了这几件事情以后，这个网关能帮我们做限流，进行缓存，帮助我们做安全的风控，这是运行时的功能，但作为一个业务系统的服务的话，会了解它所暴露给移动端的这些接口的质量以及有多少调用量，错误出现了哪一些，错误有没有增长，它的增长消费端的情况是怎样的，在上面依赖阿里大数据分析的能力，构建了一套实时分析的引擎。另外API网关本身是构建一种标准，很容易构建一套标准的监控体系，在此基础上通过数据分析、采集，然后产生了针对于每一个业务服务以及每个APP需要看到的它在使用这个网络服务上的状况，可以监控其网络质量有没有波动，有没有错误，可以快速地发现线上的问题。这是API网关。这个网关做得比较久，我一开始来的时候就做这件事情。

后面介绍的是推送网关，大家都知道，移动端有一个最大的特性是能够将消息推送我们的用户，那推送消息到用户的这件事情，这些年来在不断地发生变化，在国内厂商，安卓和IOS“风火两重天”的体系，安卓到了国内，更进步的事情是每家厂商自干一票，这件事情带来了巨大的困扰，我们也在不断地在上面不断地打磨，现在由三块组成：第一是服务，第二是通道，就是端上的SDK。

第一是采用了多通道的推送能力，前面建设的ACCS是自主的通道，这个通道存在的时候优先选择到达率最高的通道。此外，我们会在不同的场景下根据用户的终端设备情况去显示适合的厂商的推送通道服务来达成，那对于海外，我们提供了一个海外的加速，通过阿里云强大的云机房和直连的海外的带宽，我们通过直连将消息推送到海外。这是推送服务。

刚才也有嘉宾提到了推送服务的量非常巨大，所以这个服务是提供给友盟和阿里云在使用的，在设备上有各种各样的问题，我们采了很多年，也积累了很多经验。

第三个介绍一下我们的群发网关，群发网关这件事情呢，前面的同事讲的是直播，直播这件事情是比较头痛的，就是点到点的聊天是我发一条消息，你收一个消息，亿而直播的产品是一大堆人在房间里有一个人发了一个消息，通知到所有人，房间里的人数就称羡了几何的增长，房间里有一万人，就等于10万的KPS（音），如果是一个大的电视直播，有百万人在线，如果你这时候有10、8个人在发言，那你就会接收到一千万的KPS（音），那怎么将巨大的流量消化掉，这就变成了MASS系统上的挑战。

我们的设计思路是这样的，我们这里将房间分别打散到不同的机器上，也就是说每台机器上都是这个房间的一部分人，那通过这种思路，那我们可以水平地扩展扩充，只需要单击能够承载的人数，理论上是可以扩充支持更高的在线用户数，这是一个。那直播也出现另外一个问题，并不是每一个直播都是那么热门的，假设一个直播只有10个人，你假设放在一千台机器，这是另外一个灾难。那我们并不知道直播间的人数是怎么变化的，一开始人很少，又很多，又变得很少，我们需要有动态的分配能力，要调整用户落在的机器数上面。这是我们的MASS群发应对直播的群发网关。

多维群发，像ATLAS这些技术，都存在一些问题，他们需要通知指定设备的用户去更新，特别是打补丁，这个问题出现在华为的机型或华为的某一个机型上，如果没有这样一个机制，我们要做的事情是让所有的客户端都定时服务器。那大家可以想象，如果一个用户APP，每天会打开服务器，99%是没有用的，因为没有任何变化，这是一个白搭的问题，那如何去解决这个问题？那我们在此基础上构建了一个多维群发的功能，这个功能说起来也挺简单的，以前只提到ACCS在设备注册时包含了端上的设备信息，我们将这些设备接入到搜索引擎了，我们就可以快速地检索任何符合这些维度条件的设备的标识，然后我们通过这个设备标识，通过MASS向下面所有符合条件的用户设备发起通知，通知它们来更新，更新我们的补丁或做我们的动态，那通过这个实践，我们手淘HODPS（音）和ATLAS的更新的调用量下降了99%，特别是HODPS（音），它是小维度的。

最后是讲一个我们的Orange移动配置，这与MASS的多维群发有点像，那多维群发来自于说我根据现在设备的情况其判断，然后主动地下行，那前面也提到网关，网关是整个应用生存期中客户端必须去经过的一个通道，那我们在这上面有一个CHECK，是一个出发期，是有条件的，就看请求是否符合版本，以及手机端配置的版本，这个配置的版本在服务端是否已经被更新了，在上面有一个控制台，发布一个配置以后，版本进行升级，直线更新过这个版本的客户端在调用网关请求时，携带的版本号是旧的版本号，这个CHECK就要检查是否去通知去更新这个配置，一旦发现这个符合更新的条件，就会通知到移动端上去，通过这个形式可以将配置快速地更新。大家可以看到，因为它是借助应用网关的弹入请求来达成的，那到达率是极高的，只要客户端没有更新，它就会触发通知，我们可以认为更新率几乎是100%，那它的应用场景是什么？我们在双11的时候，包括平常的大数据，会在一个特定的时间点上要开启一些配置，比如说我要在零点的时候开始一起一些配置，那这些配置如何更新？我们会体现下发规则，将后端的开关指定打开的时间，很快，这些所有在线设备只要它有活跃，它就全部都会更新到。那这里有提到一个问题，所有做过大系统运维的人都知道，我们线上的服务去发布都是进行观察，是一个灰度过程。移动端一旦匹配条件就对所有的用户去发送，一旦有错误，就所有都遭殃的，同样需要一个灰度的过程，我们在ORANGE提供灰度的机制，在现有的符合条件的设备挑选一部分，通过下行通道推送一些通知观察局部的更新用户是否是稳定和正常的，通过一个机制来避免大规模的线上故障。

今天我介绍了一下手淘在无线网关这一层的产品，我们修了一条“马路”，在ACCS，造了很多车子，麻烦在移动应用上的很多需求。谢谢！

主持人：下面是Q&A环节，没有什么问题？

   提问：我想问一下，API网关，有的时候是需要对客户端去屏蔽一些服务，会有很多维护，但前端不需要做很多的交互，我可能会做一些API接口的汇聚，这一块的力度控制，还有跟后端恢复之间它可能有一些依赖性，这一块是怎么考虑的？比如查一个产品，后面要关联性的查好多服务，是否要做很复杂的逻辑，将后面的API调用，与服务的调用统一起来，会不会导致它比较复杂？

洪海（孤星）阿里巴巴高级技术专家：我们在这个过程当中经历过一个事情，我们打开一个页面，这个页面有16个功能，我们的办法是建立一个很大的接口，从线上的稳定性而言是不可取的，如果是低稳定的API，我们称为P1级和P2级的保障，我们不推荐业务方采用的方式，我们基本采用两种形态。按照FACEBOOK的PLK（音），由网关负责多发多种请求。你有6个请求，但发上来只有1个请求，在网关进行拆分，分发到不同的网关，经过多路的消息，分发请求，做到每一次都是独立业务的完整包来解决这个问题，将风险隔离开来，体验上又比较接近。

提问：我问一个问题，刚才老师讲的是网关直连，将服务器的能力移到业务化，是不是API就不需要那么多服务器的，所有都往API走？

洪海（孤星）阿里巴巴高级技术专家：如果全部转换为直连模式，整个网关就提供了一个插件的形式落在业务端上，需要提供更强的后端的转化调度能力。网关的地址落在接入层，ACCS上，这是透明的，不需要知道任何逻辑。