杭州市QCon总结–开放平台

2012-11-08

杭州QCon总结–开放平台?开放平台这个话题其实很大，涉及到多方面，比如平台搭建、安全、流量控制与计费、服务端

杭州QCon总结–开放平台

开放平台这个话题其实很大，涉及到多方面，比如平台搭建、安全、流量控制与计费、服务端性能优化等；这次QCon会议中，人人网介绍了开放平台授权与验证，飞信介绍了资源分配与控制策略，淘宝介绍了Web请求异步化处理，腾讯介绍了Open API的设计；下面是我之后的一些总结；

1、授权与验证

还是拿网上最流行的例子吧，网站A提供图片存储服务，网站B提供在线打印服务；现在用户想使用网站B提供的在线打印功能打印存储在网站A上的图片，怎么办呢？通常有两种做法：

用户先从网站A把要打印的图片下载到本地，然后再上传到网站B，最后通过网站B完成打印；

用户从网站B上直接访问存储在网站A上的图片，然后打印；

两种做法对比一下，显然是第二种用户体验更好，但有更多的问题需要解决：

网站B如何访问用户存储在网站A上的图片，即如何访问网站A提供的服务？

网站A如何保证用户数据的安全性？如防止用户1去打印用户2的图片？

直接进入主题吧，关于安全性，即授权与验证，经历了三个阶段：

1) HTTP基本认证

HTTP基本认证是一种用来允许Web浏览器，或其他客户端程序在请求时提供以用户名和口令形式的凭证，详细介绍可以看维基百科上的介绍；

其大致流程是：

客户端请求一个需要HTTP BASIC身份认证的页面，但是没有提供用户名和口令；

比如在浏览器中访问链接：http://api.minicloud.com.cn/statuses/friends_timeline.xml

服务端返回一个401的HTTP状态，如

在认证和授权的过程中涉及的三方包括：

服务提供方，用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表；

用户，存放在服务提供方的受保护的资源的拥有者；

客户端，要访问服务提供方资源的第三方应用，通常是网站，如前面提到的照片打印服务的网站B。在认证过程之前，客户端要向服务提供者申请客户端标识；

上图中几个字段的含义如下：

Consumer key：客户端标志，代表一个客户端；

Consumer secret：加密后的Consumer key；

Request token URL：用于客户端申请临时令牌的url；

Authorize URL：服务提供方提供给用户授权的url；

Access token URL：用临时令牌换取访问令牌的url；

Callback URL：用户授权后返回到客户端的url；

整个OAuth 1.x授权与认证的过程如下：

客户端向服务提供方申请接入权限；
如上面的Twitter即注册一个即可；此时会得到Consumer key以及Consumer secret；
当用户在客户端想访问存储在服务提供方的资源时，需要先向服务提供方申请临时令牌（Request token URL）；
服务提供方接收到请求后，会生成临时令牌，并返回给客户端；此时浏览器会自动转向到服务提供方的授权url；
用户在页面上同意客户端访问其资源，并进行授权；之后浏览器会自动跳转到客户端的Callback URL；
客户端根据临时令牌，向服务提供方（Access token URL）申请访问令牌；
客户端拿着访问令牌去请求服务提供方的资源；

可以看到，整个过程中，客户端不会涉及到用户的帐号信息；

下面是我在豆瓣电影设置新浪微博同步时的一些数据
请求头如下：

当用户同意授权后，此进客户端还需要根据临时令牌去服务提供方（Access token URL）换取访问令牌；这个过程在豆瓣和新浪微博的HTTP请求中没有，应该是在豆瓣服务端完成，并将访问令牌保存下来，供以后使用；

PS:新浪微博貌似即将使用新的OAuth认证，即OAuth2.0；

3) OAuth 2.0

OAuth 2.0相比OAuth 1.x有什么优点？

OAuth 1.x认证和授权流程太复杂；

OAuth 1.x只能通过浏览器来完成认证和授权，不支持移动应用、客户端；

不管OAuth2.0流程如何简化，其最终是客户端能申请到访问令牌；

OAuth2.0中的四种角色：

Resource Owner资源所有者

比如Twitter用户，他在Twitter的数据就是资源，他自己就是这些资源的所有者；

Resource Server资源服务器

保存资源的服务器，别人要访问受限制的资源就要出示访问令牌；

