现在的位置: 首页 > 自动控制 > 工业·编程 > 正文

从有到优:百度前端接入技术的升级之路

2016-01-24 17:36 工业·编程 ⁄ 共 3038字 ⁄ 字号 暂无评论

Go语言在Baidu Front-End方面的应用实践

Go语言的广泛流行取决于部署简单、并发性好、良好的语言设计,以及执行性能好。这也是在重写百度前端这一项目上为什么考虑选用Go语言的原因所在。陶春华老师介绍说,促使重写Baidu Front-End的诱因主要基于以下三点:一是修改成本高。事件驱动的编程模型本身的编码和调试难度都很大;C语言本身的难度和开发效率有很多限制。二是配置管理方式落后。为单产品线设计,无法支持平台化要求;配置变更(修改、重载、验证)能力差。三是变更和稳定性的矛盾。例如程序出core也是比较头疼的事情。

在此前提之下,团队决定使用Go语言来重写前端,但是这里也遇到了一些问题,那就是GC(Gabage Collection)本身难以避免的时间延迟。BFE的需求是要在1ms以内,最大不超过10ms,一旦超过这个平均值,那么用户体验将大打折扣。而Go-BFE实测100万连接,400ms GC延迟。这就需要不断的对GC进行优化。

在这里陶老师也介绍了两种优化思路,第一个常见的方法就是将扫描的小对象合并成大对象,利用Array来合并一组对象。第二种方法精算性更高一点,可以把消耗内存较多的内容放到C里面,因为Go语言有一个CGO接口,直接通过Go调到C可以解决这个问题,只不过代价比较大。但是,问题和方案永远是相生相伴的。用Array技术重写网络库,所有的BFE将永远用Array来写,理论上可行。这里的问题又来了,第一风险太大,第二如果Go语言升级了,还能不能继续使用下去。

陶老师在这里介绍的解决方法叫做车轮大战。即,在一组工作进程中,进程和服务是等价的,某一个进程跟服务运作到一定时间之后关闭GC,让它休息,第二个进程代替它服务,以此轮换,构成一个车轮大战的局面。如果在不能直接解决GC问题的时候直接关掉服务,然后绕过它。这基本的方案思路也就是关闭继承多进程的轮转战。(如上图)

搜索速度优化的前进之路

在整个百度接入服务里,百度搜索一直秉承提供最基础的三个保障,那就是安全、快速、可靠。许霞首先介绍说,在对速度进行度量之前,先要对数据检测、收集。对客户端数据监测的特点是:可以检测任何对象,成本高,并且监测的指标很固定。JS埋点检测数据的特点是:可以检测任何指标,甚至可以检测每一条结果的速度。第三方数据检测的特点是:可以定制,并且有一定的海外监测能力,但成本高。

收集数据的意义在于可以很清晰的了解掌握用户的搜索习惯,这对PV、UV以及变现收入有很大影响。那么如何贴切搜索引擎的特点做搜索速度的优化?通过三个方面:接入质量提升、后端处理优化和前端渲染优化。接入质量提升主要有两个考察因素:延迟和带宽,对应的也就是优化RTT和传输效率。

后端优化其实就是整个搜索引擎的优化了,分为缓存优化和检索优化。缓存优化最基础的方式就是进入、淘汰机制等等,保证淘汰机制是最合理的。检索优化,则需要对硬件以及硬件方案的选择做一些深入考虑。在前端渲染优化方面,除了考虑节省时间之外还要考虑怎样让它定性化。

对优化做决定性决策只是其中的一种方法,还有更聪明的创新方法,那就是关于无线技术。这里面所涉及的内容包括手机终端、机站以及IP网络,传输速度当然是跟这三者有密不可分关系的。机站会根据自己能获得多少收益来处理用户的请求,尽量会缩小头部信息,进行一定程度的数据压缩。手机跟机站之间建立连接以维持这种连接关系。但电耗大是很关键的问题。百度搜索做了维持连接的一些机制,当用户页面空闲很长时间或者放在后台,就可以减少电量的消耗。(如上图)

