初識微服務

一.單體架構和微服務架構的比較

1.單體架構的優點和不足

單體架構的優點：在項目的初期便於開發、便於測試、便於部署

單體架構的不足：

• 複雜性高-代碼難以理解，難以修改和重構
• 交付效率低-項目總體部署耗時長、難以定位問題、影響範圍廣、風險大、發佈頻次低
• 伸縮性差-單體只能按總體進行橫向擴展，沒法分模塊垂直擴展；IO密集型模塊（日誌收集）和cpu密集型模塊（圖片壓縮、加解密）沒法獨立擴容和升級
• 可靠性差-一個bug有可能引發整個應用的崩潰
• 受技術棧限制，團隊只能使用同一個語言和框架

什麼是橫向擴展和垂直擴展？

1）橫向擴展 也叫 水平擴展，用更多的節點支撐更大量的請求。 如成千上萬的螞蟻完成一項搬運工做

2）縱向擴展 又叫 垂直擴展，擴展一個點的能力支撐更大的請求。如利用1我的的能力，如蜘蛛俠逼停火 

2.什麼是微服務架構?

微服務架構自己來源於互聯網的思路，所以組件對外發布的服務強調了採用HTTP Rest API的方式來進行。

將單體應用拆分紅多個高內聚低耦合的小型服務，獨立部署，能夠採用不一樣的語言以及存儲，每一個小型服務運行在獨立進程當中，服務間採用輕量級通訊機制，而非採用進程內調用的方式進行通訊。

3.微服務架構的優點

• 易於開發和維護-微服務相對小，易於理解，啓動時間少，開發效率高
• 獨立部署-一個微服務的修改不須要協調其餘服務　　
• 伸縮性強-每一個服務均可以進行橫向和縱向擴展；每一個服務均可以獨立擴容
• 技術異構性-各個微服務可使用最適合該服務的技術

2、微服務所要解決的主要問題

1.服務的拆分

• 微服務拆分的原則-高內聚低耦合、服務粒度適中
• 擁有獨立的數據庫
• 微服務之間肯定服務邊界

2.數據一致性

在微服務架構下，每一個服務對應一個數據庫，這就出現了原來單體中對同一個庫的操做變成了跨服務數據庫的操做。

遇到有事務約束的場景，好比轉帳匯款、訂單狀態和庫存扣減，就從本地事務過渡到分佈式事務來了。

 

在微服務中使用最終一致性來代替強一致性。

實現最終一致性有兩種模式:

1）.用消息隊列實現可靠性模式

2）.補償模式-sagas模式

在微服務的初期儘可能粗粒度，將事務放在一個服務中。

這兩種方式都須要寫大量的代碼，阿里巴巴提出的了分佈式事務解決方案----GTS

 

3.服務通訊

• 通訊技術方案-RPCvsRESTvs異步消息

4.服務治理—服務註冊與發現

• 服務註冊中心
• 服務提供者
• 服務消費者

5.服務網關

它的定義相似於面向對象設計模式中的Facade模式，它的存在就像是整個微服務架構系統的門面同樣，全部的外部客戶端訪問都須要通過它來進行調度和過濾。

由它來實現請求路由、負載均衡、校驗過濾等功能，以及與服務治理框架的結合，請求轉發的熔斷機制、服務的聚合等。

• 身份認證、路由服務、流量控制、日誌統計

若是咱們的微服務和終端通訊，勢必要考慮身份認證，若是咱們的微服務都與每一個終端用戶打交道，那麼這些代碼就須要拷貝多份，

而且植入到每一個微服務業務代碼中，這就形成業務代碼和身份認證代碼耦合，下降代碼的複用性。

在身份認證、路由服務等放在服務網關中，向業務代碼中屏蔽這些網絡邊界的細節，使得業務服務專一於業務邏輯的開發。

• 爲前端服務的後端

　　好比將多個服務的數據聚合在一塊兒返回給前端

6.可靠性

在單體架構中，可能由於一個服務不可用致使整個系統不可用。微服務不會產生這種狀況，一個微服務不可用時不會影響和它沒有依賴關係的服務，

可是可能由於一個服務不可用致使上游服務線程服務夯死，故障進一步向上傳播。

這個地方線程服務夯死是指的是服務不斷佔用資源，致使其餘服務線程沒法正常工做。

• 倉壁隔離

倉壁隔離：給每一個應用分配一個獨立的線程池，而不是共享線程池，這樣一個應用的故障不會拖累其餘服務。

• 服務降級

服務降級：當服務不可用時，服務消費者應該對接口編寫降級方法，

好比評論服務在獲取用戶服務的頭像時，用戶服務不可用，那麼降級方法能夠返回默認頭像，或者緩存中的頭像，

好比推薦服務不可用時，網關服務右邊欄的頁面使他爲空，不展現任何信息。

• 服務熔斷

熔斷：是指服務不可用在必定的時間內達到必定的數量，自動關閉該服務的調用開關，直接調用降級邏輯，這樣下降資源耗盡的風險

7.高可觀察

• 健康檢查、集中監控

微服務整個系統都須要在咱們的監控體系中，包括註冊中心的監控、 服務進程的監控、流量的監控、日誌的監控，狀態的監控等 

將這些信息集中以圖表的形式輸出，方便查看問題。

• 日誌聚合及檢索

好比說在電商app中，咱們沒法進行下單操做，在分佈式服務架構中 ，日誌是散落在多個服務上的，咱們若是說登陸每臺服務器進行檢索是很是低效的，這就須要咱們進行日誌格式的標準化，並利用必定的手段將日誌聚合起來進行檢索查詢，咱們須要將這些檢索查詢的組件放到共享庫當中，或者代碼腳手架進行提供，以方便咱們和業務代碼進行解耦。

• 分佈式追蹤

在微服務場景中，一個客戶端發起的請求要通過多個服務的調用，咱們不知道該請求經歷哪些服務的調用，調用哪些服務出現了問題，每一個服務的輸入輸出是什麼，這都給咱們定位問題帶來的困難；除此以外若是一個請求耗時挺長，咱們不知道哪一個服務耗時最長，這就給咱們性能優化帶來了困難。隨着架構的演進，咱們須要知道服務之間的依賴關係，這就須要咱們的分佈式追蹤。

 

3、SOA和微服務的比較

• 技術棧

SOA：ESB、SOAP

微服務：輕量級MQ、REST、RPC

• 數據拆分

SOA：共享數據庫

微服務：一服務一數據庫

• 服務粒度

SOA：服務粒度比較粗，多個單體的組合

微服務:粒度更小的服務