微博平台第一代架构为LAMP架构，数据库使用的是MyIsam，后台用的是php，缓存为Memcache。
随着应用规模的增长，衍生出的第二代架构对业务功能进行了模块化、服务化和组件化，后台系统从php替换为Java，逐渐形成SOA架构，在很长一段时间支撑了微博平台的业务发展。
在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。
我们先看一张微博的核心业务图(如下)，是不是非常复杂?但这已经是一个简化的不能再简化的业务图了，第三代技术体系就是为了保障在微博核心业务上快速、高效、可靠地发布新产品新功能。

第三代技术体系
微博平台的第三代技术体系，使用正交分解法建立模型：在水平方向，采用典型的三级分层模型，即接口层、服务层与资源层;在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台。下面是平台的整体架构图：

如上图所示，正交分解法将整个图分解为3*4=12个区域，每个区域代表一个水平维度与一个垂直维度的交点，相应的定义这个区域的核心功能点，比如区域5主要完成服务层的技术架构。
下面详细介绍水平方向与垂直方向的设计原则，尤其会重点介绍4、5、6中的技术组件及其在整个架构体系中的作用。

水平分层
水平维度的划分，在大中型互联网后台业务系统的设计中非常基础，在平台的每一代技术体系中都有体现。这里还是简单介绍一下，为后续垂直维度的延伸讲解做铺垫：
接口层主要实现与Web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容(Feed)服务、用户关系服务及通讯服务(单发私信、群发、群聊)。
服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，其定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都属于这一类。图中使用泳道隔离，表示它们的独立性。另外一类为组合服务，通过各种原子服务和业务逻辑的组合来完成服务，比如Feed服务、通讯服务，它们除了本身的业务逻辑，还依赖短链、用户及发号器服务。
资源层主要是数据模型的存储，包含通用的缓存资源Redis和Memcached，以及持久化数据库存储MySQL、HBase，或者分布式文件系统TFS以及Sina S3服务。