一位攝影程式設計師的獨白
每個人都有愛好，都有釋放壓力的活動，而我也不例外，我除了每天上班，週末就會約一群好友去拍妹子，成家後，就改為拍蟲子，一拍就到了30歲，到了30歲就感覺到了中年的壓力，這時候停下手中的攝影，開始研究技術，我開始翻閱各種技術部落格，各種開源作品，靜下心去研究技術時，發現.NET的技術非常薄弱，各種解決方案都非常欠缺，尤其是微服務，在.NET領域基本上一片空白，這時候碰巧.NET CORE 的出現，研發surging想法也開始萌芽，也到處跟同事說，我要研發一套微服務框架，真正意義上的微服務框架，讓大家都去關注業務，而無需去關注webapi,rest,http,tcp,rabbitmq,快取等與業務無關的技術，這些都由框架和中介軟體去實現，而同事，朋友投過來的都是鄙夷，驚訝，意思是就憑你，是啊！就憑我，在不斷學習下，2017年我開始邁出了研發的第一步，2017年6月16日開始在github 進行開源。而半個月後被邀請到TCC開源小組孵化surging.
轉眼間已經到2018年年尾，還有一個星期就跨入2019年，在新年到來的日子，surging 也準備釋出1.0穩定版本，在這1年半的日子裡，耗費了多少個日日夜夜我已經記不清，每天下班回來我都要理清下surging ，還有哪些欠缺，需要彌補，需要完善，耗費了心血和時間在surging上,但是這一切都是值得的，因為有些公司已經採用surging ，在微服務上已經給了非常好的解決方案，並且有一家物聯網公司已經使用surging 的ws,mqtt協議，據瞭解客戶端裝置就有好幾萬臺。那下面我們來看看1.0版本有那些功能。
元件介紹
一、通訊元件
1. Dotnetty:
針對於底層的http,mqtt,TCP協議採用了dotnetty進行實現 ，並且可以配置使用Libuv，而dotnetty 是微軟的Azure團隊，使用C#實現的Netty的版本,效能非常強大。
2.websocket-sharp:
針對於底層的websocket採用了websocket-sharp進行實現，因為官方未支援.net core，所以把它轉化支援.NET CORE,並且原始碼放到surging ，並且同時和suring 一起釋出
2.Kestrel:
針對於底層的Http協議採用了Kestrel進行實現，並且swagger也依賴於Kestrel，後期會擴充套件身份驗證，資料加密，服務聚合等功能以代替閘道器，並且還會完善基於Kestrel的檔案服務
二、編解碼元件
1.Newtonsoft.Json
針對於json 的編解碼採用了Newtonsoft.Json進行實現 ，並且預設使用Newtonsoft.Json進行編解碼
2.MessagePack-CSharp
針對於messagepack 的編解碼採用MessagePack-CSharp進行實現，MessagePack-CSharp是用於C＃實現的MessagePack序列化元件，比官方的MsgPack-Cli快10倍，與其他所有C＃序列化程式相比，具有最好的效能
3.protobuf-net
針對於二進位制的protobuf格式的編解碼採用的是protobuf-net進行實現
三、日誌元件
1.Nlog
針對於Critical，Debug，Trace，Error，Information，Warning級別的日誌可以通過Nlog元件進行實現，並且可以寫入到Console，file，database
2.log4net
針對於Critical，Debug，Trace，Error，Information，Warning級別的日誌可以通過log4net元件進行實現，並且可以寫入到Console，file，database
四、註冊中心
1. consul
針對於MqttServiceRoute、ServiceCache、ServiceCommand、ServiceRoute採用了consul的Key/Value 進行儲存，並且更新是採用了心跳進行更新
2. zookeeper
針對於MqttServiceRoute、ServiceCache、ServiceCommand、ServiceRoute採用了zookeeper指定path進行node 儲存，並且更新是採用了watcher進行更新
五、佇列
1. rabbitmq
針對於訊息佇列rabbitmq 實現了訊息的重試，失敗回滾，訊息的延遲處理，目前只實現了direct
2. kafka
實現了針對於topic 進行釋出訂閱。
六、快取
1.MemoryCache
由surging 的Caching元件提供的記憶體快取，使用該型別可以方便的在程式內部快取資料並對於資料的有效性進行方便的管理
2.Redis
針對於redis 快取實現了雜湊一致性，並且配有健康檢查，對於超過6次不健康的服務會從雜湊節點移除。目前只實現了key-value
七：動態代理
1.ProxyGenerator
針對動態代理是通過Roslyn構建指令碼來生成編譯AOP動態代理，以提供通過介面建立代理方式訪問。
負載均衡
一、容錯策略
1. 隨機（Random）：
通過生成隨機數隨機選擇服務地址，呼叫量越大分佈越均勻
2. 輪詢（Polling）
通過輪詢地址選擇服務地址，存在比較慢的機器容易在這臺機器的請求阻塞較多，預設使用此負載演算法
3.雜湊一致性（HashAlgorithm）
通過第一個引數生成的雜湊值進行雜湊一致性選取服務地址，對於第一個相同引數的值的請求會定位到同一個服務提供者上
4.壓力最小優先（FairPolling）
通過輪詢優先選擇壓力最小的服務地址，針對於壓力比較小的伺服器會分配更多的請求。
服務容錯和熔斷
一、容錯策略
1.故障轉移策略(Failover):
通過設定故障轉移群集數(FailoverCluster),從而服務故障自動轉移到健康的服務提供者
2.指令碼注入策略(Injection):
通過設定指令碼注入（Injection）,服務發生錯誤時會返回所定義執行的指令碼結果
3.回退策略(FallBack)
通過設定回退的例項名（FallbackName）,服務發生錯誤時通過FallBackName去呼叫依賴注入的介面IFallbackInvoker
二、熔斷
1.錯誤率熔斷
通過設定錯誤率（BreakeErrorThresholdPercentage）,當失敗呼叫數/遠端呼叫數大於錯誤率，會啟用熔斷
2.超時熔斷
通過設定執行超時時間（ExecutionTimeoutInMilliseconds）,當服務呼叫超過執行時間會啟用熔斷
3.併發熔斷
通過設定訊號量最大併發度（MaxConcurrentRequests）,在多執行緒環境下超過設定的訊號量，會啟用熔斷
4.錯誤數熔斷
通過設定呼叫失敗的錯誤數（BreakerRequestVolumeThreshold）,在10秒鐘範圍內超過設定的呼叫失敗錯誤數，會啟用熔斷
眾籌活動
針對surging,體系比較龐大，元件涵蓋比較多，需要4名人員一起完善surging中英文文件，然後經過大家商量進行眾籌，然後得到了大家熱烈響應，決定完成後，和參加者一起去雲南旅遊，不夠我自己補上費用，經過4天的募捐已經達到6478元，最近也邀請同事，朋友參加，已經有2名非常優秀的人員參加英文文件編寫，他們的英文非常好，可以和老外遠端會議，並且公司藏龍臥虎的人非常多，最近有小組成員去了芝加哥出差，對於我這個英語二把刀的人來說，完全是個互補。並且每個月1號會把貢獻者名單更新到github
總結
surging 還有很長的路要走，我會花很多時間在surging 維護和完善上，也請大家關注元旦1.0版本的釋出，QQ群還有神祕大禮哦！