面向切面编程AOP——加锁、cache、logging、trace、同步等这些较通用的操作，如果都写一个类，则每个用到这些功能的类使用多继承非常难看，AOP就是解决这个问题的，python AOP就是装饰器
面向切面编程（AOP）是一种编程思想，与OOP并不矛盾，只是它们的关注点相同。面向对象的目的在于抽象和管理，而面向切面的目的在于解耦和复用。
举两个大家都接触过的AOP的例子：
1）java中mybatis的@Transactional注解，大家知道被这个注解注释的函数立即就能获得DB的事务能力。
2）python中的with threading.Lock()，大家知道，被这个with代码块包裹的部分立即获得同步的锁机制。
这样我们把事务和加锁这两种与业务无关的逻辑抽象出来，在逻辑上解耦，并且可以轻松的做到代码复用。
二、上下文管理器contextlib
当然你可以使用with上下文管理器实现一些AOP的思想，这里有个模块叫contextlib可以帮助你简易的实现上下文管理器。
上下文管理最常见的例子是with open('file') as fh，回收打开句柄的例子。
这种方式还是比较麻烦的，下面我们看一下python中的装饰器怎么样实现AOP编程。
三、装饰器：AOP的语法糖
python中的装饰器就是设计来实现切面注入功能的。下面给出几个例子，这几个例子都是在生产环境验证过的。
其中的任务管理机是伪代码，需要自己实现写数据库的逻辑。
1、重试逻辑
只要do函数被@retry_exp装饰，便可以获得指数退避的重试能力。
@retry_exp(max_retries=10)
def do():
# do whatever
pass
那retry_exp是如何实现的呢？
def retry_exp(max_retries=3, max_wait_interval=10, period=1, rand=False):
def _retry(func):
def __retry(*args, **kwargs):
MAX_RETRIES = max_retries
MAX_WAIT_INTERVAL = max_wait_interval
PERIOD = period
RAND = rand
retries = 0
error = None
ok = False
while retries < MAX_RETRIES:
try:
ret = func(*args, **kwargs)
ok = True
return ret
except Exception, ex:
error = ex
finally:
if not ok:
sleep_time = min(2 ** retries * PERIOD if not RAND else randint(0, 2 ** retries) * PERIOD, MAX_WAIT_INTERVAL)
time.sleep(sleep_time)
retries += 1
if retries == MAX_RETRIES:
if error:
raise error
else:
raise Exception("unknown")
return __retry
return _retry
2、降级开关
只要do函数被@degrade装饰，就会安装app名称校验redis里的开关，一旦发现开关关闭，则do函数不被执行，也就是降级。
@degrade
def do(app):
# do whatever
pass
那么degrade是怎样实现的呢？
def degrade(app):
def _wrapper(function):
def __wrapper(*args, **kwargs):
value = None
try:
redis = codis_pool.get_connection()
value = redis.get("dmonitor:degrade:%s" % app)
except Exception, _:
logger.info(traceback.format_exc())
if not value or int(value) != 1:
function()
logger.info("[degrade] is_on: %s" % app)
else:
logger.info("[degrade] is_off: %s" % app)
return __wrapper
return _wrapper
3、任务状态机
这个是最常用的，我们需要跟踪落盘DB一个任务的执行状态(等待调度，执行中，执行成功，执行失败)
一旦do方法被@tasks_decorator装饰，就获得了这样的能力。对item_param(是个json)中task_id指明的任务进行状态管理。
@tasks_decorator
def do(item_param):
# do whatever
pass
tasks_decorator是怎样实现的呢？
def tasks_decorator(function):
def _wrap(*args, **kwargs):
param_dict = kwargs.get('item_param')
task_id = param_dict.get('task_id')
try:
param_dict.update({'status': TaskStatus.Waiting, 'start_time': datetime.now().strftime('%Y-%m-%d %H:%M:%S')})
try:
manager_dao.save_task(param_dict)
except Exception, ex:
pass
_update_task_status(task_id, TaskStatus.Doing)
function(*args, **kwargs)
_update_task_status(task_id, TaskStatus.Done)
except Exception as e:
time.sleep(0.5)
_update_task_status(task_id, TaskStatus.Fail, unicode(e.message))
raise
return _wrap
4、全局唯一性
在分布式+异步环境中，如果想保证exactly once是需要额外的逻辑的，其实主要是实现唯一键，一旦唯一键实现了，就可以使用公共缓存redis进行唯一键判定了。
do函数被unique装饰，那么对于task_id对应的任务，全局只会执行一次。
@unique
def do(task_id):
# do whatever
pass
unique是怎样实现的呢？
def unique(function):
def _wrap(*args, **kwargs):
task_id = kwargs.get('task_id')
try:
redis = codis_pool.get_connection()
key = "unique:%s" % task_id
if not redis.setnx(key):
redis.expire(key, 24*60*60)
function(*args, **kwargs)
except Exception as e:
logger.error(traceback.format_exc())
raise
return _wrap
四、总结
AOP在少量增加代码复杂度的前提下，显著的获得以下优点：
1、使得功能逻辑和业务逻辑解耦，功能和业务的修改完全独立，代码结构清晰，开发方便
2、一键注入，代码复用程度高，扩展方便
应用举例
为了完成上述并发访问同一资源的功能，需要引入锁Lock的概念，也就是说，某个时刻，当有一个访问类访问这个数据对象时，这个数据对象必须上锁Locked，用完后就立即解锁unLocked，再供其它访问类访问。
使用传统的编程习惯，我们会创建一个抽象类，所有的访问类继承这个抽象父类，如下：
|
1
2
3
4
5
|
abstract class Worker { abstract void locked(); abstract void accessDataObject(); abstract void unlocked();} |
accessDataObject()方法需要有“锁”状态之类的相关代码。
Java只提供了单继承，因此具体访问类只能继承这个父类，如果具体访问类还要继承其它父类，比如另外一个如Worker的父类，将无法方便实现。
重用被打折扣，具体访问类因为也包含“锁”状态之类的相关代码，只能被重用在相关有“锁”的场合，重用范围很窄。
仔细研究这个应用的“锁”，它其实有下列特性：
“锁”功能不是具体访问类的首要或主要功能，访问类主要功能是访问数据对象，例如读取数据或更改动作。
“锁”功能其实是这个系统的一个纵向切面，涉及许多类、许多类的方法。如右图：
因此，一个新的程序结构应该是关注系统的纵向切面，例如这个应用的“锁”功能，这个新的程序结构就是aspect（方面）
在这个应用中，“锁”方面（aspect）应该有以下职责：
提供一些必备的功能，对被访问对象实现加锁或解锁功能。以保证所有在修改数据对象的操作之前能够调用lock()加锁，在它使用完成后，调用unlock()解锁。
很明显，AOP非常适合开发J2EE容器服务器，JBoss 4.0正是使用AOP框架进行开发。
具体功能如下：
Authentication 权限
Caching缓存
Context passing内容传递
Error handling 错误处理
Lazy loading 延时加载
Debugging 调试
logging, tracing, profiling and monitoring 记录跟踪 优化 校准
Performance optimization性能优化
Persistence 持久化
Resource pooling资源池
Synchronization 同步
Transactions事务
【AOP有必要吗？】
当然，上述应用范例在没有使用AOP情况下，也得到了解决，例如JBoss 3.XXX也提供了上述应用功能，并且没有使用AOP。
但是，使用AOP可以让我们从一个更高的抽象概念来理解软件系统，AOP也许提供一种有价值的工具。可以这么说：因为使用AOP结构，JBoss 4.0的源码要比JBoss 3.X容易理解多了，这对于一个大型复杂系统来说是非常重要的。
从另外一个方面说，好像不是所有的人都需要关心AOP，它可能是一种架构设计的选择，如果选择J2EE系统，AOP关注的上述通用方面都已经被J2EE容器实现了，J2EE应用系统开发者可能需要更多地关注行业应用方面aspect。
传统的程序通常表现出一些不能自然地适合单一的程序模块或者是几个紧密相关的程序模块的行为，AOP 将这种行为称为横切，它们跨越了给定编程模型中的典型职责界限。横切行为的实现都是分散的，软件设计师会发现这种行为难以用正常的逻辑来思考、实现和更改。最常见的一些横切行为如下面这些：
日志记录，跟踪，优化和监控
事务的处理
持久化
性能的优化
资源池，如数据库连接池的管理
系统统一的认证、权限管理等
应用系统的异常捕捉及处理
针对具体行业应用的横切行为
前面几种横切行为都已经得到了密切的关注，也出现了各种有价值的应用，但也许今后几年，AOP 对针对具体行业应用的贡献会成为令人关注的焦点。
实现项目
AOP是一个概念，并没有设定具体语言的实现，它能克服那些只有单继承特性语言的缺点（如Java），AOP具体实现有以下几个项目：
AspectJ (TM)： 创建于Xerox PARC. 有近十年历史，成熟
缺点：过于复杂；破坏封装；需要专门的Java编译器。
动态AOP：使用JDK的动态代理API或字节码Bytecode处理技术。
基于动态代理API的具体项目有：
JBoss 4.0 JBoss 4.0服务器
基于字节码的项目有：
aspectwerkz ，spring
作用
面向过程编程离我们已经有些遥远，面向对象编程正主宰着软件世界。当每个新的软件设计师都被要求掌握如何将需求功能转化成一个个类，并且定义它们的数据成员、行为，以及它们之间复杂的关系的时候，面向切面编程（Aspect-Oriented Programming，AOP）为我们带来了新的想法、新的思想、新的模式。
如果说面向对象编程是关注将需求功能划分为不同的并且相对独立，封装良好的类，并让它们有着属于自己的行为，依靠继承和多态等来定义彼此的关系的话；那么面向切面编程则是希望能够将通用需求功能从不相关的类当中分离出来，能够使得很多类共享一个行为，一旦发生变化，不必修改很多类，而只需要修改这个行为即可。
