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

[lichun]

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

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

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

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

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

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

[wy315700]

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

[gamexg]

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

[virusdefender]

这就是服务化的概念吧

[halfcrazy]

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

[hao123yinlong]

dubbox

[wowpanda]

饿了么？

[JohnDeng]

知道是哪家了...

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

[dalei]

你需要 restfulframework

[hrong]

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

[Tink]

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

[est]

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

[Madeline]

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

[felixzhu]

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

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

[binux]

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

[raysmond]

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

[twor2]

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

[latyas]

说说我的看法

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

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

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

[msg7086]

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

[inisun]

最近就做了个 webservice

[minsheng]

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