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、一键注入,代码复用程度高,扩展方便

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏编程札记

深入golang之---goroutine并发控制与通信

本文章通过goroutine同步与通信的一个典型场景-通知子goroutine退出运行,来深入讲解下golang的控制并发。

1.1K7
来自专栏小灰灰

Java实现几种简单的重试机制

背景 当业务执行失败之后,进行重试是一个非常常见的场景,那么如何在业务代码中优雅的实现重试机制呢? 设计 我们的目标是实现一个优雅的重试机制,那么先来看下怎么...

2.3K8
来自专栏菩提树下的杨过

ZooKeeper 笔记(5) ACL(Access Control List)访问控制列表

zk做为分布式架构中的重要中间件,通常会在上面以节点的方式存储一些关键信息,默认情况下,所有应用都可以读写任何节点,在复杂的应用中,这不太安全,ZK通过ACL机...

7486
来自专栏编程思想之路

WiFiAp探究实录--功能实现与源码分析

Android虐我千百遍,我待Android如初恋。 ——————编辑于2017-08-02——————— wifi热点说的是wifiAp相...

1.5K9
来自专栏大学生计算机视觉学习DeepLearning

c++ 网络编程(九)TCP/IP LINUX/windows--使用IOCP模型 多线程超详细教程 以及 多线程实现服务端

原文链接:https://www.cnblogs.com/DOMLX/p/9661012.html

2372
来自专栏晓晨的专栏

ASP.NET Core 依赖注入(DI)简介

5644
来自专栏晓晨的专栏

.NET 通过 Autofac 和 DynamicProxy 实现AOP

2433
来自专栏从零开始学自动化测试

python接口自动化7-参数关联

前言 我们用自动化发帖之后,要想接着对这篇帖子操作,那就需要用参数关联了,发帖之后会有一个帖子的id,获取到这个id,继续操作传这个帖子id就可以了 一、删...

3184
来自专栏Java开发者杂谈

RocketMQ专题2:三种常用生产消费方式(顺序、广播、定时)以及顺序消费源码探究

​ 在进行常用的三种消息类型例子展示的时候,我们先来说一说RocketMQ的几个重要概念:

2381
来自专栏技术博客

设计模式之四(抽象工厂模式第一回合)

首先关于抽象工厂模式的学习,我们需要慢慢的,由浅入深的进入。不能单刀直入,否则可能达不到预期学明白的目标。

1061

扫码关注云+社区