混合微服務 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