分享知乎使用Python的异步框架Tornado的经验事例

2010年10月，包括李申申在内的初始架构选择，最初只有两名工程师；到2010年12月推出时，有四名工程师。Python是知乎的主要开发语言。因为Python简单强大，可以快速上手，开发效率高，社区活跃，团队成员更喜欢。使用Tornado框架的知乎。因为它支持异步，非常适合实时comet应用，简单轻量，学习成本低，然后是FriendFeed的成熟案例和Facebook的社区支持。知乎的产品有一个特点，就是想和浏览器端建立长连接，方便Feed和通知的实时推送，所以Tornado更合适。起初，整个团队的所有精力都集中在产品功能的开发上，而其他方面基本上可以节省时间和最简单的方法来解决。当然，这在后期也带来了一些问题。最初的想法是使用云主机来节省成本。知乎的第一台服务器是Linode主机，内存为512MB。但网站上线后，内部测试的受欢迎程度超出了预期，很多用户反馈网站非常慢。跨国网络延迟大于预期，特别是国内网络不平衡，全国用户访问情况不同。这个问题，再加上当时要备案域名，知乎又回到了自己买机器找机房的老路上。买了机器，找了机房，又遇到了新的问题，服务经常下降。当时，服务提供商的机器内存总是有问题，总是重启。最后，有一次机器停机了，然后知乎做了Web和数据库的高可用性。创业就是这样的情况，永远不知道明天早上醒来会面临什么样的问题。这是当时阶段的架构图，Web和数据库都是主从。当时的图片服务托管在拍云上。除了主从，读写分离也是为了性能更好。为了解决同步问题，增加了一个离线脚本的服务器，以避免对在线服务的响应延迟。此外，为了改善内网吞吐量的延迟，还更换了设备，使整个内网的吞吐量增加了20倍。2011年上半年，知乎已经非常依赖Redis了。除了最初的队列和搜索，后来像cache一样开始使用，单机存储成为瓶颈，所以引入了分片，同时达到了一致性。知乎团队是一个非常相信工具的团队，相信工具可以提高效率。工具实际上是一个过程，工具没有所谓的最佳工具，只有最合适的工具。而且它在整个过程中，随着整个状态和环境的变化而不断变化。知乎自己开发或使用的工具包括Profiling(函数级跟踪请求，分析调优)、Werkzeug(方便调试的工具)、Puppet(配置管理)和Shipit(一键上线或回滚)等。日志系统知乎最初是一个邀请系统。2011年下半年，知乎上线申请注册。没有邀请码的用户也可以填写一些信息申请知乎注册。当用户数量达到更高的水平时，就会有一些广告账户，需要扫除广告。日志系统的需求提上议事日程。该日志系统必须支持分布式收集、集中存储、实时、可订阅和简单。当时研究了一些开源系统，比如Scribe，一般都不错，但是不支持订阅。Scala开发了Kafka，但团队在Scala方面积累较少，Flume也差不多，而且比较重。因此，开发团队选择开发自己的日志系统——Kids（KidsIsDataStream）。顾名思义，Kids是用来收集各种数据流的。Kids参考了Scribe的思路。Kdis可以在每个服务器上配置Agent或Server。Agent直接接收来自应用程序的消息。收集消息后，可以直接打给下一个Agent或中心Server。订阅日志时，可以从Server或中心节点的一些Agent上获取。具体细节如下图所示：知乎还基于Kids制作了一个Web小工具（KidsExplorer），支持实时在线日志已成为调试在线问题的主要工具。Kids已经开源，放在Github上。事件驱动的架构知乎有一个特点。添加答案后，后续操作实际上只更新通知和动态。然而，随着整个功能的增加，更新索引、更新计数、内容审查等操作越来越多，后续操作也越来越多。按照传统的方式，维护逻辑会越来越大，维护性会很差。这种场景非常适合事件驱动，所以开发团队调整了整个架构，做了事件驱动架构。此时首先需要的是一个消息队列，它应该能够获得各种事件，并且对一致性有很高的要求。针对这一需求，知乎开发了一种叫Sink的小工具。得到消息后，先保存本地化，持久化，再分发消息。若机器挂断，重启时可完全恢复，确保消息不会丢失。然后通过Miller开发框架，将信息放在任务队列中。Sink更像是串行信息订阅服务，但任务需要并行处理，Beanstalkd派上用场，全周期管理任务。如下图所示：例如，如果用户现在回答问题，系统将首先将问题写入MySQL，将信息插入Sink，然后将问题返回给用户。Sink通过Miller将任务发送给Beanstalkd，Worker可以找到并处理任务。刚开始上线的时候，每秒有10个消息，然后就有70个任务。如今，通过当前的事件驱动架构，每秒有100个事件和1500个任务。2013年，知乎每天都有上百万的PV进行页面渲染优化。页面渲染实际上是计算密集型的。此外，它还具有IO密集型的特点，因为它需要获取数据。此时，开发团队对页面进行了组件化，并升级了数据获取机制。知乎根据整个页面组件树的结构，从上到下分层获取数据。当上层数据已经获得时，下层数据不需要继续下去，几层基本上有几次数据获取。结合这个想法，知乎自己做了一套模板渲染开发框架——ZhihuNode。经过一系列的改进，页面的性能有了很大的提高。问题页面从500ms减少到150ms，Feed页面从1s减少到600ms。服务架构（SOA）随着知乎的功能越来越复杂，整个系统也越来越大。知乎是怎么做服务的？首先需要最基本的RPC框架，RPC框架也经历了几个版本的演变。第一版是Wish，它是一个严格定义序列化的模型。STP用于传输层，这是一个非常简单的传输协议，在TCP上运行。刚开始用的还不错，因为刚开始只写了一两个服务。然而，随着服务的增加，一些问题开始出现。首先，Protocolbuffer会生成一些描述代码，这些代码非常冗长，在整个库中看起来非常丑陋。此外，严格的定义使其不方便使用。此时，一位工程师开发了一种新的RPC框架——Snow。使用简单的JSON进行数据序列化。然而，松散的数据定义面临的问题是，例如，如果服务需要升级和重写数据结构，就很难知道使用了哪些服务，也很难通知它们。错误经常发生。因此，编写RPC框架的第三个RPC框架工程师希望结合前两个框架的特点，首先保持简单，然后需要相对严格的序列协议。这个版本介绍了ApacheAvro。同时，增加了一种特殊的机制，可以插入传输层和序列协议层，可以使用JSON或Avro，传输层可以使用STP或二进制协议。然后建立一个服务注册发现，只需要简单地定义服务的名称就可以找到哪台机器上的服务。同时，知乎也有相应的调优工具，基于Zipkin开发了自己的Tracing系统。知乎的服务按调用关系分为三层：聚合层、内容层和基础层。按属性可分为数据服务、逻辑服务和渠道服务三类。数据服务主要是一些特殊类型的数据存储，如图片服务。逻辑服务更多的是CPU密集和计算密集的操作，如答案格式的定义和分析。通道服务的特点是没有存储，更多的是转发，比如Sink。这是引入服务后的整体架构。目前，知乎在产品方面保留了以下关键点：1。知乎基础模块中的一个问题对应于n个答案，一个答案对应于n个评论，因此我们可以将基础模块称为1个问题-n答案-n评论模块。假设知乎架构模型中只有基本模块，会是什么样的场景？也就是说，随着时间的推移，信息流不断生成新内容，并迅速替换和冲走旧信息。这种线性显示对基本模块没有区别，对用户来说将是一场灾难：在简单列出的线性信息海洋中，用户吸收所需信息的成本过高；信息流就像一条河流，那些具有挖掘价值的信息点转瞬即逝，也就是说，信息价值被严重挥霍；用户不能从信息河中“舀”有价值的信息点，信息可见但不可用，不能产生长期效应。知乎的产品设计师很好地认识到了这些潜在的“灾难”知乎的产品设计师很好地认识到了这些潜在的“灾难”，并对每个问题点进行了有针对性的产品设计方案。以下木柄逐一分析。2.主题模块主题模块用于解决“用户在线简单列出的信息海洋中吸收所需信息的成本过高”的问题。在知乎中，每个基本模块（1个问题-n答案-n评论模块）都可以添加“主题”标志，“主题”描述了基本模块的“类别”，主题模块和基本模块是多对多的映射关系（many2many）。事实上，在以内容为核心的网站组织架构模型中，为内容添加“logo”的做法并不少见。许多网站称这种“logo”为标签（如lofter）。然而，知乎的话题比普通网站的标签更遥远：知乎的话题不像标签那样孤立。它定义了一套组织主题的数据结构。请注意，主题本身是基本模块的组织形式，有一套数据结构来描述主题的组织形式，所以我们可以称这个数据结构为“描述结构组织的结构组织”，知乎本人就是这样介绍这个“结构组织的描述”的。：知乎的所有话题都是通过父子关系形成一个有根无循环的有向图；根题是所有话题的顶级父题；请不要直接将根题绑定到问题上。3.发现模块发现模块解决了信息流像河流一样流动的问题，具有挖掘价值的信息点转瞬即逝，即信息价值被严重挥霍。3.发现模块发现模块解决了信息流像河流一样流动的问题，具有挖掘价值的信息点转瞬即逝，即信息价值被严重挥霍。发现模块主要由推荐和流行两部分组成。热门内容是由用户群体行为制作的“内容选择”，推荐内容是知乎运营商对“群体行为”的补充和改进，最大限度地减缓有价值的信息流量或二次“逆流”，旨在“浮动”和“停留”有价值的信息。此外，值得一提的是，如果发现模块是构建在知乎基本模块上的信息“停留模块”，那么主题模块也有一个“停留模块”——“主题本质模块”。发现模块是挖掘整体有价值的信息，而“主题本质模块”挖掘主题有价值的信息，使有价值的信息在不同的组织维度上“停留”，而不是被大量的信息流冲走。4.收集模块收集模块解决了用户无法从信息河中“舀”有价值的信息点，信息可见但不可用，无法产生长期效果的问题。收藏功能是许多内容为王的网站架构的重要组成部分，使用户能够从广阔的信息流中舀出他们感兴趣的勺子。知乎的收藏模块支持创建收藏文件夹，即用户可以重新组织收藏内容并存储在相应的收藏文件夹中。此外，知乎的收藏模块还走得更远，用户组织的收藏夹可以设置为“公共”状态，并与其他用户分享。也就是说，用户的自私行为（收集他们感兴趣或有帮助的内容）产生了利他效应（其他用户也可以看到他人的收藏夹并从中受益）。从内容组织的角度来看，知乎的收藏夹不仅提供了“舀”保存信息的功能，还起到了“停留”和“浮动”优质信息的作用。5.知乎日报模块知乎日报模块是一个特殊的模块。它不是知乎的主要模块。您可以将其理解为知乎产品的衍生模块。事实上，它也从另一个角度回答了信息价值被严重挥霍的问题。知乎日报模块和知乎主模块采用松耦合架构模式，是知乎庞大优质内容生产机的二次开发。《知乎日报》采用“日报”的方式，每天组织一次知乎产生的经典内容。知乎日报的简单布局和呈现更符合人们在移动终端的阅读习惯，让那些觉得在移动终端使用知乎不方便或想在碎片化时间阅读的用户有一个更贴心的知乎产品可供选择。

以上就是关于分享知乎使用Python的异步框架Tornado的经验事例的相关介绍，更多分享知乎使用Python的异步框架Tornado的经验事例相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对分享知乎使用Python的异步框架Tornado的经验事例有更深的了解和认识。