.Net 大型分散式基礎服務架構橫向演變概述

一. 業務背景

     構建具備高可用，高擴展性，高性能，能承載高併發，大流量的分散式電子商務平臺，支持用戶，訂單，採購，物流，配送，財務等多個項目的協作，便於後續運營報表，分析，便於運維及監控。

二. 基礎服務架構說明

參考“大型電子商務架構說明”.doc

（或http://my.oschina.net/chejiangyi/blog/521950）

三. 基礎服務架構橫向演進架構圖

四. 基礎服務橫向演進架構概述

1. 分散式任務調度平臺演進

   （開源地址:http://git.oschina.net/chejiangyi/Dyd.BaseService.TaskManager博文:http://my.oschina.net/u/2379842/blog/484635）

分散式任務調度平臺演進方向主要有兩個不同方向：分散式任務資源調度平臺和分散式任務流調度平臺，這個兩個方向最終會形成兩個不同的系統平臺。

   1）分散式任務資源調度平臺

    所 有操作系統都將安裝java/.net任務管理器服務（類似docker的管理節點），每個任務管理器裡面可以動態運行多個資源任務，所有java /.net服務或者任務都將視為基礎的資源任務(類似docker的容器概念)。此平臺用於整個公司業務基礎資源管理（類似docker的管理系統）。能 夠實現服務/任務的，負載均衡（網路，cpu，記憶體，流量），故障轉移，是整個彈性基礎服務管理平臺的基礎。

      使用場景：為了實現基礎服務的彈性調度和管理。未來所有業務服務或者後臺任務都以“任務”的形式存在，遇到高併發，大流量，硬體壓力，自動伸縮（自動擴展任務負載均衡到其他節點）來擴展容量和抗負載能力（在分散式彈性基礎服務管理平臺中配置管理）。

   2）分散式任務流調度平臺

    用於創建流程式任務，用於多任務之間的協作和運行。（類似創建辦公流程一樣的多協作形式的任務，並根據任務的執行結果進行流程的流轉。也可以入hadoop一樣分散式任務運行）

    使用場景：可以以此基礎實現類似風控系統（單個訂單進來，多個任務進行風險判斷的規則引擎，每個規則都是一個任務），大型的數據統計和抽取（可以實現map reduce之類的），分散式爬蟲任務（運行一個流程，創建多個子爬蟲任務不斷運行）。

2. 分散式配置中心平臺演進

   （開源地址: http://git.oschina.net/chejiangyi/Dyd.BaseService.ConfigManager博文:http://my.oschina.net/u/2379842/blog/533604）

分散式配置中心的演進方向主要會集成兩塊平臺：分散式集群高可用管理平臺和分散式服務降級保障平臺。當然基礎的分散式配置中心的功能將會保留，這兩個平臺的功能前期會集成入配置中心（後期發展到一定複雜度會從配置中心單獨剝離出來，但是又依賴基礎的配置中心）。

   1）分散式集群高可用管理平臺

    這是基於配置中心（也支持輪詢回調）的軟性負載均衡，故障檢測預警，故障轉移實現的統一管理和檢測平臺，與keepalive之類的軟體有些類似，會支持資料庫，網站，第三方軟體等。

   2）分散式服務降級保障平臺

    這是基於配置中心的服務、功能降級保障平臺，前期會進行降級配置的統一管理和人工手動降級（後期一般會根據服務的cpu，記憶體，流量，相應時間等狀況，自動進行降級，這時可以考慮單獨擴展成一個平臺）

3. 分散式監控平臺演進

   （開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.Monitor博文:http://my.oschina.net/u/2379842/blog/510655）

