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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

推荐学习书目

› Learn Python the Hard Way

Python Sites

› PyPI - Python Package Index

› http://diveintopython.org/toc/index.html

› Pocoo

值得关注的项目

› PyPy

› Celery

› Jinja2

› Read the Docs

› gevent

› pyenv

› virtualenv

› Stackless Python

› Beautiful Soup

› 结巴中文分词

› Green Unicorn

› Sentry

› Shovel

› Pyflakes

› pytest

Python 编程

› pep8 Checker

Styles

› PEP 8

› Google Python Style Guide

› Code Style from The Hitchhiker's Guide

这是一个创建于 3250 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

数据

程序

JSON

字符

34 条回复 • 2015-12-23 17:51:34 +08:00

wy315700

2015-12-22 20:44:01 +08:00

这就是中间件的思维啊，不过不适合用 http 去做，，，

gamexg

2015-12-22 20:48:45 +08:00

常见的做法。
不过全手写就太麻烦了，楼主可以看看 thrift 等库。

virusdefender

2015-12-22 20:49:47 +08:00

这就是服务化的概念吧

halfcrazy

2015-12-22 20:52:46 +08:00

用 RPC 例如 thrift protobuf 这些性能效率会比 json 高很多

hao123yinlong

2015-12-22 21:26:09 +08:00

dubbox

wowpanda

2015-12-22 21:26:32 +08:00

饿了么？

JohnDeng

2015-12-22 21:36:06 +08:00

知道是哪家了...

就不怕写入程序挂了..然后全部挂了..

dalei

2015-12-22 21:53:21 +08:00 via iPad

你需要 restfulframework

hrong

2015-12-22 21:58:12 +08:00 via Android

web service 不就是这样的么？服务化， ESB 。

Tink

2015-12-22 22:01:19 +08:00

读取数据库的服务得可靠，要不然这个崩了就全挂了

est

2015-12-22 22:18:09 +08:00

SOA 。 microservice 。 http 性能跑不到 1w req/s 就是脑残设计。

Madeline

2015-12-22 23:06:40 +08:00

服务之间可以考虑用基于 socket 的 zeromq 来通信，比 http 性能高很多。

felixzhu

2015-12-22 23:49:27 +08:00

服务化的前提是业务稳定有一定规模，快速迭代开发的小项目就开始服务化得不偿失。

然后后期肯定是要换做 RPC 框架的，这得问你们架构师最开始什么想法。。。

binux

2015-12-22 23:54:42 +08:00

aws 各种服务就是这样的, 逐层封装就好了, 有什么不合理的?

raysmond

2015-12-22 23:59:48 +08:00

做成微服务的方式吧，用 REST 接口

twor2

2015-12-23 00:11:41 +08:00

大一点的系统，应该是面向维护和稳定的，而不应该是面向开发的

latyas

2015-12-23 00:34:43 +08:00

说说我的看法

microservice ，很不错的设计，对于这种架构，最好要走 HTTP 协议， hessian （你让其他语言怎么活） thrift protocolbuffer 甚至与阿里的奇啪 RPC 框架 dubbo 都完全没必要， HTTP-JSONRPC 或者 HTTP-RESTFUL API 都是很合理的结构，特殊的序列化协议赢在序列化和反序列化的速度，以及信息的压缩比上，然并卵，除非你的程序已经达到一定量级了，不然这种系数级的性能提升远不如多加一台服务器来的快速，并且用这种非人类可读的协议， debug 的时候可以 debug 到你流泪。

数据访问层抽象成 API 而不是直接访问数据库，对于业务系统，数据的操作是透明的，业务代码程序员无需关注数据层的物理实现，优化的时候也可以独立出来优化。

至于就接为什么用 python ？因为描述场景速度快。

msg7086

2015-12-23 02:55:57 +08:00

microservices 结构很好啊。写好测试规范好 API ，以后要扩展起来就是神一样的。
单机可以扔进 docker/虚拟机，以后业务上来了，放进 LAN 里跑，再以后可以上集群。

inisun

2015-12-23 03:31:06 +08:00

最近就做了个 webservice

minsheng

2015-12-23 07:34:17 +08:00 via iPhone

这个场景蛮适合 Haskell 的 Servant ，用类型系统保证 API 的正确性，也能根据 API 的类型自动输出其它语言的绑定。推荐看看，挺好玩的。

jasontse

2015-12-23 07:45:39 +08:00 via Android

代价太大了吧

jtacm

2015-12-23 08:58:16 +08:00

这个和 Python 有什么关系？

kanezeng

2015-12-23 09:06:13 +08:00

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

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

bk201

2015-12-23 09:24:09 +08:00

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

strahe

2015-12-23 09:30:33 +08:00

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

lovedboy

2015-12-23 09:46:52 +08:00

合理。

izoabr

2015-12-23 09:55:26 +08:00

蛮好的，对外，特别是大项目，对程序员的要求就低了，拿文档一看，甚至那 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

2015-12-23 09:57:41 +08:00

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

azhao

2015-12-23 11:20:34 +08:00

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

sunchen

2015-12-23 12:30:55 +08:00

看项目规模

billwang

2015-12-23 13:03:21 +08:00

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

hqlf6rqieee3

2015-12-23 13:14:47 +08:00

你需要 django 和 django-rest-framework

johnsneakers

2015-12-23 16:18:37 +08:00

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

libook

2015-12-23 17:51:34 +08:00

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