导读:本篇文章首席CTO笔记来给大家介绍有关django怎么监测服务状态的相关内容,希望对大家有所帮助,一起来看看吧。
Python3.7配合Django2.0来调用钉钉(dingding)在线api实时监测员工考勤打卡情况新冠疫情期间,大多数公司为了避免交叉感染都或多或少的采用了远程办公的方式,这显然是一个明智的选择,基本上钉钉(dingding)作为一个远程办公平台来用的话,虽然差强人意,但是奈何市面上没有啥更好的选择,矬子里拔将军,也还是可以凑合用的,不过远程办公有个问题,就是每天需要检查员工的考勤,居家办公虽然灵活,但是大家究竟有没有办公,则是另外一回事,钉钉提供的解决方案就是考勤在线打卡功能,但是检查出勤钉钉在移动端就有点费劲,需要在钉钉app里点击至少5次,还不能实时刷新,pc端的钉钉oa系统做的更烂,还不如移动端来得方便,另外如果你在一家上千人的企业里,这家企业有大大小小几十个部门,你又非常倒霉的担任这家公司的人事主管,每天按部门来出员工考勤报表就不是一件容易事了,所以利用钉钉开放的接口,使用Django自己打造一套实时监控员工考勤的web平台是我们本次的目的。
项目背景是一家普通科技公司,大概有五个部门,每个部门100人左右
首先进入钉钉开放平台:open-dev.dingtalk.com
在企业内部开发中,选择小程序,新建一个小程序应用,这里其实也还有别的选择,比如h5微应用,主要是小程序兼容性更好一点。
填写应用的名称、简介、Logo等基本信息这些按下不表,按照要求填写即可,也不必非得填写真实信息,这里有个坑就是一定不要忘了配置安全域名或者ip,安全域名是当我们的检测平台上线的时候部署的域名,应用可以跟指定的域名进行网络通信,如果不配置的话,请求钉钉接口会报403错误。
另外还有一个坑,也就是钉钉默认开放的接口仅限于基础权限接口
如果需要考勤或者签到接口的话,还得单独点击申请,这就有点让人看不懂了,那么多接口,全都得靠用鼠标点击开通,不开通就用不了,这个用户体验真是让人非常酸爽,产品设计成这样,钉钉的pm难辞其咎。
OK,前置准备工作就已经就绪了,现在我们只要根据官方文档来写接口就可以了,选择服务端api文档:
钉钉考勤打卡的接口说明是这样的:
这里每个接口都需要一个access_token用来鉴权,这个token是用id和秘钥通过接口交换回来的,具体在应用详情里可以获取
这里我们封装成方法
搞定了token,还需要获取您的部门下所有员工的员工id,因为考勤接口参数只能接受员工id,而非部门id
最后请求考勤接口即可
完整的后台Django后台接口
这样,就可以愉快的通过线上平台来实时监测部门员工考勤了,效果是这样的:
Django中怎么使用django-celery完成异步任务许多Django应用需要执行异步任务,以便不耽误httprequest的执行.我们也可以选择许多方法来完成异步任务,使用Celery是一个比较好的选择,因为Celery
有着大量的社区支持,能够完美的扩展,和Django结合的也很好.Celery不仅能在Django中使用,还能在其他地方被大量的使用.因此一旦学会使用Celery,我
们可以很方便的在其他项目中使用它.
1.Celery版本
本篇博文主要针对Celery3.0.x.早期版本的Celery可能有细微的差别.
2.Celery介绍
Celery的主要用处是执行异步任务,可以选择延期或定时执行功能.为什么需要执行异步任务呢?
第一,假设用户正发起一个request,并等待request完成后返回.在这一request后面的view功能中,我们可能需要执行一段花费很长时间的程序任务,这一时间
可能远远大于用户能忍受的范围.当这一任务并不需要立刻执行时,我们便可以使用Celery在后台执行,而不影响用户浏览网页.当有任务需要访问远程服务器完
成时,我们往往都无法确定需要花费的时间.
第二则是定期执行某些任务.比如每小时需要检查一下天气预报,然后将数据储存到数据库中.我们可以编写这一任务,然后让Celery每小时执行一次.这样我们
的web应用便能获取最新的天气预报信息.
我们这里所讲的任务task,就是一个Python功能(function).定期执行一个任务可以被认为是延时执行该功能.我们可以使用Celery延迟5分钟调用function
task1,并传入参数(1,2,3).或者我们也可以每天午夜运行该function.
我们偏向于将Celery放入项目中,便于task访问统一数据库和Django设置.
当task准备运行时,Celery会将其放入列队queue中.queue中储存着可以运行的task的list.我们可以使用多个queue,但为了简单,这里我们只使用一个.
将任务task放入queue就像加入todolist一样.为了使task运行,我们还需要在其他线程中运行的苦工worker.worker实时观察着代运行的task,并逐一运行这
些task.你可以使用多个worker,通常他们位于不同服务器上.同样为了简单起见,我们这只是用一个worker.
我们稍后会讨论queue,worker和另外一个十分重要的进程,接下来我们来动动手:
3.安装Celery
我们可以使用pip在vietualenv中安装:
pipinstalldjango-celery
4.Django设置
我们暂时使用djangorunserver来启动celery.而Celery代理人(broker),我们使用Djangodatabasebrokerimplementation.现在我们只需要知道Celery
需要broker,使用django自身便可以充当broker.(但在部署时,我们最好使用更稳定和高效的broker,例如Redis.)
在settings.py中:
importdjcelery
djcelery.setup_loader()
BROKER_URL='django://'
...
INSTALLED_APPS=(
...
'djcelery',
'kombu.transport.django',
...
)
第一二项是必须的,第三项则告诉Celery使用Django项目作为broker.
在INSTALLED_APPS中添加的djcelery是必须的.kombu.transport.django则是基于Django的broker
最后创建Celery所需的数据表,如果使用South作为数据迁移工具,则运行:
pythonmanage.pymigrate
否则运行:(Django1.6或Django1.7都可以)
pythonmanage.pysyncdb
5.创建一个task
正如前面所说的,一个task就是一个Pyhtonfunction.但Celery需要知道这一function是task,因此我们可以使用celery自带的装饰器decorator:@task.在
djangoapp目录中创建taske.py:
fromceleryimporttask
@task()
defadd(x,y):
returnx+y
当settings.py中的djcelery.setup_loader()运行时,Celery便会查看所有INSTALLED_APPS中app目录中的tasks.py文件,找到标记为task的function,并
将它们注册为celerytask.
将function标注为task并不会妨碍他们的正常执行.你还是可以像平时那样调用它:z=add(1,2).
6.执行task
让我们以一个简单的例子作为开始.例如我们希望在用户发出request后异步执行该task,马上返回response,从而不阻塞该request,使用户有一个流畅的访问
过程.那么,我们可以使用.delay,例如在在views.py的一个view中:
frommyapp.tasksimportadd
...
add.delay(2,2)
...
Celery会将task加入到queue中,并马上返回.而在一旁待命的worker看到该task后,便会按照设定执行它,并将他从queue中移除.而worker则会执行以下代
码:
importmyapp.tasks.add
myapp.tasks.add(2,2)
7.关于import
这里需要注意的是,在impprttask时,需要保持一致.因为在执行djcelery.setup_loader()时,task是以INSTALLED_APPS中的app名,
加.tasks.function_name注册的,如果我们由于pythonpath不同而使用不同的引用方式时(例如在tasks.py中使用frommyproject.myapp.tasksimport
add形式),Celery将无法得知这是同一task,因此可能会引起奇怪的bug.
8.测试
a.启动worker
正如之前说到的,我们需要worker来执行task.以下是在开发环境中的如何启动worker:
首先启动terminal,如同开发django项目一样,激活virtualenv,切换到django项目目录.然后启动django自带web服务器:pythonmanage.pyrunserver.
然后启动worker:
pythonmanage.pyceleryworker--loglevel=info
此时,worker将会在该terminal中运行,并显示输出结果.
b.启动task
打开新的terminal,激活virtualenv,并切换到django项目目录:
$pythonmanage.pyshell
frommyapp.tasksimportadd
add.delay(2,2)
此时,你可以在worker窗口中看到worker执行该task:
[2014-10-0708:47:08,076:INFO/MainProcess]Gottaskfrombroker:myapp.tasks.add[e080e047-b2a2-43a7-af74-d7d9d98b02fc]
[2014-10-0708:47:08,299:INFO/MainProcess]Taskmyapp.tasks.add[e080e047-b2a2-43a7-af74-d7d9d98b02fc]succeededin0.183349132538s:4
9.另一个例子
下面我们来看一个更为真实的例子,在views.py和tasks.py中:
#views.py
frommyapp.tasksimportdo_something_with_form_data
defview(request):
form=SomeForm(request.POST)
ifform.is_valid():
data=form.cleaned_data
#Scheduleatasktoprocessthedatalater
do_something_with_form_data.delay(data)
returnrender_to_response(...)
#tasks.py
@task
defdo_something_with_form_data(data):
call_slow_web_service(data['user'],data['text'],...)
10.调试
由于Celery的运行需要启动多个部件,我们可能会漏掉一两个.所以我们建议:
使用最简单的设置
使用pythondebug和logging功能显示当前的进程
11.Eager模式
如果在settings.py设置:
CELERY_ALWAYS_EAGER=True
那么Celery便以eager模式运行,则task便不需要加delay运行:
#若启用eager模式,则以下两行代码相同
add.delay(2,2)
add(2,2)
12.查看queue
因为我们使用了django作为broker,queue储存在django的数据库中.这就意味着我们可以通过djangoadmin查看该queue:
#admin.py
fromdjango.contribimportadmin
fromkombu.transport.djangoimportmodelsaskombu_models
admin.site.register(kombu_models.Message)
13.检查结果
每次运行异步task后,Celery都会返回AsyncResult对象作为结果.你可以将其保存,然后在将来查看该task是否运行成功和返回结果:
#views.py
result=add.delay(2,2)
...
ifresult.ready():
print"Taskhasrun"
ifresult.successful():
print"Resultwas:%s"%result.result
else:
ifisinstance(result.result,Exception):
print"Taskfailedduetoraisinganexception"
raiseresult.result
else:
print"Taskfailedwithoutraisingexception"
else:
print"Taskhasnotyetrun"
14.定期任务
还有一种Celery的常用模式便是执行定期任务.执行定期任务时,Celery会通过celerybeat进程来完成.Celerybeat会保持运行,一旦到了某一定期任务需要执
行时,Celerybeat便将其加入到queue中.不像worker进程,Celerybeat只有需要一个即可.
启动Celerybeat:
pythonmanage.pycelerybeat
使Celery运行定期任务的方式有很多种,我们先看第一种,将定期任务储存在django数据库中.即使是在django和celery都运行的状态,这一方式也可以让我们
方便的修改定期任务.我们只需要设置settings.py中的一项便能开启这一方式:
#settings.py
CELERYBEAT_SCHEDULER='djcelery.schedulers.DatabaseScheduler'
如何使用djangosessionDjango完全支持匿名Session。Session框架允许每一个用户保存并取回数据。它将数据保存在服务器端,并将发送和接收Cookie的操作包装起来。在Cookie中包含的是SessionID,而不是数据本身。
启用Sessions?
Session是通过中间件的方式实现的。
要启用Session的功能,需要完成以下步骤:
修改MIDDLEWARE_CLASSES设置,并确定其中包含了'django.contrib.sessions.middleware.SessionMiddleware'。``django-admin.pystartproject``所创建的缺省的settings.py就已经激活了SessionMiddleware。
将'django.contrib.sessions'添加到你的INSTALLED_APPS设置中,并执行manage.pysyncdb以便安装用于存储Session数据的表格。
ChangedinDjango1.0:如果你并未使用数据库存储Session,则此步骤可以忽略;参考配置Session引擎。
Ifyoudon’twanttousesessions,youmightaswellremovetheSessionMiddlewarelinefromMIDDLEWARE_CLASSESand'django.contrib.sessions'fromyourINSTALLED_APPS.It’llsaveyouasmallbitofoverhead.
1.Django,Nginx和Gunicorn的关系
在杜赛的博客中,对Django+Nginx+Gunicorn这三兄弟的描述是这样的:
如果用餐馆来做比喻的话,Nginx就是迎宾小姐,客人如果点了酒水,迎宾小姐自己就帮忙拿了;而Gunicorn是传菜员,Django是厨师,他两一起满足客人对现炒美食的需求。
这个比喻具体是在说什么呢?
首先,我们要分清楚Web应用和Web服务器这两个概念。Django开发出来的程序是Web应用,它本身不能起到监听用户请求并响应这种“收发员”的功能。监听用户请求并响应是Web服务器的职责。
Nginx就是一个Web服务器。即使没有web应用运行,只有一大堆html静态页面,我们也可以通过配置路由和返回的页面来使用Nginx搞出一个静态网站。
Django开发的Web应用本身是没有和客户端(浏览器)交互的功能的。我们在本地能够运行它是只是因为Django其内置了一个小型Web服务器而已,不过它性能受限,不能用于生产环境。
那么将Nginx和Django组合是不是就大功告吉了呢?没那么简单。Python官方定义了WSGI(WebServerGatewayInterface)作为Web服务器与PythonWeb应用程序或框架之间的建议标准接口。这样可以提高Web应用程序和服务器之间的可移植性。显然Django需要一个实现WSGI的服务器来和它配合。然而Nginx作为一个普通的http服务器,并没有实现这个接口。
这可以通过两种方式变通:
这里使用的是第二种途径。Gunicorn是一个遵循WSGI的Web服务器。Nginx可以在需要和Django打交道的时候把任务交给Gunicorn处理,而在不需要的时候自己解决就行。在我们的情况下就是/static和/media这种静态资源由Nginx自行快速响应,其他请求通过socket传送给Gunicorn,Gunicorn通过WSGI和Django通信并返回动态响应。这就是为什么说传菜员Gunicorn和厨师Django他俩一起满足顾客对现炒美食的需求。
其实Gunicorn本身不需要Nginx的带领也是可以独立运作的,但是它的性能比较差因此不推荐这么做。Gunicorn的官方文档也强烈推荐把Gunicorn部署在如Nginx这样的代理服务器的后方,以防止安全问题。
参考好文:
为什么nginx可以直接部署,还要uWSGI,gunicorn等中间件
名字是小明:尝试理解Flask源码之搞懂WSGI协议
Django如何监听启动,开启另外后台线程apache,或者tornado多进程,有能力自己写个wsgi协议服务器去调djangoDjango是一个开放源代码的Web应用框架,由Python写成。采用了MVC的软件设计模式,即模型M,视图V和控制器C。它最初是被开发来用于管理劳伦斯出版集团旗下的一些以新闻内容为...
如何实现Django启动服务器时一起启动socket监听django启动时会访问一次manage.py,你可以在里面把你启动socket监听的函数运行一下,这样就可以实现你说的要求了。
如果解决了您的问题请采纳!
如果未解决请继续追问!
结语:以上就是首席CTO笔记为大家整理的关于django怎么监测服务状态的相关内容解答汇总了,希望对您有所帮助!如果解决了您的问题欢迎分享给更多关注此问题的朋友喔~
logo设计
创造品牌价值
¥500元起
APP开发
量身定制,源码交付
¥2000元起
商标注册
一个好品牌从商标开始
¥1480元起
公司注册
注册公司全程代办
¥0元起
查
看
更
多