# 概览

![image.png](/static/img/10d0ac2c0f22a352028d19c2090d09e6.image.webp)



## 1. 面向过程还是面向对象
世界的本质是由对象组成的，平时看上去相互无关的独立对象在不同的驱动力和规则下体现出不同的运动过程，然后这些过程便展现了我们找个生动的世界。

在面向过程眼中，世界一切都不是孤立的，他们相互紧密联系在一起，缺一不可，互相影响，互相作用，并形成一个具有严格因果律的小系统；而更多的小系统组成了更大的系统，所有小系统之间的关联也是紧密和不可分割的。

### 1.1 面向过程方法
面向过程的分析方法是找到过程的起点，然后顺藤摸瓜，分析每一个部分，直至达到过程的终点。如图

`DFD图`：表达了“（从上一步）输入数据——>（在这一步）功能计算——>（向下一步）输出数据”


![image.png](/static/img/35cbb64581c8d93ae11ec61cc368b01e.image.webp)

由此发现，数据很重要。为了更好地管理数据，人们通过定义主键、外键等手段将数据之间的关系描绘出来，结构化地组织他们，利用关系理论，即数据库的三大范式来保证他们的完备性和一致性。

对关系型数据库起到了重要的促进作用，分析方法ER模型由此而生。

`但随着需求复杂、系统越来越大、功能点越来越多，经常出现一份数据被多个过程分享，经常出现矛盾的数据需求。为了解决这个问题，IBM在20世纪70年代提出了UC矩阵，来求解功能和数据之间的依赖问题。`

UC矩阵：将功能点和数据分别作为横纵坐标来组成一个二维矩阵，，在横纵坐标的每个交叉点上标记功能点对数据的需求，即U(use)和C(Create)。

标记完成后，对功能点位置和数据位置在各自坐标系上进行调整，调整的目标是尽量将C放在整个矩阵的对角线上，这时，各个功能点对数据的交叉依赖是最小的。

![image.png](/static/img/cb95d19236023fb9f51f48f8c6230479.image.webp)
最后，再把相邻的一些功能点分组，由此来获得数据交叉依赖性最小，功能最紧密的子系统。

例如，在煤炭企业管理信息系统的子系统划分案例中，通过建立U/C矩阵、进行正确性检验、求解及子系统划分，最终将系统划分为经营决策、煤炭生产、运销、财务和人事等子系统，每个子系统具有高内聚和低耦合的特点，减少了子系统之间的信息依赖，提高了管理效率和经济效益。


UC矩阵尽管是一个有用的方法，但面向过程的困难并没有从根本上解决：
* 将世界视为过程的前提是：这个过程是稳定的，所有的工作成果依赖于对这个过程的步步分析
* 并且还导致：面向过程的每一步都是预设好的，有着严谨的因果关系。

如今，SOA已经提上日程，IBM也提出了著名的口号：On-Demand Business（随需应变的商务）

### 1.2 面向过程的困难
因为构成一个系统的因素太多，要把所有可能的因素都考虑到，把所有因素的因果关系都分析清楚，再把这个过程模拟出来实在是太困难了。

我们的精力有限，计算能力有限，只能放弃对整个过程的了解，重新寻找一个方法，能够将复杂的系统转换为一个我们可以控制的小单元。

### 1.3 面向对象方法
面向对象（Object Oriented，简称OO）方法将世界看做一个个相互独立的对象，相互之间并无因果关系。只有在某个外部力量的驱动下，对象之间才会根据某种规律相处传递信息。

这些交互构成了这个生动世界的一个“过程”。在没有外力的情况下，对象则保持着静止的状态。

面向对象是多个独立的对象通过某种外力驱动的，这些独立的独享有着一些奇怪的特性：
* 封装： 对象有着坚硬的外壳，从外部来看，除了与外界交互的消息通道外，对象内部就是一个黑匣子，什么也看不到。
* 聚合：对象可以结合在一起形成新的对象，结合后的对象具有前两者特性的总和
* 继承：对象可以繁育，产下的孩子将拥有父辈全部的本领
* 接口：每个对象有多个外貌，在不同情况下可以展现不同的外貌，但本质只有一个。
* 多态：多个对象可能长着相同的脸，但同样的脸背后却是不同的对象，有着不同的行为

