这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
为什么……不拿另一个 HTTP 服务器来当作数据库来给一个 Web App 使用？
raincious · 2014-07-02 22:09:10 +08:00 · 6364 次点击这是一个创建于 3826 天前的主题，其中的信息可能已经有所发展或是发生改变。
// 首先，我知道这个想法挺怪异且折腾的（所以出现在了奇思妙想里啊，啊哈哈哈哈）。
貌似现在大多数常见的Web架构布局都一个用各种语言写的Web App+ 一个（或多个）数据库，然后Web App直接连接这个数据库存取数据。
而很多手机App的布局都是一个Native的客户端，然后连接到一个Web App，然后Web App连接到数据库取回数据交给手机App。
那为什么不可以用另一个HTTP服务器来当数据库用，然后其他Web App通过各种方式取得这个HTTP数据库服务器返回的内容（以比如Json的形式），貌似这样可以更加容易的管理缓存和实现分布式啊？
然后Web App就可以也像移动端App一样，仅仅负责显示和交互之类的了。（对吧？）
是不是因为HTTP协议的性能不好？刚拿Go自带的HTTP模块做了个测试，大多数请求在1ms左右完成（虽然还是比数据库的查询时间长了很多），但比整个网站的运行时间要短。如果复用链接的话，可能能以相对不是延迟很久的时间完成多次请求。
代码：
https://gist.github.com/06dda39721dccda06348.git
// 好吧，怪异的想法，请勿喷。
貌似现在大多数常见的Web架构布局都一个用各种语言写的Web App+ 一个（或多个）数据库，然后Web App直接连接这个数据库存取数据。
而很多手机App的布局都是一个Native的客户端，然后连接到一个Web App，然后Web App连接到数据库取回数据交给手机App。
那为什么不可以用另一个HTTP服务器来当数据库用，然后其他Web App通过各种方式取得这个HTTP数据库服务器返回的内容（以比如Json的形式），貌似这样可以更加容易的管理缓存和实现分布式啊？
然后Web App就可以也像移动端App一样，仅仅负责显示和交互之类的了。（对吧？）
是不是因为HTTP协议的性能不好？刚拿Go自带的HTTP模块做了个测试，大多数请求在1ms左右完成（虽然还是比数据库的查询时间长了很多），但比整个网站的运行时间要短。如果复用链接的话，可能能以相对不是延迟很久的时间完成多次请求。
代码：
https://gist.github.com/06dda39721dccda06348.git
// 好吧，怪异的想法，请勿喷。
第 1 条附言 · 2014-07-03 09:37:58 +08:00
仔细想了下，其实就是个数据库中间层。那么也就协议无关了。HTTP只是可以保证通用访问性，而且可以顺便实现权限管理，让不同的访问源能够获得不同权限的数据。
相当于将Web App的数据层拿出来了。
比如，目前是需要将查询之类写在Web App里，未来可以按照指定协议写一个Json格式的请求数据，提交给HTTP协议的数据库，HTTP数据库查询之后返回结果Json。
具体过程是这样：
客户端访问Web App -> Web App构建Json发送给HTTP数据库 -> HTTP数据库构建通过配置构建好查询发送给真正的数据库（们） -> 真正的数据库（们）返回结果 -> HTTP服务器搜集数据库的返回，缓存并构建结果 -> HTTP服务器构建一个结果Json，然后返回这个数据给Web App。
不过似乎有点多此一举的感觉，貌似我得再想想。
相当于将Web App的数据层拿出来了。
比如，目前是需要将查询之类写在Web App里，未来可以按照指定协议写一个Json格式的请求数据，提交给HTTP协议的数据库，HTTP数据库查询之后返回结果Json。
具体过程是这样：
客户端访问Web App -> Web App构建Json发送给HTTP数据库 -> HTTP数据库构建通过配置构建好查询发送给真正的数据库（们） -> 真正的数据库（们）返回结果 -> HTTP服务器搜集数据库的返回，缓存并构建结果 -> HTTP服务器构建一个结果Json，然后返回这个数据给Web App。
不过似乎有点多此一举的感觉，貌似我得再想想。
 |
1
isy 2014-07-02 22:23:24 +08:00  1
|
 |
2
jsonline 2014-07-02 22:25:00 +08:00 via Android
什么叫另一个HTTP服务器
|
 |
4
2code 2014-07-02 22:36:12 +08:00 2
Apache CouchDB™ is a database
that uses JSON for documents, JavaScript for MapReduce indexes, and regular HTTP for its API |
 |
5
xingxiucun 2014-07-02 22:43:31 +08:00 3
你这个HTTP数据库的另外一个名字叫API服务器？
|
 |
6
WildCat 2014-07-02 23:02:11 +08:00 via iPhone
Hybrid App不就是这么做的？
|
 |
7
izoab 2014-07-02 23:12:47 +08:00
呃···，原谅我没太看明白。
是不是想说新浪微博那样的。 但不管怎样，数据库的存在是必要的，因为他解决检索、统计和持久化的问题，如果直接通过http直接去获取元数据，给json，那是不是有权限管理和数据组织的问题？所以不能直接去获取元数据，而是需要一个应用去管理和维系数据与应用关系，让你获取到你应该获取的内容，而不应该获取的就不给你了，要也不给。 这样的话，把上面这些压力就给服务器了，而手机App这样的东西就可以傻瓜化，减轻手机的负载了。。。 哎呀，反正也没看懂。。。 |
 |
