.NET Core下的Spring Cloud——前言和概述
前言
前幾年一直在寫類似dubbo，Srping Cloud的微服務框架輾輾轉轉重復了多次，也重構推翻了很多次，其中誕生了“Rabbit.Rpc”,”Go”,”RabbitCloud”等開源項目。
其中不乏他人對這些項目的完善。很高興自己的開源項目能夠給他人提供思路和復用代碼。
關於Rabbit.Rpc相關的文章：
《.NET輕量級RPC框架：Rabbit.Rpc》
《擁抱.NET Core，跨平臺的輕量級RPC：Rabbit.Rpc》
挫折
但無一不被推翻。為什麽呢？是因為沒有耐心？喜新厭舊嗎？
回顧經歷，鄙人一直在互聯網類型的公司就職，用戶量和請求量都不算低，而自己造的輪子在具體應用上多多少少存在一些問題。
為什麽不去解決遇到的問題呢？
一個人的精力有限，越深入越發現一個微服務框架需要考慮的事情太多，而不是簡簡單單寫點代碼達到展示可用。
真正用在生產上會遇到很多奇奇怪怪的需求，有技術正確的也有業務需要的。
而且每一個項目對微服務框架的需求也不盡一樣。經常遇到某些功能在A處可用，在B處就沒那麽流利了。
是能力不足代碼太low嗎？
也存在這個可能。個人覺得微服務框架需要大量的微服務實踐經驗。或許是本人的實踐經驗還不夠。
站在巨人的肩膀上
這時候我發現了一個項目“SteeltoeOSS”這是Spring Cloud團隊在.NET下的實現。這時我準備擁抱開源，放棄自己造核心輪子的想法。利用社區的經驗衍生出更方便的使用方式。
然而SteeltoeOSS因為創建不久，無法完全對標Java Spring Cloud的實現，缺少了一些快速上手的能力，比如feign（聲明式API請求客戶端），Hystrix的集成，ribbot（負載均衡服務器），只有基於eureka的服務發現。
這樣的情況便萌生了我補缺的想法，我基於SteeltoeOSS添加了三個新的項目，分別是：steeltoe-extensions（Steeltoe.Discovery.Consul.Client，基於consul的服務發現），ribbon和feign（簡單可用）。其中feign屬於簡單可用，耦合的比較緊，目前feign還在ribbon的git倉庫。
為什麽要這麽做？
“.NET不缺乏輪子，而是缺乏穩定生產可用的輪子。”
目前這套解決方案只在前段時間"福州首屆.NET開源社區線下技術交流會"上公開宣講過。
這套解決方案也用於生產,不是滿足私欲的花瓶框架。
下面是生產環境的相關情況：
最大峰值：80W/min
日請求量：2億
微軟官方實地勘察調研，並作為案例向社會推廣.NET Core。
看看效果
首先準備2個server（服務提供方）
這邊大家意會就可以了，後續會寫詳細的文章來一步一步完成和解釋這些步驟。
配置如下：
大概的意思是：
本地綁定的服務端口分別是 6001和6002
配置Consul的地址和註冊到Consul上的服務地址
其中server2關閉了url健康檢查（consul定時向server1請求，返回200代表健康），啟用了心跳檢查（定時向consul報告我還活著）。
設置服務的名稱
添加actuator端點（提供健康檢查等能力，來自SteeltoeOSS）
Program如下：
大概的意思是：
根據不同的serverId加載不同的配置文件並且創建對應的WebHost
其中UseDiscoveryClient是啟用發現客戶端的意圖
Startup如下：
大概的意思是：
server1啟用mvc，健康檢查端點和CloudFoundry端點（url健康檢查）
server2只啟用mvc（心跳檢查）
Controller如下：
大概的意思：返回當前時間
看看Consul
我們可以發現Consul上註冊了一個timeService，並且有兩個健康的節點，分別是：localhost:6001和localhost:6002。
這樣我們就完成了同一個服務兩個實例的環境，下一步就是如何調用這些服務。
編寫客戶端（服務調用方）
配置文件
大概的意思是：
配置Consul的地址
當前程序不註冊到Consul上（目前只是調用方無需註冊到Consul）
只查詢健康的服務信息（不健康的節點不會返回）
使用feign調用
定義接口
大概的意思是：
定義了一個ITimeService接口，裏面有個方法叫GetNowAsync。
在接口定義上添加FeignClientAttribute，指定這個接口對應的服務名稱是：timeService（server端的服務名稱：Spring:Application:Name），定義一個回退類型（當服務不可用時返回一個可控值，DateTime的最小時間）
初始化和調用
運行
關掉server試試？
在開啟server？
使用HttpClientFactory調用
初始化和調用
運行
可以看到6001和6002在交替請求，證明采用的策略是輪詢。
寫在最後
本篇屬於開篇，後續會單獨介紹ribbon、feign、Steeltoe.Discovery.Consul.Client。
開源的地址如下：
https://github.com/majian159/ribbon
https://github.com/RabbitTeam/steeltoe-extensions
.NET技術棧QQ群：384413261（點擊加入 .NET Group）
.NET Core下的Spring Cloud——前言和概述