对象与它有着联系的身边的一小群伙伴，有这几种关系：
* 依赖：对象只知道与它有着联系的一群小伙伴
* 耦合：与小伙伴保持着信息交流的关系
* 类属性：即便在伙伴之间，每个对象也保护着自己的领地
* 方法：对象只允许其他人通过它打开的小小窗口，进行交流。

其他概念：
* 抽象：对象寻找相似性质并组成部落的过程，称为抽象
* 类：组成的部落
* 实例化：部落里每个成员既有共同的性质也有自己的个性，只有把个性赋给部落成员才能区分它们并使它们活动起来
* 复用：对象可以用于其他地方
### 1.4 面向对象的困难
* 对象是怎么被抽象出来的？为什么要这么抽象而不是那么抽象？
* 什么样的组合是最好的？什么组合是最坏的？
* 如果只给我一个对象组合，我怎么才能理解它表达了怎么样的含义呢？


![image.png](/static/img/5708d6561a8374f93d20eee0a92d9ee1.image.webp)

想要解决困难，需要：
* 一种把现实世界映射到对象世界的方法
* 一种从对象世界描述现实世界的方法
* 一种验证对象世界行为是否正确反映了现实世界的方法

UML就是来解决这些困难的
> 你今天OO了吗？


![image.png](/static/img/6eafd8a358a1687618a52f7bd5d4dba3.image.webp)
## 2. uml带来了什么？
### 2.1 什么是UML
UML是一种建模语言，UML定义了一些建立模型所需要的、表达某种特定含义的基本元素，这些元素称为：元模型，例如用例、类等。

还定义了元模型互相之间关系的规则，以及如何用这些元素和规则绘制图形以建立模型来映射现实世界，这些规则和图形称为表示法和视图(view)


### 2.2 统一语言
统一语言的意义：
* 试图用统一的语言来覆盖整个软件过程，让不同的团队操着同一个口音顺畅地沟通
* 要让人和机器都能懂
### 2.3 可视化
解决可读性的问题

### 2.4 从现实世界到业务模型
建立模型：
* 知道如何抽象现实世界。本质是人、事、物和规则组成，人为核心。uml称之为参与者，参与者是模型信息来源的提供者，也是第一驱动者。
* uml称之为：用例。用来表示驱动者的业务目标，也就是参与者想要做什么并且获得什么。而这件事怎么做的，依据什么规则，通过称之为业务场景和用例场景的UML视图来描绘的。

![image.png](/static/img/8393b28cd34271808ea4810f0c1e4766.image.webp)
### 2.5 从业务模型到概念模型
通过称之为概念化的过程 来建立适合计算机理解和实现的模型，这个模型称为：分析模型。

分析模型介于原始需求和计算机实现之间，是一种过渡模型。

绘制分析模型最主要的元模型：
1. 边界类

![image.png](/static/img/52bcb4f848592e5cc126eb66d450ff34.image.webp)

狭义上说：边界就是界面，所有对计算机的操作都要通过计界面进行

广义上说：任何实物都分为里面和外面，他们之间的交互都需要一个边界。只有两个不同职责的簇之间的交互都需要一个边界，换句话说，边界决定了外面能对里面做什么事儿？
2. 实体类

![image.png](/static/img/e03999b990e05449ccb2a8516ecf448b.image.webp)

原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物。

这些实体类可以看做是业务实体的实例化结果
3. 控制类

![image.png](/static/img/d0faebae1611385cac1c2ce42f694cc0.image.webp)

采用控制类表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。


![image.png](/static/img/37dbccf5b24c71aac844488fc9135dc0.image.webp)
### 2.6 从概念模型到设计模型
设计模型的工作就是建造零件，组装汽车的过程。

实现类可以简单地从分析类映射而来
* 概念模型的边界类可以转换为操作界面或者系统接口
* 控制类可以被转换为计算程序或控制程序，例如工作流、算法体等
* 实体类可以转换为数据表、XML文档或者其他带有持久化特征的类。

一般来说，可以遵循的规则有：
* 软件架构和框架：规定了实现类必须实现的接口、必须继承的超类、必须遵守的编程规则等。例如采用J2ee架构时，Home和Remote接口就是必需的
* 编程语言：各类编程语言有不同的特点
* 规范或中间件： 需要遵循规范或中间件规定的那必须特性


![image.png](/static/img/8445c44ad3d89ef238f74e0a80ad0f89.image.webp)

### 2.7 面向对象的困难解决了吗？

