什麼是微服務架構？
微服務架構是一種可將應用程式拆解成細項服務的技術，各項服務則執行某些具體的業務功能，從而為現代開發人員提供極易擴充且靈活的應用程式設計方法。這些服務通常為「鬆散耦合」，可以日後獨立進行建置、部署和擴充。
每個服務都是通過標準化的應用程式介面 (API)與其他服務溝通，因此這些服務能夠以不同的語言或技術編寫，這與建置成單體結構的系統完全不同，單體結構中的各項服務不可分割、相互連結、只能一起調整。
由於每項服務的功能有限，因此其規模和複雜度要小很多。微服務這個術語源自於這種分離功能設計，與實體大小無關。
為何使用微服務架構？
微服務架構越來越受歡迎，因為它的模組化特質帶來了靈活性、擴充性，並可減少開發工作。此種架構的部署靈活性，加上雲端原生無伺服器以及功能即服務部署選項（例如 AWS Lambda 和 Microsoft Azure Cloud Functions）的興起，在當今的 IT 環境中為微服務締造了美好的發展環境。這些雲端平台能夠讓微服務和功能從不活動狀態輕鬆擴展到極大量並重新恢復原狀，而客戶只需為他們使用的運算容量付費。
隨著企業不斷尋求更加敏捷、減少瓶頸、縮短應用程式遞送時間，微服務架構越來越受歡迎。
微服務架構的好處
- 可用不同的編程語言來建立應用程式組件
- 可以維持個別的後續開發和部署流程
- 可以建立極易擴充的應用程式
- 可以使用雲端原生的功能即服務部署選項
- 降低通常需付出的營運成本
- 服務可以隔離和鬆散耦合，能夠分區進行升級與增強
微服務架構使用案例
- 採用雲端原生部署選項：利用無伺服器和功能即服務，使營運更高效且易擴充。
- 遷移舊應用程式的既有功能：從大型單體應用程式中分解出細項服務，以便它們可以獨立維護和擴充。
- 善用現代應用程式架構：採用事件導向、鬆散耦合的微服務應用程式型樣，能夠根據使用案例需求來使用不同的程式設計語言。例如，針對運算量大的功能使用圍碁程式，並針對快速的 Web 應用程式使用 Node.js 等。
DevOps 是什麼？為何微服務經常提到它？
DevOps 可以解釋為一種以工具為中心的觀念，工具/技術在本質上是為了簡化開發人員所需完成的工作。除了改進工具之外，它也有助於營運和開發團隊之間彼此合作，以更快、更高效地完成專案。
例如，假設您正要建立一個允許使用者查詢其帳戶餘額的應用程式，在過去的應用程式開發週期中，這通常需要開發人員先建立應用程式，再將其交給營運團隊，但無需對最終結果負責，因為營運團隊的工作就是讓它能夠順利運作。但在互動更緊密的 DevOps 環境中，雙方需要共同合作，這表示開發人員將從開始到結束，全程負責應用程式的生命週期，例如他們在發行期間也必須隨時待命。雙方團隊需要持續溝通，確保一切順利，然後您就可以享受到 DevOps 的好處（上市速度加快、開發週期更輕鬆、人員更加負責等）。
新的 DevOps 工作模式會帶來重大文化轉變，單靠使用新工具並無法讓 DevOps 計畫成功。如果您單純堅信新工具自動會使一切運行妥當，則很可能會影響成果。
基於微服務的特性，部署過程通常需要強大的 DevOps 程序支援，而增加工具使用和增強共享實務，有助於減少各項任務被任何細小、變動的內容所影響。您除了可以降低這種轉變的打擊或負荷，還能繼續享有微服務的諸多好處。
展望未來：事件驅動的微服務、無伺服器運算、功能即服務（FaaS）
當人們首次開始嘗試微服務時，他們通常預設使用熟悉的技術，例如RESTful API，但 REST 的運作方式為請求-回應通訊類型，這種同步方法的問題在於，各項服務變得相互依賴，而您必須等待回應。如果某項服務運行緩慢或沒有回應，就表示呼叫它的服務也會運行緩慢或失敗。這種耦合方式可能失去某些微服務架構的效益，因為它建立的結構使相互依存性提高，類似於服務導向架構 (SOA) 風格。
如果您使用事件驅動模型來設計服務，則可以確保某些部分的應用程式繼續運作。其他部分可能不受影響，而不是整個應用程式都變得沒反應。以 Netflix 為例，您有時可能會發現「繼續觀看」按鈕消失了。這是因為某項特定服務變得不可用，但不表示整個 Netflix 停止，使用者仍然可以瀏覽節目和觀看預告。因此，即使 Netflix 可能不提供某一項服務，但其他服務還是可用的。
完全接受微服務方法的開發人員會意識到，真正的擴充性來自於鬆散耦合和事件導向架構。一項服務可以不與其他服務同步，它可以做某個動作、播送一條訊息，然後繼續執行原來的主要功能，而不必等待另一個服務的回應。