携程APP好用的秘诀大起底 告诉你APP性能优化也有捷径可走！

   <p><strong>携程无线网络服务通道架构</strong></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/d59c223a980cdcd371e682f6f31e2bf3.jpg"></p>    <p>陈浩然介绍了2016年年初携程无线网络服务通道的架构图，其中无线APP有两个通道，一是Native，基于TCP设计的一套网络服务通道，连了TCP Gateway;二是Hybrid，用GS写界面，最后是通过传统的HTTP请求到达HTTP Gateway，TCP Gateway和HTTP Gateway最终链接到对应的SOA服务。</p>    <p>陈浩然表示，APP端是通过TCP连接连到TCP Gateway，转化后通过HTTP请求转化到后端一个标准的SOA接口当中，是一个标准的HTTP协议，前端通过TCP连接。</p>    <p>他在演讲中表示，TCP协议是传统协议，位于第三层，只控制网络层的传输协议，到了应用层还是需要设计一层应用层协议，类似RPC机制。携程的TCP Gateway分为两个部分，第一部分是在接入层管理TCP连接，主要基于Netty实现，负责App端TCP连接管理。第二部分是在路由层，基于Netty Zuul对服务进行路由、监控、安全、鉴权方面的管理。“实现方式就是一个可插件式的中间件，不同插件实现不同功能，如路由、安全、鉴权，数据格式最新的是基于Protocol Buffers实现的。”</p>    <p>HTTP Gateway功能较为简单，直接负责HTTP请求转发，路由层也是基于Zuul实现，功能上和TCP Gateway非常接近，数据格式就是传统JSON数据格式。</p>    <p>之所以需要Gateway，陈浩然解释道，因为携程业务很多，目前有20多个事业部，每个事业部有自己的服务集群，如果将所有的服务集群耦合在一起，每个BU的发布都会影响到其他BU。而设置Gateway进行服务转化，后端所有业务逻辑是完全分割开来的，相应的部署、发布、监控都是完全割离开来的，这样可以避免干扰，提升效率。</p>    <h3><strong>TCP与HTTP协议优劣势对比</strong></h3>    <p>谈及为什么要基于TCP实现时，陈浩然认为，主要是与HTTP协议对比得出的结论。HTTP协议优势非常明显，封装性好，HTTP协议更标准化，客户端和服务端解决方案相对成熟。但是劣势在于可控性很差，受网络影响严重，像HTTP1.1协议里的KeepAlive、Pipeline这些机制很难发挥作用。</p>    <p>而 TCP协议做网络服务，优势是可以针对网络连接、发送请求和接受响应，不同阶段可以完全分割很清楚，可以针对不同阶段做定制性优化。劣势是实现很复杂，因为要实现自己的应用层协议，开发成本和复杂度都比较高。</p>    <h3><strong>优化APP网络服务全生命周期</strong></h3>    <p>陈浩然表示，App对网络环境要求较高，不同的网络类型带宽和延迟差别非常大，其中延迟对网络性能影响最大。虽然服务端做了很多优化，但是如果网络性能不佳，依然会带来较大延迟，优化效果不如在App端做优化更好。</p>    <p>陈浩然将App网络服务生命周期划分为六个部分：一是DNS解析，二是建立连接，三是序列化网络请求报文，四是发送网络请求，五是接受网络响应，六是反序列化网络响应报文。“携程的做法是把生命周期每个步骤都进行细化，针对每个阶段进行优化。”</p>    <h3><strong>DNS解析的优化</strong></h3>    <p>DNS解析阶段有三个问题：一是解析有1%失败概率，二是域名解析地址影响网络服务，三是解析耗时容易产生延迟。</p>    <p>DNS解析优化有两种解决方案：一种是自建HTTP-DNS，用IP地址访问，发一个HTTP请求上来访问DNS服务器，可以根据客户端IP地址，告诉最合适服务端的IP地址是多少，但服务端开发部署成本比较高，而且第一次还是要发HTTP-DNS服务，前置服务带来额外延迟。第二个解决方案是在App端内置服务器IP列表，彻底取消DNS解析，但是客户端如何能够快速知道哪个服务端IP地址最好，需要自行判断。</p>    <p>携程采取的解决方法是在App内置服务IP列表，每个IP都有一个权重机制，会根据每次网络服务选择权重最高的IP地址。IP权重如何计算?携程在客户端用Ping值，每个服务IP启动之后立刻进行Ping值，根据Ping值的延迟时间进行计算，Ping值最低的权重最高，如果Ping不通可能是权重为零，最差的服务端地址。在网络环境切换时，IP权重会重新计算。</p>    <h3><strong>TCP连接的优化</strong></h3>    <p>这方面优化的重点是保持长连接。如果每次都建立连接整体耗时会非常大，用户体验非常差。携程的做法是配置一个TCP长连接池，专门用来存放长连接，根据网络环境不同更新连接池大小的上线。每次网络服务要发一个网络请求，用户点击查询，会优先从长连接中拿出一个空闲长连接出来进行网络服务，发完收到响应一切都成功了，会再将空闲长连接放回到连接池当中，等待下一次网络服务发起。如果TCP长连接服务失败，也会用短连接进行重试，会有一些限制条件，实际上是长短结合的概念。为了简单处理目前还没有支持Pipeline或者是Multiplexing机制。</p>    <h3><strong>弱网和网络抖动情况优化</strong></h3>    <p>携程会根据网络类型以及端到端的Ping值进行计算，首先将当前网络质量划分为好、中、差、非常差四类网络质量参数，然后根据参数调整长连接个数，在4G/WIFI会增加长连接池大小，目前长连接池是四个。其次根据网络质量参数调整TCP连接、发送请求，以及调整write或者read的超时时间。第三个方法是当网络类型切换时，一旦客户端IP变化，直接关闭所有长连接，现有正在发的网络服务会进行自动重试。</p>    <h3><strong>数据格式优化</strong></h3>    <p>陈浩然表示，之前携程App是使用自定义数据格式。后来调研了Protocol Buffers、Flat Buffers、Thrift这几种比较常见的格式，最终选用了Protocol Buffers。在携程特定的数据类型下，数据包大小可以降低，相对于之前的数据格式大小降低了20%-30%。序列化、反序列化时间也是可以降低10%-20%。如果大家自己开发这样一个网络协议，数据格式主要是考察两点：一个是数据包大小，一个是序列化和反序列化时间。数据包大小更重要，因为如果数据包太小，网络服务在传输过程中非常耗时。</p>    <p>“我的感触主要有两点：一是尽量减少网络连接时间，第二个尽量减少传输Size，尽量减少网络带宽和延迟的影响，延迟是必不可免的，带宽是受限制的，数据量越小越好，同时也是连接越少越好。”陈浩然总结道。</p>    <p>他认为选择格式和自身业务类型相关，Flat Buffers更适合于社交关系型数据存储。而Thrift不单单是一个数据格式的解决方案，更多是IPC解决方案，包含了一个完整IPC解决方案。陈浩然告诉听众，非死book的App就使用Flat Buffers，用于本地数据Modle存储。</p>    <h3><strong>网络服务重试机制</strong></h3>    <p>携程发现所有网络服务失败原因中有90%都是因为TCP连接失败。连接失败是否可以进行重试?陈浩然认为重试更多需要考虑可靠性问题，服务是否有幂等性问题，需要自己去解决。</p>    <p>携程在这方面的经验是如果在建立连接、序列化网络请求报文，包括发送网络请求这三个阶段失败，则直接进行重试，并不需要业务程序来通知需要重试。另外也可以自行确保服务幂等性，添加重试参数。“携程目前网络服务成功率已经从95.3%增长到99.5%。”陈浩然告诉听众。</p>    <p><strong>Hybrid网络性能优化</strong></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/a9c145d464802984a9c31c7594a2124a.png"></p>    <p>传统Hybrid网络服务基于系统接口，无法控制网络流程，平均网络服务成功率仅为97%左右，携程想了两个方案：一是拦截所有HTTP请求进行直接转发。二是用Hybrid网络接口方式进行转发。最终携程选择了第二个方案。</p>    <p>通过这张图可以看出，发一个网络请求是走Hybrid接口，由Native发一个TCP连接到TCP Gateway，并不知道TCP这个通道存在，还是正常发一个网络请求，是Get还是Post，告诉Hybrid库要发HTTP请求，以为还是HTTP请求，到Hybrid框架这一层，现在知道要发一个HTTP请求，把HTTP请求所有参数作为一个正常的TCP服务，传到TCP Gateway，这一层解析出服务号之后，其实要发HTTP请求，会拼接成一个正常的HTTP请求，再发到HTTP Gateway。对于HTTP Gateway而言，并不知道HTTP请求是从传统Hybrid还是H5网站发来的HTTP请求，还是从TCP Gateway这一层发送的请求，对HTTP Gateway不需要做任何改造动作。只不过在HTTP端Hybrid网络层和TCP Gateway做一些改造，这样HTTP请求做一个通道的动作去做协议转发。HTTP Gateway把包装过的HTTP请求转发到后端服务器之后，服务端响应之后会把相应HTTP响应报文再传给TCP Gateway，再会重新打包成一个正常携程协议TCP响应报文给客户端，会再把这个报文解开，类似于把一个HTTP请求发送完了，得到响应概念，再传给Hybrid业务层。需要做的改造只是针对HTTP里Hybrid网络发送接口需要进行改造，包括TCP Gateway要加一个功能。对于业务端，传统Hybrid业务层面开发者完全不需要知道这一层，HTTP Gateway也不需要这一层，对于业务来说是完全透明。</p>    <p>通过这样的通道架构，所有HTTP请求都会通过TCP Gateway进行中转，中转到HTTP Gateway，对于业务是完全透明的，平均网络服务成功率已经提升到了99.2%，同时还把网络服务耗时降低了30%。</p>    <h3><strong>海外网络性能优化</strong></h3>    <p>携程在海外没有IDC，除了CDN静态资源之外，业务服务所有的请求都需要回源，速度非常慢。如何破?</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/0b900c5dec81a2c286d67dd05de87c1b.png"></p>    <p>携程采用了Akamai(全球最大的CDN厂商解决方案)，有一个专署通道，到海外可以走Akamai专署通道，而不是传统Internet路由线路到达服务端。如果海外用户登录，Akamai通过定制域名获取服务端IP，之后所有网络服务会优先走Akamai通道，然后直接落地到携程IDC，不需要再走传统联通、电信运营商通道。当然陈浩然也表示，Akamai通道不是万能的，但平均耗时可以减少到30%，比传统Internet通道优化很多。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8cd671b4d9328c523f9110a7f3528541.png"></p>    <p>最新的无线网络服务通道架构图，不管Hybrid还是Native，都是走TCP连接做网络服务，Hybrid有一个内部API来控制去发送网络请求，不需要再让系统来控制HTTP请求到HTTP Gateway，而只是全部用Native TCP连接到TCP Gateway，如果是Hybrid请求被包装过了，就转成HTTP请求到HTTP Gateway，如果是正常TCP请求就直接发送到对应后端服务，这是最新的网络服务通道。</p>    <p>本文由陈浩然于2016年8月，在WOT2016移动互联网技术峰会性能专场《无线App网络服务通道治理和性能优化》主题演讲整理而成。WOT2016大数据峰会将于2016年11月25-26日在北京粤财JW万豪酒店召开，届时，数十位大数据领域一线专家、数据技术先行者将齐聚现场，在围绕机器学习、实时计算、系统架构、NoSQL技术实践等前沿技术话题展开深度交流和沟通探讨的同时，分享大数据领域最新实践和最热门的行业应用。</p>    <p> </p>    <p> </p>    <p>来自：http://network.51cto.com/art/201610/518594.htm</p>    <p> </p>