分 布式監控平臺演進方向主要是這幾塊的功能擴展：分散式資料庫監控平臺，分散式緩存監控平臺，分散式伺服器集群監控預警平臺，分散式業務監控平臺，分散式日 志監控分析預警平臺等。這幾塊的功能擴展，全部以插件架構形式集成入監控平臺。包括以後根據基礎服務和平臺演進的要求，越來越多的監控插件會集成入監控平 台，而非單純依賴第三方監控（任何一個高要求的大型網站，必須建立自身的監控體系）。

   1）分散式資料庫監控平臺

    收 集各種dba常規的sqlserver或mysql資料庫的信息彙總，用於分析問題語句，及問題語句自動預警，及一些自動化的索引建議，同時提供cpu， 記憶體，io，sql阻塞等情況的預警。（特別是大量資料庫分庫分表的情況下，需要集中優化與預警，及sql性能下降的提醒等）

   2）分散式緩存監控平臺

    可 以是單純的某種分散式緩存的監控，如redis，memcache，ssdb等。分散式緩存中間件平臺會在自身平臺中有監控數據，前期不集成到這裡。當然 開源社區也會有很多第三方的相關監控，但是如果想實現自身的一些特殊要求，比如統一的多維度預警就難以實現，特殊分析等，前期具體看情況而定，後期必定自 研一套。

   3）分散式伺服器集群監控平臺

    用於linux,windows的集群監控，根據配置支持多種操作系統指標的監控支持。操作系統級別的監控重要性就不必說了，也有很多第三方的相關監控工具，具體的也要看情況而定，但是涉及到預警這塊還是必須自研。

   4）分散式業務監控平臺

    用於業務級別的監控，如api,業務sql，一些業務方法調用頻率耗時，及類似百度站長工具的一些行為分析（這塊做的東西就很深入了，需要大數據分析）等。

   5）分散式日誌監控分析預警平臺

    用於彙集整個業務線，基礎服務平臺錯誤日誌分析及分等級預警，關鍵業務日誌列印分析等，這塊是監控平臺前期必須自研和統一的。

4. 分散式消息隊列演進

   （開源地址: http://git.oschina.net/chejiangyi/Dyd.BusinessMQ博文:http://my.oschina.net/u/2379842/blog/515860）

分散式消息隊列的演進主要是未來滿足公司對不同類型的消息隊列類型的穩定性及性能要求等（目前消息隊列相對成熟），主要有幾方面擴展：

   1） 支持push方式的消息推送。

   2） 插件化剝離底層消息存儲的單一依賴，支持多種存儲擴展（記憶體，文件，資料庫）等。

   3） 外圍介面相容actviemq，rabbitmq等多種消息存儲及形式。

   4） 支持消息的事務化消費（多方業務訂閱消費，一方消費失敗則所有消費回滾，否則消息消費出錯）

   5） 消息的服務化（broker），支持http，thrift協議等，便於跨語言使用。

   6)  彈性消費能力和彈性擴容等支持。

5. 分散式緩存平臺演進

（開源地址:http://git.oschina.net/chejiangyi/XXF.BaseService.DistributedCache博文:http://my.oschina.net/chejiangyi/blog/595038）  

目前分散式緩存做的很簡單，只是簡單的一個sdk代理機制。未來分散式緩存平臺演進方向主要有以下幾點：

   1） 以redis協議為模板，支持多種緩存存儲介質。

   2） 支持一致性（環形）等多種hash分片方式。

   3） 強大的監控及管理平臺。

   4） 支持緩存的桶遷移，支持緩存的主備（從），故障轉移，負載均衡等。

   5） 緩存的服務化（proxy），支持http，thrift協議等，便於跨語言使用。

6)  彈性緩存擴容等支持。

6. 分散式服務中心平臺演進

   （暫未開源,開源計劃中）

分散式服務中心平臺要保持輕量級和高性能，未來演進方嚮應該包含以下幾點：

   1）支持多種服務通信協議（thrift，自定義協議）。

   2）支持tcp和http。

   3）支持服務負載均衡和故障轉移。

   4）強大的監控管理平臺（耗時，連接數，cpu等性能，調用鏈，熔斷機制，服務文檔等）

5）彈性服務抗壓支持。

7. 分散式web版本發佈管理平臺

   分散式web版本發佈管理平臺主要包含以下兩塊內容：

   1.用於公司項目web的統一版本控制，負載均衡節點統一發佈和回滾。

   2.未來公司手機h5頁面版本控制和版本管理。

8. 分散式資料庫管理平臺

   分散式資料庫管理平臺主要包含兩塊內容：分散式資料庫中間件平臺，分散式資料庫運維平臺。

    1）分散式資料庫中間件平臺    

主要集成資料庫中間件功能，如分庫分表sharding機制，sql攔截監控，sql耗時分析，優化建議等，類似tddl及mycat，細節不再贅述。

2）分散式資料庫運維平臺

分散式資料庫集群的監控及運維管理功能，分散式資料庫遷移功能，資料庫運維工具，腳本及運維日誌等。

