一. 業務背景

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

二. 基礎服務架構說明

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

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

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

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

1. 分散式任務排程平臺演進

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

   1）分散式任務資源排程平臺

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

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

   2）分散式任務流排程平臺

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

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

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

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

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

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

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

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

3. 分散式監控平臺演進

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

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

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

   2）分散式快取監控平臺

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

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

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

   4）分散式業務監控平臺

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

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

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

4. 分散式訊息佇列演進

分散式訊息佇列的演進主要是未來滿足公司對不同型別的訊息佇列型別的穩定性及效能要求等（目前訊息佇列相對成熟），主要有幾方面擴充套件：

   1） 支援push方式的訊息推送。

   2） 外掛化剝離底層訊息儲存的單一依賴，支援多種儲存擴充套件（記憶體，檔案，資料庫）等。

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

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

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

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

5. 分散式快取平臺演進

目前分散式快取做的很簡單，只是簡單的一個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生態環境。