全站HTTPS能否确保网站彻底安全?

2015年3月,百度搜索成为国内首家完成全站HTTPS改造的大型站点;且目前来看,全站HTTPS已经成为百度产品的首要标准;同时,统一接入平台也大幅提升了HTTPS的接入效率和性能。陈曦洋老师在开讲前是这样介绍大背景的。全站HTTPS的原因是为了让用户保持良好的使用体验,解决反馈较多的劫持和隐私泄露等问题。这些问题的具体case,包括页面被加上URL参数,不停刷新;页面被DNS劫持到其他网站;用户手机号码遭泄漏;白页,搜索功能异常等等。正是出于对用户数据的安全保密,维护网站正常运作的考量,百度专门成立了由百度搜索和运维部组成的HTTPS-SUPPORT团队,对HTTPS进行深入研究,提供完整的服务,保障用户正常访问百度原始产品。

陈曦洋老师在这里详细介绍了全站HTTPS改造的成本,这也是很多人都比较关心的焦点问题,这不仅涉及到证书的部署,还会涉及到激增的计算量,需要多次协商和握手,而用户端搜索的延迟将会给HTTPS改造需要解决的问题。除此以外,对于一个大型网站而言,架构如何解决多业务部署HTTPS的问题,巨大的页面和模板数量,以及如何解决实际部署中的各种问题,让用户无损/平滑的完成切换,其实是更具有挑战性的工作。

计算性能涉及到密钥(证书)的长度,1024和2048位在性能有什么差别呢?原来使用HTTP协议的时候,假设cps可以达到2w+,而转换成HTTPS之后,cps只能达到2-3千;在访问速度方面,使用了HTTPS之后,不做任何优化,访问百度的速度可能会恶化250-500ms,一些设计比较差的页面可能会恶化500-1200ms;在架构和产品成本方面,对于百度这样的综合性网站,牵一发而动全身,仅仅是在页面形式上就要改大量的模板,成本相当大。

那么有没有可选的优化方案呢?陈老师认为,性能优化上优先使用ECC。这里使用ECC密钥长度大小要比RSA和DH密钥长度短。在硬件的优化上则可以使用硬件加速卡,可以做TLS的远程卸载(小型站点在不面对大量的恶意请求时 完全可以通过纯软件卸载,只需要保证连接复用率)。在访问速度上的优化上,通过复用连接和协议优化可以尽量减少握手次数,就可以让它接近于原始HTTP的性能。怎么去减少握手次数?比如Session cache和Session ticket可以极大的减少用户在一定时间内再次访问时的计算开销,而HSTS能在浏览器内部完成HTTP到HTTPS的跳转,不再经过一次网络传输和浏览器开销。另外还可以用SPDY-HTTP2方案,优点是基于单连接,能进一步提升连接复用比例,协议支持header压缩,在无线网络下有重要意义,这些都可以提高访问速度。

除了对协议层进行优化之外,也可以在应用层做些优化,预连接就是一个很好的优化方案。比如在网页端或者客户端,用户发起访问请求之前提前把这个握手过程完成,减少延迟,这一点也很重要。另外陈老师建议站点在发展到一定规模时一定要做整体的接入规划,控制域名数量,一些服务需要变成公共的,比如图片,静态资源的存储和访问。

在最后,陈老师也回答了大家普遍比较关心的问题,那就是使用HTTPS就代表着绝对安全吗?事实上并没有绝对地安全,代码是人写的,很多问题都是实际的实现上或者依赖的其他环境上出现了漏洞,OpenSSL HeartBlood就是最典型的案例,甚至连随机数的生成和一些加密算法上也可能有人为埋下的漏洞,CDN回源这样的路径很多情况下也是使用的HTTP。百度使用HTTPS只能保护用户在浏览百度产品的时候的安全,但是很多手机号的泄露是第三方站点导致的(它们会通过非法渠道购买识别用户手机号的服务),这个问题并不能通过百度的HTTPS解决。但是相对于HTTP,HTTPS的安全防范性能更高,增加了坏人的做恶难度。

来源:InfoQ

给我留言

留言无头像?