混合微服务 vs Django

在设计所谓的"Next-Generation CMS"，即Echoes CMS的时候，对于我这种懒得本身写Django App的人来讲，经过我会去复制别人的代码，因而我继续在Github上漫游。接着找到了DjangoProject.com的源码，又看了看Mezzanine(ps: 我博客用的就是这个CMS)。因而从DjangoProject复制了Blog的代码，从Mezzanine复制了conf的代码，而后就有了Echoes的codebase。而后，继以前的文章(《微服务的小思考》我想了想， 这不就是我想要的模型么?

微服务与Django

Django 应用架构

Django MVC结构以下如示:

而后，记住这张图，忘记上面的MVC，Django其实是一个MTV

• Model
• Template
• View

主要是Django中的views.py一般是在作Controller的事。

然而对于一个Django的应用来讲，他的架构以下所示:

Django的每一个App就表明着程序的一个功能。每一个App有本身的models、views、urls、templates因此对于一个app来讲他的结构以下:

.
|______init__.py
|____models.py
|____tests.py
|____views.py

若是是新版的Django那么它的结构以下:

.
|______init__.py
|____admin.py
|____migrations
| |______init__.py
|____models.py
|____tests.py
|____views.py

上面少了templates，最后会有一个总的URL，即第一张图的URL Dispatcher。接着，让咱们看看微服务是怎样的。

微服务

一个典型的微服务以下所示:

有不一样的技术栈python、spring、scala，可是他们看上去和Django应用的图差很少，除了数据库不同。

混合微服务

与其将复杂的测试、逻辑部分变得不可测，不如把这些部分放置于系统内部。

当咱们在咱们的服务器上部署微服务的时候，也就意味着实现因此的服务都是在咱们系统的内部，咱们有一个Kernel以及他们的Kernel Moduels，即微服务群们。他们调用DB，或者某些第三方服务。

System Libraries至关于咱们的URL Dispatcher。而咱们的URL Dispatcher实际上所作的即是将各自调用的服务指向各自的app。

这样咱们便可以解决部署的问题，又能够减小内部耦合。

其余

我猜，微服务的流行是由于程序员能够欢乐地使用本身的语言，哪怕是Logo。

Follow my projects on GitHub

QQ交流群: 321689806

微博: @phodal