Tips：本篇已加入系列文章閱讀目錄，可點選檢視更多相關文章。
寫這篇部落客要目的是記錄一下自己的學習過程，隻能是簡單入門級别的，因為水準有限就寫到哪算哪吧，寫的不對之處歡迎指正。
代碼放在：https://github.com/xiajingren/NetCoreMicroserviceDemo
關于微服務的概念解釋網上有很多...
個人了解，微服務是一種系統架構模式，它和語言無關，和架構無關，和工具無關，和伺服器環境無關...
微服務思想是将傳統的單體系統按照業務拆分成多個職責單一、且可獨立運作的接口服務。至于服務如何拆分，沒有明确的定義。
幾乎任何後端語言都能做微服務開發。
微服務也并不是完美無缺的，微服務架構會帶來更多的問題，增加系統的複雜度，引入更多的技術棧...
一個用戶端，一個産品服務，一個訂單服務。3個項目都是asp.net core web應用程式。建立項目的時候記得啟用一下Docker支援，或者後面添加也行。
為産品、訂單服務添加一些基礎代碼，就簡單的傳回一下 服務名稱，目前時間，服務的ip、端口。
為了友善，我使用Docker來運作服務，不用Docker也行，關于docker的安裝及基本使用就不介紹了。
build鏡像：
在項目根目錄打開PowerShell視窗執行：<code>docker build -t productapi -f ./Product.API/Dockerfile .</code>
Successfully代表build成功了。
運作容器:
執行：<code>docker run -d -p 9050:80 --name productservice productapi</code>
執行：<code>docker ps</code>檢視運作的容器：
沒問題，使用浏覽器通路一下接口：
也沒問題，其中的ip端口是Docker容器内部的ip端口，是以端口是80，這個無所謂。
産品服務部署好了，下面部署一下訂單服務，也是同樣的流程，就把指令簡單貼一下吧：
build鏡像：<code>docker build -t orderapi -f ./Order.API/Dockerfile .</code>
運作容器：<code>docker run -d -p 9060:80 --name orderservice orderapi</code>
浏覽器通路一下：
OK，訂單服務也部署完成了。
用戶端我這裡隻做了一個web用戶端，實際可能是各種業務系統、什麼PC端、手機端、小程式。。。這個明白就好，為了簡單就不搞那麼多了。
因為用戶端需要http請求服務端接口，是以需要一個http請求用戶端，我個人比較習慣RestSharp，安利一波：https://github.com/restsharp/RestSharp
添加基礎代碼：
IServiceHelper.cs：
ServiceHelper.cs：
Startup.cs：
HomeController.cs：
Index.cshtml：
代碼比較簡單，這裡就不用docker了，直接控制台啟動，使用浏覽器通路：
一切正常。進行到這裡，各個服務也獨立運作了，用戶端也能正常調用了，貌似算是完成一個簡易的微服務了。但是，微服務架構最重要的原則就是——“高可用”。以上的做法明顯不能滿足高可用性，因為任何一個服務挂掉，所有依賴這個服務的業務系統都會受影響。
停止一下訂單服務：<code>docker stop orderservice</code>
訂單服務停止，導緻用戶端業務系統無法擷取訂單資料。
要解決這個問題，很容易想到：叢集。
既然單個服務執行個體有挂掉的風險，那麼部署多個服務執行個體就好了嘛，隻要大家不同時全挂就行。
使用docker運作多個服務執行個體：
現在訂單服務和産品服務都增加到3個服務執行個體。
那麼稍微改造一下用戶端代碼吧：
當然拿到這些服務位址可以自己做複雜的負載均衡政策，比如輪詢，随機，權重等等 都行，甚至在中間弄個nginx也可以。這些不是重點，是以就簡單做一個随機吧，每次請求來了随便通路一個服務執行個體。
浏覽器測試一下：
可以看到請求被随機配置設定了。但是這種做法依然不安全，如果随機通路到的執行個體剛好挂掉，那麼業務系統依然會出問題。
簡單處理思路是：
1.如果某個位址請求失敗了，那麼換一個位址接着執行。
2.如果某個位址的請求連續多次失敗了，那麼就移除這個位址，下次就不會通路到它了。
。。。。。。
業務系統實作以上邏輯，基本上風險就很低了，也算是大大增加了系統可用性了。
然後思考另一個問題：
實際應用中，上層的業務系統可能非常多，為了保證可用性，每個業務系統都去考慮服務執行個體挂沒挂掉嗎？
而且實際應用中服務執行個體的數量或者位址大多是不固定的，例如雙十一來了，流量大了，增加了一堆服務執行個體，這時候每個業務系統再去配置檔案裡配置一下這些位址嗎？雙十一過了又去把配置删掉嗎？顯然是不現實的，服務必須要做到可靈活伸縮。
這時候就引入一個名詞：服務注冊與發現
未完待續...
——本文使用【Typora】+【EasyBlogImageForTypora】編輯
歡迎關注我的公衆号，一起學習。
如果本文對您有所幫助，您可以點選右下方的【推薦】按鈕支援一下；文中如有不妥之處，還望指正，非常感謝！！！
作者：xhznl
出處：http://www.cnblogs.com/xhznl/
文章可以轉載，但請注明出處