虎嗅:四年覆盖9成互联网企业中高层的网站架构演变

本文涉及的产品
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
对象存储 OSS,20GB 3个月
简介: 本期大咖秀的分享嘉宾是虎嗅网联合创始人韩祖利老师,韩老师和阿里云资深架构师江南一起为大家分享了他们的上云实践。

直播视频:

                

                                                               (点击图片观看)

 幻灯片下载地址:https://oss-cn-hangzhou.aliyuncs.com/yqfiles/638c6edabb06d539f82d34539613ecaf.pdf

                                                     

在本次直播的开场,主持人阿里云架构师江南简单回顾了三月份阿里云组织的8场大咖秀直播活动。云栖社区3月份的大咖秀邀请到了游族网络,驴妈妈,小咖秀,空格,涂鸦科技,美柚,有货,微博等8位阿里云客户与阿里云资深架构师们一起分享他们的上云实战。往期视频及文字回顾 本期大咖秀邀请到了虎嗅网联合创始人韩祖利老师。

 

虎嗅网架构演进

 

技术架构演变:从单机到多机,系统不断解耦,架构不断完善,阿里云一路相伴


                
 

在最开始的时候,虎嗅的业务形态不是十分确定,整体访问量也不是太大,最初只使用单机,选择了阿里云ECS的低配机器。但是随着业务发展,虎嗅发现注册用户和每天需要发送的邮件越来越多,发送邮件问题成为了瓶颈。所以后来开始将Mail网关从原有系统中独立出来,再到后来网站的访问量越来越大,业务的压力也与日俱增,整体的产品逻辑也越来越复杂。导致数据库的压力越来越大,于是虎嗅网从原本的单机中将数据库独立出来,后来又将图片的服务器独立出来。


图片独立两个主要原因:

  • 第一:整个业务的压力不断变大,未来单机的ECS可能会变为多机,而多机则会存在静态资源同步的问题,所以提前将图片业务剥离出来。
  • 第二:就是随着业务的发展,虎嗅的各个平台对于所使用的图片资源的尺寸大小品质等都有不同的要求。

将图片服务器独立出来,可以解决这些问题。在韩老师分享了将图片服务器独立的一些经验之后又接着谈一些虎嗅网关于图片存储方面观点


图片存储的主要几个作用:


                
 

  • 裁剪:将图片内容分发到Web端和APP,同一张图用到的尺寸,对品质的要求都不一样,需要通过对图片等剪裁实现全能缩放、品质调整等功能,
  • 加速:对于用户而言,网页的响应速度非常重要,将图片服务器独立出来能将CDN直接挂到图片上,这样客户访问就会非常快。
  • 分发:当CDN发生故障或者线路发生故障时荣造成网站访问都到影响。虎嗅选择了使用多个CDN,当一个线路出现问题,将会快速切换线路,保证用户无感知。当用户或者编辑想向图片存储服务器上传图片时,服务器会自动同步到几个CDN上去,同步可以保证快速切换,并且起到数据冗余的作用。
  • 外图缓存:对于虎嗅这样的类似轻社区的公司而言,有时候不可避免要应用外部图片,而外部图片往往因为外部网站不希望占用其带宽,而使用使用防盗链,这样会导致外部图片不稳定,导致无图或者加载缓慢。虎嗅网采取的策略是自动缓存下载外图到本地服务器上。

因为当时虎嗅网开始研发图片存储技术的时间比较早,所以并没有使用阿里云的OSS系统,当时的图片存储系统属于使用ECS自建系统。


