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