五四陈科学院-坚信科学，分享技术 » 人人网

[54chen开发日记]注解和拦截器实现权限通用模型的设计实践

54chen — Sun, 22 Aug 2010 08:35:20 +0000

------------------英文大爱-----------------------

在近期的开发过程中，有使用到拦截器来实现权限控制，使用这种设计方案，可以很好地分离权限与系统本身的功能，让开发过程更加关注系统的核心功能，同时可以很容易做到开发时的任务划分，同时使项目代码的可读性大大提升。先来普及几个相关的名词：

1.AOP：是OOP的延续，是（Aspect Oriented Programming）的缩写，意思是面向切面编程，也有叫面向方面编程，不过切面更加形象。可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。

2.GoF：《Design Patterns: Elements of Reusable Object-Oriented Software》（即《设计模式》一书），由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 合著（Addison-Wesley，1995）。这几位作者常被称为"四人组（Gang of Four）"，而这本书也就被称为"四人组（或 GoF）"书。话说为首的Erich Gamma，在QCon的大会上54chen也有半面之缘。

权限模型的常量定义

一个系统里最常见的需求莫过于权限、角色，事实上往往这样子的需求和系统本身的功能又是没有太多关联的。按照常规的做法，我们需要两个类，一个表明都有什么权限（例如：删除帖子权限、编辑帖子权限，等等）;另一个类表明，各个角色都有什么权限。这样子相当于定义了一个权限和角色模型。

拦截器与注解

拦截器（Invocation）在在流行的开源框架中很常见，依赖的技术就是Java的动态代理。许多流行的框架都提供实现拦截器的接口，可以很简单就实现一个拦截器，此文不表如何实现。注解（Annotations）是JAVA在5.0后引入的特性，它引入的目的是为了替代一些简单的配置到java代码里，而不用原来的xml。

注解请求示例

        一般的框架，都会有一个controller类，以下用伪代码表示：
public class ThreadsController{ @PriCheckRequired({MemberPrivilegeIdentity.CREATE_THREAD}) public String createThread(){ return "createThread"; } }
        如代码中所示，一个controller里的一个method对应一个url请求（例中所示为创建帖子）。我们只需要在其方法上标注@PriCheckRequired({MemberPrivilegeIdentity.CREATE_THREAD})，PriCheckRequired就是注解，其传递了一个信息MemberPrivilegeIdentity.CREATE_THREAD，这也就是前文说的权限类中的创建帖子权限。
拦截器工作
        拦截器一般都是实现一个框架提供的接口来实现，常用框架都支持。
可以想像在拦截器里要做的事情：

1.根据规定好的request请求的参数，取到用户属于哪个角色。
2.根据controller中注解，取到当前要判断的权限。
3.对比用户角色是否有注解中的权限，如果有，放行，反之拦截。

代码实现
拦截器的代码实现与框架有关:
rose框架如何实现拦截器请看http://code.google.com/p/paoding-rose/wiki/Rose_Code_Fragment_Interceptor;另外spring等都可以简单实现拦截器。

篇末
这种方式可以做的事情还有许多，例如cache等公共模块的地方，都可以使用，对开发速度、任务划分、代码重用程度都有非常适用的地方。

想快点找到作者也可以到Twitter上留言: @54chen
或者你懒得带梯子上墙，请到新浪微博：@54chen

闲谈分布式key-value存储服务nuclear及其他

cc0cc — Sat, 27 Mar 2010 08:44:23 +0000

以下内容由[五四陈科学院]提供

现在很多国内公司都纷纷开始了key-value的nosql存储方式，然而，从什么时候开始key-value会变得这么流行呢？是风靡一时，还是顺应时代的潮流？前后数一数，有豆瓣网的beandb、有新浪的SDD、小道消息还有腾讯的TDB以及人人网的nuclear。再数国外，吹起这阵风的原因是亚马逊的一篇文档，这篇文档讲述了在亚马逊的S3服务中所使用的存储系统dynamo实现方式，但遗憾的是dynamo并不开源。紧随其后，facebook来了位号称是当年亚马逊dynamo的开发人员之一的同志，实现了facebook的cassandra，并且值得表扬的是还将其开源了。与此同时，相同理论下产生的，还有linkedin的voldemort系统。

百家争鸣还是百家讲坛

分布式存储的目标，是解决大规模数据在数据量不断增长的情况下，让服务更加稳定，更容易扩展。

其主要具备以下几个特点：

1.高可靠性：系统能够长时间高效运行不迭机。严格的说即使坏了一部分机器也没事。

2.可扩展性：可以随意增加减少机器，不用担心额外的数据损失。

3.负载均衡：要保证每个节点的数据都是负载均衡的，不出现集中负载到一个节点的情况。

4.一致性：因为是分布式的节点，就需要保证节点与节点之间保存数据的一致。

鱼与熊掌不可兼得，这几点，往往完成了其中几点就会损失另外一点，要全部达到完美，是一件非常困难的事情。

在国内的几个存储来看，基本都是只实现了其中的一部分，再按照自己业务的需求，来加强其中更为关心的建设。

beansdb的最终一致性通过哈希树实现快速完整数据同步（短时间内数据可能不一致）；可以在不中断服务的情况下进行容量扩展；异步IO和高性能的KeyValue数据TokyoCabinet：通过N,W,R进行配置（这点其实是dynamo的文档里的方案，并非beansdb所创）；Memcache兼容协议，大量可用客户端。sdd也大同小异。

Nuclear完成了这些功能，并且可以适配到mysql\tc\bdb等存储引擎之上。

为什么已经有开源的项目，还要去自己实现呢？简单的说，twitter敢用，你敢用吗？

分布式key-value存储之所以稳定的原因

从设计之初，注定这个系统会很稳定。为什么呢，主要是下面几点：

1.dynamo文档中的NWR的观点，可以让节点在损坏的情况下也能稳定如新。基本上这些系统都实现了。

2.dynamo文档中的两层数据节点的观点，可以让各节点在大负载的情况下负载均衡。部分实现了这一点。

3.底层存储的时候是key-value的读和取，只有一个维度的底层操作，对引擎来说，所有的操作都是可计算时间的。这一点的意思是说，假设都是MYSQL的底层存储，这个系统只会有一堆的select value form table where key=num这样的查询，而不会出现select * from table where key in(num1,num2,num3....)这样的查询，这两个查询不同的地方在于，如果都是1000次的查询，那么前一条的时间是可以准确预估的，而后一条取决于mysql底层实现的逻辑，而这个逻辑对上层是不可见的。

更多不明原因。。。

适合使用的范围

这套系统也不是放之四海而皆准的东西，如果说您的系统有如下的特征，可以考虑考虑：

1.数据插入后不需要各维度的查询。

2.数据不需要100%精确立即展示。

更多不明特点。

总结

其实这个系统，在过十亿的数据量下才有意思。
本文作者：
54chen(陈臻)，人人网分布式存储研究人员，业余时间混迹于各技术组织且乐此不疲。目前关注实施PHP培训。对flex等前端技术有一点研究。
个人技术站点:http://www.54chen.com/ 。可以通过电子邮件 czhttp@gmail.com 联系到他。

[文中所提及的链接]

beansDB:http://code.google.com/p/beansdb/

SDD:http://code.google.com/p/sina-sdd/

Nuclear:http://ugc.renren.com

S3:http://aws.amazon.com/s3/

dynamo:http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf

cassandra:http://incubator.apache.org/cassandra/

voldemort:http://project-voldemort.com/

想快点找到作者也可以到Twitter上留言: @54chen
或者你懒得带梯子上墙，请到新浪微博：@54chen