9. 分散式彈性基礎服務管理平臺

   分散式彈性基礎服務管理平臺除了包含自身平臺外，還包含分散式高併發作戰平臺。

   1）分散式高併發作戰平臺

    用於搶購，秒殺時的一個作戰平臺，該平臺將所有基礎服務的外圍核心監控，服務升降級配置，手工擴容等相關配置項目快捷的，整合一起為多級降級方案。

   2）分散式彈性基礎服務管理平臺

    用於結合分散式任務資源管理平臺，分散式監控，分散式消息隊列，分散式服務中心，分散式配置中心等所有基礎平臺的可控制基礎服務及業務服務/任務自動彈性伸縮，故障恢復的配置，管理，監控平臺。

    使用場景：

    1）某個業務服務突然間流量超過閥值，通過分散式任務資源管理平臺，將服務擴展到1/n台負載均衡服務，當流量低於某個閥值時自動回收服務。

    2）當某個業務的消息量大量堆積，通過分散式任務資源管理平臺，增加業務消息消費任務負載均衡，當消息堆積量低於某個閥值時回收任務。

    3）當某個後臺任務的突然死掉，通過分散式任務資源管理平臺，在另外一臺伺服器上嘗試重啟任務。

10. 概述總結

    以 上基礎服務演變的概述比較粗糙，但是大致能夠表明未來演變的核心方向和功能，這也是根據自身平臺業務不同，方向不同形成的不同於常規開源解決方案的演變方 向。當然糾結於細節實現的時候，也會比文中所述更加繁瑣，功能更多，性能和實現要求更高，更偏向於輕量級和業務適應性。

五. 基礎服務自主研發戰略

   在 網站研發處於前期或者創業未盈利階段，可以考慮大量使用第三方的開源框架，以佈局整體架構，及考慮架構的完整性和擴展性。雖然如此，但凡大型網站或者網站 涉及到高併發，大流量的壓力，核心的基礎服務的基礎設施必須全部或者部分自研。因為這種性能要求極高的網站，必須對各個細節的把控和要求都很嚴格，對基礎 服務的性能，質量要求也極高，採用一些完善的第三方開源框架反而可能是種累贅（如redis,leveldb等輕量級的除外）。而且未來基礎服務的統一監 控，彈性伸縮，及與雲計算的層面的自主伸縮性契合都需要修改部分核心代碼實現。如果採用第三方框架，必須對這些代碼非常瞭解後修改，同時還要不斷的跟開源 社區版本保持分支一致。一般第三方開源框架往往是集大成的常規解決方案，更加通用化，而我們業務往往只需要一部分功能的輕量級解決方案足矣，性能更高。

    故而從短期看基礎服務使用第三方可以快速的部署架構，從長期看基礎服務未來必定需要改進或者自主研發。而且研發基礎服務的技術難度，在後期做彈性基礎服務和雲計算平臺時來說其實不算什麼，反而是更好的技術沉澱和基石。（目前淘寶，京東，美團，蘑菇街，大眾點評，噹噹網，窩窩團，58同城等都採取部分或者全部自研基礎服務的方式。）

六. 基礎服務開源戰略

    公 司的競爭一般在於商業本質的競爭，而非在於技術的競爭。故開源基礎服務對於公司來說，若能形成開源生態圈，則可以促進開源項目穩定性，優化開源代碼，根據 反饋不斷的提升自身的基礎服務產品，吸引相關的高級技術人才維護檢驗項目，減少項目的開發維護成本，同時提升公司在技術領域的影響力，提升開發人員的成就 感。（目前淘寶，噹噹網，58同城等都有部分項目開源）

1）開源成長路線：

路 線1:下載開源源碼->學習開源項目->成功部署項目（根據開源文檔或者QQ群項目管理員協助）->成為QQ群相關項目管理員 ->瞭解並解決日常開源項目問題->總結並整理開源項目文檔並分享給大家或推廣->成為git項目的開發者和參與者

路線2:下載開源源碼->學習開源項目->成功部署項目（根據開源文檔或者QQ群項目管理員協助）->在實際使用中發現bug並提交bug給項目相關管理員

路線3:下載開源源碼->學習開源項目->成功部署項目（根據開源文檔或者QQ群項目管理員協助）->自行建立開源項目分支->提交分支新功能給項目官方開發人員->官方開發人員根據項目情況合併新功能併發布新版本

2）關於開源生態圈的構想

生態閉環：官方開源項目->第三方參與學習->第三方改進並提交新功能或bug->官方合併新功能或bug->官方發佈新版本

為什麼開源? .net 開源生態本身弱,而強大是你與我不斷學習，點滴分享,相互協助，共同營造良好的.net生態環境。

開源理念: 開源是一種態度，分享是一種精神，學習仍需堅持，進步仍需努力，.net生態圈因你我更加美好

by 車江毅

 (僅根據實際業務所設想的基礎服務演變方向，不包含分散式存儲，搜索引擎，大數據等，歡迎交流)

  開源QQ群: .net 開源基礎服務  238543768