.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. 對於一些業務邏輯十分複雜的業務，可能一次調用便與十幾甚至數十個接口相關，爲了知足性能需求，咱們不得不引入通知系統來異步處理一些內容。異步處理緊接着就帶來了數據一致性問題。

 

以上即是本章內容，若有稍可愚目者，還請不吝賜教。

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