一. 業務背景java
構建具有高可用,高擴展性,高性能,能承載高併發,大流量的分佈式電子商務平臺,支持用戶,訂單,採購,物流,配送,財務等多個項目的協做,便於後續運營報表,分析,便於運維及監控。mysql
二. 基礎服務架構說明linux
參考「大型電子商務架構說明」.docgit
(或http://my.oschina.net/chejiangyi/blog/521950)web
三. 基礎服務架構橫向演進架構圖redis
四. 基礎服務橫向演進架構概述sql
1. 分佈式任務調度平臺演進docker
(開源地址:http://git.oschina.net/chejiangyi/Dyd.BaseService.TaskManager博文:http://my.oschina.net/u/2379842/blog/484635)數據庫
分佈式任務調度平臺演進方向主要有兩個不一樣方向:分佈式任務資源調度平臺和分佈式任務流調度平臺,這個兩個方向最終會造成兩個不一樣的系統平臺。windows
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生態環境。