关键词：
初期架构选型
在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年下半年，知乎上线了申请注册，没有邀请码的用户也可以通过填写一些资料申请注册知乎。用户量又上了一个台阶，这时就有了一些发广告的账户，需要扫除广告。日志系统的需求提上日程。
这个日志系统必须支持分布式收集、集中存储、实时、可订阅和简单等特性。当时调研了一些开源系统，比如Scribe总体不错，但是不支持订阅。Kafka是Scala开发的，但是团队在Scala方面积累较少，Flume也是类似，而且比较重。所以开发团队选择了自己开发一个日志系统——Kids（Kids Is Data Stream）。顾名思义，Kids是用来汇集各种数据流的。
Kids参考了Scribe的思路。Kdis在每台服务器上可以配置成Agent或 Server。Agent直接接受来自应用的消息，把消息汇集之后，可以打给下一个Agent或者直接打给中心Server。订阅日志时，可以从 Server上获取，也可以从中心节点的一些Agent上获取。
具体细节如下图所示：
知乎还基于Kids做了一个Web小工具（Kids Explorer），支持实时看线上日志，现在已经成为调试线上问题最主要的工具。（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框架的工程师，希望结合前面两个框架的特点，首先保持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
云计算技术—数据中心基础架构变迁史
目录文章目录目录数据中心基础架构变迁史1997-2007，第一波浪潮：裸机服务器基础架构2005-至今，第二波浪潮：虚拟化基础架构/云计算2010-至今，第三波浪潮：超融合基础架构（HCI）/私有云HCI的发展历程HCI的关键技术2014-至今，... 查看详情
云计算技术—数据中心基础架构变迁史
目录文章目录目录数据中心基础架构变迁史1997-2007，第一波浪潮：裸机服务器基础架构2005-至今，第二波浪潮：虚拟化基础架构/云计算2010-至今，第三波浪潮：超融合基础架构（HCI）/私有云2014-至今，第四波浪潮：应用定义基础... 查看详情
一文遍历大数据架构变迁史
...作者结合自己在数据中台领域多年实践经验，总结了数据架构知识、BI知识，以及分享给大家一些产业互联网实施经验。本文是系列文章中的第三篇。在前面两篇“关于数字化转型的几个见解”、“唯一性定理中的数据中台”提... 查看详情
阅读《大型网站技术架构》第三章心得
今天阅读了《大型网站技术架构》的第三章，这一章主要讲解了大型网站核心架构要素，并且概括的讲解了相应的实现方法。 软件架构除了系统功能需求外，还需要关注性能、可用性、伸缩性、扩展性、安全性... 查看详情
网站架构变迁
原文:网站架构变迁网站架构变迁Intro#从最早的html的学习到现在从单体应用迁移到微服务架构，所经历的网站架构也一直在变化，于是想写一篇关于网站架构变迁的文章。单服务器#最早的我们的网站只有一台服务器，网站应用+... 查看详情
互联网时代，我眼中的架构变迁
...更具体一点的说是系统架构、软件架构，或者是最常见的网站架构。本文就来探讨一下 查看详情
springcloud学习心得
...能路由、总线、鉴权等。SpringCloud基于SpringBoot实现微服务架构，它是Java项目从单体应用架构向微服务架构变迁的主流选择之一。 特性(1)分布式/版本化配置(2)服务注册和发现(3)路由(4)service-to-service调用(5)负 查看详情
余额宝技术架构及演进阅读心得
余额宝总结起来包括这样几个属性，第一它是一个传统的货币基金，但它把T+0做到极致，另外他管理大量的用户资产。同时他具备极简的用户体验，符合互联网精神。我们在网页、支付宝APP或者其他途径能快速方便的进行基金申... 查看详情
10本java架构师必读书籍
1、大型网站系统与JAVA中间件实践本书围绕大型网站和支撑大型网站架构的Java中间件的实践展开介绍。从分布式系统的知识切入，让读者对分布式系统有基本的了解；然后介绍大型网站随着数据量、访问量增长而发生的架构变迁... 查看详情
阅读心得8：《王者荣耀游戏服务器架构演进(完整版)》
...发的复杂度，这也是需要关注的问题。 功能约束，是架构设计决定性因素。基于游戏领域的功能特征，对服务器端系统来说，有以下几 查看详情
网上收集的“知乎网”技术方案架构
知乎的整个网站架构图如下： 知乎是国内很少的使用Python开发的一个网站，也很多值得我们学习的地方，从知乎让我们也可以了解到一些新的WEB技术。一、Python框架知乎目前使用的是Tornado 框架。Tornado全称TornadoWebServer，... 查看详情
互联网时代架构变迁
...更具体一点的说是系统架构、软件架构，或者是最常见的网站架构。 本文就来探讨一下互联网时代，技术架构的演进过程及其优缺点。 为了方便表述，我姑且把互联网的架构演进过程分为三个时代：单机时代、集群时代... 查看详情
阅读心得6：《首次公开！菜鸟弹性调度系统的架构设计》
阿里妹导读：菜鸟方舟(ark)是面向菜鸟所有研发的资源管理和运维平台，负责对菜鸟的基础设施资源进行管控，以支撑日常和大促的资源需求。弹性调度是菜鸟方舟的一个重要组成部分，也是方舟的一个重要的功能特性。 通... 查看详情
大型网站技术架构阅读笔记5
大型网站技术架构阅读笔记5这一次主要阅读了本书的对大型网站典型故障案例的分析以及在架构师中架构师的领导艺术。一般的故障现象，由于某应用发布后，数据库Load居高不下，远超于正常水平，持续报警。主要的原因... 查看详情
大型网站技术架构：核心原理与案例分析阅读笔记二
大型网站技术架构：核心原理与案例分析阅读笔记二网站架构设计时可能会存在误区，其实不必一味追随大公司的解决方案，也不必为了技术而技术，要根据本公司的实际情况，制定适合本公司发展的网站架构设计，否则会变得... 查看详情
《大型网站技术架构核心原理与案例分析》阅读笔记-01
...sp; 通过阅读该书籍我们能够更加清楚的树立大型网站的的技术发展历程，剖析大型网站技术架构模式，深入的讲述大型互联网架构核心原理，并通过一些典型的技术案例来讲述大型网站开发全景视图，该书籍深入的阐述... 查看详情
朱晔的互联网架构实践心得s1e4：简单好用的监控六兄弟
...种约定俗成的说法）：这两套体系都由收集器+存储+展示网站构 查看详情
大型网站技术架构：核心原理与案例分析阅读笔记四
大型网站核心架构要素之可用性 网站的可用性指标是网站架构设计中的重要指标，对外是服务承诺，对内是考核指标。所以说，一个高可用的网站架构是一个公司所需要具备的。而在影响网站可用性的众多因素中，硬件... 查看详情