之前轉載過一篇對 Martin Fowler 大師寫的微服務架構的說明文章：《微服務（Microservices）》。今天再轉載一篇對於這個架構的優缺點進行總結的文章。
轉載自：《微服務，讓開發過程更簡單還是更復雜？》、《有關微服務架構的爭論：更簡單還是更復雜？》。
隨著DevOps、持續交付等理念的深入人心，微服務架構開始走進我們的視野。
那麼微服務是業界期待已久的解決方案麼？或者說微服務要比整體解決方案更加簡單？
讓我們先對微服務下個定義：
微服務是用一組小服務的方式來構建一個應用，服務獨立執行在不同的程式中，服務之間通過輕量的通訊機制（如RESTful介面）來互動，並且服務可以通過自動化部署方式獨立部署。正因為微服務架構中，服務之間是相互獨立的，所以不同的服務可以使用不同的語言來開發，或者根據業務的需求使用不同型別的資料庫。
來自ThoughtWorks的James Lewis和Martin Fowler分享了他們對微服務架構的理解以及看法。文章中作者詳細介紹了微服務的特點以及相對於傳統架構的微服務架構的優勢。
微服務的一些優勢是顯而易見的：
- 服務簡單，只關注一個業務功能
在James看來，傳統的整體風格的架構在構建部署和擴充套件伸縮方面有很大的侷限性，其服務端應用就像是一塊鐵板，笨重且不可拆分，系統中任何程式的改變都需要整個應用重新構建和部署新版本。在進行水平擴充套件時也只能整個系統擴充套件，而不能針對某一個功能模組進行擴充套件。
而微服務架構將系統以元件化的方式分解為多個服務，服務之間相對獨立且鬆耦合，單一功能的改變只需要重新構建部署相應的服務即可。 - 每個微服務可由不同團隊開發
傳統的開發模式在分工時往往以技術為單位，比如UI團隊、服務端團隊和資料庫團隊，這樣的分工可能會導致任何功能上的改變都需要跨團隊溝通和協調。而微服務則倡導圍繞服務來分工，不同的服務可以採用不同的技術來實現，一個團隊中應該包含開發所需的所有技能，比如使用者體驗、資料庫、專案管理。 - 微服務是鬆散耦合的
微服務架構拋棄了ESB複雜的業務規則編排、訊息路由等功能，微服務架構中服務是高內聚的，每個服務都會處理相應的業務，所有的業務邏輯應該儘量在服務內部處理，且服務間的通訊儘可能的輕量化，比如使用Restful的方式。 - 可用不同的程式語言與工具開發
傳統的軟體開發中經常會使用同一個技術平臺來解決所有的問題，而經驗表明使用合適的工具做合適的事情會讓開發變得事半功倍。微服務架構天生就具有這樣的特性，我們可以使用Node.js來開發一個簡單的報表頁面，使用C++來編寫一個實時聊天元件。
微服務架構的引入為多樣化持久儲存資料提供可能，持久層可以使用傳統關聯式資料庫和NoSQL。不同於傳統的應用，微服務架構中，我們可以為每個服務選擇一個新的適合業務邏輯的資料庫系統，比如MongoDB、PostgreSQL。這樣做的好處是顯而易見的，首先我們可以根據業務型別（讀多還是寫多等）來決定使用哪種型別的資料庫，其次這樣可以減小單個資料庫的負載。
James的文章在社群引起了廣泛的討論，Contino公司的CTO Benjamin Wootton撰文表示微服務並沒有想象中的那麼好，並建議開發者在選用此架構時一定要慎重。Benjamin認為微服務架構時可能會面臨下面一些挑戰：
- 運維開銷
更多的服務也就意味著更多的運維，產品團隊需要保證所有的相關服務都有完善的監控等基礎設施，傳統的架構開發者只需要保證一個應用正常執行，而現在卻需要保證幾十甚至上百道工序高效運轉，這是一個艱鉅的任務。 - DevOps要求
使用微服務架構後，開發團隊需要保證一個Tomcat叢集可用，保證一個資料庫可用，這就意味著團隊需要高品質的DevOps和自動化技術。而現在，這樣的全棧式人才很少。 - 隱式介面
服務和服務之間通過介面來“聯絡”，當某一個服務更改介面格式時，可能涉及到此介面的所有服務都需要做調整。 - 重複勞動
在很多服務中可能都會使用到同一個功能，而這一功能點沒有足夠大到提供一個服務的程度，這個時候可能不同的服務團隊都會單獨開發這一功能，重複的業務邏輯，這違背了良好的軟體工程中的很多原則。 - 分散式系統的複雜性
微服務通過REST API或訊息來將不同的服務聯絡起來，這在之前可能只是一個簡單的遠端過程呼叫。分散式系統也就意味著開發者需要考慮網路延遲、容錯、訊息序列化、不可靠的網路、非同步、版本控制、負載等，而面對如此多的微服務都需要分散式時，整個產品需要有一整套完整的機制來保證各個服務可以正常運轉。 - 事務、非同步、測試面臨挑戰
跨程式之間的事務、大量的非同步處理、多個微服務之間的整體測試都需要有一整套的解決方案，而現在看起來，這些技術並沒有成熟。
總而言之，微服務架構有很多吸引人的地方，不過在擁抱微服務之前要認清它所帶來的挑戰。而每一種架構都有其優缺點，我們需要根據專案業務和團隊情況來選擇合適的架構。