現在大型網路服務的架構都使用微服務架構設計，是什麼讓微服務架構這麼流行？什麼是微服務？

什麼是微服務

微服務(Microservice)是一種分散式系統的做法。傳統的單體式服務(Monolithic)中，通常使用程式模組化的方式將功能進行區隔，但隨著系統增長、功能增加的情況下，會變得越來越難以維護、修復。微服務將單體式系統拆分為多個較小的服務各司其職，讓各服務聚焦在自身的功能上，彼此間藉由通訊協定(最常使用的是HTTP協定)傳遞訊息以達成整體系統的串接。在Docker快速席捲IT界後，藉由將服務封裝在容器中，微服務更容易被部署到並擴展不同的主機上。

微服務的好處

微服務有以下好處：

• 技術異質性：在拆分成多個單一小模組的情況下，各模組團隊可選擇各自適合或習慣的程式語言和相關工具，而不必整間公司只使用單一技術。某個模組需要特別提升效能時，可選擇對平行加速較擅長的Golang。對圖學計算或社群網路時，可選擇圖資料庫(Graph DB)來優化。
• 彈性：傳統單體式架構運行的系統如果服務失敗，整個系統會無法運作。微服務架構中的單一服務失敗時，其他服務仍可正常運作，可避免全面性的失敗。
• 水平擴展：單體式架構擴展時，會因系統過於龐大，消耗過多的系統資源而難以擴展。微服務可以只擴展需要擴展的幾個服務，依照需求控制每個服務的副本數。
• 容易部署：單體式架構變更程式碼時，整個系統都必須重新測試，並重新部署，運行失敗時，可能需要大量的還原才能恢復舊版本的運行。微服務可針對單一服務進行升級，若運行中出問題可將其直接換回舊版本而不影響其他系統的運作。

微服務的不足

微服務架構並非萬靈丹，在享有微服務很多方便的特性時，整個團隊需要付出更多的努力使這些服務穩定運行。

首先最重要的是測試。微服務的測試變得更加複雜，在測試一項功能時往往會和多個服務溝通運作，整合測試時需要啟動相關的服務才能進行測試，撰寫測試程式時也需要進行端對端(End-to-End)測試(至少有Stub服務)。

其次是監控。單體式架構在服務運行失敗時問題相對單純，可能重新啟動運行失敗的服務即可正常運作。微服務架構當服務個數增加並運行在多台主機上時，更需要有良好的監控方式來確保所有服務都正常運作。

資料庫的分散式交易也是一個極大的難題。單體式架構在處理資料庫交易時通常只有一個資料庫需要處理。當每個微服務各自擁有各自的資料庫但又需要確保每個服務寫入資料庫的資料都正確時就需要面對極為複雜的分散式交易。

總結

微服務架構帶給了研發團隊諸多的便利性，但若團隊技術水平、溝通協調並未跟進，很可能會造成很多維運上的災難。要維持微服務良好的運作，各微服務團隊需要付出更多的心力在人與人的溝通和服務與服務的溝通。在容器架構的興起後，微服務更成為目前銳不可當趨勢。

圖片來源：

http://dockerone.com/uploads/article/20150524/89d9bfed11ff35943269b24b23b866b1.png

http://dockerone.com/uploads/article/20150524/858f9ae6c861c8c93cd5379be54f9fc1.png

作者:德鴻科技 研發部 Tony