> 原文出处:http://weibo.com/p/1001643875679132642345
> 作者:苏星宇,[@zhuidawugui](http://weibo.com/n/zhuidawugui)
![document/2015-09-14/55f668043ad17](https://box.kancloud.cn/document_2015-09-14_55f668043ad17.png)
**大纲**
微博平台主要负责微博基础功能。接下来将会介绍
* 平台的作用,以及服务提供的形式
* 平台Web服务的部署
* 平台Web框架简介
## 背景
目前整体架构大体上分为三层
* 展现层:手机端,主站和第三方应用,承担相关业务的前端展示
* 适配层:负责服务端和多个展示端的接口适配
* 服务层:提供基础功能服务,包括Feed服务,用户关系,开放平台和消息箱等
![](https://box.kancloud.cn/2015-09-14_55f66614c8d5b.jpg)
平台作为整个微博架构的基础功能服务层,对外以Http接口的方式提供服务。接口遵守RESTful规范。接口示例如下:
![](https://box.kancloud.cn/2015-09-14_55f66614e833d.jpg)
关于RESTful,与其说是规范,其实更像是一种架构设计风格。它主要是提供了一组设计原则和约束条件,广泛应用于C/S或者B/S架构中。要想理解什么是RESTful,可以从它的全称入手--Representational State Transfer,翻译成中文是表现层状态转化。这段晦涩的文字省略了主语,"表现层"其实指的是"资源"(Resources)的"表现层"。核心概念包括
* 资源是由URI来指定。
* 对资源的操作包括获取、创建、修改和删除资源,这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
* 通过操作资源的表现形式来操作资源。
概括起来,平台对外提供服务的形式就是通过HTTP接口对基础资源进行存取。
## 平台服务部署
对平台的定位和服务形式有所了解后,我们看下平台的Web服务部署结构。
![](https://box.kancloud.cn/2015-09-14_55f666150e7e6.jpg)
平台的服务部署在多个机房中。以北京为例,就有AX、BX和CX三个机房。自建的DNS服务会将用户的流量根据不同的运营商切换到不同的机房。
用户请求到达服务端后,首先会经过反向代理服务器。反向代理(Reverse Proxy)方式是指以代理服务器来接受公网上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给公网上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器。平台目前使用的反向代理有LVS和Nginx。
* LVS:Linux Virtual Server,基于IP的负载均衡和反向代理技术
* Nginx:基于HTTP的负载均衡和反向代理服务器
关于Nginx,除了以上提到的之外,还负责集群的健康检查。这个主要是通过Nginx自带的健康检查模块实现的。Nginx server会轮询后端集群的index.jsp页面,如果返回200则认为服务器正常,请求会正常被转发到该服务器;返回503则进行服务器摘除,请求将不会再到达该服务器。
经过反向代理转发后,请求会到达部署Web应用的应用服务器。平台目前主要使用Tomcat作为应用容器。之后,请求会被统一的Web框架解析并处理。稍后会详细讲述Web框架的内容。
对于上行和下行不同的请求,请求处理的链路也不同。
以微博核心业务Feed流为例。应用服务器在收到下行请求(如查询一条微博的内容)时,会直接访问缓存资源,如果命中则直接返回结果给客户端,否则继续查询DB,将结果返回客户端。
而收到上行请求(如发微博)时,应用会将上行请求写入一个消息队列中。由另一个单独的处理应用读取消息队列,执行上行请求的资源操作,比如写入缓存、更新DB等等。
![](https://box.kancloud.cn/2015-09-14_55f666153c8ba.jpg)
这种队列加处理机的上行请求模式被平台广泛使用,主要有以下优点:
* 解除前端应用和后端资源的耦合
* 削峰填谷:在请求量很大时,队列可以作为缓冲,缓解后端资源的压力
由于请求被分配到不同机房,因此多机房之间的数据也需要同步。目前我们使用虚拟消息管道WMB来同步机房之间的数据:所有的上行请求在到达某个机房后都会通过WMB重放到其他机房,从而保证机房后端资源一致。除此之外,为了容灾,后端资源如缓存,DB的主从集群会分布在不同机房。彼此之间通过应用自身(Redis、MySql)或者客户端(Memcached)来同步主从数据。
## 平台Web框架
下面给大家简单介绍下我们使用的Web框架。前面我们提到,在请求到达应用容器后,首先会被统一Web框架进行处理。用户请求在应用容器中的整个处理链路如下。
![](https://box.kancloud.cn/2015-09-14_55f666155bcf2.jpg)
Web框架的处理主要是将Http形式的请求转换成应用运行环境(如JVM)理解的请求,包括接口路由、参数处理和参数校验等等。平台目前使用Credus作为统一的Web框架,它是一个基于Jersey改造的自研框架。
Jersey是JAX-RS(JSR311)开源参考实现用于构建RESTful Web service。特性比较丰富,包括
* 接口路由
* 功能丰富的Filter
* Http参数校验
* 文档生成
此外Jersey还提供一些额外的API和扩展机制,所以开发人员能够按照自己的需要对Jersey进行扩展。
在Jersey提供的扩展机制上,我们开发了Credus,主要功能有
* 封装Jersey框架
* 定制内容
* Wiki模板
在Jersey提供的Filter机制上,Credus框架定制了一系列接口通用策略和功能。包括用户认证、接口频次限制、接口信息统计和返回接口JsonP封装。另外,还进一步扩展了Jersey原有的参数校验,增加了更多了参数校验方式。Web请求在Credus框架中的处理过程如下
![](https://box.kancloud.cn/2015-09-14_55f666157b84c.jpg)
## 总结
这次和大家分享了微博平台的相关知识,包括平台功能、平台服务部署以及平台Web框架介绍。希望通过本次分享,大家能够对微博平台有所了解,同时对服务结构有一个整体的认识,对以后的工作有所帮助。
由于篇幅和主题的限制,还有很多内容没有具体展开,有兴趣可以关注[@平台技术沙龙](http://weibo.com/n/%E5%B9%B3%E5%8F%B0%E6%8A%80%E6%9C%AF%E6%B2%99%E9%BE%99)。
------------------**新兵训练营简介**------------------
微博平台新兵训练营活动是微博平台内部组织的针对新入职同学的团队融入培训课程,目标是团队融入,包括人的融入,氛围融入,技术融入。当前已经进行4期活动,很多学员迅速成长为平台技术骨干。
微博平台是非常注重团队成员融入与成长的团队,在这里有人帮你融入,有人和你一起成长,也欢迎小伙伴们加入微博平台,欢迎私信咨询。
------------------**讲师简介**------------------
苏星宇,[@zhuidawugui](http://weibo.com/n/zhuidawugui),微博平台及大数据部——通讯系统研发工程师,2014年1月毕业于中国科学技术大学,校招进入微博。先后负责粉服平台、群聊、微博相机消息箱等业务后端设计和研发工作。关注分布式系统设计和服务保障,Storm流式处理。新兵训练营第三期学员