.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的源碼和基礎服務的源碼，兩者無縫結合起來，做到高流量時候自動的擴容及低流量時的自動縮容，做到資源的動態調配合。
（本說明基於當前公司的實際情況的部分架構簡要說明，未涉及工作流，搜索引擎，大數據挖掘等其他方面，僅作參考）
by 車江毅
