web 后端开发的思考

web 后端开发的思考

概述

---

随着互联网的崛起，http 调用成为最流行的调用方式 ，但不排除其他的，例如 grpc 等比较注重性能的调用，但 http 的调用基本满足了我们 80% 的应用开发调用需求，这里 记录一些自己对 web 后端开发的一些思考和想法。

db connect

---

说到每一个请求,基本上都需要通过访问数据库，那么一个请求在使用 一个 db connect 这种方式已经成为一种正常的 处理设计。
那么这种设计是合的吗？ 我通过调研很多 orm 框架 来得到答案。

• django orm
• sqlalchemy
• peewee
• gorm
• ….

django orm

Since each thread maintains its own connection, your database must support at least as many simultaneous connections as you have worker threads.

这是来自于 django database 官方文档中的一段话, 大概意思是 web 服务支持多少个并发，数据库就需要支持多少个并发 。

sqlalchemy

sqlalchemy 是很著名的 orm，很多大型的项目都用到了它，例如： openstack 等，当然也有很多轻量的 web 框架也用到了它，例如 flask web 框架等 ，在 web 开发和后端服务器开发都很好的得到了认可 ，功能非常强大。扯远了。

就拿 flask sqlalchemy 的插件来的配置说吧，

SQLALCHEMY_POOL_SIZE 这个是配置在 app 上，flask_sqlalchemy 通过 app 得到这个配置，默认 5 个 连接，

flask_sqlalchemy 提供了一个连接池，每个请求过来的时候就申请一个链接，请求处理完就回收这个链接到地址池中，但不会断开这个 tcp 链接, 这是 sqlalchemy 为了减少链接数据库的开销影响处理的时间， 使用了保持链接 ，当然每一次请求都会做 mysql.ping 确保连接都是可用的。

设想一下并发 10 个 请求（默认 flask_sqlalchemy 的连接池是 5），每个请求都会取一个数据库连接(@app.before_request) 进行 处理请求，那么第六个请求就只能等待 连接池有空闲的连接，这个很好实现 。当然他也有SQLALCHEMY_MAX_OVERFLOW 来协作在 正常不能满足的情况下增加一些 连接池的链接数。

peeweee

这个是轻量级的 orm ，使用方式和 django 的 orm 很像，它也是有维护链接池 ，但只维护一个长连接，一旦请求结束 ，占用的数据库连接就断掉了 tcp 的数据库连接，这种比较适合压力比较小的系统.

总结

---

web 开发中使用的 数据库连接一般分为两种，一种是一个请求一个数据库连接，像 flask + peewee ，它把请求方在全局的 flask.g 中，在整个请求的生命周期都用这个数据库连接；另一种就是随使用随释放，想 django 的 rom 和 sqlalchemy 等, 使用 python 的 with 属性，或 用 golang 的 defer 来实现 return 前的回调。 其实设计到请求的上下文管理问题，如何优雅的管理上下文，就能优雅的关机一切。

context

---

上下文对每个 web 开发来说都很重要，他详细描述了一个请求的生命周期。最精彩的是 flask 的 context，这归根结底是 thread.local 的功能，一个对象在多个线程保持隔离，每个线程都能获取到当前的 context 对象等信息。

django 的 context 是放在入口函数中，我也观察了一些 golangye 实现的 web 框架（echo， beego 等），他们基本也是这么做的，其实我是不是很理解，有可能额还没有发现更深层的问题。

result data

---

对于接口返回数据基本分为两种

• http code 的方式, 这种基本依靠 http 的 code 定义的信息来实现。
• 信息写入 json 返回信息中，让应用来判断信息内容有效等信息

{
    code: 0
    data: xxxx
    message: "error log"
}

但是在现实业务系统中都有找到他们的影子，基本边界定义为：

• 如果是权限问题或用法直接返回 http code（401， 400）
• 如果是业务层调用，属于业务层的逻辑建议用 json 方式，把状态信息放入 在 json 中，方便 第三方系统调用的数据判断等。