.net 大型分佈式電子商務架構說明

 

背景

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

 

架構演變

         基礎框架剝離 -> 分庫分表 -> 基礎服務建設 -> 私有云建設 ->分佈式操做系統

 

基礎框架

         整個公司不管有多少項目，須要沉澱最基礎的框架，裏面通常包含核心的分庫分表規則，統一的數據庫操做類庫，統一的通信類，統一的日誌類，統一的加密算法，統一的基礎服務sdk，公用的一些工具類等等。該框架用於定義最基礎的公司架構，設計，統一最基礎的技術及項目架構規範，攔截及監控最基礎的核心調用等。框架命名通常比較簡單，如京東，能夠定義爲jdf；淘寶，能夠定義爲tbf。

 

分庫分表

         分庫分表爲最常規的架構拆分方案。通常會從業務角度進行不一樣視角的拆分，如用戶視角和商戶視角。固然前提也須要業務方面或者其餘技術力量的支持，不出現或者解決拆分後跨多個分庫或者分表的表查詢及查詢結果合併問題。分庫分表前也經過須要預估容量，預估性能。分庫分表也常常會遇到全局id，或者分佈式id自增且惟一的問題，這些都要預先在設計和架構層面要充分考慮。

用戶視角如圖所示

商戶視角如圖所示

 

基礎服務

         基礎服務是系統分佈式的一個核心。它每每與操做系統基礎組件相對應,只不過它是分佈式的。如基礎服務通常包含分佈式存儲，分佈式緩存，分佈式計算，分佈式消息，分佈式服務，分佈式任務調度，分佈式監控等。對應於操做系統的磁盤，內存，cpu，跨進行消息，進程，計劃任務，系統監控等。

         公司的基礎服務暫時包含幾塊: 分佈式緩存,業務消息隊列，任務調度，監控平臺，服務中心，分佈式鎖服務，配置中心。

基礎服務如圖所示

 

         分佈式緩存（暫未開源）

         目前主要是解決核心幾個頁面的緩存問題，好比首頁和列表頁等，從而解決高頻繁下頻繁查詢數據庫的問題。通常來講緩存的內容越細越好，這樣緩存的內容會比較多，對數據庫的性能優化效果天然很佳。可是緩存越細，則關於緩存的清理工做就越細緻，很容易代碼編寫過程當中忘記清理緩存的狀況，影響面和用戶體驗會很糟糕。

這種狀況可能有兩種方式解決，一種是架構上已經達到服務化和模塊化層面，每一個模塊只處理自身相關的緩存。如用戶服務，訂單服務，商戶服務，商品服務等，僅處理自身相關的緩存。那麼緩存足夠細，固然代碼處理也能更加細緻。另一種是數據庫或者其餘層面的修改回調，批量清除相關的緩存；由於粒度很粗，可是可能會出現大量可用緩存被清理，形成部分雪崩效應。

因此咱們常常會認爲使用緩存很容易，可是用好緩存須要的是根據業務需求和許可設計緩存結構，儘可能用好緩存，達到理想的性能；又或者咱們只使用少許粗粒度的緩存，定義好緩存失效時間，部分代碼清理部分緩存的方式來，這樣能保證熱點頁面的較高性能; 可是這種狀況下咱們依然要注意緩存項不能太多，代碼規範管理。

同時咱們注意到業務的緩存會有一些特色，有些緩存具有高熱點特性，有些緩存具有瞬間熱點特性，有些緩存能夠丟失，有些緩存儘可能保證不丟失（不然可能形成雪崩效應）。故咱們要根據實際業務不一樣，採用不一樣的存儲介質。好比redis，memcache，ssdb等，應用場景都略微不一樣。而作爲公司級的緩存中間件，應該適當的屏蔽這些存儲特性，最好能夠作到無縫配置，同時具有負載均衡，性能監控等等。

 

         業務消息隊列（開源地址: http://git.oschina.net/chejiangyi/Dyd.BusinessMQ 博文:http://my.oschina.net/u/2379842/blog/515860）

         主要是解決業務間的高可靠性消息傳遞，及功能的異步化處理。這種消息隊列必須有如下幾點：承載高併發，業務消息不容許丟失，業務消息必須能支撐超大量的堆積而穩定，支持消息的回溯。通常公司可能會考慮企業服務總線（esb），可是針對電子商務瞬間高併發和大量消息堆積的需求，可能不太合適，並且esb包含的東西不少，屬於重量級的解決方案，更適合通常企業項目，如企業的內部管理系統。固然一些公司可能也會使用activemq，rabbitmq，kafka，metaq，tbnotify等等，具體的會根據使用場景和實際業務需求選擇。好比一些內存的消息中間件，不支持持久化，不支持消息堆積，不支持消息回溯，其實不適合當前公司的業務場景，故而放棄或者部分場景使用。

 

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

         主要是解決業務的後端任務掛載，隔離，定時調度，任務出錯報警等。將來能夠作到父子任務的關聯，任務資源的自動分配和協調，任務的故障轉移和均衡。那麼網絡爬蟲，報表分析，彈性計算等資源型任務就能夠適用了。

 

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

         每一個公司對監控的需求其實都不同，通常會根據業務不一樣，根據架構不一樣，根據基礎服務不一樣，會不一樣程度的抓取和集成一些性能指標，業務日誌，錯誤日誌，耗時性能，流量等等至監控平臺。市面上有不少大而全的監控平臺，其實也都提供了sdk作二次開發，目的也在於此。