![image.png](/static/img/dfcf8e31d3028c068398f2fa2a8ed705.image.webp)

UML作为标准的面向对象建模语言，它需要再某个建模方法的知道下进行建模工作。

统一过程是这其中最为著名的额建模方法
## 3. 统一过程简介
### 3.1 RUP是什么？
RUP（Rational Unified Process）译为统一过程。

是一个采用了面向对象思想，使用UML作为软件分析设计语言，并且结合了项目管理、质量保证等许多软件工程知识综合而成的一个非常完整和庞大的软件方法。

* 定义了软件开发过程中最重要的阶段和工作（四个阶段和九个核心工作流）
* 定义了参与软件开发过程的各种角色和他们的职责
* 定义了软件生产过程中产生的工件，并提供了模板
* 最后采用了演进式软件生命周期（迭代）将工作、角色和工件串在一起，形成了统一过程。


![image.png](/static/img/5fe3209c5673b0289f56bbc78a0d3c6b.image.webp)


![image.png](/static/img/3345637dd4a19dcf0657a730b5bf6a69.image.webp)
### 3.2 RUP与UML
统一过程和UML是不同的两个领域：
* UML是一种语言，用来描述生产过程中要产生的文档
* 统一过程则是指导如何产生这些文档以及这些文档要讲述什么的方法。
### 3.3 RUP与软件工程

### 3.4 RUP与最佳实践

![image.png](/static/img/137dc94a90e1ab37b28442a3058a60e8.image.webp)
### 3.5 RUP与本书

01 为什么需要UML？

python任务调度框架-apscheduler

## 1. 准备
* 虚拟机one：192.168.30.135:80
* 虚拟机two：192.168.30.128:80
* 两个虚拟机装的nginx都是：nginx version: nginx/1.18.0

官网参考地址： http://nginx.org/
 



## 2.配置代理
在各虚拟机上的conf.d文件夹下建立nginx配置文件，名字分别为：“xuniji_one.conf”、“xuniji_two.conf”
反向代理我写在了xuniji_one.conf中，如下:
```shell
upstream xuniji_fuzai {
	server 192.168.30.128:80;
	server 192.168.30.135.80;
}

server {
	listen 80;
	server_name www.xuniji.one.com;
	location /{
		proxy_pass http://xuniji_fuzai
		proxy_set_header Host $proxy_host;
		proxy_set_header X-Real-Ip $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		
		root /usr/share/nginx/html;
		index /index.html index.htm;
	}

}
```

参数介绍：

* upstream后面的名称与proxy_pass后面的地址对应。（名称可以随意写）

* upstream中的两个server地址就是两个服务器的地址。
* proxy_pass：设置后端代理服务器的地址。这个地址(address)可以是一个域名或ip地址和端口，或者一个 unix-domain socket路径。
* proxy_set_header：就是可设置请求头-并将头信息传递到服务器端。
　　　　　　

## 3.测试
打开浏览器，访问设置代理的服务器（www.xuniji.one.com）。每次访问最终都是请求不同的服务器。



 

 

 

## 4.nginx的六种负载均衡策略

### 1. 轮询（默认策略，nginx自带策略）
上面的例子就是轮询的方式，它是upstream模块默认的负载均衡默认策略。会将每个请求按时间顺序分配到不同的后端服务器。

```shell
http {
    upstream xuniji_fuzai {
        server 192.168.30.128:80;
        server 192.168.30.135:80;
    }
  
    server {
        listen 81;
        server_name www.xuniji.one.com;
  
        location / {
            proxy_pass http://xuniji_fuzai;
            proxy_set_header Host $proxy_host;
        }
    }
}
```

### 2. weight（权重，nginx自带策略）：

指定轮询的访问几率，用于后端服务器性能不均时调整访问比例。

```shell
http {
    upstream xuniji_fuzai {
        server 192.168.30.128:80 weight=7;
        server 192.168.30.135:80 weight=2;
    }
  
    server {
        listen 81;
        server_name www.xuniji.one.com;
  
        location / {
            proxy_pass http://xuniji_fuzai;
            proxy_set_header Host $proxy_host;
        }
    }
}
```


### 3. ip_hash（依据ip分配，nginx自带策略）
指定负载均衡器按照基于客户端IP的分配方式，这个方法确保了相同的客户端的请求一直发送到相同的服务器，可以解决session不能跨服务器的问题。

