flask网站项目(5)--订单支付、总结与优化

1、订单支付

订单支付与上个项目(Django电商网站)的支付类似，同样调用支付宝的接口，简单流程：用户点击’去支付’按钮跳转发送请求(携带订单ID)，后端接收请求并校验参数后调用支付宝接口返回支付链接，由前端控制跳转或新打开一个页面显示用户与支付宝的交互页面(在移动端上还可以唤醒支付宝客户端)，用户支付完成后进行支付结果处理：
①使用return_url(return_url是支付宝返回的让用户访问的网址，可以是局域网网址)，支付宝会将信息(sign/trade_no/total_price等)以url参数的方式直接拼接在提供的return_url中，在支付界面支付完成后，支付宝会自动跳转(使用户的浏览器发起GET请求)到拼接后的return_url页面，在此页面中根据支付宝提供的结果处理订单交易状态、保存交易流水号(需要将第三方支付的唯一交易流水号进行保存，后续查询使用)等操作就在该页面中完成；
②使用notify_url(notify_url是支付宝访问的地址，必须是公网网址)，不常用；
③后端调用接口去访问支付宝获取交易状态，一般在去支付(去支付功能返回访问支付宝的url)的回调函数或过渡页面执行，相对①更安全稳定，与支付宝交互的流程如下。

2、总结与部署

完成上述功能后，整个网站就基本完成了，在开发时使用的是测试用的flask服务器，实际应用中使用nginx与gunicorn，具体的部署架构与网站访问流程如下：

注：①前后端分离，对于后端来说只需要处理页面动态的请求，而对于静态页面/图片/静态文件(css/js等)的请求都应有一个或多个统一的服务器进行处理；
②当静态页面与flask项目分离时，注意csrf的设置，以及必须要考虑到的浏览器缓存不重复发送请求等情况(304)；
③前端与后端通过json格式进行数据传递(特殊文件的传输如图片/多媒体等需要另行考虑)，因此发送请求时必须注意Ajax的发送形式设置与响应时响应头中content-type的设置。

3、优化

该项目基于flask框架，使用前后端分离的架构，使用的一些优化方法：
①数据库表设计时的空间换时间；
②第三方图片存储，第三方的短信验证码发送，第三方的图片验证码生成；
③celery异步发送短信验证码，以及异步处理支付宝支付结果；
④使用redis存储特定页面的缓存；
⑤使用art-template前端模板简化前端操作；
⑥添加了许多验证机制，尤其在用户注册时，提高了网站的安全性；
⑦使用统一的状态码，前后端只通过json传递数据，解耦的同时也减小了异常的处理范围；
⑧使用如图所示的方式进行部署，提高了网站处理并发的能力。

此外，还可以进行优化或需要注意的问题有：
①如图所示的缓存处理格式，可能存在的隐患：
若redis数据库获取时出现异常，则resp_json未定义，因此一般添加else语句，保证try后无异常时再对缓存数据进行返回。

②关于mysql中同时执行order_by和limit时可能存在的问题：当order_by的字段值相等时，其排列顺序并不固定，因此假如limit(5)，共有10个字段值相同的数据，可能出现多次查询的结果不一致的问题。

③关于csrf：flaskwtf的防护机制CSRFProtect，其是将生成的csrf保存到session中，并将session中的csrf与请求体中的csrf进行对比，并非从cookie中提取csrf值，因此在某些特定的情况下会出现错误(如退出登录，清空了当前浏览器的session，但登录页面已缓存没有再次发送请求将csrf_token值保存在session中，即cookie中还存在，提交的表单也从cookie中获取到了值，但session中不存在)。

④应使用os.path.join(os.path.dirname(file), ‘xxx’)拼接路径，意为当前文件目录下的xxx。

⑤关于模型类方法：经常将一些比较常用的方法封装在模型类中，以使得调用时简单，如：
Ⅰ信息转换为字典输出，调用jsonify时简单；
Ⅱ密码的hash存储与检验；
Ⅲ图片完整url的合成。

⑥关于数据库的优化：
Ⅰ表结构的优化，以及设计时应遵循的三范式，空间换时间，关联的使用等；
Ⅱ索引及复合索引的使用；
Ⅲsql语句的优化，如尽量不使用select *，尽量不使用嵌套与联合查询，在数据量很大时不使用外键等；
Ⅳ读写分离与主从；
Ⅴ分库分表；
Ⅵ多利用缓存等
关于数据库的优化在后续MySQL简介中会详细处理分析。

以上即flask租房网站项目的全部内容，其中一些组件的配置皆搜索可得，此处不再赘述，完整代码参[https://github.com/Icemelon99/test_project_ihome]。