SPO Azure开发之-Storage

说起Azure的storage, 还得从最早那几个项目开始,原来有个academy的迁移和online直播的东西,大概有64个TB的视频数据需要挪到云端,原来都是丢在local的集群上的,于是得写个工具把这个东西丢过去。然后发现是个网络带宽和磁盘读写的体力活。于是一阵捣腾,把Azure storage里面能用的feature都给用了一遍。
Azure的存储提供三类结构:
Table: 支持异构化的数据表操作,主要用来存储表类型数据,个人觉得最大的优势还是在于支持异构数据项目,但是在习惯redis之类的key/value数据库以后,你会发现其优势也不是十分明显,当然,azure的table是以集群的方式出现的,可靠性可以管到99.98%,三个九,还是比较牛X的。
Queue:这一块也是比较成熟的分布式队列系统了,常用的队列操作,以及队列内key时间的控制都已经比较成熟,在大量并发获取key时,我们得保证在同一时间只有一个worker能拿到当前的key,并且如果这个item被搞定,那就需要清掉这条数据,如果没有,那么这个key需要自动在一段时间以后再出来,让worker继续来进行操作。
Blob:这是微软自己的一套分布式的存储结构,后台的代码没有看到过,但是大家用Azure VM存储,以及各种镜像备份都依赖于他,同样,在media Service当中,也是借助于blob的存储来完成媒体编码的转化,这里需要关注的是,blob->container>source。在第三个层级,是没有目录的概念的,这里可以通过资源的path来模拟层级结构,但是在内部实际上是没有文件夹之类的概念的。当然,对于blob里面的每一个container,你都可以把他看作是一个文件夹。
storage-concepts
来个全家福。
下面借助于本身这个用来迁移的工具,来说明Azure里面storage的一些简单应用场景。
1. 由于TB级别数据量对单条网络带宽的占用较大,实际上网络IO已经成为瓶颈,于是得分多路来用。
2. 对于转码的要求,在media Service当中有最大job的限制,这里就需要引入queue的帮助
3. 整体是分布式架构,程序得丢到多个机器上面一起跑。
大致思路是这样的,每个程序从自己的那份table当中,获取需要迁移到blob里面的内容列表,进行校验,列表此时就可以借助Azure的table来完成,当然,部分日志记录也是利用Azure的table来完成的。然后集中丢入计划压入到queue中,然后用work机器来完成上传,其实我们这块最早的源列表是在SharePoint上面的,轻松用CSOM搞定。每个work机器开三个线程,来负责数据传输的工作,其实由于网络带宽的缘故,本来想多开几个线程的,但是于效率无意。这里其实第一步到blob以后,还需要监控其调用media service转码的过程。于是超时,重试,以及分布式队列的策略需要自己用code进行控制了。

SPO Azure开发之-Auth

在最早使用SharePoint07的时候,认证还大多基于membership以及windows.而且那时候的SharePoint自带sso模块,也只是模拟用单一用户登录而已。在进入了SharePoint2010以后,由于identity foundation的逐渐成熟,claims based authentication的基于声明的认证方式,也进入到SP的标准模块当中。所以说这个东西并不是啥子新的东西,很早就有了。对于现在O365来说,一个tenant里面的基本上所有的认证都是通过这种方式来实现的。
话说这种方式为啥好呢,其实要从诸多的异构系统说起,如果有过做多系统单点登录的经验,你就不难了解这一套认证的设计思路了。最早我们做单点登录,无非以下几种方式。
1。模拟登陆
2。统一到一套认证中
3。对码跳转
由于在不同的系统当中,都有其本系统独立的人员权限和组。一般单点很难把所有不同的系统统一起来,如果采用唯一账号模拟登陆,那跳转后的系统权限也只能是这一个账号的所有拥有的内容。当然你也可以改造各个系统,使得他们的认证都从用同一套用户和认证,这样不可避免的要对各种系统进行改造了。如果系统各式各样,改造起来估计能头大致死。如果想改造得少一点,其间还得做不同用户在不同系统当中的映射关联,比如王小五在A系统里叫wangxiaowu,但是他在B系统里面就叫wanxiaowu了。如果你说他们没区别,ok. 你眼睛有点花了。
所以很多同志们就拿出了一种折中的解决办法,以一套相对统一的标准来解决这个问题。办法如下图:
2376.image3_5F00_thumb_5F00_56056FFD
其原理就是轻度改造现有系统,让用户都到STS当中去进行验证,而STS相当于认证中心,对所有挂接在其上的系统都做WS-Trust. 而对于各个用户信息,我们用claim来声明其信息,协议一般用SAML. 用户流图如下:
Untitled picture
下面可能主要通过解析SharePoint Online的认证过程,来解析这整个过程。
1。请求SharePoint online站点,站点检查用户浏览器是否已经登录,一般是看cookies里面是否有从sts拿到的token.当然,这个token是有过期时间的
2。之后跳转到统一认证中心的认证页面里面去,让用户进行登录,用户登录完完毕以后,会返回给用户一个security token.
3。之后用户浏览器拿着这个token跑到spo的页面里面去,然后获取到对应的cookies,里面包含两个,一个是fedauth一个trfa.
image_thumb
至于代码我这里就不重复黏贴了,有兴趣的可以在这里下载下来看。