主持人江南在这里谈到:不仅是对图片的使用,还有裁剪等一系列要求,是当时虎嗅自建图片存储的原因。其实随着阿里云产品的不断演进,从架构上更建议用户将像图片这样的静态资源存储到阿里云的开放存储服务OSS系统;另外从成本上看,自建的存储往往是在云端购买ECS 配套的云盘,这个价格和OSS的价格相比几乎要相差一倍以上。韩老师也讲到,虎嗅对图片的存储还有一定的需求,这个对目前阿里云的很多用户而言都是常见的一个场景,阿里云OSS就针对于媒体提供了一些额外的服务,比如在图片这方面,阿里云OSS系统就可以对上传的图片进行像修图,添加水印这一类的操作,而用户在访问这些图片时只需要在其URL后加上一个样式的字符串,这时得到的图片就是经过裁剪或者是添加水印之后的图片资源。阿里云OSS不仅能将图片存储到服务器上,还能对图片进行一系列的处理。而且客户在调用这些处理时和其他的方式不同,用户只需要像访问网页那样发送一个URL,就可以得到处理后的图片。


除了对图片资源的存储处理以外,江南还建议虎嗅网的视频类资源也参考阿里云OSS及相关的一些服务,因为OSS上存储视频资源是可以和阿里云的媒体转码服务MPS产品直接互通,互通之后就可以对上传到OSS的视频自动调用用户事先定义好的MTS模板对其进行媒体处理,包括转码、截图、打水印、剪辑、按分辨率缩放,这些处理都能很方便地完成。这样在云上的用户,在今后遇到类似场景时就不必自己搭建应用服务系统来处理这些媒体数据资源。


韩祖利老师也非常认同江南的观点,韩老师认为当时虎嗅在自建图片存储时还没有这么完善阿里云OSS系统,如果当时能够使用OSS系统,虎嗅网的整个开发周期和成本将会降低很多。


图片服务器独立之后,虎嗅网又将像JS,CSS这样的静态资源独立出来,以便提高整体响应速度,业务量不断上升 系统压力也越来越大。于是虎嗅将单机ECS横向扩展成为多机的ECS来做计算。多机计算采用阿里的SLB来做多机前端的负载均衡,但是这是虎嗅发现计算问题解决了,但是数据库又面临巨大压力,于是采取在中间加入了缓存的策略,虎嗅在众多的缓存方式中选择了简单的MemCache。

 

主动式缓存管理:


                
 

在缓存管理方面,主动式缓存管理分为了两大部分,一部分是业务缓存,另一部分是基础数据缓存。


所谓业务缓存是指将基础数据经过业务处理缓存起来,举个例子比方说用户在访问虎嗅网的首页,这时候其实用户打开首页的过程需要系统数据库对十几张表进行查询,然后将整个数据处理整合之后再展现给用户。由于这个过程先是访问数据库,之后计算再去组合,导致过程比较长。所以虎嗅网将用户查询的数据先缓存起来,当其他用户再次访问相同内容时就无需等待过长的时间,这样整体上减少了CPU的计算量,包括后端服务器的查询量,用户等待的时间就比较短,用户体验上就会感觉非常快。


虎嗅网的缓存的管理还是采用了相对比较一般的方式,使用了map式的管理方式。其实对于缓存暂时没有更好的实现方式,所以使用map式的管理做了联动。当页面涉及的数据发生变化时,缓存会主动去清理那些无效的数据。


缓存管理的另外一个方面就是基础数据的缓存,基础数据缓存从某些角度来讲其实就是数据库某些基础数据的映射,当用户去读取某一个数据的时候,系统会将用户读取的数据全部缓存起来,当表中发生数据变化的时候,系统会主动清理掉之前对该数据查询的缓存。这是通过把整个MVC的Model层改造的方式实现的。这样成本降低了,而且仅对于写Model部分的工程师来讲会麻烦一点,而对于写业务逻辑的工程师而言则是感觉不到的。这样做的好处在于极大地降低了数据库的压力,提高了整个网站的响应速度。


在分享完关于缓存方面的经验,韩老师又接着和大家分享虎嗅网的架构演变,随着业务的不断发展,访问量越来越大,并且知名度也越来越高。虎嗅网也遇到了安全性问题,一个是最直接的攻击,比如DDos,CC还有一些暴力破解,跟踪扫描等。后来增加了防火墙并且使用的是阿里的高防服务。虎嗅经常会用到高达为几十个G的即时量,对于像虎嗅这样的创业公司或者是以轻模式运行的公司来讲,几十个G带宽的采购成本是非常高的,选用高防服务之后,整体的成本就会显得非常低了。对于一些CC的攻击,虎嗅的负载均衡使用了阿里云RDS服务。使用了高防服务之后就无需太过关心这些问题,攻击存不存在对网站而言影响不大。而且在受到攻击时,用户是感知不到的。对于网站工程师来讲则会收到通知,系统的压力也会有所上升,但是不至于使系统崩溃。

 

