什麼是微服務

banq發表於2013-12-26
微服務


假設一個ProductSpeed有兩個不同的構造器：

public class ProductSpeed {
  public ProductSpeed(String name) {
    ...
  }
 
  public ProductSpeed(String name, int order)) {
 
  }
}
<p class="indent">


第一個構造器是使用在不相關的產品的訂單中。

第二個構造器是我們關注的，因為我們在向使用者顯示這些產品時首先進行一下排序。

產生這兩個構造器的原因是：這個物件可能產生於兩個不同的系統，只是在一個系統中有排序要求存在，而另外一個沒有這個要求。

我們實際做的是一個物件兩個不同的版本，但是我們不能取名為：ProductSpeedForSystem1′ 和 ‘ProductSpeedForSystem2′!

在領域驅動設計DDD中，我們可以認為ProductSpeed是存在兩個不同有界上下文中(共享核心)，如果是在一個大型整塊系統中，它們是分別位於不同的包下面。

下面我們就要區分這兩個不同的上下文，進一步我們會發現以第二個建構函式建立的ProductSpeed物件其實和系統其他應用並沒有互動，只是為客戶端排序而存在，直接服務於客戶端，向外服務，而不是向內部元件提供互動(向內不能稱為"服務"了)，因此這個獨立的上下文可以成為一個微服務。

原來我們是透過一個整塊API提供所有功能，如下圖的Main API：

什麼是微服務

將上下文區分開以後，微服務可以從原來整塊上下文獨立出來了：

什麼是微服務

微服務定義：
每個應用程式都只做一件事
•足夠小，適合存在你的腦袋即可。
- “如果一個類大到我腦袋記不住就是實在太大“

•足夠小，你可以把它們扔掉
- 用重寫來維護

微服務類似Unix的服務：
1. 嵌入了Web容器(以往JavaEE都是服務執行在tomcat等Web容器中)
– 比如可以使用Jetty / SimpleMind
(案例：http://www.jdon.com/idea/javaee7/websocket-jetty.html)，這樣可以防止抽象洩漏，否則你會去閱讀Tomcat原始碼。

– 測試（測試甚至不重要）和易部署，脫離容器，直接是一個應用，無需那麼多Mock了。

2.打包成單個可執行的jar包
– 有自己獨立的配置
– 標準的unix rc.d 指令碼

3. 可以以類似Unix後臺啟動Httpd服務方式等啟動
– Unix的後臺守護 Daemons看樣子工作這麼多年很好，除非你有特殊需求，否則不要重複發明輪子。

4. 每個應用都是獨立分離的，符合領域驅動設計和Conways法則的有界上下文，使用物理的實現真正分離他們。

5.如果有共同的程式碼，將其成為一個底層設施的庫包。
–對待它們就像對待其他開源庫包專案一樣。
–可以將其提交到Maven中央倉庫，作為一個二進位制依賴包。

6. 能夠自給自足Provisioned。
許多小應用程式的複雜性管理之道是在於讓它們自我管理。比如ServiceA和ServiceB自己實現負載平衡和自動擴充套件，資料庫自己實現叢集。

7. 用看門狗來堅持應用的狀態，類似Scala的Actor模型，如果有失敗，自動重啟它們。每個應用都要向外暴露它們的執行情況，以便監視。

微服務原始定義見：http://2012.33degree.org/talk/show/67

相關文章