迎元旦，慶surging 1.0發佈

一位攝影程序員的獨白

       每一個人都有愛好，都有釋放壓力的活動，而我也不例外，我除了天天上班，週末就會約一羣好友去拍妹子，成家後，就改成拍蟲子，一拍就到了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、通訊組件

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的文件服務

2、編解碼組件

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進行實現

3、日誌組件

1.Nlog

針對於Critical，Debug，Trace，Error，Information，Warning級別的日誌能夠經過Nlog組件進行實現，而且能夠寫入到Console，file，database

2.log4net

針對於Critical，Debug，Trace，Error，Information，Warning級別的日誌能夠經過log4net組件進行實現，而且能夠寫入到Console，file，database

4、註冊中心

1. consul

針對於MqttServiceRoute、ServiceCache、ServiceCommand、ServiceRoute採用了consul的Key/Value 進行存儲，而且更新是採用了心跳進行更新

2. zookeeper

針對於MqttServiceRoute、ServiceCache、ServiceCommand、ServiceRoute採用了zookeeper指定path進行node 儲存，而且更新是採用了watcher進行更新

5、隊列

1. rabbitmq

針對於消息隊列rabbitmq 實現了消息的重試，失敗回滾，消息的延遲處理，目前只實現了direct

2. kafka

實現了針對於topic 進行發佈訂閱。

6、緩存

1.MemoryCache

由surging 的Caching組件提供的內存緩存，使用該類型能夠方便的在程序內部緩存數據並對於數據的有效性進行方便的管理

2.Redis

針對於redis 緩存實現了哈希一致性，而且配有健康檢查，對於超過6次不健康的服務會從哈希節點移除。目前只實現了key-value

七：動態代理

1.ProxyGenerator

針對動態代理是經過Roslyn構建腳原本生成編譯AOP動態代理，以提供經過接口建立代理方式訪問。

負載均衡

1、容錯策略

 

1. 隨機（Random）：

經過生成隨機數隨機選擇服務地址，調用量越大分佈越均勻

2. 輪詢（Polling）

經過輪詢地址選擇服務地址，存在比較慢的機器容易在這臺機器的請求阻塞較多，默認使用此負載算法

3.哈希一致性（HashAlgorithm）

經過第一個參數生成的哈希值進行哈希一致性選取服務地址，對於第一個相同參數的值的請求會定位到同一個服務提供者上

4.壓力最小優先（FairPolling）

經過輪詢優先選擇壓力最小的服務地址，針對於壓力比較小的服務器會分配更多的請求。

 

服務容錯和熔斷

1、容錯策略

1.故障轉移策略(Failover):

經過設置故障轉移羣集數(FailoverCluster),從而服務故障自動轉移到健康的服務提供者

2.腳本注入策略(Injection):

經過設置腳本注入（Injection）,服務發生錯誤時會返回所定義運行的腳本結果

3.回退策略(FallBack)

經過設置回退的實例名（FallbackName）,服務發生錯誤時經過FallBackName去調用依賴注入的接口IFallbackInvoker

2、熔斷

1.錯誤率熔斷

經過設置錯誤率（BreakeErrorThresholdPercentage）,當失敗調用數/遠程調用數大於錯誤率，會啓用熔斷

2.超時熔斷

經過設置執行超時時間（ExecutionTimeoutInMilliseconds）,當服務調用超過執行時間會啓用熔斷

3.併發熔斷

經過設置信號量最大併發度（MaxConcurrentRequests）,在多線程環境下超過設置的信號量，會啓用熔斷

4.錯誤數熔斷

經過設置調用失敗的錯誤數（BreakerRequestVolumeThreshold）,在10秒鐘範圍內超過設置的調用失敗錯誤數，會啓用熔斷

衆籌活動

針對surging,體系比較龐大，組件涵蓋比較多，須要4名人員一塊兒完善surging中英文文檔，而後通過你們商量進行衆籌，而後獲得了你們熱烈響應，決定完成後，和參加者一塊兒去雲南旅遊，不夠我本身補上費用，通過4天的募捐已經達到6478元，最近也邀請同事，朋友參加，已經有2名很是優秀的人員參加英文文檔編寫，他們的英文很是好，能夠和老外遠程會議，而且公司藏龍臥虎的人很是多，最近有小組成員去了芝加哥出差，對於我這個英語二把刀的人來講，徹底是個互補。而且每月1號會把貢獻者名單更新到github

總結

surging 還有很長的路要走，我會花不少時間在surging 維護和完善上，也請你們關注元旦1.0版本的發佈，QQ羣還有神祕大禮哦！