除了安全问题以外,还有一个问题就是垃圾,大家都知道,当网站影响力越来越大的时候,一些恶意用户就会希望发一些广告和垃圾信息。虎嗅网最初采用了一套非常严格的垃圾过滤系统,从内容到行为去过滤信息。但是后来发现,当这样的垃圾过滤规则越来越严格的时候,对用户的友好性就越来越差。但是如果不严格就又过滤不掉,所以后来接入了阿里云的反欺诈系统。这样当用户着陆到虎嗅的网页的时候,系统就可以得到当前用户的一个评分,由此判断用户的信用等级是良好还是其他,如果信用等级是良好,系统在后端就会减少垃圾过滤系统对用户的限制。但是对于信用评分特别低的用户,也就是说存在风险的用户,对于他们发的内容就会先进行审后发。再有就是对这样用户的行为进行判断,如果用户发布很多内容是重复的,或者行为像一个机器人,系统就会去跟踪其行为。如果说反映给系统的评分是风险,可能就会直接拒绝这样的用户。

 

主此人江南提到虎嗅也是反欺诈服务的典型用户,如果用户自己构建一个这样的评分过滤系统的话,因为底层用来支持的数据可能不足而容易造成“误杀”的情况,也会有很多“漏网”的情况。而阿里在安全方面的优势在于阿里云的安全产品包括其他的服务产品都是基于原有的海量数据信息,这些数据信息有的可能是来自阿里集团内部的业务系统,因为阿里集团本身内部的业务线也非常完整,非常庞大,我们十几年来接了大量的终端用户,对他们的行为可以说是心里有数。另外我们当然也会从互联网上利用我们的技术获取到一些行为分析的结论,动用这些结论加在一起形成一个庞大的知识库,支持我们像在垃圾过滤,反欺诈这样的一些应用场景内的一些安全的服务。

 

现在阿里的反欺诈产品现在已经成为阿里云云盾产品的一部分,阿里云也以很多不同的模式输出给用户去使用反欺诈的能力,像刚才韩总介绍的拿到一个用户之后,系统可以通过用户的基础信息,对其风险进行核实,判断其是否存在欺诈风险以及风险的程度,这就是云盾的反欺诈产品提供的一项服务。在这个服务的过程中,服务器端也就是业务端就可以根据返回的用户评分的结果去控制下一步业务执行应该往哪一个流程上走,在往流程上走的时候应该给与用户多大的权限。

 

此外在反欺诈方面,还有一些针对于风险识别,风险拦截这两个场景下的一些服务的模式。在风险识别这边,可以根据用户在客户端页面上提交上来的一些行为数据,通过反欺诈服务器对其进行分析,最后得到一个经过分析的风险识别结果,当业务系统调用这个风险识别结果的时候,就会判断出该用户是可疑还是存在风险,进而指导后续的业务流程走向。像这样的风险识别对于一些防营销作弊,薅羊毛这种行为,包括在支付过程中给予的一些保护,还包括在论坛上进行一些类似灌水,发垃圾信息,发违规信息这些场景的处理来说,都能起到非常好的作用。

 

另外像刚才提到的像风险拦截,现在大家在登录淘宝的时候,可能发现,原来传统的图片验证码的方式已经变成了滑块的方式,这其实也是风险拦截提供的一种服务方式,它通过滑块的这个过程对用户进行一个简单的判定,如果判定访问用户可信的话,会颁发一个可信签名的串,后续使用这个串进行登录等一系列操作,这样配合前端有效地控制风险。这样对于防止垃圾注册、恶意登录,像刷库撞库这些行为也都是非常有好处的。所以整体上来看呢,阿里云基于庞大的数据资源和强大的安全体系的技术的能力为像虎嗅这样的用户提供反欺诈的服务。

 

