从0到100——知乎架构变迁史
159 浏览量
2021-02-21
00:08:20
上传
评论
收藏 438KB PDF 举报
从从0到到100——知乎架构变迁史知乎架构变迁史
淘宝用的是JBoss，框架是iBATIS，缓存服务器是自己开发的，基本遵循SNA架构，水平扩展，数据库是Oracle，阿里集团的
DBA几乎是国内最强悍的。目前淘宝的系统架构正在重构，计划用两到三年时间重写，目标有两个：
也许很多人还不知道，知乎在规模上是仅次于百度贴吧和豆瓣的中文互联网最大的UGC(用户生成内容)社区。知乎创业三年
来，从0开始，到现在已经有了100多台服务器。目前知乎的注册用户超过了1100万，每个月有超过8000万人使用；网站每个
月的PV超过2.2亿，差不多每秒钟的动态请求超过2500。
在ArchSummit北京2014大会上，知乎联合创始人兼 CTO 李申申带来了知乎创业三年多来的首次全面技术分享。本文系根据
演讲内容整理而成。
初期架构选型
在2010年10月真正开始动手做知乎这个产品时，包含李申申在内，最初只有两位工程师；到2010年12月份上线时，工程师是
四个。
知乎的主力开发语言是Python。因为Python简单且强大，能够快速上手，开发效率高，而且社区活跃，团队成员也比较喜
欢。
知乎使用的是Tornado框架。因为它支持异步，很适合做实时Comet应用，而且简单轻量，学习成本低，再就是有FriendFeed
的成熟案例，Facebook 的社区支持。知乎的产品有个特性，就是希望跟浏览器端建立一个长连接，便于实时推送Feed和通
知，所以Tornado比较合适。
最初整个团队的精力全部放在产品功能的开发上，而其他方面，基本上能节约时间、能省的都用最简单的方法来解决，当然这
在后期也带来了一些问题。
最初的想法是用云主机，节省成本。知乎的第一台服务器是512MB内存的Linode主机。但是网站上线后，内测受欢迎程度超
出预期，很多用户反馈网站很慢。跨国网络延迟比想象的要大，特别是国内的网络不均衡，全国各地用户访问的情况都不太一
样。这个问题，再加上当时要做域名备案，知乎又回到了自己买机器找机房的老路上。
买了机器、找了机房之后又遇到了新的问题，服务经常宕掉。当时服务商的机器内存总是出问题，动不动就重启。终于有一次
机器宕掉起不来了，这时知乎就做了Web和数据库的高可用。创业就是这样一个情况，永远不知道明早醒来的时候会面临什
么样的问题。
这是当时那个阶段的架构图，Web和数据库都做了主从。当时的图片服务托管在又拍云上。除了主从，为了性能更好还做了
读写分离。为解决同步问题，又添加了一个服务器来跑离线脚本，避免对线上服务造成响应延迟。另外，为改进内网的吞吐量
延迟，还更换了设备，使整个内网的吞吐量翻了20倍。
在2011年上半年时，知乎对Redis已经很依赖。除了最开始的队列、搜索在用，后来像Cache也开始使用，单机存储成为瓶
颈，所以引入了分片，同时做了一致性。
知乎团队是一个很相信工具的团队，相信工具可以提升效率。工具其实是一个过程，工具并没有所谓的最好的工具，只有最适
合的工具。而且它是在整个过程中，随着整个状态的变化、环境的变化在不断发生变化的。知乎自己开发或使用过的工具包括
Profiling（函数级追踪请求，分析调优）、Werkzeug（方便调试的工具）、Puppet（配置管理）和Shipit（一键上线或回滚）
等。
日志系统
知乎最初是邀请制的，2011年下半年，知乎上线了申请注册，没有邀请码的用户也可以通过填写一些资料申请注册知乎。用
户量又上了一个台阶，这时就有了一些发广告的账户，需要扫除广告。日志系统的需求提上日程。
评论0