把一个系统分为几个不同的程序，不允许直接操作数据库
全部通过 HTTP 集中请求到某个数据服务程序来操作数据，这种架构是否合理？
数据服务程序要增加接收数据保存或者修改的接口.
需要操作的程序就得把数据转成json, 再发送给数据服务.
现在这个项目一大半的代码都在写参数检查，和
json序列化了!
就一个保存数据的操作，各种datetime 转字符串，decimal转字符串！
 |
1
wy315700 Dec 22, 2015
这就是中间件的思维啊，不过不适合用 http 去做，，，
|
 |
2
gamexg Dec 22, 2015
常见的做法。
不过全手写就太麻烦了，楼主可以看看 thrift 等库。 |
 |
3
virusdefender Dec 22, 2015
这就是服务化的概念吧
|
 |
4
halfcrazy Dec 22, 2015
用 RPC 例如 thrift protobuf 这些性能效率会比 json 高很多
|
 |
5
hao123yinlong Dec 22, 2015
dubbox
|
 |
6
wowpanda Dec 22, 2015
饿了么？
|
 |
7
JohnDeng Dec 22, 2015
知道是哪家了...
就不怕写入程序挂了..然后全部挂了.. |
 |
8
dalei Dec 22, 2015 via iPad
你需要 restfulframework
|
 |
9
hrong Dec 22, 2015 via Android
web service 不就是这样的么？服务化， ESB 。
|
 |
10
Tink PRO 读取数据库的服务得可靠，要不然这个崩了就全挂了
|
 |
11
est Dec 22, 2015
SOA 。 microservice 。 http 性能跑不到 1w req/s 就是脑残设计。
|
 |
12
Madeline Dec 22, 2015
服务之间可以考虑用基于 socket 的 zeromq 来通信，比 http 性能高很多。
|
 |
13
felixzhu Dec 22, 2015
服务化的前提是业务稳定有一定规模，快速迭代开发的小项目就开始服务化得不偿失。
然后后期肯定是要换做 RPC 框架的，这得问你们架构师最开始什么想法。。。 |
 |
14
binux Dec 22, 2015
aws 各种服务就是这样的, 逐层封装就好了, 有什么不合理的?
|
 |
15
raysmond Dec 22, 2015
做成微服务的方式吧，用 REST 接口
|
 |
16
twor2 Dec 23, 2015
大一点的系统，应该是面向维护和稳定的，而不应该是面向开发的
|
 |
17
latyas Dec 23, 2015
说说我的看法
microservice ，很不错的设计，对于这种架构，最好要走 HTTP 协议， hessian （你让其他语言怎么活） thrift protocolbuffer 甚至与阿里的奇啪 RPC 框架 dubbo 都完全没必要， HTTP-JSONRPC 或者 HTTP-RESTFUL API 都是很合理的结构，特殊的序列化协议赢在序列化和反序列化的速度，以及信息的压缩比上，然并卵，除非你的程序已经达到一定量级了，不然这种系数级的性能提升远不如多加一台服务器来的快速，并且用这种非人类可读的协议， debug 的时候可以 debug 到你流泪。 数据访问层抽象成 API 而不是直接访问数据库，对于业务系统，数据的操作是透明的，业务代码程序员无需关注数据层的物理实现，优化的时候也可以独立出来优化。 至于就接为什么用 python ？ 因为描述场景速度快。 |
 |
18
msg7086 Dec 23, 2015
microservices 结构很好啊。写好测试规范好 API ，以后要扩展起来就是神一样的。
单机可以扔进 docker/虚拟机，以后业务上来了，放进 LAN 里跑，再以后可以上集群。 |
 |
19
inisun Dec 23, 2015
最近就做了个 webservice
|
 |
20
minsheng Dec 23, 2015 via iPhone
这个场景蛮适合 Haskell 的 Servant ，用类型系统保证 API 的正确性，也能根据 API 的类型自动输出其它语言的绑定。推荐看看，挺好玩的。
|
 |
21
jasontse Dec 23, 2015 via Android
代价太大了吧
|
 |
22
jtacm Dec 23, 2015
这个和 Python 有什么关系？
|
 |
23
kanezeng Dec 23, 2015
看情况啦，不过一般放公网的系统哪怕再小最好这样，不用暴露数据库本机不是。数据库服务器的防火墙只需要给那个提供数据服务 api 的机器留个口就行。如果客户端程序访问数据库，那就要求数据库服务器暴露给所有的客户端啊。
另外，方便扩展，方便前后端分离，方便支持更多平台也都是很好地结果啊。 |
 |
24
bk201 Dec 23, 2015
你当你在写个人程序呢，反正 java 基本都是这样写程序的。
|
 |
25
strahe Dec 23, 2015
我们公司也这样的，都是各写各的代码，最后接口文档给出来就好了
|
 |
26
lovedboy Dec 23, 2015
合理。
|
 |
27
izoabr Dec 23, 2015
蛮好的，对外，特别是大项目，对程序员的要求就低了，拿文档一看，甚至那 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 压力会比较大，所以让它能支持横向扩展才行，不过会有一个数据库锁的问题，如果碰上了锁，性能就不好办了，所以后端数据库优化要根据业务具体情况来做。 |
|
28
izoabr Dec 23, 2015
上面这个方式，还有一个好处就是可以在 MQ 和 WORKER 这两个地方加插件，比如做统计分析、安全检查、数据拦截之类的。
|
 |
29
azhao Dec 23, 2015
这是微服务的架构,架构是合理的
但是划分是不合理的,因为数据库本身就是一个服务了,如果确实要保护数据全安,就应该拆表物理分离区分保护 好好的一个解耦变成了强合耦 |
 |
30
sunchen Dec 23, 2015
看项目规模
|
 |
31
billwang Dec 23, 2015
如果为了安全这么做的话也无可厚非
|
 |
32
hqlf6rqieee3 Dec 23, 2015
你需要 django 和 django-rest-framework
|
 |
33
johnsneakers Dec 23, 2015
骚年， 你就快悟到了 microservice 的真谛。 可以搜索关键词看看。 (PS:我司目前在用这样的架构,很爽)
|
 |
34
libook Dec 23, 2015
项目达到一定规模需要解决一些问题，对于一些问题，有一种很好的思路就是分层，我猜你这种设计就是分层的设计，这种架构设计广泛存在于 Java WEB 项目中，底层模块用于操作数据库，其逻辑对表层透明，底层与表层之间约定接口，这样每一层的每个模块功能相对单一，开发起来非常方便，在业务复杂度到一定程度确实能大大减少代码的重复以及大大降低逻辑复杂度。不过还要看用于何种场合和如何设计。通常是一个小团队维护一层，层与层之间的接口要有规范的版本管理。如果你觉得你们公司使用这种架构并没有达到上述优点反而变成了累赘的话还不如换架构。
|
Select Language