实际上像这样的服务使用由海量数据支持的云服务的优势还是比较明显的,如果说自建的话还是非常困难的。


在搜索方面,随着虎嗅网用户量的不断上升,搜索的量也变得非常大。搜索也会对系统造成非常大的压力,之前虎嗅网维护着一套非常大的搜索系统,但是发现不如使用阿里云的OpenSearch的服务,在使用之后发现,使用阿里云的OpenSearch服务能让网站集中精力关注的自身业务,整个系统不用自己去维护,虎嗅在对系统进行不断解耦的过程中也把评论系统,包括数据统计系统等都完全独立出来。因为评论量比较大,将评论系统从原系统中解耦出来,使得评论的页面的响应速度大大加快。

 

架构思想

                
 

总结虎嗅整个架构思想,从一开始到现在始终贯穿的就是解耦的思想。当你的业务不是非常稳定时,系统一定会存在巨大的变化,可能今天是这样,明天就会变一个样子,变化速度非常快。如果整个系统全部耦合在一起,就容易造成混乱,所以尽量去解耦。


另外一点就是保持简单的结构,简单的结构给系统带来的好处就是能够使维护非常轻松。网站的维护成本以及开发人员的成本都会极大地降低。


第三个就是尽量使用云服务,这样可以整个地去减少维护成本。我们经常会遇到这样的情况,比如在公司里面,看到某些系统的维护成本比其开发成本要高很多,但是当使用云服务这些非业务核心的服务或者系统的时候,几乎不需要自己去维护,对成本的降低是非常可观的。

 

虎嗅为什么选择阿里云呢?


                
 

其实阿里云的优势非常之多,第一是极大降低系统自建时间和人力成本。第二是系统集成非常的简单和高效。阿里云的优势之三在于健全的配套基础服务,虎嗅网的专职运维人员基本为零,也就是说使用阿里云相当于拥有了一个有强大技术支持的大型外包的运维团队。这样可以使我们专注于研发部分,在需要的时候就去购买相应的云服务。再一个优势就是阿里云的服务的系统的数据是互通的。当你使用OpenSearch,你不需要自己同步数据,只需要进行简单的设置就可以将数据同步到RDS上过去。

 

江南也谈到其实在阿里云设计之初就认为在阿里云生态内部的所有产品之间应该存在天然的数据互通和协作,像前面谈到OSS上存储的视频服务能直接和阿里云上的一个视频转码服务直接互通,这就是一个例子。除此这外,还有像韩老师刚才提到的OpenSearch和RDS这两个产品是天然互通的。其实更多的像阿里云有很多大数据类的产品或者数据仓库类的产品,它和阿里云经典的云产品之间也是存在着天然的互通性。因为我们现在看到,用户使用阿里云的基础云资源搭建自身的业务系统,这些业务系统必然会产生日常运营的业务数据,这些日常运营数据就可以天然地通过阿里云内部的互通灌入到一些像大数据的数据仓库里面去。

 

如果像虎嗅有一些未来数据分析的业务需求的话,这个产品之间的互通将会变得非常简单,几乎可以一键式完成。我们也能看到,阿里云的一些用户可能不是将全部的数据放在云上,有一些数据是存储到自己的一些IDC或者自建的机房里面,这样如果他们的数据产生在云端,那么就需要每天将这些数据先下载到本地再进行一定的处理,这个过程中不仅产生了大量的公网流量费用,而且对于网络带宽占用造成网络延迟,将原本可以进行实时分析的系统变成了一个只能够离线进行数据分析的系统,这可能对业务层面造成影响。

 

从这个角度讲,阿里云和其他云服务厂商比较大的区别就是我们提供了一个非常完善的产品线,用户想做的很多业务都可以在阿里云上找到合适的云产品加以解决,并且这些云产品之间拥有非常良好的互通性。这就比其他的一些云服务提供商所谓的能在某一点上提供服务要更占据优势。