Client客户端

一个经过授权后，可以代表资源所有者访问资源服务器上受限制资源的一方。比如开发者开发的应用；

Authorization Server授权服务器

对资源所有者进行认证，认证通过后，向客户端发放访问令牌；

在OAuth2.0中，获取访问令牌有4种流程：

Authorization Code授权码
其大致流程是：客户端访问资源服务器上的资源，首先要引导用户到授权服务器进行授权，用户同意后客户端会获得授权码，客户端再根据授权码去换取访问令牌；
Implicit Grant隐式授权
相比授权码，隐式授权少了第一步的取授权码的过程；该方式主要用于无服务端的应用，比如浏览器插件等；
Resource Owner Password Credentials资源所有者密码证书授权
此授权方式是客户端用用户的帐号信息去换取访问令牌；这种验证主要用于用户对客户端有极高的信任度的情况；
Client Credentials客户端证书授权
此授权是客户端使用自己的client证书（如client_id及client_secret组成的Http Basic验证码）来获取访问令牌；同样该授权主要用于对客户端信任的场景；

在OAuth2.0中，使用访问令牌来向资源服务器发出请求，取得资源；这里的资源服务器需要使用Https协议，否则访问令牌极可能被其它方获取；

2、资源分配与控制策略

飞信业务的特殊性：

数据抓取，如飞信同步抓取其他微博、SNS的信息；（主动同步）

数据同步，如飞信状态同步到其他微博、SNS或其他同步到飞信；（被动同步）

飞信客户端，如电脑、手机等客户端；

资源分配：根据应用场景，将服务器资源分为：

普通服务群

高级服务群

客户端服务群

试验服务群

主动同步抓取群

每类服务器集群，其资源限流策略也不尽相同，主要根据应用、IP、时间几个维度综合考虑；但其总体策略是控制精度让位于响应时间和服务器资源开销；

以后遇到类似的需求时再研究吧?

3、Web请求异步化

为什么会有这个概念，主要是因为容器线程的利用率不高；在前端高并发情况下，容器线程全部被占用，系统响应变慢，吞吐量下降；Web请求异步化中，两个关系要素：

上下文环境

异步化后，上下文环境如何保持；

Response

在非异步化请求过程中，容器线程会一直Hold，直接后端服务返回结果，并直接输出Response到客户端；异步化后结果如何返回给客户端，也是个问题；

Web请求处理模型

参考淘宝放翁的Web服务请求异步化介绍；

非异步化Web请求处理：
不管后端服务是否异步化，连接线程都是阻塞式等待其返回；当前端并发量增大时，容器的吞吐量会成为瓶颈；
异步化Web请求处理，后端服务提供者为阻塞模式：
增加工作者线程，工作都线程获得异步上下文后，释放容器线程；当后端服务完成时，由工作者线程根据异步上下文将结果直接返回给客户端；
异步化Web请求处理，后端服务提供者为非阻塞模式（Push & complete mode）:
连接线程将业务异步交给服务提供者，由服务提供者线程处理完后根据异步上下文将结果返回给客户端；
异步化Web请求处理，后端服务提供者为非阻塞模式（Pull & complete mode）:
和前一个相比，是获取结果的方式不同；由另外工作者线程获取结果，并根据异步上下文返回给客户端；
异步化Web请求处理，后端服务提供者为非阻塞模式（Push & resume mode）:
相比3，结果是返回给调用者，即重入servlet由它返回结果给客户端；

Servlet 3.0异步处理

新的Servlet 3.0规范中，3个新特性其中一个就是对异步处理的支持；在Servlet 3.0中，容器线程不再需要一直阻塞，直到后端服务处理完毕输出响应后才能释放，而是在接收到请求之后，容器线程将工作委派给另一个线程来完成，自己在不生成响应的情况下返回至容器；当工作者线程完成业务处理后，根据异步上下文环境直接commit响应到客户端；

针对业务处理较耗时的情况，这将大大减少服务器资源的占用，并且提高并发处理速度；

4、总结

这次QCon收获还是蛮大的，会上听讲师演讲、会后看同事的总结分享、根据相关主题查阅资料，了解了很多以前没接触的技术，开扩了眼界；感谢部门、感谢公司~

热点排行

软件架构设计

杭州市QCon总结–开放平台