microservices 其目標是將應用程式切割成多個單純的、小型的功能，每一個獨立的小功能都各自成為一個服務，每一個服務有自己的 process，各服務之間透過輕量的 protocol 互相溝通，並發佈到多個 server 上。
microservice 就像是在遵循著汽車工廠的進化歷史
在進行系統開發時，通常會先採用單一獨立的應用系統架構，也就是使用一個大型的應用程式伺服器(ex: weblogic)，並在上面部屬自己的大型應用程式。
但隨著應用程式組件的輕量化，應用程式部屬環境也慢慢地往輕量化位移，我們可以用比較小型的應用程式伺服器(ex: nodejs)，進行應用程式的開發。
由於應用程式的開發成本的降低，系統開發再慢慢地朝向多個伺服器同時運作的環境，也逐漸產生將系統切割成多個 microservice 開發後，再進行組裝的概念。
整個進化的過程就像是汽車工廠的演進一樣，一開始是由一個獨立的工廠開發設計並進行組裝，後來慢慢地出現零組件工廠，汽車工廠只需要整合多個衛星工廠，就可以組裝一台車輛。
這個過程當然也可能會出現一些特殊的工廠服務，例如只提供汽車設計的公司，只提供組裝代工的工廠，只提供螺絲、引擎或外殼的工廠等等。基本上這都是從最初的汽車工廠中，慢慢地進化而來的，其切割且獨立重點在於：
- 該服務是否可獨立運作
- 該服務是否有獨立獲利的能力
能夠獨立出來的服務，在其運作的過程中，也會慢慢更趨近於最佳化，變成一種專業的服務。
優點
每個 microservice 只提供一個小型並獨立的功能，程式開發時因耦合度較低，可以專注在該功能的實作上。
各 microservice 經由不同的組合，可組成不同的應用程式
每一個 microservice 可由不同的開發單位進行開發
microservice 因功能獨立且單純，開發人員較容易維護與修改程式
microservice 僅包含 business logic code，沒有 user interface components
當服務規模擴大時，系統很容易擴展
microservice 可運作於中低效能的 server 上
缺點
多個獨立 process 代表需要更高超的 DevOps 管理技術
分佈式系統的管理會很複雜
軟體出錯時，需要多個單位協同處理，較耗時間
RPC 呼叫需要花費時間
Docker 簡化了 service deployment
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 的商業邏輯變動，這可能會造成牽一髮動全身的疑慮。
如果說要讓 API 在「設計好了」的時候，再釋放給其他服務使用，這就等於消滅了 microservice 的初衷，可「快速」開發小型的服務的能力，我們什麼時候才能確認 API 是「好的」？
沒有留言:
張貼留言