畢竟業務不一樣，服務器環境不一樣，架構基礎設施不一樣，天然關注的性能點和指標參數也都不同，故從長遠發展，監控平臺對整個分佈式系統的穩定性是具有關鍵性做用。大型的分佈式電子商務系統，監控平臺自己就是大量系統性能分析師的分析思路，分析技巧的總結和沉澱。固然中小型的企業，能夠直接使用第三方監控工具，可是性能分析每每是過後的，非及時性的；又或者第三方的監控工具不少，卻沒有有效的整合在一塊兒，真正分析性能的時候卻一片茫然。又或者大型項目單個操做涉及的系統或服務不少，須要拿到分佈式的調用堆棧和調用鏈…. 種種這些都不免須要公司沉澱本身的監控平臺。

 

服務中心（暫未開源）

主要是解決多個項目之間的同步調用，項目的公用api下沉，及遠程調用服務的負載均衡，性能監控，預警等等。當前其本質上是服務的管理，公開，協調，運維等，知足業務soa的架構設計。特別是將來對業務細化拆分，模塊化，同步解耦起關鍵做用,相似淘寶的HSF。

 

分佈式鎖（開源地址:http://git.oschina.net/chejiangyi/XXF.BaseService.DistributedLock 博文:http://my.oschina.net/u/2379842/blog/511291）

分佈式鎖服務的應用即使在大型業務項目中都不該該常用，特別是對性能要求較高的功能，不建議使用或謹慎使用。任何使用分佈式鎖的功能建議進行codereview和使用論證。理論上分佈式鎖經常使用於基礎設施服務的分佈式協調，可是一些業務對一致性要求較高，特別對瞬間併發致使相同業務同時執行的要求特別高，須要採用分佈式鎖，不然不採用。

 

配置中心（暫未開源）

主要是解決多項目之間的配置聚合及統一管理，同時具有配置的及時更新。若集成任務調度服務能夠作到配置的負載均衡和配置的故障轉移等。爲何要解決公司的項目配置？公司項目從頁面前端，採購，物流，配送，財務，b2b等具備多個項目，多個項目各自一樣具備多個服務，多個後臺任務，這些程序都互相獨立，且部分須要負載均衡（將來數量將達到上千個數量）可是又常常須要公用同一套配置體系。若每一個程序都配置同一個配置信息，那麼將來作某個配置信息的遷移或者更新，運維和開發人員根本不知道哪裏須要更新。故配置的彙集管理在大型項目中是很是有必要的。並且基於配置中心也能夠實現熱切換，自動故障轉移，軟性負載等分佈式的服務管理能力。

 

以上這些僅僅是目前公司根據業務發展須要使用的一些基礎服務，固然不少公司也會根據自身的業務需求使用分佈式存儲，分佈式搜索引擎等，也會根據自身對基礎服務的可靠性要求，穩定性要求選擇不一樣的開源基礎服務框架進行改造，或者直接使用或者二次封裝。從架構師的視角，針對業務發展，要謹慎選擇，又要謹慎考慮是否須要重複造輪子。

文中介紹的相關基礎服務可加入開源QQ羣: .net開源基礎服務,238543768 一塊兒交流心得。

 

私有云、混合雲建設

         不少創業公司初期，特別是電子商務類型的公司，能夠會優先考慮第三方雲計算平臺來搭建整個平臺和架構，天然更多的多是基於成本，資源，人手方面考慮。可是當公司發展到必定程度，創建本身的機房多是很是必要的選擇。我的認爲雲計算的服務器（ecs）達到60-100臺集羣的時候，考慮搭建公司的機房已經很是有必要了，而當機房的物理機器達到20臺的時候，可能也須要考慮放棄單純的kvm，轉而使用openstack及配合使用docker，container等容器技術會更加合適。

         公司對私有云的建設主要是偏重於物理機的資源合理利用，及私有云的有效，靈活管理，甚至必要的狀況下，修改openstack的源代碼，配合前端的流量和壓力狀況進行擴容和縮容，更加深層次的自動的負載均衡和自動的故障切換等等。

 

分佈式操做系統

         分佈式操做系統自己是一種概念思想的，自己未必具體的如何作的執行步驟。我的認爲它更偏向於在雲計算平臺搭建後的資源更加有效整合，及平臺在解決業務能力的穩定性和擴展能力；從架構師的視角看，也許更多的站在更高的層次全局的俯視整個平臺架構，一個總體的電子商務的分佈式操做系統和解決方案，而非僅僅是雲計算平臺。在這個階段咱們能夠嘗試修改openstack的源碼和基礎服務的源碼，二者無縫結合起來，作到高流量時候自動的擴容及低流量時的自動縮容，作到資源的動態調配合。

 

（本說明基於當前公司的實際狀況的部分架構簡要說明，未涉及工做流，搜索引擎，大數據挖掘等其餘方面，僅做參考）

 

本文轉自車江毅：http://my.oschina.net/u/2379842/blog/521950