Twitter的核心业务逻辑，在于following和be followed。进入Twitter个人主页，用户会看到自己关注(following)的作者最近发表的微博。所谓微博，就是一则短信。Twitter规定，短信的长度不得超过140个字符。短信不仅可以包含普通文字信息，也可以包含URL，指向某个网页，或者照片及视频等。这就是following的过程。
当用户写了一则短信并发表以后，用户的关注者会立刻在他们的个人主页中看到用户写的最新短信。这就是be followed的过程。
实现这个业务流程似乎很容易。核心是为每一个注册用户定制一个被关注者的表，主要内容是每一个关注其的用户的ID。同时，也定制一个关注者的表，主要内容是该用户关注的每一个作者的ID。当用户打开自己的个人主页时，Twitter先查阅关注者表，找到所有关注的作者的ID，然后去数据库读取每一位作者最近写的短信，汇总后按时间顺序显示在用户的个人主页上。当用户写了一则短信时，Twitter先查阅被关注者表，找到所有关注其的用户的ID，然后逐个更新那些用户的主页。如果有关注者正在阅读被关注者的Twitter个人主页，主页里暗含的JavaScript(客户端脚本语言之一)会自动每隔几十秒访问一下Twitter服务器，检查正在看的被关注者的主页是否有更新。如果有更新，立刻下载新的主页内容。这样关注者就能读到最新发表的短信了。
从作者发表到读者获取，中间的延迟取决于JavaScript(客户端脚本语言之一)更新的间隔以及Twitter服务器更新每个用户的主页的时间。
从系统架构上来说，传统的三层架构(three-tier architecture)足够满足这个业务逻辑的需要。事实上，最初的Twitter系统架构的确就是三段论。
网站的架构设计，传统的做法是三段论。所谓“传统的”，并不等同于“过时的”。大型网站的架构设计强调实用。新潮的设计固然吸引人，但是技术可能不成熟，风险高。所以，很多大型网站走的是稳妥的传统的路。
2006年5月Twitter刚上线的时候，为了简化网站的开发，他们使用了Ruby-on-Rails工具，而Ruby-on-Rails的设计思想就是三段论。前段，即表述层(presentation tier)用的工具是Apache WebServer，主要任务是解析HTTP协议，把来自不同用户、不同类型的请求分发给逻辑层。中段，即逻辑层(logic tier)用的工具是Mongrel Rails Server，利用Rails现成的模块，降低开发的工作量。后段，即数据层(data tier)用的工具是MySQL数据库。
Twitter的服务可以概括为两个核心——用户和短信。用户与用户之间的关系，是关注与被关注的关系，也就是following和be followed。对于一个用户来说，只读自己关注的那些用户写的短信。而用户自己写的短信，只有那些关注自己的人才会读。抓住这两个核心，就不难理解Twitter的其他功能是如何实现的了。
围绕这两个核心，就可以着手设计Data Schema，也就是存放在数据层(data tier)中的数据的组织方式。不妨设置三个表:(1)用户表:用户ID、姓名、登录名和密码、状态(在线与否)。(2)短信表:短信ID、作者ID、正文(定长为140字符)、时间戳。(3)用户关系表(记录关注与被关注的关系):用户ID、他关注的用户ID(following)、关注他的用户ID(be followed)。
当用户发表一条短信的时候，执行以下几个步骤:把该短信记录到“短信表”中。从“用户关系表”中取出关注他的用户的ID。有些关注他的用户目前在线，另一些可能离线。在线与否的状态，可以在“用户表”中查到。过滤掉那些离线的用户的ID，把那些关注他并且目前在线的用户的ID，逐个推进一个队列(queue)。从这个队列中，逐个取出那些关注他并且目前在线的用户的ID，更新这些人的主页，也就是添加最新发表的这条短信。
以上这几个步骤，都由逻辑层(logic tier)负责。前三步容易解决，都是简单的数据库操作。最后两步需要用到一个辅助工具——队列。队列的意义在于分离任务的产生与任务的执行。队列的实现方式有多种，例如Apache Mina就可以用来做队列。但是Twitter团队自己动手实现了一个队列——Kestrel。Mina与Kestrel各自有什么优缺点，还没人做过详细比较。
不管是Kestrel还是Mina，看起来都很复杂。如果逻辑层只在一台服务器上运行，那么对动态链表和静态数组这样简单的数据结构稍加改造，的确可以当做队列使用。Kestrel和Mina这些“重量级”的队列，意义在于支持联络多台机器、分布式的队列。
表述层的主要职能有两个。HTTP协议处理器(HTTP processor)拆解接收到的用户请求以及封装需要发出的结果。分发器(dispatcher)把接收到的用户请求分发给逻辑层的机器处理。如果逻辑层只有一台机器，那么分发器没有意义。但是如果逻辑层由多台机器组成，什么样的请求发给逻辑层哪一台机器，就大有讲究了。逻辑层的众多机器可能各自专门负责特定的功能，而在同功能的机器之间要分摊工作，使负载均衡。访问Twitter网站的工具可以是浏览器，也可以是手机，或者类似于QQ的电脑桌面工具以及各式各样的网站插件，以便把其他网站链接到Twitter网站上。因此，Twitter的访问者与Twitter网站之间的通信协议，不仅仅是HTTP，也存在其他协议。
三段论的Twitter架构，主要是针对HTTP协议的终端。但是对于其他协议的终端，Twitter的架构没有明显地划分成三段，而是把表述层和逻辑层合二为一，在Twitter的文献中，这种二合一经常被称为“API”。
综上所述，一个能够完成Twitter基本功能的简单架构如图2-4所示。2006年5月Twitter刚上线的时候，Twitter的架构与图2-4差别不大，不一样的地方在于加了一些简单的缓存(cache)。即便到了现在，从Twitter的架构中依然可以清晰地看到图2-4的轮廓。Twitter的功能注释图见图2-5。
图2-4 Twitter的功能基本框架图
图2-5 Twitter的功能注释图
Twitter工程师认为，一个用户体验良好的网站在用户的请求实现之后，应该在平均500ms以内完成回应。而Twitter的理想是达到200～300ms的反应速度。因此在网站架构上，Twitter大规模、多层次、多方式地使用缓存。Twitter在缓存使用方面的实践以及从这些实践中总结出来的经验教训，是Twitter网站架构的一大看点。Twitter的整体架构设计图见图2-6。Twitter平台图见图2-7。Twitter平台的构成见图2-8。
图2-6 Twitter的整体架构设计图
图2-7 Twitter平台图
图2-8 Twitter平台的构成
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
