1. 程式人生 > >.NET Core 實踐一:微服務架構的優點(轉)

.NET Core 實踐一:微服務架構的優點(轉)

微服務現在已經是各種網際網路應用首選的雲架構元件,無論是 BAT 還是 滴滴、美團 ,微服務都是重要的一環。

相對於微服務,傳統應用架構有以下缺點:

1. 業務程式碼混雜,團隊成員職責邊界不清,團隊協作體驗不佳,開發效率低下。

傳統應用架構中,各個業務模組程式碼都存在於同一個應用當中,各個業務模組之間互動邏輯複雜,程式碼統統混在一起,難免出現要去別人程式碼裡改程式碼的情況

2. 程式碼耦合度高,日趨臃腫,難以重構,維護成本越來越高。

感受過被F12支配的恐懼嗎?

3. 容錯能力弱,單點故障引發全域性崩潰。

4.無法針對熱點業務增加資源,造成浪費。

 

典型的微服務架構概覽

 

微服務架構按照功能和業務將應用程式分離成若干個部分,使各個部分之間鬆綁。一個典型的簡單微服務架構至少有以下幾個部分:

1. UI 層:即前端視覺層,包括 web 端網頁、手機APP以及PC客戶端。

2. 閘道器層:閘道器層類似我們家裡用的路由器,可以將入站請求重定向到目標為服務,並將站內的微服務進行整合打包輸出到站外。UI層一般會通過 HTTP/HTTPS 協議訪問閘道器向公網暴露的介面。此外,閘道器還應該具有鑑權的功能。

3. 反向代理:反向代理(Reverse Proxy)方式是指以代理伺服器來接受internet上的連線請求,然後將請求轉發給內部網路上的伺服器,並將從伺服器上得到的結果返回給internet上請求連線的客戶端,此時代理伺服器對外就表現為一個伺服器。通過在網路各處放置反向代理

節點伺服器所構成的在現有的網際網路基礎之上的一層智慧虛擬網路,CDN系統能夠實時地根據網路流量和各節點的連線、負載狀況以及到使用者的距離和響應時間等綜合資訊將使用者的請求重新導向離使用者最近的服務節點上。

4. 微服務叢集:根據需求不同,微服務叢集中會包含至少1個微服務例項,通過負載平衡將請求分配到每個例項上。如果使用Docker容器服務,則微服務叢集中至少包含一個Docker例項,配合負載平衡,我們可以動態的決定要啟用多少個Docker例項,並在不需要的時候銷燬冗餘的例項,提供完全自動化的彈性計算能力。

 5. 互操作性:微服務之間一般選用 HTTP/HTTPS 或者 RPC 作為互操作協議,使用JSON或者ProtoBuf序列化物件。由於微服務都部署在同一個內網之中,效能損耗幾乎可以忽略不計,如果選用RPC + ProtoBuf 的互動方案,延遲會更低。

微服務架構還有一些不足:

1. 微服務首先強調的是服務規模小,便於服務的伸縮和擴充套件,但是這也會導致服務碎片化,對人員管理提出了挑戰。

2. 微服務是一個分散式的系統,每一個微服務都有自己的資料庫,雖然在一定程度上增加了應用程式的整體可靠性,但是也不可避免的帶來大量冗餘資料。

3. 隨著服務規模增長,微服務的例項數量將會飛速增長,比如美國著名的線上電視網站 NetFlix(網飛)有大約600個微服務例項,而且這個數量還在不斷地增長。微服務的運維程式將不斷攀升。

4. 對於一些業務邏輯十分複雜的業務,可能一次呼叫便與十幾甚至數十個介面相關,為了滿足效能需求,我們不得不引入通知系統來非同步處理一些內容。非同步處理緊接著就帶來了資料一致性問題。

 

以上便是本章內容,如有稍可愚目者,還請不吝賜教。

下一章我將會通過一個例子分析同步執行和非同步執行的優劣。

轉載自:https://www.cnblogs.com/TO-WW/p/7309346.html