```shell
http {
    upstream xuniji_fuzai {
        ip_hash;
        server 192.168.30.128:80;
        server 192.168.30.135:80;
    }
  
    server {
        listen 81;
        server_name www.xuniji.one.com;
  
        location / {
            proxy_pass http://xuniji_fuzai;
            proxy_set_header Host $proxy_host;
        }
    }
}
```

### 4. least_conn（最少连接，nginx自带策略）

把请求转发给连接数较少的后端服务器。

```shell
http {
    upstream xuniji_fuzai {
        #把请求转发给连接数比较少的服务器
        least_conn;
        server 192.168.30.128:80;
        server 192.168.30.135:80;
    }
  
    server {
        listen 81;
        server_name www.xuniji.one.com;
  
        location / {
            proxy_pass http://xuniji_fuzai;
            proxy_set_header Host $proxy_host;
        }
    }
}   
```

### 5. fair（第三方）

按照服务器端的响应时间来分配请求，响应时间短的优先分配。

```shell
http {
    upstream xuniji_fuzai {
        fair;
        server 192.168.30.128:80;
        server 192.168.30.135:80;
    }
  
    server {
        listen 81;
        server_name www.xuniji.one.com;
  
        location / {
            proxy_pass http://xuniji_fuzai;
            proxy_set_header Host $proxy_host;
        }
    }
}  
```

### 6. url_hash（第三方）

该策略按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，需要配合缓存用。

```shell
http {
    upstream xuniji_fuzai {
        hash $request_uri;
        server 192.168.30.128:80;
        server 192.168.30.135:80;
    }
  
    server {
        listen 81;
        server_name www.xuniji.one.com;
  
        location / {
            proxy_pass http://xuniji_fuzai;
            proxy_set_header Host $proxy_host;
        }
    }
}
```

nginx的负载均衡

# 分布式函数调度框架
## 环境及功能介绍
* python 3.9
* funboost框架
```
pip3 install -i http://mirrors.al2iyun.com/pypi/simple/  funboost --upgrade --trusted-host mirrors.aliyun.com
```



### 介绍
 分布式函数调度框架，支持5种并发模式，20+消息中间件，20种任务控制功能。
 
 用途概念就是常规经典的：生产者+消息队列中间件+消费者  编程思想
