介紹：
寫這篇文章有多方面的原因，第一當然是為了以后自己可以隨時翻閱，第二也算是一種積累吧。因為有些東西你弄個之后，過了很長時間不用，可能會有些忘卻，但是你因為以前弄個吧，有不是那種小白，需要去找示例代碼，而你缺的只是一個引子然你回想起來。所以我們大多數園子的人不少寫文章就是為了這個吧。當然有順序有規律的去學習會比盲目的去學要好的多，所有我這也是分步進行的，也不失為一個想了解微服務，但是又不知道如何下手的人提供一個思路。當然我寫的也不是多好，有些也是看着官網做的，有的理解也是不很到位。共同學習共同進步嗎。
其實在寫這個文章的時候我已經做了很多功課（已經寫過其中的技術點了）。只是后來想了想還是整理出來一個目錄吧，方便以后歸類整理，不然每一篇單個的文章不知道是干什么，畢竟使用了多個技術點。我寫的文章數也不是很多，我也不是特意為了寫文章而寫文章，只是為了自己的一個文檔整理而已，所有有的篇幅問題了我們就笑笑吧。
我也沒有那么多的時間去深入的發掘，所以寫的都是一些入門示例，主要是讓我們明白他是個什么，對就是這個意思。深入的我們入門以后可以自己去探索。還是剛才那句話，因為我只是做筆記記錄，所有我是有時間說不定才會更新一些文章，所有高手就繞行吧，我現在只寫了一些入門示例，當然以后有時間或者需要了還會持續更新本系列吧。
為什么選擇微服務哪？相對於傳統的應用架構：
- 業務代碼混雜，團隊成員職責邊界不清，團隊協作體驗不佳，開發效率低下。傳統應用架構中，各個業務模塊代碼都存在於同一個應用當中，各個業務模塊之間交互邏輯復雜，代碼統統混在一起，難免出現要去別人代碼里改代碼的情況
- 代碼耦合度高，日趨臃腫，難以重構，維護成本越來越高。感受過被F12支配的恐懼嗎？
- 容錯能力弱，單點故障引發全局崩潰。
- 無法針對熱點業務增加資源，造成浪費。
ASP.NET Core 其實是一個非常適合做微服務的一個 Web 框架，它足夠的輕量級並且擁有超高的性能。並且對於 Rest 這些風格的接口支持的非常的友好。更多好處我其實不太願意去說，因為只有你自己去體會才會知道。
微服務架構按照功能和業務將應用程序分離成若干個部分，使各個部分之間松綁。一個典型的簡單微服務架構至少有以下幾個部分：
- UI 層：即前端視覺層，包括 web 端網頁、手機APP以及PC客戶端
- 集群：根據需求不同，微服務集群中會包含至少1個微服務實例，通過負載平衡將請求分配到每個實例上。
- 代理：反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然后將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現為一個服務器。
- 網關層：網關層類似我們家里用的路由器，可以將入站請求重定向到目標為服務，並將站內的微服務進行整合打包輸出到站外。UI層一般會通過 HTTP/HTTPS 協議訪問網關向公網暴露的接口。
系列目錄：
微服務系列文章主要介紹微服務所使用到的一些技術和一些技術示例：