韩老师表示,他们在网站开发运维过程中也有感受,虎嗅网也在进行一些大数据的尝试,在内部建立系统时总结时发现最大的困难是数据的同步问题,后来发现阿里云的数据互通优势就足以解决所遇到的问题。



关于虎嗅


虎嗅网是一个用户可以参与的商业资讯与观点交流平台,看起来更像是资讯与轻社区的结合,核心是关注互联网与移动互联网公司的起轨迹,产业潮汐的动力与趋势,以及互联网与移动互联网如何改造传统行业。虎嗅网对自己的定义是一家互联网公司,目标是聚合幼稚的创新信息人群


相关系列文章:


相关实践学习
Serverless极速搭建Hexo博客
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
相关文章
|
28天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
95 6
|
28天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
37 1
|
2月前
|
运维 供应链 安全
SD-WAN分布式组网:构建高效、灵活的企业网络架构
本文介绍了SD-WAN(软件定义广域网)在企业分布式组网中的应用,强调其智能化流量管理、简化的网络部署、弹性扩展能力和增强的安全性等核心优势,以及在跨国企业、多云环境、零售连锁和制造业中的典型应用场景。通过合理设计网络架构、选择合适的网络连接类型、优化应用流量优先级和定期评估网络性能等最佳实践,SD-WAN助力企业实现高效、稳定的业务连接,加速数字化转型。
SD-WAN分布式组网:构建高效、灵活的企业网络架构
|
29天前
|
Kubernetes Cloud Native 云计算
云原生技术深度解析:重塑企业IT架构的未来####
本文深入探讨了云原生技术的核心理念、关键技术组件及其对企业IT架构转型的深远影响。通过剖析Kubernetes、微服务、容器化等核心技术,本文揭示了云原生如何提升应用的灵活性、可扩展性和可维护性,助力企业在数字化转型中保持领先地位。 ####
|
2月前
|
存储 人工智能 算法
精通RAG架构:从0到1,基于LLM+RAG构建生产级企业知识库
为了帮助更多人掌握大模型技术,尼恩和他的团队编写了《LLM大模型学习圣经》系列文档,包括《从0到1吃透Transformer技术底座》、《从0到1精通RAG架构,基于LLM+RAG构建生产级企业知识库》和《从0到1吃透大模型的顶级架构》。这些文档不仅系统地讲解了大模型的核心技术,还提供了实战案例和配套视频,帮助读者快速上手。
精通RAG架构:从0到1,基于LLM+RAG构建生产级企业知识库
|
29天前
|
运维 Cloud Native Devops
云原生架构:重塑企业IT的未来####
随着数字化转型浪潮的汹涌,云原生架构凭借其高度灵活、可扩展和高效的特性,正逐步成为企业IT系统的核心。本文将深入探讨云原生架构的核心要素、技术优势以及如何引领企业实现业务创新与敏捷交付。 ####
|
2月前
|
Cloud Native Devops 持续交付
云原生架构:重塑企业IT的无形之手####
本文旨在探讨云原生架构如何成为推动企业数字化转型的核心动力,它不仅是一种技术升级,更是业务与开发模式的深刻变革。通过剖析云原生的核心要素——微服务、容器化、持续集成/持续部署(CI/CD)、以及DevOps文化,本文揭示了这一架构如何提升系统的弹性、可扩展性和敏捷性,为企业在竞争激烈的市场环境中赋予快速响应和创新的能力。不同于传统综述,本文将以一个虚构案例贯穿始终,直观展示云原生架构从理论到实践的转化过程,为读者提供一幅生动的技术蓝图。 --- ###
|
2月前
|
机器学习/深度学习 人工智能 前端开发
移动应用的架构演变与未来趋势
【10月更文挑战第20天】移动应用开发经历了从简单到复杂的演进过程,其架构设计也随着技术进步和用户需求的变化而不断演化。本文将探讨移动应用架构的变迁,分析当前流行的架构模式,并预测未来的发展趋势,旨在为开发者提供架构设计的参考和启示。
34 0
|
25天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
6天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。