一、瞭解微服務架構
阿新 • • 發佈：2018-12-23
“微服務架構”在這幾年非常的火熱，以至於關於微服務架構相關的開源產品被反覆的提及（比如：netflix、dubbo），Spring Cloud也因Spring社群的強大知名度和影響力也被廣大架構師與開發者備受關注。
一：為什麼需要微服務架構？
- 網際網路/內聯網/網路更加成熟
- 輕量級執行時技術的出現(node.js, WAS Liberty等)
- 新的方法與工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)
- 新的輕量級協議(RESTful API介面, 輕量級訊息機制)
- 簡化的基礎設施：作業系統虛擬化(hypervisors), 容器化(e.g. Docker), 基礎設施即服務 (IaaS), 工作負載虛擬化(Kubernetes,Spark…)等
- 服務平臺化(PaaS)： 雲服務平臺上具有自動縮放、工作負載管理、SLA 管理、訊息機制、快取、構建管理等各種按需使用的服務
- 新的可替代資料持久化模型：如NoSQL, MapReduce, BASE, CQRS等
- 標準化程式碼管理：如Github等
二：什麼是微服務？
什麼是“微服務架構”呢？簡單的說，微服務架構就是將一個完整的應用從資料儲存開始垂直拆分成多個不同的服務，每個服務都能獨立部署、獨立維護、獨立擴充套件，服務與服務間通過諸如RESTful API的方式互相呼叫。這些服務共用一個集中式的管理，服務也可用不同的語音開發，使用不同的資料儲存技術。
三：單體架構和微服務架構
單體應用架構顧名思義就是一個包中包含所有的功能的應用程式。單體應用比較容易部署、測試，在專案的初期可以很好的執行，但隨著需求的不斷增加，單體應用變得越來月臃腫，可維護性、靈活性逐漸降低，維護成本越來越高。
優點：
- 易於開發：傳統的開發工具和開發流程都對單體架構有很好的支援
- 部署簡單：只需要把war檔案（或目錄層次結構）複製到web伺服器即可
- 水平擴充套件容易：通過在負載均衡器後面執行應用程式的多個副本，很容易做到水平擴充套件
缺點：
- 複雜性高：隨著應用程式需求變多，且複雜，應用程式會變得難以理解和修改
- 部署頻率低：隨著應用程式越來越大，構建和部署的時間也會增加。全量部署的方式消耗時間長、影響範圍大、風險高，這使專案上線部署的頻率較低
- 技術債務：隨著時間推移、需求變更和人員更迭，會逐漸形成應用程式的技術債務，並且越積累越多
- 可靠性較低：任何模組中錯誤都可能導致整個程式執行失敗
- 獨立擴充套件能力受限：當不同模組具有不同的資源需求時，單體架構難以獨立擴充套件這些模組
- 阻礙技術創新：單體應用往往使用統一的技術平臺或方案解決所有的問題，都必須使用相同的開發語音和框架，想要引入新的框架和新技術會非常困難
微服務架構就是將整個應用分解為多個微服務，各個微服務獨立執行在自己的程序中，並分別有自己的資料庫，微服務之間使用REST或者其他協議通訊。
優點：
- 易於開發和維護：每個微服務為獨立的業務開發，只關注某個特定的功能，所以業務清晰、程式碼量較少
- 區域性修改容易部署：修改功能後，只需重新部署對應的微服務，無需全部部署，並且不影響其他微服務功能
- 技術棧不受限：在微服務架構中，可以結合專案業務及團隊的特點，合理地選擇技術棧
- 按需伸縮：可根據需求，實現細粒度的擴充套件
缺點：
- 運維要求較高
- 分散式固有的複雜性：使用微服務構建的是分散式系統。對於一個分散式系統，系統容錯、網路延遲、分散式事務等都會帶來巨大的問題
- 介面調整成本高：微服務之間通過介面進行通訊。如果修改某一個微服務的API，可能所有用到這個介面的微服務都需要進行調整。
- 重複勞動：很多服務可能都會使用到相同的功能，而這個功能並沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開發這一功能，從而導致程式碼重複