混合微服務 vs Django

Phodal發表於2015-05-25
微服務Django

在設計所謂的"Next-Generation CMS"，即Echoes CMS的時候，對於我這種懶得自己寫Django App的人來說，通過我會去複製別人的程式碼，於是我繼續在Github上漫遊。接著找到了DjangoProject.com的原始碼，又看了看Mezzanine(ps: 我部落格用的就是這個CMS)。於是從DjangoProject複製了Blog的程式碼，從Mezzanine複製了conf的程式碼，然後就有了Echoes的codebase。然後，繼之前的文章(《微服務的小思考》我想了想， 這不就是我想要的模型麼?

微服務與Django

Django 應用架構

Django MVC結構如下如示:

Django MVC

然後，記住這張圖，忘記上面的MVC，Django實際上是一個MTV

  • Model
  • Template
  • View

主要是Django中的views.py通常是在做Controller的事。

然而對於一個Django的應用來說，他的架構如下所示:

Django apps architecture

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。接著，讓我們看看微服務是怎樣的。

微服務

一個典型的微服務如下所示:

microservices architecture

有不同的技術棧python、spring、scala，但是他們看上去和Django應用的圖差不多，除了資料庫不一樣。

混合微服務

與其將複雜的測試、邏輯部分變得不可測，不如把這些部分放置於系統內部。

Linux OS Hybrid

當我們在我們的伺服器上部署微服務的時候，也就意味著實現所以的服務都是在我們系統的內部，我們有一個Kernel以及他們的Kernel Moduels，即微服務群們。他們呼叫DB，或者某些第三方服務。

System Libraries相當於我們的URL Dispatcher。而我們的URL Dispatcher實際上所做的便是將各自呼叫的服務指向各自的app。

這樣我們即可以解決部署的問題，又可以減少內部耦合。

其他

我猜，微服務的流行是因為程式設計師可以歡樂地使用自己的語言，哪怕是Logo。

Follow my projects on GitHub

QQ交流群: 321689806

微博: @phodal

相關文章