前言
最近因为政企部门的工作失误，导致我们的项目差点挂掉，客户意见很大，然后我们只能被动进入007加班状态，忙得嗷嗷叫，直到今天才勉强把项目改完交付，是时候写一个小结。
技术
因为前期需求不明确，数据量不大，人手也不多，所以我直接用Django做了后端，Django自带的admin可以作为管理后台使用，可以很快完成这个需求。
我们的前端有两个，一个数据展示大屏，一个可视化地图。前者使用Vue+ElementUI+DataV实现，后者使用jQuery+百度MapV。
大概的效果如下所示，涉及到数据的部分只能打码，感谢理解~
这个是Django的admin界面，主页是我重新写的
数据展示大屏
可视化地图
技术含量其实不高，但项目在具体实施和落地的过程中，有一些问题和细节，还是有必要记录一下
切换MySQL数据库
开发的时候默认用的SQLite数据库，到了正式环境，需要切换到CS架构的服务器，比如MySQL
我的配置是这样
# 数据库配置
database_config = {
'sqlite3': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
},
'mysql': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'name',
'USER': 'root',
'PASSWORD': 'password',
'HOST': 'mysql' if DOCKER else 'localhost',
'PORT': '3306',
}
}
DATABASES = {'default': database_config['sqlite3']}
这样方便切换不同的数据库，其实还可以把数据库切换用环境变量来控制，docker中使用MySQL，本地开发环境使用sqlite。
MySQL的HOST配置是：'mysql' if DOCKER else 'localhost' 也是为了适配本地环境和docker环境的切换，后续我再封装一下 DjangoStarter 的数据库配置部分，实现前面说的环境变量切换配置。
大量数据导入问题
本项目遇到的第一个麻烦的问题是大量的数据导入
客户提供的数据是Excel格式，大概几百万条吧，我首先使用Python对数据进行预处理，做了一些去重、数据清洗之类的操作，然后导出成JSON文件。
然后在导入Django数据库的时候就遇到了问题，DjangoORM的速度太慢了！
让他跑数据跑了一个晚上，才导入了80w条数据左右，这肯定不行啊，因为被业务部门捅了娄子，项目还有几天的时间就要上线了，要赶！总共数据有几百万呢……
没办法，只能直接上SQL了，掏出Navicat，连上服务器的MySQL数据库，然后把数据直接导入临时表，再用SQL一番折腾，导入到Django生成的表里，这样数据的问题就搞定了。
（当然后续还有一系列的数据问题，前期的数据清洗还是不够的，后面发现的一些数据缺失啥的问题，在赶进度的过程中边处理，做了一些补救措施，最后也还好勉强可以用）
下次数据清洗还是得试一下Pandas这种专业的工具，单靠Python本身不够。
接口缓存
由于数据量太大，有几个需要计算操作的接口是比较慢的，该优化的暂时都优化了（下面或许会写一下DjangoORM的优化），所以只能上缓存了
项目用了我的「DjangoStarter」项目模板，本身集成了Redis支持，所以缓存直接用Redis的就好了。
缓存有两种使用方式，用Django默认的cache_page装饰器，或者第三方库rest_framework_extensions。
前者作用于 function view 上，当然 class view 也能用，但是得加 method_decorator，然后得自己封装一个缓存过期配置。
后者可以使用 rest_framework 的缓存配置，相对来说更方便，只是需要安装一个库。(另外提一点，rest_framework_extensions这个库还有其他的一些功能，有空再介绍，感兴趣的同学可以探索一下)
最终我选择了第二个，哈哈~
不过我都介绍一下吧，很简单
cache_page 的使用
from django.views.decorators.cache import cache_page
from rest_framework.decorators import api_view
@cache_page(CACHE_TIMEOUT)
@api_view()
def overview(request: Request):
...
其中 CACHE_TIMEOUT 的单位是秒，也可以设置成 None，这样缓存就永不过期了。
rest_framework_extensions
rest_framework 的缓存配置
REST_FRAMEWORK = {
# 缓存过期时间
'DEFAULT_CACHE_RESPONSE_TIMEOUT': 60 * 60,
}
安装
pip install drf-extensions
使用
常用的两种方式，装饰器和Mixin
装饰器用法
from rest_framework_extensions.cache.decorators import cache_response
class ViewSet(viewsets.ModelViewSet):
...
@cache_response()
def list(self, request, *args, **kwargs):
...
Mixin用法，注意 CacheResponseMixin 要放在 ModelViewSet 的前面
from rest_framework_extensions.cache.mixins import CacheResponseMixin
class ViewSet(CacheResponseMixin, viewsets.ModelViewSet):
...
参考资料
- drf实现常用数据缓存：https://segmentfault.com/a/1190000018170069
响应数据量太大问题
前面那个可视化地图的页面，需要获取几万条人员信息，这个接口一开始没做优化，返回的数据大小有50MB，就很离谱，单纯网络传输就用了40秒，卡的一批。
前端小伙伴反映这个问题后，我查看一下服务器的日志，发现响应时间就达到了5秒，这忍不了啊。一开始是加了缓存，效果显著，响应时间直接压缩到了0.1秒！不过没用，传输时间还是很长。
继续分析，因为是用DjangoStarter的自动代码生成功能实现的接口，所以请求之后会默认返回人员信息的所有字段，但很明显，地图上只需要三个字段：ID、经纬度。
所以我重新写了个 serializer
class BasicPersonSerializer(serializers.ModelSerializer):
class Meta:
model = BasicPerson
fields = ['id', 'address_lng', 'address_lat']
然后在 viewsets 里也重写了 list 方法，用上新定义的这个 serializer
class BasicPersonViewSet(viewsets.ModelViewSet):
...
@cache_response()
def list(self, request, *args, **kwargs):
queryset = self.filter_queryset(self.get_queryset())
page = self.paginate_queryset(queryset)
if page is not None:
serializer = BasicPersonSerializer(page, many=True)
return self.get_paginated_response(serializer.data)
serializer = BasicPersonSerializer(queryset, many=True)
return Response(serializer.data)
然后再来测试一下，响应时间69毫秒，数据量变成4MB+，效果很显著！
整个传输时间只需要1.2秒左右~
妙啊，但是我还不满足，既然还有优化空间，那就继续优化。
给接口加个gzip压缩吧~
为图省事，直接上全站压缩
MIDDLEWARE = [
'django.middleware.gzip.GZipMiddleware',
]
搞定
再次请求看看
数据大小被压缩到480kb，传输时间只需要356毫秒！妙啊
这个问题就搞定了。
参考资料：Django使用gzip实现压缩请求 - https://www.pythonf.cn/read/116970
聚合查询
既然用Django了，有了这么方便好用的ORM，就别老想着用什么SQL语句了。
我在这个项目里比较常用的是这几个
- aggregate
- annotate
- values （虽然这个可能不算，但用的很多）
- Count
- Sum
每个函数的具体用法我就不复制粘贴了，看下面的参考资料吧~
参考资料：
- 聚合 | Django 文档 | Django (djangoproject.com)
- 075： 【Django数据库】ORM聚合函数详解-Sum - zheng-weimin - 博客园 (cnblogs.com)
性能优化
Django性能确实有点一言难尽，性能优化也老生常谈了，不过就实际运用而已，我们这也还是在探索之中，因为大部分场景是够用的，没有多高的并发。
不过有个比较慢的地方是展示大屏的数据接口，因为要汇集好几个表的数据进行统计，几十万上百万的数据，有点慢，一开始响应时间需要40秒，这也太离谱了。
肯定是得优化的，优化思路从减少数据库访问次数、合并运算、增加缓存入手，优化完成之后冷启动速度5秒，命中缓存60毫秒内，效果还是可以的。
关于性能优化这块以后还是得继续看看，Django有太多可以优化的地方了……
（或者不行的话直接用.Net Core这种高性能的平台重写？）
部署
部署方面依然是 uwsgi / docker / docker-compose 这套组合，之前用了好多次了，比较稳定，配置文件都是现成的，直接把代码上传服务器 up一下就启动了，非常方便。
对了还需要配置一下nginx，uwsgi是专有协议，需要做个转发，才能使用http访问到。
部署之后关闭debug模式，还需要进入docker容器里，在bash里执行 collectstatics 收集静态文件。
之后要更新的话，只需要在pycharm里配置 commit 的时候顺便deploy，把修改的代码文件提交到服务器，然后修改一下 readme.md 文件（我配置了监听这个文件）即可重启服务。
项目监控
对了，还有一个关键的，项目上线之后，需要监控项目的运行状态
对于Django项目，我用的是sentry来做监控，很好用，集成也很方便，这个sentry我准备后面写篇文章来介绍。
PS：对于.Net Core项目，我用的是.Net专用的ExceptionLess，这个界面很简洁直观，但文档没有sentry详细，不过docker搭建还是很方便的。
可以看我之前的这篇文章：[Vue2.x项目整合ExceptionLess监控](
小结
OK，大概就是这样了，项目也不是到这里就结束了，只是暂告一个段落，接下来看看客户那边有什么新的需求再来继续开发。
Django框架陆陆续续也用了两三年的时间了，虽然应用场景都比较简单，但属于是基本摸清了开发流程和定制的上限，像django-admin这种内置的管理后台，尽管有大量的自定义配置功能，还有simpleUI这种优秀的第三方界面，但他的上限还是摆在那，遇到稍微需要定制化的管理后台需求，还是得自己搞一套，好在用RestFramework写接口实在是方便，接口导出来，套个vue+elementUI的前端，一套后台就搞定了。
如果还需要数据大屏这类可视化功能，我们现在也积累了一些这方面的技术和经验，可以比较快的出产品。
接下来很多新的项目还是优先使用.Net Core技术，从稳定性和性能的方面考虑，我还是更信赖.Net Core。
Django的优势主要还是在于开发效率和背靠Python社区的强大生态，不过性能和部署方便就要稍逊一点点。
总之，都好用，看场景使用~