微服務架構設計代表了一種架構設計思想，配合現在的容器技術（如 Docker），可在軟件開發流程、部署、服務維護等各方面產生效率提升。
但不一定所有的業務場景都適合微服務，有時候非常簡單的業務場景下，微服務反而會降低效率。什么是微服務，其特性，好處及陷阱，是本文要討論的內容。
一、什么是微服務
微服務是一種軟件架構風格，它是以專注於單一責任與功能的小型功能區塊為基礎，利用模組化的方式組合出復雜的大型應用程序，各功能區塊使用與語言無關的 API（例如 REST）集相互通訊，且每個服務可以被單獨部署，它具備以下三個核心特點：
-
微服務為大型系統而生。隨着業務的快速增長，會帶來系統流量壓力和復雜度的上升，系統的可維護性和可擴展性成為架構設計的主要考慮因素，微服務架構設計理念通過小而美的業務拆分，通過分而自治來實現復雜系統的優雅設計實現。
-
微服務架構是面向結果的。 微服務架構設計風格的產生並非是出於學術或為標准而標准的設計，而是在軟件架構設計領域不斷演進過程中，面對實際工業界所遇到問題，而出現的面向解決實際問題的架構設計風格。
-
專注於服務的可替代性來設計。 微服務架構設計風格核心要解決的問題之一便是如何便利地在大型系統中進行系統組件的維護和替換，且不影響整體系統穩定性。
二、微服務的特征
-
每個微服務僅對單個業務負責，且為該業務的容量負責；
-
每個微服務可以進行獨立部署，即不需要依賴其它微服務及其相關資源，如數據庫、內存緩存系統等；
-
輕量級的通信協議，例如REST、STOMP、AMQP等；
-
服務的可替代性，代表着每個微服務原則上都可以使用不同的語言、框架進行技術實現，且更換實現后的微服務對於整個業務系統不會造成影響；
-
每個微服務擁有單獨的數據存儲；
-
每個微服務由小團隊維護，服務以業務來進行拆分后，每個微服務的維護工作將有人數不多的小團隊進行維護；
三、微服務帶來的好處
-
獨立的可擴展性，每個微服務都可以獨立進行橫向或縱向擴展，根據業務實際增長情況來進行快速擴展；
-
獨立的可升級性，每個微服務都可以獨立進行服務升級、更新，不用依賴於其它服務，結合持續集成工具可以進行持續發布，開發人員就可以獨立快速完成服務升級發布流程；
-
易維護性，每個微服務的代碼均只專注於完成該單個業務范疇的事情，因此微服務項目代碼數量將減少至IDE可以快速加載的大小，這樣可以提高了代碼的可讀性，進而可以提高研發人員的生產效率；
-
語言無關性，研發人員可以選用自己最為熟悉的語言和框架來完成他們的微服務項目（當然，一般根據每個公司的實際技術棧需要來了），這樣在面對新技術或新框架的選用時，微服務能夠更好地進行快速響應；
-
故障和資源的隔離性，在系統中出現不好的資源操作行為時，例如內存泄露、數據庫連接未關閉等情況，將僅僅只會影響單個微服務；
-
優化跨團隊溝通，如果要完全實踐微服務架構設計風格，研發團隊勢必會按照新的原則來進行划分，由之前的按照技能、職能划分的方式變為按照業務（單個微服務）來進行划分，如此這般團隊里將有各個方向技能的研發人員，溝通效率上來說要優於之前按照技能進行划分的組織架構；
-
原生基於“雲”的系統架構設計，基於微服務架構設計風格，我們能構建出來原生對於“雲”具備超高友好度的系統，與常用容器工具如Docker能夠很方便地結合，構建持續發布系統與IaaS、PaaS平台對接，使其能夠方便的部署於各類“雲”上，如公用雲、私有雲以及混合雲。
四、避免微服務的陷阱
-
不要以微服務作為開始，在項目剛開始時，一般都還很小，不需要進行非常完整的業務拆分，如果采用“微服務”作為開始會有點殺雞用牛刀的感覺，當然，你的項目非常之龐大的話，以“微服務”為始是個不錯的選擇；
-
不要自己進行基礎設施的管理，微服務意味着一堆的數據庫、消息系統、數據緩存系統等，會帶來相應的運維管理成本（這里的前提是，沒有良好的自動化運維平台和工具），建議多使用IaaS、PaaS平台，部署發布與其對接；
-
無DevOps、不微服務，如果研發團隊不具備DevOps的理念並貫徹執行，僅想單獨來實施微服務的話，在實施過程中會發現比之前的架構維護要困難些，主要原因是微服務需要持續集成、持續部署及監控等工具或系統的配合才能降低其帶來的維護成本；
-
不要創建過多的微服務，微服務的業務顆粒度一定要根據實際業務系統的現狀及日后規划來制定，切記不要制定過細的拆分顆粒度；
-
可能帶來的延遲問題，由於服務拆分開來，部署到不同的平台或網絡，可能會引起微服務間的調用延遲問題，服務間的調用延遲可能帶來整體系統的響應緩慢問題；
-
微服務不是銀彈。
-