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

[shuizhengqi]

现在在做的项目，是一个 django 工程下面建了多个 app，然后整体做成了 restful api 的风格对外提供服务，但是今天老大说这样不行，想把模块分开，一个模块布在一个机器上，做成微服务的样子。我个人的理解是多个 app 也能达到这种效果，可以在不同的机器上启动相同的项目，然后到时候根据 url 不同，访问的机器不同就行了。不知道大家都是怎么做这种微服务的

谢谢各位的分享，我现在是用的 rest framework，所以不涉及 web 的部分，决定还是继续在一个工程里面建不同的 app 来进行开发了。

[wellsc]

import django as flask

[wellsc]

错了，应该是 import flask as django

[shuizhengqi]

@wellsc。。import java as django

[tabris17]

你非要用铲子来拧螺丝理论上也是可以的

[owenliang]

就是拆分服务 这叫不了微

[ArthurMarcel]

这是业务拆分，微服务的架构和这个不一样啊..

[wdlth]

一个模块布在一个机器上，你们老大是想表达服务器多，随便用么？

[takanasi]

真羡慕你们服务器多的人。

[p2pCoder]

微服务 你首先 要有个 服务 注册与 发现中心

[workwonder]

你这还是一个大单体项目，然后只暴露其中一个模块部署多份，感觉有点掩耳盗铃啊。

[alexsunxl]

这叫业务拆分 不叫微服务，复制 wiki 的你先看看概念

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

但这些是误解，实际上：

由于服务是独立自主的（也称：真空性），除了需要能够有自己的一套执行方式外，还不应该仰赖另一个服务。为此，服务内会有着与其他服务相同的逻辑，这也导致了服务并不轻量。这部分有两派说法，分别是在服务之间建立同套资源库、工具，但这可能导致额外的相依性存在。而另一种说法则是传统地将程式码复制与贴上，这将避免相依性问题，但在全域修改时可能不易管控，需要分散管理。
微服务属于分布式系统的概念之一，程式码并不会因此变得简单、短少，反而有可能为了处理外来的事件而变得更多。
微服务需要额外处理事件的广播、甚至是分布式的错误回溯问题，这导致开发时可能会更加地复杂，且花上更多时间在处理错误上。
基于第一点误解，微服务为了自主有可能会跨域实作，如文章服务有可能会带有使用者服务的理念，所以在处理事情上并不会特别专一。

[qiu0130]

说说我们的做法，首先有一个 getaway 实现服务的发现和注册等基本功能，然后是利用 mq 通信，可以用 rpc 或者 http 方式，最后就是服务解耦，服务粒度最小化，这样部署和维护方便。

[Hstar]

我觉得正确做法是 django 的 web 服务尽量在一起, 通过各种手段比如负载均衡降低性能要求.
后续具体的操作比如 IO 可以用各种 mq 或者 rpc 来做, 这部分可以拆分的很细.
只有一个 django 项目很省事, 登录状态 /权限管理等等几乎不需要太多维护.
把一个完整的 django 项目拆开, 楼上有句话说的对, 掩耳盗铃, 还是说你们部门没什么事做了需要给自己找点事冲 KPI?

[linoder]

团队大了比如好几百人 拆分值得 就几个几十个的话 还是别给自己加工作量为好

[xpresslink]

你们老大估计也是半吊子，微服务是一套体系架构，开发部署运维模式都是要整体考虑的，这和传统模式非常不一样。
一般情况都是用 Docker 来跑微服务的，你再学习一下吧。

[chaleaochexist]

@alexsunxl 微服务这么麻烦,那优势是啥...

[alexsunxl]

@chaleaochexist
优势也是有很多的。 项目跨团队协作方便，代码发布更新粒度可以很小， 还有很多列举费劲，有兴趣自己找找资料吧

优劣都非常明显，适合大公司大团队大项目， 低于 5 个人的项目都没必要搞这个的。

[shuizhengqi]

@alexsunxl 这都两年前的问题了。。

[chaleaochexist]

@alexsunxl 谢谢

@shuizhengqi 我是放狗搜出来的. V2EX 权重很高. 至少我是这么认为.