一分鐘了解微服務的好處和陷阱

微服務架構設計代表了一種架構設計思想，配合現在的容器技術（如 Docker），可在軟體開發流程、部署、服務維護等各方面産生效率提升。

但不一定所有的業務場景都适合微服務，有時候非常簡單的業務場景下，微服務反而會降低效率。什麼是微服務，其特性，好處及陷阱，是本文要讨論的内容。

一、什麼是微服務

微服務是一種軟體架構風格，它是以專注于單一責任與功能的小型功能區塊為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關的 API（例如 REST）集互相通訊，且每個服務可以被單獨部署，它具備以下三個核心特點：

微服務為大型系統而生。随着業務的快速增長，會帶來系統流量壓力和複雜度的上升，系統的可維護性和可擴充性成為架構設計的主要考慮因素，微服務架構設計理念通過小而美的業務拆分，通過分而自治來實作複雜系統的優雅設計實作。

微服務架構是面向結果的。 微服務架構設計風格的産生并非是出于學術或為标準而标準的設計，而是在軟體架構設計領域不斷演進過程中，面對實際工業界所遇到問題，而出現的面向解決實際問題的架構設計風格。

專注于服務的可替代性來設計。 微服務架構設計風格核心要解決的問題之一便是如何便利地在大型系統中進行系統元件的維護和替換，且不影響整體系統穩定性。

二、微服務的特征

每個微服務僅對單個業務負責，且為該業務的容量負責；

每個微服務可以進行獨立部署，即不需要依賴其它微服務及其相關資源，如資料庫、記憶體緩存系統等；

輕量級的通信協定，例如REST、STOMP、AMQP等；

服務的可替代性，代表着每個微服務原則上都可以使用不同的語言、架構進行技術實作，且更換實作後的微服務對于整個業務系統不會造成影響；

每個微服務擁有單獨的資料存儲；

每個微服務由小團隊維護，服務以業務來進行拆分後，每個微服務的維護工作将有人數不多的小團隊進行維護；

三、微服務帶來的好處

獨立的可擴充性，每個微服務都可以獨立進行橫向或縱向擴充，根據業務實際增長情況來進行快速擴充；

獨立的可更新性，每個微服務都可以獨立進行服務更新、更新，不用依賴于其它服務，結合持續內建工具可以進行持續釋出，開發人員就可以獨立快速完成服務更新釋出流程；

易維護性，每個微服務的代碼均隻專注于完成該單個業務範疇的事情，是以微服務項目代碼數量将減少至IDE可以快速加載的大小，這樣可以提高了代碼的可讀性，進而可以提高研發人員的生産效率；

語言無關性，研發人員可以選用自己最為熟悉的語言和架構來完成他們的微服務項目（當然，一般根據每個公司的實際技術棧需要來了），這樣在面對新技術或新架構的選用時，微服務能夠更好地進行快速響應；

故障和資源的隔離性，在系統中出現不好的資源操作行為時，例如記憶體洩露、資料庫連接配接未關閉等情況，将僅僅隻會影響單個微服務；

優化跨團隊溝通，如果要完全實踐微服務架構設計風格，研發團隊勢必會按照新的原則來進行劃分，由之前的按照技能、職能劃分的方式變為按照業務（單個微服務）來進行劃分，如此這般團隊裡将有各個方向技能的研發人員，溝通效率上來說要優于之前按照技能進行劃分的組織架構；

原生基于“雲”的系統架構設計，基于微服務架構設計風格，我們能建構出來原生對于“雲”具備超高友好度的系統，與常用容器工具如Docker能夠很友善地結合，建構持續釋出系統與IaaS、PaaS平台對接，使其能夠友善的部署于各類“雲”上，如公用雲、私有雲以及混合雲。

四、避免微服務的陷阱

不要以微服務作為開始，在項目剛開始時，一般都還很小，不需要進行非常完整的業務拆分，如果采用“微服務”作為開始會有點殺雞用牛刀的感覺，當然，你的項目非常之龐大的話，以“微服務”為始是個不錯的選擇；

不要自己進行基礎設施的管理，微服務意味着一堆的資料庫、消息系統、資料緩存系統等，會帶來相應的運維管理成本（這裡的前提是，沒有良好的自動化運維平台和工具），建議多使用IaaS、PaaS平台，部署釋出與其對接；

無DevOps、不微服務，如果研發團隊不具備DevOps的理念并貫徹執行，僅想單獨來實施微服務的話，在實施過程中會發現比之前的架構維護要困難些，主要原因是微服務需要持續內建、持續部署及監控等工具或系統的配合才能降低其帶來的維護成本；

不要建立過多的微服務，微服務的業務顆粒度一定要根據實際業務系統的現狀及日後規劃來制定，切記不要制定過細的拆分顆粒度；

可能帶來的延遲問題，由于服務拆分開來，部署到不同的平台或網絡，可能會引起微服務間的調用延遲問題，服務間的調用延遲可能帶來整體系統的響應緩慢問題；

微服務不是銀彈。