很多人觉得 flask 不适合做大型项目，其实这是不对的，flask 不仅做小众网站强悍，
做大型网站也毫不逊色。一个好的目录结构，对整个项目的影响是深远的，尤其是对
维护开发人员，更是阅读友好，方便查阅修改的。
注：这里说的适不适合做大型项目，完全只是从目录结构考虑的，不考虑插件等，
不接受杠精反驳
给大家看一下我的目录结构：
给大家简单聊一下各个模块的作用
myblog(项目名)下有 app, logs, migrations, venv 四个文件夹或模块
app 下面是按照功能模块进行划分的，比如article是和文章相关的功能，
auth 是登录认证相关功能，comment是相关评论功能等
logs 是项目的日志文件
migrations 是数据库迁移相关
venv 项目的虚拟环境
manager.py 是项目的入口，目前用作开发调试，
后期会维护一个wsgi.py 方便用gunicorn近期启动管理
对于目录结构可能还有更好的设计，我们把目录功能拆的那么细，那么项目
是如何串起来的呢。这个才是关键。
蓝图
把各个功能模块串起来，其实蓝图功不可没，首先在功能模块中创建一个蓝图
然后把这个蓝图对象articles_bp 在app上进行注册
这时候有人会问，如果有多个模块的话，扩展起来每次都要修改application.py里的
configure_blueprint函数，这样有点麻烦，有没有简单一点的办法呢，答案当然是有的了
自己写一个实现自动注册的功能就好了。可以通过 importlib.import_module来进行
动态导入模块，我们的蓝图对象知道一个规则，命名统一以XXX开头或结尾，然后通过
分析该模块是是否有蓝图对象，来实现自动注册功能。这里就不赘述了。
通过以上的操作 ，我们就把各个功能模块串联在一起了。
日志
日志配置也很重要，一个好的日志，对定位问题有巨大的帮助。
我这里用的日志策略是按天划分，一天一个日志， 默认保存一个月以内的日志，
下面给大家看一下代码。
数据库迁移
我们总希望部署能够简单，所幸，我们找到了数据库迁移工具包flask_migrate, 使用也很简单。
flask db init # 初始化工具，并生成一个migrations文件夹
flask db migrate # 生成迁移文件，也就是migrations下面的version文件夹里的文件
这些文件都是具体执行的动作指令，比如创建表啊类似等
flask db upgrade # 执行数据库操作动作，实际上就是执行上图中upgrade()函数，
来操作数据库, 比如上图有个create_table 你就能明白，这是一个创建表的动作。
执行完成之后，可以检查数据库是否有这个表生成。
然而实际上我们经常和flask_script一起使用，比如：
使用命令方式相应改为上图注释中所示那样。
数据迁移的坑
最初连接数据库是用mysql+pymysql 这种方式，但是这样会有一个warning
心里不爽，经过一番搜索，找到一个答案，改成了 mysql+mysqlconnector这种
方式，果然不报warning，心里美滋滋。
然后再做数据迁移的时候，我发现第一次迁移生成的迁移文件还算正常，
什么创建表之类的，但是当我更改数据库模型，准备升级数据库的时候，
我发现，这种连接方式有个严重的问题，导致我通过
flask db migrate生成的迁移文件，每次都是创建表，
而在运行flask db upgrade 总是报错，表已存在。
折腾了好久，最后实在找不到答案的情况下，福至心灵的改了下连接方式，果然
就正常了，虽然还是由警告，但是也比诡异的出错强。
说的有点杂，但是都是一把辛酸泪啊。
写到这里，基本的目录架子也算有了，剩下的就是我们继续优化我们的功能代码，
功能目录，但愿在需求变更的时候，我们能更有效率。