### 5种并发模式
* threading（使用的是可变线程池，可以智能自动缩小和扩大线程数量）
* gevent
* evenlet
* asyncio(框架可以直接支持asynic定义的协程函数作为任务，celery不支持)
* single_thread
### 20多种中间件
```
RABBITMQ_AMQPSTORM = 0  # 使用 amqpstorm 包操作rabbitmq  作为 分布式消息队列，支持消费确认.推荐这个。

RABBITMQ_RABBITPY = 1  # 使用 rabbitpy 包操作rabbitmq  作为 分布式消息队列，支持消费确认。

REDIS = 2  # 使用 redis 的 list结构，brpop 作为分布式消息队列。随意重启和关闭会丢失大量消息任务，不支持消费确认。

LOCAL_PYTHON_QUEUE = 3  # 使用python queue.Queue实现的基于当前python进程的消息队列，不支持跨进程 跨脚本 跨机器共享任务，不支持持久化，适合一次性短期简单任务。

RABBITMQ_PIKA = 4  # 使用pika包操作rabbitmq  作为 分布式消息队列。

MONGOMQ = 5  # 使用mongo的表中的行模拟的 作为分布式消息队列，支持消费确认。

PERSISTQUEUE = 6  # 使用基于sqlute3模拟消息队列，支持消费确认和持久化，但不支持跨机器共享任务，可以基于本机单机跨脚本和跨进程共享任务，好处是不需要安装中间件。

NSQ = 7  # 基于nsq作为分布式消息队列，支持消费确认。

KAFKA = 8  # 基于kafka作为分布式消息队列，建议使用BrokerEnum.CONFLUENT_KAFKA。

REDIS_ACK_ABLE = 9  # 基于redis的 list + 临时unack的set队列，采用了 lua脚本操持了取任务和加到pengding为原子性，随意重启和掉线不会丢失任务。
                  

SQLACHEMY = 10  # 基于SQLACHEMY 的连接作为分布式消息队列中间件支持持久化和消费确认。支持mysql oracle sqlserver等5种数据库。

ROCKETMQ = 11  # 基于 rocketmq 作为分布式消息队列，这个中间件必须在linux下运行，win不支持。

REDIS_STREAM = 12  # 基于redis 5.0 版本以后，使用 stream 数据结构作为分布式消息队列，支持消费确认和持久化和分组消费，是redis官方推荐的消息队列形式，比list结构更适合。

ZEROMQ = 13  # 基于zeromq作为分布式消息队列，不需要安装中间件，可以支持跨机器但不支持持久化。

RedisBrpopLpush = 14  # 基于redis的list结构但是采用brpoplpush 双队列形式，和 redis_ack_able的实现差不多，实现上采用了原生命令就不需要lua脚本来实现取出和加入unack了。

"""
操作 kombu 包，这个包也是celery的中间件依赖包，这个包可以操作10种中间件(例如rabbitmq redis)，但没包括分布式函数调度框架的kafka nsq zeromq 等。
同时 kombu 包的性能非常差，可以用原生redis的lpush和kombu的publish测试发布，使用brpop 和 kombu 的 drain_events测试消费，对比差距相差了5到10倍。
由于性能差，除非是分布式函数调度框架没实现的中间件才选kombu方式(例如kombu支持亚马逊队列  qpid pyro 队列)，否则强烈建议使用此框架的操作中间件方式而不是使用kombu。
"""
KOMBU = 15

"""基于confluent-kafka包，包的性能比kafka-python提升10倍。同时应对反复随意重启部署消费代码的场景，此消费者实现至少消费一次，第8种BrokerEnum.KAFKA是最多消费一次。"""
CONFLUENT_KAFKA = 16

""" 基于emq作为中间件的。这个和上面的中间件有很大不同，服务端不存储消息。所以不能先发布几十万个消息，然后再启动消费。mqtt优点是web前后端能交互，
前端不能操作redis rabbitmq kafka，但很方便操作mqtt。这种使用场景是高实时的互联网接口。
"""
MQTT = 17

HTTPSQS = 18  # 基于httpsqs的

PULSAR = 20   # 下一代分布式消息系统。5年后会同时取代rabbitmq和kafka。

UDP = 21  # 基于socket udp 实现的。小规模使用不支持持久化，好处是不用安装软件。

TCP = 22  # 基于socket tcp 实现的。小规模使用不支持持久化，好处是不用安装软件。

HTTP = 23 # 基于http实现的，小规模使用不支持持久化，好处是不用安装软件。

NATS = 24  # 高性能中间件nats,中间件服务端性能很好,。

TXT_FILE = 25 # 磁盘txt文件作为消息队列，支持单机持久化，不支持多机分布式

PEEWEE = 26 # peewee包操作mysql，使用peewee包操作mysql表模拟消息队列

REDIS_PUBSUB = 27 #  使用redis pubsub实现的广播，每个消费者都会消费同一条消息。
```

