【微服務目錄】.NET Core 微服務介紹

介紹：

寫這篇文章有多方面的緣由，第一固然是爲了之後本身能夠隨時翻閱，第二也算是一種積累吧。由於有些東西你弄個以後，過了很長時間不用，可能會有些忘卻，可是你由於之前弄個吧，有不是那種小白，須要去找示例代碼，而你缺的只是一個引子然你回想起來。因此咱們大多數園子的人很多寫文章就是爲了這個吧。固然有順序有規律的去學習會比盲目的去學要好的多，全部我這也是分步進行的，也不失爲一個想了解微服務，可是又不知道如何下手的人提供一個思路。固然我寫的也不是多好，有些也是看着官網作的，有的理解也是不很到位。共同窗習共同進步嗎。

其實在寫這個文章的時候我已經作了不少功課（已經寫過其中的技術點了）。只是後來想了想仍是整理出來一個目錄吧，方便之後歸類整理，否則每一篇單個的文章不知道是幹什麼，畢竟使用了多個技術點。我寫的文章數也不是不少，我也不是特地爲了寫文章而寫文章，只是爲了本身的一個文檔整理而已，全部有的篇幅問題了咱們就笑笑吧。
我也沒有那麼多的時間去深刻的發掘，因此寫的都是一些入門示例，主要是讓咱們明白他是個什麼，對就是這個意思。深刻的咱們入門之後能夠本身去探索。仍是剛纔那句話，由於我只是作筆記記錄，全部我是有時間說不定纔會更新一些文章，全部高手就繞行吧，我如今只寫了一些入門示例，固然之後有時間或者須要了還會持續更新本系列吧。

爲何選擇微服務哪？相對於傳統的應用架構：

• 業務代碼混雜，團隊成員職責邊界不清，團隊協做體驗不佳，開發效率低下。傳統應用架構中，各個業務模塊代碼都存在於同一個應用當中，各個業務模塊之間交互邏輯複雜，代碼通通混在一塊兒，不免出現要去別人代碼裏改代碼的狀況
• 代碼耦合度高，日趨臃腫，難以重構，維護成本愈來愈高。感覺過被F12支配的恐懼嗎？
• 容錯能力弱，單點故障引起全局崩潰。
• 沒法針對熱點業務增長資源，形成浪費。

ASP.NET Core 實際上是一個很是適合作微服務的一個 Web 框架，它足夠的輕量級而且擁有超高的性能。而且對於 Rest 這些風格的接口支持的很是的友好。更多好處我其實不太願意去說，由於只有你本身去體會纔會知道。

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

• UI 層：即前端視覺層，包括 web 端網頁、手機APP以及PC客戶端
• 集羣：根據需求不一樣，微服務集羣中會包含至少1個微服務實例，經過負載平衡將請求分配到每一個實例上。
• 代理：反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的鏈接請求，而後將請求轉發給內部網絡上的服務器，並將從服務器上獲得的結果返回給internet上請求鏈接的客戶端，此時代理服務器對外就表現爲一個服務器。
• 網關層：網關層相似咱們家裏用的路由器，能夠將入站請求重定向到目標爲服務，並將站內的微服務進行整合打包輸出到站外。UI層通常會經過 HTTP/HTTPS 協議訪問網關向公網暴露的接口。

系列目錄：

微服務系列文章主要介紹微服務所使用到的一些技術和一些技術示例：

• 微服務——微服務的介紹和目錄
• 微服務——【Consul】服務發如今windows下簡單使用（一）
• 微服務——【polly】微服務故障處理庫（二）
• 微服務——動態代理AspectCore的使用（三） 
• 微服務——網關Ocelot+Consul實現集羣輪詢（四）