V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐学习书目
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
lichun
V2EX  ›  Python

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

  •  
  •   lichun · 2015-12-22 20:43:13 +08:00 · 5756 次点击
    这是一个创建于 3019 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    一个电商后台订单系统,拿 Python 做的!

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

    34 条回复    2015-12-23 17:51:34 +08:00
    wy315700
        1
    wy315700  
       2015-12-22 20:44:01 +08:00
    这就是中间件的思维啊,不过不适合用 http 去做,,,
    gamexg
        2
    gamexg  
       2015-12-22 20:48:45 +08:00
    常见的做法。
    不过全手写就太麻烦了,楼主可以看看 thrift 等库。
    virusdefender
        3
    virusdefender  
       2015-12-22 20:49:47 +08:00
    这就是服务化的概念吧
    halfcrazy
        4
    halfcrazy  
       2015-12-22 20:52:46 +08:00
    用 RPC 例如 thrift protobuf 这些性能效率会比 json 高很多
    hao123yinlong
        5
    hao123yinlong  
       2015-12-22 21:26:09 +08:00
    dubbox
    wowpanda
        6
    wowpanda  
       2015-12-22 21:26:32 +08:00
    饿了么?
    JohnDeng
        7
    JohnDeng  
       2015-12-22 21:36:06 +08:00
    知道是哪家了...

    就不怕写入程序挂了..然后全部挂了..
    dalei
        8
    dalei  
       2015-12-22 21:53:21 +08:00 via iPad
    你需要 restfulframework
    hrong
        9
    hrong  
       2015-12-22 21:58:12 +08:00 via Android
    web service 不就是这样的么?服务化, ESB 。
    Tink
        10
    Tink  
       2015-12-22 22:01:19 +08:00
    读取数据库的服务得可靠,要不然这个崩了就全挂了
    est
        11
    est  
       2015-12-22 22:18:09 +08:00
    SOA 。 microservice 。 http 性能跑不到 1w req/s 就是脑残设计。
    Madeline
        12
    Madeline  
       2015-12-22 23:06:40 +08:00
    服务之间可以考虑用基于 socket 的 zeromq 来通信,比 http 性能高很多。
    felixzhu
        13
    felixzhu  
       2015-12-22 23:49:27 +08:00
    服务化的前提是业务稳定有一定规模,快速迭代开发的小项目就开始服务化得不偿失。

    然后后期肯定是要换做 RPC 框架的,这得问你们架构师最开始什么想法。。。
    binux
        14
    binux  
       2015-12-22 23:54:42 +08:00
    aws 各种服务就是这样的, 逐层封装就好了, 有什么不合理的?
    raysmond
        15
    raysmond  
       2015-12-22 23:59:48 +08:00
    做成微服务的方式吧,用 REST 接口
    twor2
        16
    twor2  
       2015-12-23 00:11:41 +08:00
    大一点的系统,应该是面向维护和稳定的,而不应该是面向开发的
    latyas
        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 ? 因为描述场景速度快。
    msg7086
        18
    msg7086  
       2015-12-23 02:55:57 +08:00
    microservices 结构很好啊。写好测试规范好 API ,以后要扩展起来就是神一样的。
    单机可以扔进 docker/虚拟机,以后业务上来了,放进 LAN 里跑,再以后可以上集群。
    inisun
        19
    inisun  
       2015-12-23 03:31:06 +08:00
    最近就做了个 webservice
    minsheng
        20
    minsheng  
       2015-12-23 07:34:17 +08:00 via iPhone
    这个场景蛮适合 Haskell 的 Servant ,用类型系统保证 API 的正确性,也能根据 API 的类型自动输出其它语言的绑定。推荐看看,挺好玩的。
    jasontse
        21
    jasontse  
       2015-12-23 07:45:39 +08:00 via Android
    代价太大了吧
    jtacm
        22
    jtacm  
       2015-12-23 08:58:16 +08:00
    这个和 Python 有什么关系?
    kanezeng
        23
    kanezeng  
       2015-12-23 09:06:13 +08:00
    看情况啦,不过一般放公网的系统哪怕再小最好这样,不用暴露数据库本机不是。数据库服务器的防火墙只需要给那个提供数据服务 api 的机器留个口就行。如果客户端程序访问数据库,那就要求数据库服务器暴露给所有的客户端啊。

    另外,方便扩展,方便前后端分离,方便支持更多平台也都是很好地结果啊。
    bk201
        24
    bk201  
       2015-12-23 09:24:09 +08:00
    你当你在写个人程序呢,反正 java 基本都是这样写程序的。
    strahe
        25
    strahe  
       2015-12-23 09:30:33 +08:00
    我们公司也这样的,都是各写各的代码,最后接口文档给出来就好了
    lovedboy
        26
    lovedboy  
       2015-12-23 09:46:52 +08:00
    合理。
    izoabr
        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 压力会比较大,所以让它能支持横向扩展才行,不过会有一个数据库锁的问题,如果碰上了锁,性能就不好办了,所以后端数据库优化要根据业务具体情况来做。
    izoabr
        28
    izoabr  
       2015-12-23 09:57:41 +08:00
    上面这个方式,还有一个好处就是可以在 MQ 和 WORKER 这两个地方加插件,比如做统计分析、安全检查、数据拦截之类的。
    azhao
        29
    azhao  
       2015-12-23 11:20:34 +08:00
    这是微服务的架构,架构是合理的
    但是划分是不合理的,因为数据库本身就是一个服务了,如果确实要保护数据全安,就应该拆表物理分离区分保护
    好好的一个解耦变成了强合耦
    sunchen
        30
    sunchen  
       2015-12-23 12:30:55 +08:00
    看项目规模
    billwang
        31
    billwang  
       2015-12-23 13:03:21 +08:00
    如果为了安全这么做的话也无可厚非
    hqlf6rqieee3
        32
    hqlf6rqieee3  
       2015-12-23 13:14:47 +08:00
    你需要 django 和 django-rest-framework
    johnsneakers
        33
    johnsneakers  
       2015-12-23 16:18:37 +08:00
    骚年, 你就快悟到了 microservice 的真谛。 可以搜索关键词看看。 (PS:我司目前在用这样的架构,很爽)
    libook
        34
    libook  
       2015-12-23 17:51:34 +08:00
    项目达到一定规模需要解决一些问题,对于一些问题,有一种很好的思路就是分层,我猜你这种设计就是分层的设计,这种架构设计广泛存在于 Java WEB 项目中,底层模块用于操作数据库,其逻辑对表层透明,底层与表层之间约定接口,这样每一层的每个模块功能相对单一,开发起来非常方便,在业务复杂度到一定程度确实能大大减少代码的重复以及大大降低逻辑复杂度。不过还要看用于何种场合和如何设计。通常是一个小团队维护一层,层与层之间的接口要有规范的版本管理。如果你觉得你们公司使用这种架构并没有达到上述优点反而变成了累赘的话还不如换架构。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2724 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 12:38 · PVG 20:38 · LAX 05:38 · JFK 08:38
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.