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

來自： http://my.oschina.net/chejiangyi/blog/624765

一. 業務背景

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

二. 基礎服務架構說明

參考“大型電子商務架構說明”.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