一位攝影程式員的獨白

       每個人都有愛好，都有釋放壓力的活動，而我也不例外，我除了每天上班，周末就會約一群好友去拍妹子，成家後，就改為拍蟲子，一拍就到了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群還有神秘大禮哦！