微服務架構

微服務發展史

任何一個理論或者技術的出現往往是伴隨著現實中出現了相應的問題，而產生的的一系列解決辦法，往往在專案初期業務并不是很復雜、用戶量不是很大，單體架構完全符合當時的需求，所以在專案初期是都是從單體架構進行開始的，

隨著用戶量、資料量的增加以及業務功能的逐漸完善和復雜化，單體架構造成了業務代碼耦合嚴重、代碼復用性降低、單臺資料庫以及服務器造成了瓶頸，為了減少業務的耦合度，對業務和資料庫進行劃分，并采用集群化方式進行擴展，提高系統的吞吐量，

我理解的SOA架構是對于一個大的業務場景需要對多個其他的應用進行整合，為了進一步加強對于共享業務的解耦，采用SOA架構可以增強共享業務的重用，實作對應用的快速整合，

下圖是SOA架構和微服務架構的架構圖，

SOA架構和微服務架構的架構圖

SOA架構就是面向服務的一種解決方案，而微服務架構則是針對業務的進一步優化，微服務架構根據業務將服務的粒度進一步細分，降低了業務之間的耦合度，但隨之而來也帶來了一系列的問題，

降低代碼耦合、提高復用性

微服務架構通過對共享業務更細粒度的劃分，降低了業務之間的耦合度，增加了共享業務代碼的復用性，
職責專一

由于每個服務的職責比較清晰，所以對于每個業務的開發、維護等會更加簡單，
完全獨立
- 每個微服務都是獨立的，完全可以每個服務采用不同的技術堆疊，便于團隊化的開發以及技術選型的靈活性，
- 可以動態卸載，所以單個服務出現問題可以在不影響整體服務的運行進行下線處理，

呼叫鏈復雜

隨著服務的不斷增加，業務呼叫鏈路變得更加復雜，如果出現問題，為問題的排查帶來了一定的難度，
服務間的通信挑戰

每個服務都是獨立進行部署的，所以服務之前的通信，以及通信所造成的網路問題也成為了系統需要考慮的問題，
分布式帶來的問題
- 每個服務有可能采用不同的資料庫，所以整個系統資料的一致性也是一項新的挑戰，需要引入分布式事務的解決方案，
- 為了保證對于共享資料的訪問，微服務系統也需要采用一套分布式鎖的解決方案，
復雜度增加

綜上所述，微服務架構系統會帶來一系列的技術性問題，需要引入更多來對系統完成治理以及監控的技術，增加了系統的復雜度，

《Spring Cloud Alibaba 微服務原理與實戰》
微服務架構 vs. SOA架構

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/291821.html

標籤：其他