知乎在我们不知不觉中走进了我们的生活，许多人包括我自己在内都把知乎当作了搜索引擎，个人认为，现在的百度使用起来让人感到厌烦，搜索出来的第一页往往都是一些广告，搜索出来的内容也几乎毫无价值，其中包括百度贴吧等论坛，文件不能共享，甚至有时要求必须下载百度贴吧App才能继续浏览。因此，知乎的崛起定是必然。
目前知乎在规模上是仅次于百度贴吧和豆瓣的中文互联网最大的UGC(用户生成内容)社区。知乎创业三年来，从0开始，到现在已经有了100多台服务器。目前知乎的注册用户超过了1100万，每个月有超过8000万人使用；网站每个月的PV超过2.2亿，差不多每秒钟的动态请求超过2500。
知乎使用的是Tornado框架。因为它支持异步，很适合做实时comet应用，而且简单轻量，学习成本低，再就是有FriendFeed 的成熟案例，Facebook 的社区支持。知乎的产品有个特性，就是希望跟浏览器端建立一个长连接，便于实时推送Feed和通知，所以Tornado比较合适。最初的想法是用云主机，节省成本。知乎的第一台服务器是512MB内存的Linode主机。但是网站上线后，内测受欢迎程度超出预期，很多用户反馈网站很慢。跨国网络延迟比想象的要大，特别是国内的网络不均衡，全国各地用户访问的情况都不太一样。这个问题，再加上当时要做域名备案，知乎又回到了自己买机器找机房的老路上。
知 乎团队是一个很相信工具的团队，相信工具可以提升效率。工具其实是一个过程，工具并没有所谓的最好的工具，只有最适合的工具。而且它是在整个过程中，随着整个状态的变化、环境的变化在不断发生变化的。知乎自己开发或使用过的工具包括Profiling（函数级追踪请求，分析调优）、Werkzeug（方便调试的工具）、Puppet（配置管理）和Shipit（一键上线或回滚）等。
随着知乎的功能越来越庞杂，整个系统也越来越大。知乎是怎么做的服务化呢？首先需要一个最基本的RPC框架，RPC框架也经历了好几版演进。
第一版是Wish，它是一个严格定义序列化的模型。传输层用到了STP，这是自己写的很 简单的传输协议，跑在TCP上。一开始用的还不错，因为一开始只写了一两个服务。但是随着服务增多，一些问题开始出现，首先是 ProtocolBuffer会 生成一些描述代码，很冗长，放到整个库里显得很丑陋。另外严格的定义使其不便使用。这时有位工程师开发了新的RPC框架——Snow。它使用简单的 JSON做数据序列化。但是松散的数据定义面对的问题是，比如说服务要去升级，要改写数据结构，很难知道有哪几个服务在使用，也很难通知它们，往往错误就 发生了。于是又出了第三个RPC框架，写RPC框架的工程师，希望结合前面两个框架的特点，首先保持Snow简单，其次需要相对严格的序列化协议。这一版 本引入了 Apache Avro。同时加入了特别的机制，在传输层和序列化协议这一层都做成了可插拔的方式，既可以用JSON，也可以用Avro，传输层可以用STP，也可以用 二进制协议。再就是搭了一个服务注册发现，只需要简单的定义服务的名字就可以找到服务在哪台机器上。同时，知乎也有相应的调优的工具，基于Zipkin开发了自己的 Tracing系统。
按照调用关系，知乎的服务分成了3层：聚合层、内容层和基础层。按属性又可以分成3类：数据服务、逻辑服务和通道服务。数据服务主要是一些要做特殊数据类型的存储，比如图片服务。逻辑服务更多的是CPU密集、计算密集的操作，比如答案格式的定义、解析等。通道服务的特点是没有存储，更多是做一个转发，比如说Sink。
文章来源：
https://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=403282668&idx=3&sn=c9d5c13f797adfde514c144e8f1cfce0&scene=21#wechat_redirect