老牌大型门户网站多年经验——搜狐服务架构优化

IT大咖说

发布于 2018-07-30 10:25:21

1.3K0

发布于 2018-07-30 10:25:21

文章被收录于专栏：IT大咖说

内容来源：2017 年 08 月 10 日，搜狐研发中心架构师陈伟在“第二届APMCon中国应用性能管理大会”进行《搜狐服务架构优化实践》演讲分享。IT 大咖说（微信ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：2625 | 7分钟阅读

摘要

搜狐业务横跨新闻，视频，社交，移动端，垂直领域等诸多方向，业务模式也非常多样化。在最近两年，搜狐的后台服务体系，运维体系，CDN架构，IDC架构都在快速的优化改进。影响用户体验的点都有哪些，如何优化，我们在这一轮搜狐服务的优化中进行了深入的思考和实践。本次将和大家分享在大型综合网站的后台架构优化，微服务体系，用户端连接优化，监控体系建设等方面的经验和教训。

嘉宾演讲视频回顾及PPT，请复制链接：http://t.cn/Rdv9UjA，粘贴至浏览器地址栏即可。

接入层优化

接入层优化其实没有太多的技巧，最核心的要点是离用户越近越好，这也是我们做接入层优化的主要思路。

自有节点的流量调度

我们在全国拥有众多的IDC机房，这种情况下最重要的是如何让用户访问离他最近的节点。因此在自有节点的流量调度上我们做了很多工作，这个过程中最难的其实是发现用户的真实位置，传统的做法是通过DNS体系实现整体调度，但是运营商的DNS或者说用户的DNS并不一定能反应真实的网络情况。为了更精准的调度，我们开始使用类似EDNS这样的协议，并且升级自身的DNS系统，采用更精准的IP库。

第三方CDN调度

搜狐在过去的十几年里一直都是采用自己的IDC方案，但是最近几年公有CDN也发展的非常快，在一些特定领域有很大的优势。所以我们使用了自建CDN加上第三方CDN的混合方案，这其中面临的核心问题还是调度，随着CDN的增加调度会越发麻烦。这种架构下就需要与第三方CDN结合的更紧密，获取到他们原始节点的位置，以及通过客户端这样的特殊方式探查当前网络环境下效果最好的CDN。

上文的方案依然是基于EDNS，在精准度上还是不够。为此我们采用了更进一步的方案，即客户端自主的测试域名对应的每个CDN的速度，然后结合服务器给的一定策略，综合主动的选择最优策略来访问。这个方案局限性在于无法在App以外的环境下获得很好的效果，另外在调度上也变得更加复杂。所以一般这种方案都是用在标准CDN访问的情况下，比如核心App有着大量的图片和视频。

以上所有策略都依赖于对全网环境和真实数据的了解，所有我们做了一套全网实时品质监控系统，数据源不光来自我们自身还有一些第三方的检查机构提供的原始数据。

协议优化

接入层优化除开从流量调度上着手，还可以介入协议优化。这方面优化效果比较好的就是SPDY和HTTP2，通过我们的测试发现响应延时降低到了原先的几分之一。实现这样的效果还需要做一些准备，主要是页面要自主的做适应这两个协议的工作。之前在web环境下域名会被打散，图片被存储在各个域名下，这样的方式在HTTP2中是不推荐的，因此我们在和业务线协调之后转而使用HTTPS，并且改进域名分布方式，获得了不错效果。

平台化

搜狐与很多围绕单一业务展开的公司不同，有着众多的业务线，且业务之间的联系也不是很紧密。而技术的快速发展，使得我们的技术栈不断的更新，变得越发复杂。这样的体系导致业务部门之间相对独立，没有全公司的应用运维管理更多的是基础运维。

平台化的应用能够有效缓解以上问题，它通过把一些公有的基础设施抽离出来，以降低业务线的负担。最近几年内我们逐渐将数据库、Redis集群、对象存储、图片处理等都做成公司内部的私有云形式，提供给业务线使用，这个过程中我们还花费了很多精力让这些组件来适应各种语言开发以及对不同模式的兼容。

SCS对象存储

SCS对象存储的底层系统是我们自己搭建的，目前已达到了百亿级的存储量，并且和传统的KV不同，这套系统不仅能和多家CDN对接，与图片处理、视频处理系统也能完美融合。

Redis集群

对于大多数业务Redis都是需要用到的缓存，因此我们针对Redis集群采用了Docker的资源分配方式并且提供自助化的申请平台。对比之前采用工单的方式，云化平台无需再考虑持久性和可用性问题。

监控报警

监控报警服务有Domeos提供，自动配置通用报警。数据源来着硬件统计信息，业务日志、负载均衡等，新开发业务几乎无需配置即可使用。

Docker & 微服务

我们自己研发了一个Domeos系统，它是基于Kubernetes的开源部署系统，在该平台下能够比较容易的完成业务上线、回滚、服务配置、跨机房应用以及持续集成等。它的主要作用不仅仅体现在线上环境的变化，实际上更多的是规范了整个公司的开发行为以及历史遗留问题。从成本上来看资源的复用大大提高，开发成本得以降低。

日志收集和分析

日志收集和分析的大致流程如上图所示。App应用运行在Docker中，控制台日志比较容易收集，对于散落文件日志会要求在上线之前进行配置。这些日志会经由Flume或Flumentd收集，再交由ELK、Kafka、Storm其中之一处理。

负载均衡与服务发现

Docker之所以不能简单的应用，很多时候都是因为负载均衡和服务发现不是很好做。所以我们在这方面做了很多工作。基层代理使用Nginx完成，由于动态部署的原因，造成每个容器的位置随时都会改变，变更之后的新IP信息会被Nginx获取到，而所有的外部应用通过Nginx访问的时候能够自动的进行负载均衡和服务发现。Nginx上还能做日志分析和监控，比如分析服务响应时间过长的原因。

反劫持

劫持主要有三个方面的影响，一是无孔不入的广告带来的糟糕用户体验，二是对于广告收入的影响，三是服务可控性无法保障，由于劫持导致改版升级无法顺利的抵达用户端。

对此的解决方案有两个，一是监控，利用全国的布点快速发现问题进行报警；二是投诉和协调，这也是最有用的方案，基本上能够解决大部分问题。而针对小区宽带的广告插入问题，更好的解决方式是HTTPS，但是由于一些兼容性和性能上的局限无法大规模的迁移到HTTPS上。

我今天的分享就到这里，谢谢大家！