8
XadillaX 2014-07-03 00:24:16 +08:00
你自己不知道罢了。很多地方都是这么做的，就我目前刚上手的项目构架也是这样的。
|
 |
9
lincanbin 2014-07-03 00:25:03 +08:00
Web App现在基本都是Ajax了，所以不是直连数据库，而是有一套JOSN格式交换数据的API。
客户端和Web App也是可以共用的，但是没什么必要，一般都会另外开发一套，因为业务逻辑上会有一定差别。 |
 |
10
caomu 2014-07-03 01:44:04 +08:00 via Android 1
我想到的是RESTful API。。。
|
 |
11
ming 2014-07-03 01:45:15 +08:00
当然可以 现在很多应用其实就是这么做的
|
 |
12
yakczh 2014-07-03 08:21:50 +08:00
sql 写到页面里吗?
|
 |
13
rrfeng 2014-07-03 08:55:16 +08:00
插播一句……
ttserver 支持 http 方式 |
 |
14
raincious OP @XadillaX 貌似是的。我觉得我越想越像是MongoDB，但是这主意主要是解决数据库依赖的问题，让应用程序依赖一个中间层协议，而不是直接依赖数据库。这样就可以在不更改一行代码的情况下使用各种（从SQL到Redis）数据库。
|
 |
15
isno 2014-07-03 09:48:47 +08:00 1
http://www.isno.cn/2014/06/golang-thrift-google-protobuf/ 之前写的一个文章，设计一个跨语言高性能的数据中心（还没写完）
|
 |
16
qwe542398 2014-07-03 10:22:52 +08:00
ajax？
|
 |
17
semicircle21 2014-07-03 10:34:48 +08:00 1
用HTTP协议做数据库的API接口并不少见, MongoDB 等等.
但数据库(DBMS)和HTTP服务器面向的问题是不一样的: 就拿最简单的key-value式的需求而言, 如果用HTTP服务器, 假设用静态文件来实现, 当海量的几十字节的小key-value对存成硬盘上时, 文件系统经不起这么造, 这时就需要数据库来组织管理了. 如果你用go的map来实现, 那实际上也是map解决的数据库的问题(且不谈持久化), 而不是HTTP服务器能做到的.. ...不知我表达清楚没, 楼主感受下哈~ |
|
18
semicircle21 2014-07-03 10:39:55 +08:00
@isno 文章不错, 已读, 期待下文, 你后来真的用thrift了吗? 效果如何?
我大概10个月之前看thrift, 那时项目的状态不太好, 所以没敢用. |
 |
19
qiongqi 2014-07-03 11:29:03 +08:00 1
lz的思路扩展下，就是把数据读取和存储作为一层，同时为web，APP，wap等提供数据，然后web，APP，wap自己把数据拼入模版？我理解是这样的，是吗？
一般业务量大的都有类似的做法的，下面的层里不仅仅有数据库，还有其它东西，通信的协议也不仅仅是http的，有很多tcp的，甚至有udp的。。 |
 |
20
iam36 2014-07-03 12:24:18 +08:00 1
性能考虑
jason对于大量数据是很没有效率的协议标准 换个说法,有天网络带宽达到某种程度的时候,数据库(目前的性能级别的）就会广泛存在于互联网间了． 这个问题基于你的理解层面很有价值，加油． |
|
21
iam36 2014-07-03 12:25:08 +08:00 1
补充一点, web server其实比现在的商用数据库简单得多:)
|
|
23
isno 2014-07-03 18:35:01 +08:00
@semicircle21 thrift的性能是很变态的，cassandra 数据库是用thrift 做的接口， 最近比较忙， 博文还没写完， 整个数据中心实现 简单来说就是 protobuf做数据定义， thrift 实现接口， 效果超出预期
|
 |
24
ichou 2014-07-04 00:38:41 +08:00
难道楼主说的不是数据服务器分离？ 顺便把一部分逻辑移到数据服务器上么？
说到实际情况中，感觉逻辑如何分离本身就会是个不小的问题，项目迭代到后面极可能发现之前的 API 就是个坑 哈哈~ |
 |
25
yangkeao 2014-07-04 14:13:55 +08:00
前后端分离？？
我是不是想得太简单了? |
|
26
raincious OP @ichou 如果真这样做的话，API设计一定要合理了。而且得考虑版本。确实可能成为个坑。但是作为解决数据库依赖的中间层还是挺好的。不过这样就仍然必须还得有WebApp存在。
|
 |
27
yueyoum 2014-07-04 17:30:21 +08:00 1
LZ 一定不知道 CouchDB
|
 |
28
zhenggc1 2014-07-04 18:19:23 +08:00 1
楼主可以去看看rest和soa相关的内容。
|
 |
29
ChiChou 2014-07-04 22:36:08 +08:00 1
LZ 一定没用过 ElasticSearch
|
|
30
raincious OP @yueyoum
唔……你错了呢……其实我还是知道名字的…… 嗯……关键我的思维是为我的MySQL找个中间层，免得未来要换数据库太麻烦。（主要是https://v2ex.com/t/119720被一楼震到了） 所以……我其实没想真的换一个数据库。不过想想如果这样还不如直接上个CouchDB。 |
 |
31
lm902 2014-07-07 13:46:05 +08:00
Azure Table Storage HTTP+XML
|
Select Language