首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐学习书目
Learn Python the Hard Way
Python 学习手册
Python Cookbook
Python 基础教程
Python Sites
PyPI - Python Package Index
http://www.simple-is-better.com/
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
V2EX  ›  Python

来说说你们是怎么用 django 做微服务 的

  •  1
     
  •   shuizhengqi · 2017-11-21 15:20:29 +08:00 · 7837 次点击
    这是一个创建于 720 天前的主题,其中的信息可能已经有所发展或是发生改变。
    现在在做的项目,是一个 django 工程下面建了多个 app,然后整体做成了 restful api 的风格对外提供服务,但是今天老大说这样不行,想把模块分开,一个模块布在一个机器上,做成微服务的样子。我个人的理解是多个 app 也能达到这种效果,可以在不同的机器上启动相同的项目,然后到时候根据 url 不同,访问的机器不同就行了。不知道大家都是怎么做这种微服务的
    第 1 条附言  ·  2017-11-22 09:19:55 +08:00
    谢谢各位的分享,我现在是用的 rest framework,所以不涉及 web 的部分,决定还是继续在一个工程里面建不同的 app 来进行开发了。
    19 回复  |  直到 2019-10-08 21:25:40 +08:00
        1
    wellsc   2017-11-21 15:28:03 +08:00
    import django as flask
        2
    wellsc   2017-11-21 15:31:20 +08:00   ♥ 1
    错了,应该是 import flask as django
        3
    shuizhengqi   2017-11-21 15:37:57 +08:00
    @wellsc。。import java as django
        4
    tabris17   2017-11-21 15:39:13 +08:00   ♥ 1
    你非要用铲子来拧螺丝理论上也是可以的
        5
    owenliang   2017-11-21 16:29:24 +08:00 via Android
    就是拆分服务 这叫不了微
        6
    ArthurMarcel   2017-11-21 21:18:04 +08:00
    这是业务拆分,微服务的架构和这个不一样啊..
        7
    wdlth   2017-11-21 21:28:59 +08:00
    一个模块布在一个机器上,你们老大是想表达服务器多,随便用么?
        8
    takanasi   2017-11-21 21:30:36 +08:00
    真羡慕你们服务器多的人。
        9
    p2pCoder   2017-11-21 21:31:57 +08:00
    微服务 你首先 要有个 服务 注册与 发现中心
        10
    workwonder   2017-11-21 22:38:35 +08:00 via Android
    你这还是一个大单体项目,然后只暴露其中一个模块部署多份,感觉有点掩耳盗铃啊。
        11
    alexsunxl   2017-11-21 22:51:42 +08:00   ♥ 1
    这叫业务拆分 不叫微服务,复制 wiki 的你先看看概念

    微服务这个名词令许多人以为是非常轻量、非常微小的,且以为透过该理念实作程式就能够达到下列效果:
    微服务很轻量。
    程式码将会变得更加地简洁。
    变得更简单、开发时程变短。
    微服务处理的事情变得更单一。

    但这些是误解,实际上:

    由于服务是独立自主的(也称:真空性),除了需要能够有自己的一套执行方式外,还不应该仰赖另一个服务。为此,服务内会有着与其他服务相同的逻辑,这也导致了服务并不轻量。这部分有两派说法,分别是在服务之间建立同套资源库、工具,但这可能导致额外的相依性存在。而另一种说法则是传统地将程式码复制与贴上,这将避免相依性问题,但在全域修改时可能不易管控,需要分散管理。
    微服务属于分布式系统的概念之一,程式码并不会因此变得简单、短少,反而有可能为了处理外来的事件而变得更多。
    微服务需要额外处理事件的广播、甚至是分布式的错误回溯问题,这导致开发时可能会更加地复杂,且花上更多时间在处理错误上。
    基于第一点误解,微服务为了自主有可能会跨域实作,如文章服务有可能会带有使用者服务的理念,所以在处理事情上并不会特别专一。
        12
    qiu0130   2017-11-21 22:57:39 +08:00 via Android
    说说我们的做法,首先有一个 getaway 实现服务的发现和注册等基本功能,然后是利用 mq 通信,可以用 rpc 或者 http 方式,最后就是服务解耦,服务粒度最小化,这样部署和维护方便。
        13
    Hstar   2017-11-21 23:23:04 +08:00
    我觉得正确做法是 django 的 web 服务尽量在一起, 通过各种手段比如负载均衡降低性能要求.
    后续具体的操作比如 IO 可以用各种 mq 或者 rpc 来做, 这部分可以拆分的很细.
    只有一个 django 项目很省事, 登录状态 /权限管理等等几乎不需要太多维护.
    把一个完整的 django 项目拆开, 楼上有句话说的对, 掩耳盗铃, 还是说你们部门没什么事做了需要给自己找点事冲 KPI?
        14
    linoder   2017-11-21 23:27:30 +08:00
    团队大了比如好几百人 拆分值得 就几个几十个的话 还是别给自己加工作量为好
        15
    xpresslink   2017-11-22 10:45:15 +08:00
    你们老大估计也是半吊子,微服务是一套体系架构,开发部署运维模式都是要整体考虑的,这和传统模式非常不一样。
    一般情况都是用 Docker 来跑微服务的,你再学习一下吧。
        16
    chaleaochexist   34 天前
    @alexsunxl 微服务这么麻烦,那优势是啥...
        17
    alexsunxl   34 天前   ♥ 1
    @chaleaochexist
    优势也是有很多的。 项目跨团队协作方便,代码发布更新粒度可以很小, 还有很多列举费劲,有兴趣自己找找资料吧

    优劣都非常明显,适合大公司大团队大项目, 低于 5 个人的项目都没必要搞这个的。
        18
    shuizhengqi   34 天前
    @alexsunxl 这都两年前的问题了。。
        19
    chaleaochexist   34 天前
    @alexsunxl 谢谢

    @shuizhengqi 我是放狗搜出来的. V2EX 权重很高. 至少我是这么认为.
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   953 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 68ms · UTC 19:34 · PVG 03:34 · LAX 11:34 · JFK 14:34
    ♥ Do have faith in what you're doing.