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