把系统分为几个不同的程序，不允许直接操作数据库，都通过 HTTP 方式来访问数据是否合理？

[lichun]

在现在公司就遇到了这样的架构设计：

把一个系统分为几个不同的程序，不允许直接操作数据库
全部通过 HTTP 集中请求到某个数据服务程序来操作数据，这种架构是否合理？

这种系统写起来特别难受啊，一个增删改查要改两套代码。

数据服务程序要增加接收数据保存或者修改的接口.
需要操作的程序就得把数据转成json, 再发送给数据服务.

一个电商后台订单系统，拿 Python 做的！

现在这个项目一大半的代码都在写参数检查，和json序列化了!
就一个保存数据的操作，各种datetime 转字符串， decimal转字符串！

[jasontse]

代价太大了吧

[jtacm]

这个和 Python 有什么关系？

[kanezeng]

看情况啦，不过一般放公网的系统哪怕再小最好这样，不用暴露数据库本机不是。数据库服务器的防火墙只需要给那个提供数据服务 api 的机器留个口就行。如果客户端程序访问数据库，那就要求数据库服务器暴露给所有的客户端啊。

另外，方便扩展，方便前后端分离，方便支持更多平台也都是很好地结果啊。

[bk201]

你当你在写个人程序呢，反正 java 基本都是这样写程序的。

[strahe]

我们公司也这样的，都是各写各的代码，最后接口文档给出来就好了

[lovedboy]

合理。

[izoabr]

蛮好的，对外，特别是大项目，对程序员的要求就低了，拿文档一看，甚至那 json 一看就知道这个接口怎么用。
而数据结构和对象关系只需要那个读写数据库的 ORM 去维护就可以了，别人不用管。

至于这个读写数据库操作的东西其实还可以加一个 MQ ，前段 NGINX 之类的带一个动态语言去处理 HTTP 请求（这部分是不是可以叫做 CGI 了），然后丢到 MQ 里，后面一堆 worker 从 MQ 听消息存取数据，然后反馈到 MQ 里，前面 HTTP 拿到反馈就给客户端。
这样这个 worker 就可以横向随便拓展了，谁负载低谁就先拿走消息去处理并反馈。
处理 http 的 nginx 也可以随便横向拓展，用 DNS 轮训或者其他 HTTP 负载均衡技术就可以解决。


DB<----->WORKER<------->MQ<------->HTTP （ CGI ）<------->NGINX


这个 HTTP （ CGI ）主要是轻量级，它不操作数据库，只负责做 MQ 的消息转发，所以很轻量化，甚至可以用静态语言去写，或者封装到 NGINX 里面去，所以这部分性能可以压榨出来。

后面的 WORKER 压力会比较大，所以让它能支持横向扩展才行，不过会有一个数据库锁的问题，如果碰上了锁，性能就不好办了，所以后端数据库优化要根据业务具体情况来做。

[izoabr]

上面这个方式，还有一个好处就是可以在 MQ 和 WORKER 这两个地方加插件，比如做统计分析、安全检查、数据拦截之类的。

[azhao]

这是微服务的架构,架构是合理的
但是划分是不合理的,因为数据库本身就是一个服务了,如果确实要保护数据全安,就应该拆表物理分离区分保护
好好的一个解耦变成了强合耦

[sunchen]

看项目规模

[billwang]

如果为了安全这么做的话也无可厚非

[hqlf6rqieee3]

你需要 django 和 django-rest-framework

[johnsneakers]

骚年， 你就快悟到了 microservice 的真谛。 可以搜索关键词看看。 (PS:我司目前在用这样的架构,很爽)

[libook]

项目达到一定规模需要解决一些问题，对于一些问题，有一种很好的思路就是分层，我猜你这种设计就是分层的设计，这种架构设计广泛存在于 Java WEB 项目中，底层模块用于操作数据库，其逻辑对表层透明，底层与表层之间约定接口，这样每一层的每个模块功能相对单一，开发起来非常方便，在业务复杂度到一定程度确实能大大减少代码的重复以及大大降低逻辑复杂度。不过还要看用于何种场合和如何设计。通常是一个小团队维护一层，层与层之间的接口要有规范的版本管理。如果你觉得你们公司使用这种架构并没有达到上述优点反而变成了累赘的话还不如换架构。