单体应用-》服务化-》微服务
原本单体应用业务高度耦合，测试部署成本高。
改为服务化后各个服务方维护自己的一块，例如微博拆分为平台、各垂直业务方
微服务是更进一步的拆分，各个业务方将各自系统中按模块进行拆分，进一步解耦，方便弹性扩缩容，服务越简单越容易提升性能
正交分解法
水平方向，采用典型的三级分层模型，即接口层、服务层、资源层
垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台。
水平分层
接口层主要实现与web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容(Feed)服务、用户关系服务及通讯服务(单发私信、群发、群聊)
服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，其定义时不依赖任何其他服务的服务模块，比如常用的短链服务、发好奇服务都属于这一类。途中使用泳道隔离，表示他们的独立性。另一类为组合服务，通过各种原子服务和业务逻辑的组合来完成服务，比如Feed服务、通讯服务，它们除了本身的业务逻辑，还依赖短链、用户及发号器服务。
资源层主要是数据模型的存储，包含通用的缓存资源Redis和Memcached，以及持久化数据库存储Mysql\HBase或者分布式文件系统TFS以及Sina S3服务
水平分层有一个特点，依赖关系都是从上往下，上层服务依赖下层，下层服务不会依赖上层，构建了一种简单直接的依赖关系。
与分层模型相对应，微博系统中的服务器主要包括三种类型：前端机(提供API接口服务)、队列机(处理上行业务逻辑，主要是数据写入)和存储(mc、mysql、mcq、redis、hbase等)
垂直延伸技术架构
随着业务架构的发展和优化，平台研发实现了许多卓越的中间件产品，用来支撑核心业务，这些中间件由业务驱动产生，随着技术组件越来越丰富，形成完备的平台技术框架，大大提升了平台的产品研发效率和业务运行稳定性。
下面介绍下其中的核心组件
接口层WEBV4框架
接口框架简化和规范了业务接口开发工作，将通用的接口层功能打包到框架中，采用spring的面向切面AOP设计理念
服务层框架
服务层主要设计RPC远程调用以及消息队列框架，这是微博平台在服务层使用最为广泛的两个框架
MCQ消息队列
微博平台内部大量使用MCQ消息队列服务，基于memcache协议，消息数据持久化写入berkeleyDB,只有get/set两个命令，同事也非常容易做监控，有丰富的客户端库，线上运行多年，性能比通用MQ高很多倍
Motan RPC框架
微博的Motan RPC服务，底层通讯引擎采用了netty网络框架，序列化协议支持HESSIAN和java序列化，通讯协议支持Motan、http、tcp、mc等、Motan在内部大量使用，在系统的健壮性和服务治理方面，有较为成熟的技术解决方案，健壮性上，基于Config配置管理服务实现了高可用与负载均衡策略，服务治理方面，生成完整的服务调用链数据，服务请求性能数据，响应时间，QPS以及标准化error、Exception日志信息
资源层框架
有封装mysql与hbase的key-list dal中间件、有定制化的计数组件，有支持分布式MC与Redis的proxy，在这里分下下平台架构的对象库和SSB CaChe组件
对象库
对象库支持便捷的序列化与反序列化微博的对象数据:序列化时，将JVM内存中的对象序列化写入在HBASE中并生成唯一的ObjectId,当需要访问该对象时,通过objectId读取，对象库支持任意类型的对象，支持PB、json、二进制序列化协议，微博中最大的应用场景将微博中引用的视频、图片、文章统一定义为对象，一共定义了几十种对象类型，并抽象出标准对象元数据Schema,对象的内容上传到对象存储系统(Sina S3),对象元数据中保存Sina S3的下载地址
SSDCache
微博将SSD应用在分布式缓存场景中，将传统的redis/mc+mysql方式，扩展为redis/mc+ssd cache+mysql方式，ssd cache作为二级缓存使用，既解决了mc/redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力
垂直的监控与服务治理
随着服务规模和业务变得越来越复杂，即使业务架构师也很难准确地描述服务之间的依赖关系，服务的管理运维变得越来越难，在这个背景下，参考google的dapper和twitter的zipkin,平台实现了自己的大型分布式追踪系统watchman
watchman大型分布式追踪系统
如其他大型互联网应用一样，微博平台由众多的分布式组件构成，用户通过浏览器或移动客户端的每一个HTTP请求到达应用服务器后，会经过很多个业务系统或系统哦组件，并留下足迹(footprint)。但是这些分散的数据对于问题排查，或者流程优化都帮助有限。对于这样一种典型的跨进程、跨线程的场景，汇总手机并分析这类日志就显得尤为重要。另一方面，手机每一处足迹的性能数据，并根据策略对各子系统做流控或降级，也是确保微博平台高可用的重要因素。要能做到追踪每个请求的完整调用链路；手机调用链路上每个服务的性能数据；能追踪系统中所有的Error和Exception;通过计算性能和比对性能指标(SLA)在回馈到控制流程中，基于这些目标就诞生了微博的watchman系统
该系统设计的一个原则就是低侵入性：作为非业务组件，应当尽可能少侵入或者不侵入其他业务系统，保持对适用房的透明，可以大大减少开发人员的负担和接入门槛。基于此考虑，所有日志采集都分布在技术框架中间件中，包括接口框架、PRC框架以及其他资源中间件。
watchman由技术团队搭建框架，应用在所有业务场景中，运维基于此系统完善监控平台，业务和运维共同使用此系统，完成分布式服务治理，包括服务扩容和缩容、服务降级、流量切换、服务发现和灰度。