2015/07/20

microservices 其目標是將應用程式切割成多個單純的、小型的功能，每一個獨立的小功能都各自成為一個服務，每一個服務有自己的 process，各服務之間透過輕量的 protocol 互相溝通，並發佈到多個 server 上。

microservice 就像是在遵循著汽車工廠的進化歷史

在進行系統開發時，通常會先採用單一獨立的應用系統架構，也就是使用一個大型的應用程式伺服器(ex: weblogic)，並在上面部屬自己的大型應用程式。

但隨著應用程式組件的輕量化，應用程式部屬環境也慢慢地往輕量化位移，我們可以用比較小型的應用程式伺服器(ex: nodejs)，進行應用程式的開發。

由於應用程式的開發成本的降低，系統開發再慢慢地朝向多個伺服器同時運作的環境，也逐漸產生將系統切割成多個 microservice 開發後，再進行組裝的概念。

整個進化的過程就像是汽車工廠的演進一樣，一開始是由一個獨立的工廠開發設計並進行組裝，後來慢慢地出現零組件工廠，汽車工廠只需要整合多個衛星工廠，就可以組裝一台車輛。

這個過程當然也可能會出現一些特殊的工廠服務，例如只提供汽車設計的公司，只提供組裝代工的工廠，只提供螺絲、引擎或外殼的工廠等等。基本上這都是從最初的汽車工廠中，慢慢地進化而來的，其切割且獨立重點在於：

能夠獨立出來的服務，在其運作的過程中，也會慢慢更趨近於最佳化，變成一種專業的服務。

優點

Docker透過Container技術可以將任何小程式打包成可獨立執行的映像檔，發佈到任何可執行Docker的平臺上執行。開發者只要將應用程式所需的功能程式打包成Docker image file，部署到伺服器就能成為提供不同功能的微服務。

原本需要幾分鐘開機時間的 VM，到了 Docker 變成了幾秒，deployment 的速度成了 microservice 最有效率的部屬平台的原因。

業者更進一步開發了 Container OS，一種只保留OS核心和Docker所需執行環境，以及管理Docker叢集的工具的輕量化作業系統，這更能有效提昇 container 的整體性能。

對於 architect 來說，最麻煩的問題不在了解 microservices 的優點與概念，問題在於要如何正確且有效地切割應用程式。

一個好的開發者在開發獨立應用程式時，會嘗試將系統分成不同的模組，也就是模組化的系統設計，讓模組與模組之間的耦合度降低，以降低系統的複雜度。

切割模組對於應用程式來說，並不是一件難事，我們總能快速地將系統模組化，通常一個應用程式可識別出來的模組數量大概都是 5~10個。

但進入到 microservices 的概念之後，我們要識別的是更小型且能夠獨立運作的服務規模，這就像是在系統設計初期，就要有效地判斷出商業邏輯層中，哪些可以劃分為同一個物件類別，這是一件困難的工作。

每一個服務或零組件，都需要提供一個 API 界面讓其他服務存取，API 的設計可能會經歷多個版本的沿革，這等於同時造成了 API 使用者以及開發者的困擾。

對開發者來說，為了保持 API 的相容性，不讓使用舊版 API 的其他服務掛點，需要耗費精神同時維護多個版本的 API，並等待其他服務都順利轉移至新版 API 之後，才能將舊版的 API 關閉。

對使用者來說，由於 API 的不穩定，相對就造成一些使用上的問題，比較簡單一點的更新，可能就是增加了參數或是新的 API，比較麻煩的，可能是整個 API 的商業邏輯變動，這可能會造成牽一髮動全身的疑慮。

如果說要讓 API 在「設計好了」的時候，再釋放給其他服務使用，這就等於消滅了 microservice 的初衷，可「快速」開發小型的服務的能力，我們什麼時候才能確認 API 是「好的」？