一、微博平台架构变迁
1、微博平台第一代架构为LAMP架构，数据库使用的是MyIsam，后台用的是php，缓存为Memcache。
2、随着应用规模的增长，衍生出的第二代架构对业务功能进行了模块化、服务化和组件化，后台系统从php替换为Java，逐渐形成SOA架构，在很长一段时间支撑了微博平台的业务发展。在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。
3、微博平台的第三代技术体系，使用正交分解法建立模型：在水平方向，采用典型的三级分层模型，即接口层、服务层与资源层；在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台。
二、水平分层
1、接口层主要实现与Web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容服务、用户关系服务及通讯服务。
2、服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，其定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都属于这一类。
另外一类为组合服务，通过各种原子服务和业务逻辑的组合来完成服务，比如Feed服务、通讯服务，它们除了本身的业务逻辑，还依赖短链、用户及发号器服务。
3、资源层主要是数据模型的存储，包含通用的缓存资源Redis和Memcached，以及持久化数据库存储MySQL、HBase，或者分布式文件系统TFS以及Sina S3服务。
三、垂直延伸技术架构
区别于水平方向上层依赖下层的关系，垂直方向以技术框架为地基支撑点，向两侧驱动影响业务架构、监控平台、服务治理平台，下面介绍一下其中的核心组件。
1、接口层Web V4框架
接口框架简化和规范了业务接口开发工作，将通用的接口层功能打包到框架中，采用了Spring的面向切面设计理念。接口框架基于Jersey 进行二次开发，基于annotation定义接口，内置Auth、频次控制、访问日志、降级功能，支撑接口层监控平台与服务治理，同时还有自动化的Bean-json/xml序列化。
2、服务层框架
服务层主要涉及RPC远程调用框架以及消息队列框架，这是微博平台在服务层使用最为广泛的两个框架。
3、资源层框架
资源层的框架非常多，有封装MySQL与HBase的Key-List DAL中间件、有定制化的计数组件，有支持分布式MC与Redis的Proxy。
随着SSD硬盘的普及，优越的IO性能使其被越来越多地用于替换传统的SATA和SAS磁盘，常见的应用场景有三种：
1、替换MySQL数据库的硬盘，目前社区还没有针对SSD优化的MySQL版本，即使这样，直接升级SSD硬盘也能带来8倍左右的IOPS提升；
2、替换Redis的硬盘，提升其性能；
3、用在CDN中，加快静态资源加载速度。
微博平台将SSD应用在分布式缓存场景中，将传统的Redis/MC + Mysql方式，扩展为 Redis/MC + SSD Cache + Mysql方式，SSD Cache作为L2缓存使用，第一降低了MC/Redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力。
四、垂直的监控与服务治理
随着服务规模和业务变得越来越复杂，即使业务架构师也很难准确地描述服务之间的依赖关系，服务的管理运维变得越来难。
在这个背景下，参考google的dapper和twitter的zipkin，平台实现了自己的大型分布式追踪系统WatchMan。
WatchMan由技术团队搭建框架，应用在所有业务场景中，运维基于此系统完善监控平台，业务和运维共同使用此系统，完成分布式服务治理，包括服务扩容与缩容、服务降级、流量切换、服务发布与灰度。
原文链接：