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