.NET Core 實踐一：微服務架構的優點(轉)
微服務現在已經是各種網際網路應用首選的雲架構元件，無論是 BAT 還是 滴滴、美團 ，微服務都是重要的一環。
相對於微服務，傳統應用架構有以下缺點：
1. 業務程式碼混雜，團隊成員職責邊界不清，團隊協作體驗不佳，開發效率低下。
傳統應用架構中，各個業務模組程式碼都存在於同一個應用當中，各個業務模組之間互動邏輯複雜，程式碼統統混在一起，難免出現要去別人程式碼裡改程式碼的情況
2. 程式碼耦合度高，日趨臃腫，難以重構，維護成本越來越高。
感受過被F12支配的恐懼嗎？
3. 容錯能力弱，單點故障引發全域性崩潰。
4.無法針對熱點業務增加資源，造成浪費。
典型的微服務架構概覽
微服務架構按照功能和業務將應用程式分離成若干個部分，使各個部分之間鬆綁。一個典型的簡單微服務架構至少有以下幾個部分：
1. UI 層：即前端視覺層，包括 web 端網頁、手機APP以及PC客戶端。
2. 閘道器層：閘道器層類似我們家裡用的路由器，可以將入站請求重定向到目標為服務，並將站內的微服務進行整合打包輸出到站外。UI層一般會通過 HTTP/HTTPS 協議訪問閘道器向公網暴露的介面。此外，閘道器還應該具有鑑權的功能。
3. 反向代理：反向代理（Reverse Proxy）方式是指以代理伺服器來接受internet上的連線請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連線的客戶端，此時代理伺服器對外就表現為一個伺服器。通過在網路各處放置反向代理
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