### 20种控制功能
```
分布式：
支持数十种最负盛名的消息中间件.(除了常规mq，还包括用不同形式的如 数据库 磁盘文件 redis等来模拟消息队列)

并发：
支持threading gevent eventlet asyncio 单线程 5种并发模式 叠加 多进程。
多进程不是和前面四种模式平行的，是叠加的，例如可以是 多进程 + 协程，多进程 + 多线程。

控频限流：
例如十分精确的指定1秒钟运行30次函数或者0.02次函数（无论函数需要随机运行多久时间，都能精确控制到指定的消费频率；

分布式控频限流：
例如一个脚本反复启动多次或者多台机器多个容器在运行，如果要严格控制总的qps，能够支持分布式控频限流。

任务持久化：
消息队列中间件天然支持

断点接续运行：
无惧反复重启代码，造成任务丢失。消息队列的持久化 + 消费确认机制 做到不丢失一个消息
(此框架很重视消息的万无一失，就是执行函数的机器支持在任何时候随时肆无忌惮反复粗暴拉电闸断电，或者强制硬关机，
或者直接用锄头把执行函数代码的机器砸掉，只要不是暴力破坏安装了消息队列中间件的机器就行，消息就万无一失，
现在很多人做的简单redis list消息队列，以为就叫做分布式断点接续，那是不正确的，因为这种如果把消息从reidis brpop取出来后，
如果消息正在被执行，粗暴的kill -9脚本或者直接强制关机，那么正在运行的消息就丢失了，如果是多线程同时并发运行很多消息，粗暴重启
会丢失几百个大量消息，这种简单的redis list根本就不能叫做安全的断点续传。
分布式函数调度框架的消费确认机制，保证函数运行完了才确认消费，正在运行突然强制关闭进程不会丢失一个消息，
下次启动还会消费或者被别的机器消费。
此框架的消息万无一失特性，不仅支持rabbbitmq因为原生支持，也支持redis，框架对redis的实现机制是因为客户端加了一层保障)。

定时：
可以按时间间隔、按指定时间执行一次、按指定时间执行多次，使用的是apscheduler包的方式。

延时任务：
 例如规定任务发布后，延迟60秒执行，或者规定18点执行。这个概念和定时任务有一些不同。
	  
指定时间不运行：
例如，有些任务你不想在白天运行，可以只在晚上的时间段运行

消费确认：
这是最为重要的一项功能之一，有了这才能肆无忌惮的任性反复重启代码也不会丢失一个任务。
（常规的手写 redis.lpush + redis.blpop,然后并发的运行取出来的消息，随意关闭重启代码瞬间会丢失大量任务，
那种有限的 断点接续 完全不可靠，根本不敢随意重启代码）

立即重试指定次数：
当函数运行出错，会立即重试指定的次数，达到最大次重试数后就确认消费了

重新入队：
在消费函数内部主动抛出一个特定类型的异常ExceptionForRequeue后，消息重新返回消息队列

超时杀死：
例如在函数运行时间超过10秒时候，将此运行中的函数kill

计算消费次数速度：
实时计算单个进程1分钟的消费次数，在日志中显示；当开启函数状态持久化后可在web页面查看消费次数

预估消费时间：
根据前1分钟的消费次数，按照队列剩余的消息数量来估算剩余的所需时间

函数运行日志记录：
使用自己设计开发的 控制台五彩日志（根据日志严重级别显示成五种颜色；使用了可跳转点击日志模板）
+ 多进程安全切片的文件日志 + 可选的kafka elastic日志
		   
任务过滤：
例如求和的add函数，已经计算了1 + 2,再次发布1 + 2的任务到消息中间件，可以让框架跳过执行此任务。
任务过滤的原理是使用的是函数入参判断是否是已近执行过来进行过滤。

任务过滤有效期缓存：
例如查询深圳明天的天气，可以设置任务过滤缓存30分钟，30分钟内查询过深圳的天气，则不再查询。
30分钟以外无论是否查询过深圳明天的天气，则执行查询。

任务过期丢弃：
例如消息是15秒之前发布的，可以让框架丢弃此消息不执行，防止消息堆积,
在消息可靠性要求不高但实时性要求高的高并发互联网接口中使用
		
函数状态和结果持久化：
可以分别选择函数状态和函数结果持久化到mongodb，使用的是短时间内的离散mongo任务自动聚合成批量
任务后批量插入，尽可能的减少了插入次数
			  
消费状态实时可视化：
在页面上按时间倒序实时刷新函数消费状态，包括是否成功 出错的异常类型和异常提示 
重试运行次数 执行函数的机器名字+进程id+python脚本名字 函数入参 函数结果 函数运行消耗时间等
			 
消费次数和速度生成统计表可视化：
生成echarts统计图，主要是统计最近60秒每秒的消费次数、最近60分钟每分钟的消费次数
最近24小时每小时的消费次数、最近10天每天的消费次数
						
rpc：
生产端（或叫发布端）获取消费结果。各个发布端对消费结果进行不同步骤的后续处理更灵活，而不是让消费端对消息的处理一干到底。

远程服务器部署消费函数：
代码里面 task_fun.fabric_deploy('192.168.6.133', 22, 'xiaomin', '123456', process_num=2) 只需要这样就可以自动将函数部署在远程机器运行，
无需任何额外操作，不需要借助阿里云codepipeline发版工具 和 任何运维发版管理工具，就能轻松将函数运行在多台远程机器。task_fun指的是被@boost装饰的函数

暂停消费：
支持从python解释器外部/远程机器 ，控制暂停消息消费和继续消费。
```




TypeError: cannot set 'is_timeout' attribute of immutable type 'TimeoutError'的错误，后来查询CSDN后运行
```
pip install https://github.com/eventlet/eventlet/archive/master.zip
```
解决了问题.

概览

python 任务调度框架-APScheduler

1. 简介

1. 准备

分布式函数调度框架

环境及功能介绍