背景

構(gòu)建具備高可用，高擴(kuò)展性，高性能，能承載高并發(fā)，大流量的分布式電子商務(wù)平臺(tái)，支持用戶，訂單，采購(gòu)，物流，配送，財(cái)務(wù)等多個(gè)項(xiàng)目的協(xié)作，便于后續(xù)運(yùn)營(yíng)報(bào)表，分析，便于運(yùn)維及監(jiān)控。

?

架構(gòu)演變

?????????基礎(chǔ)框架剝離?->?分庫分表?->?基礎(chǔ)服務(wù)建設(shè)?->?私有云建設(shè)?->分布式操作系統(tǒng)

?

基礎(chǔ)框架

?????????整個(gè)公司無論有多少項(xiàng)目，需要沉淀最基礎(chǔ)的框架，里面一般包含核心的分庫分表規(guī)則，統(tǒng)一的數(shù)據(jù)庫操作類庫，統(tǒng)一的通訊類，統(tǒng)一的日志類，統(tǒng)一的加密算法，統(tǒng)一的基礎(chǔ)服務(wù)sdk，公用的一些工具類等等。該框架用于定義最基礎(chǔ)的公司架構(gòu)，設(shè)計(jì)，統(tǒng)一最基礎(chǔ)的技術(shù)及項(xiàng)目架構(gòu)規(guī)范，攔截及監(jiān)控最基礎(chǔ)的核心調(diào)用等。框架命名一般比較簡(jiǎn)單，如京東，可以定義為jdf；淘寶，可以定義為tbf。

?

分庫分表

?????????分庫分表為最常規(guī)的架構(gòu)拆分方案。一般會(huì)從業(yè)務(wù)角度進(jìn)行不同視角的拆分，如用戶視角和商戶視角。當(dāng)然前提也需要業(yè)務(wù)方面或者其他技術(shù)力量的支持，不出現(xiàn)或者解決拆分后跨多個(gè)分庫或者分表的表查詢及查詢結(jié)果合并問題。分庫分表前也通過需要預(yù)估容量，預(yù)估性能。分庫分表也經(jīng)常會(huì)遇到全局id，或者分布式id自增且唯一的問題，這些都要預(yù)先在設(shè)計(jì)和架構(gòu)層面要充分考慮。

用戶視角如圖所示

商戶視角如圖所示

?

基礎(chǔ)服務(wù)

?????????基礎(chǔ)服務(wù)是系統(tǒng)分布式的一個(gè)核心。它往往與操作系統(tǒng)基礎(chǔ)組件相對(duì)應(yīng),只不過它是分布式的。如基礎(chǔ)服務(wù)一般包含分布式存儲(chǔ)，分布式緩存，分布式計(jì)算，分布式消息，分布式服務(wù)，分布式任務(wù)調(diào)度，分布式監(jiān)控等。對(duì)應(yīng)于操作系統(tǒng)的磁盤，內(nèi)存，cpu，跨進(jìn)行消息，進(jìn)程，計(jì)劃任務(wù)，系統(tǒng)監(jiān)控等。

?????????公司的基礎(chǔ)服務(wù)暫時(shí)包含幾塊:?分布式緩存,業(yè)務(wù)消息隊(duì)列，任務(wù)調(diào)度，監(jiān)控平臺(tái)，服務(wù)中心，分布式鎖服務(wù)，配置中心。

基礎(chǔ)服務(wù)如圖所示

?

?????????分布式緩存（暫未開源）

?????????目前主要是解決核心幾個(gè)頁面的緩存問題，比如首頁和列表頁等，從而解決高頻繁下頻繁查詢數(shù)據(jù)庫的問題。一般來說緩存的內(nèi)容越細(xì)越好，這樣緩存的內(nèi)容會(huì)比較多，對(duì)數(shù)據(jù)庫的性能優(yōu)化效果自然很佳。但是緩存越細(xì)，則關(guān)于緩存的清理工作就越細(xì)致，很容易代碼編寫過程中忘記清理緩存的情況，影響面和用戶體驗(yàn)會(huì)很糟糕。

這種情況可能有兩種方式解決，一種是架構(gòu)上已經(jīng)達(dá)到服務(wù)化和模塊化層面，每個(gè)模塊只處理自身相關(guān)的緩存。如用戶服務(wù)，訂單服務(wù)，商戶服務(wù)，商品服務(wù)等，僅處理自身相關(guān)的緩存。那么緩存足夠細(xì)，當(dāng)然代碼處理也能更加細(xì)致。另外一種是數(shù)據(jù)庫或者其他層面的修改回調(diào)，批量清除相關(guān)的緩存；因?yàn)榱６群艽?#xff0c;但是可能會(huì)出現(xiàn)大量可用緩存被清理，造成部分雪崩效應(yīng)。

所以我們經(jīng)常會(huì)認(rèn)為使用緩存很容易，但是用好緩存需要的是根據(jù)業(yè)務(wù)需求和許可設(shè)計(jì)緩存結(jié)構(gòu)，盡量用好緩存，達(dá)到理想的性能；又或者我們只使用少量粗粒度的緩存，定義好緩存失效時(shí)間，部分代碼清理部分緩存的方式來，這樣能保證熱點(diǎn)頁面的較高性能;?但是這種情況下我們依然要注意緩存項(xiàng)不能太多，代碼規(guī)范管理。

同時(shí)我們注意到業(yè)務(wù)的緩存會(huì)有一些特點(diǎn)，有些緩存具備高熱點(diǎn)特性，有些緩存具備瞬間熱點(diǎn)特性，有些緩存可以丟失，有些緩存盡量保證不丟失（否則可能造成雪崩效應(yīng)）。故我們要根據(jù)實(shí)際業(yè)務(wù)不同，采用不同的存儲(chǔ)介質(zhì)。比如redis，memcache，ssdb等，應(yīng)用場(chǎng)景都略微不同。而做為公司級(jí)的緩存中間件，應(yīng)該適當(dāng)?shù)钠帘芜@些存儲(chǔ)特性，最好可以做到無縫配置，同時(shí)具備負(fù)載均衡，性能監(jiān)控等等。

?

?????????業(yè)務(wù)消息隊(duì)列（開源地址:?http://git.oschina.net/chejiangyi/Dyd.BusinessMQ?博文:http://my.oschina.net/u/2379842/blog/515860）

?????????主要是解決業(yè)務(wù)間的高可靠性消息傳遞，及功能的異步化處理。這種消息隊(duì)列必須有以下幾點(diǎn)：承載高并發(fā)，業(yè)務(wù)消息不允許丟失，業(yè)務(wù)消息必須能支撐超大量的堆積而穩(wěn)定，支持消息的回溯。一般公司可能會(huì)考慮企業(yè)服務(wù)總線（esb），但是針對(duì)電子商務(wù)瞬間高并發(fā)和大量消息堆積的需求，可能不太合適，而且esb包含的東西很多，屬于重量級(jí)的解決方案，更適合一般企業(yè)項(xiàng)目，如企業(yè)的內(nèi)部管理系統(tǒng)。當(dāng)然一些公司可能也會(huì)使用activemq，rabbitmq，kafka，metaq，tbnotify等等，具體的會(huì)根據(jù)使用場(chǎng)景和實(shí)際業(yè)務(wù)需求選擇。比如一些內(nèi)存的消息中間件，不支持持久化，不支持消息堆積，不支持消息回溯，其實(shí)不適合當(dāng)前公司的業(yè)務(wù)場(chǎng)景，故而放棄或者部分場(chǎng)景使用。

?

?????????任務(wù)調(diào)度平臺(tái)（開源地址:http://git.oschina.net/chejiangyi/Dyd.BaseService.TaskManager?博文:http://my.oschina.net/u/2379842/blog/484635）

?????????主要是解決業(yè)務(wù)的后端任務(wù)掛載，隔離，定時(shí)調(diào)度，任務(wù)出錯(cuò)報(bào)警等。未來可以做到父子任務(wù)的關(guān)聯(lián)，任務(wù)資源的自動(dòng)分配和協(xié)調(diào)，任務(wù)的故障轉(zhuǎn)移和均衡。那么網(wǎng)絡(luò)爬蟲，報(bào)表分析，彈性計(jì)算等資源型任務(wù)就可以適用了。

?

?????????統(tǒng)一監(jiān)控平臺(tái)（開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.Monitor?博文:http://my.oschina.net/u/2379842/blog/510655）

?????????每個(gè)公司對(duì)監(jiān)控的需求其實(shí)都不一樣，一般會(huì)根據(jù)業(yè)務(wù)不同，根據(jù)架構(gòu)不同，根據(jù)基礎(chǔ)服務(wù)不同，會(huì)不同程度的抓取和集成一些性能指標(biāo)，業(yè)務(wù)日志，錯(cuò)誤日志，耗時(shí)性能，流量等等至監(jiān)控平臺(tái)。市面上有很多大而全的監(jiān)控平臺(tái)，其實(shí)也都提供了sdk做二次開發(fā)，目的也在于此。

畢竟業(yè)務(wù)不同，服務(wù)器環(huán)境不同，架構(gòu)基礎(chǔ)設(shè)施不同，自然關(guān)注的性能點(diǎn)和指標(biāo)參數(shù)也都不一樣，故從長(zhǎng)遠(yuǎn)發(fā)展，監(jiān)控平臺(tái)對(duì)整個(gè)分布式系統(tǒng)的穩(wěn)定性是具備關(guān)鍵性作用。大型的分布式電子商務(wù)系統(tǒng)，監(jiān)控平臺(tái)本身就是大量系統(tǒng)性能分析師的分析思路，分析技巧的總結(jié)和沉淀。當(dāng)然中小型的企業(yè)，可以直接使用第三方監(jiān)控工具，但是性能分析往往是事后的，非及時(shí)性的；又或者第三方的監(jiān)控工具很多，卻沒有有效的整合在一起，真正分析性能的時(shí)候卻一片茫然。又或者大型項(xiàng)目單個(gè)操作涉及的系統(tǒng)或服務(wù)很多，需要拿到分布式的調(diào)用堆棧和調(diào)用鏈….?種種這些都難免需要公司沉淀自己的監(jiān)控平臺(tái)。

?

服務(wù)中心（暫未開源）

主要是解決多個(gè)項(xiàng)目之間的同步調(diào)用，項(xiàng)目的公用api下沉，及遠(yuǎn)程調(diào)用服務(wù)的負(fù)載均衡，性能監(jiān)控，預(yù)警等等。當(dāng)前其本質(zhì)上是服務(wù)的管理，公開，協(xié)調(diào)，運(yùn)維等，滿足業(yè)務(wù)soa的架構(gòu)設(shè)計(jì)。特別是未來對(duì)業(yè)務(wù)細(xì)化拆分，模塊化，同步解耦起關(guān)鍵作用,類似淘寶的HSF。

?

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

分布式鎖服務(wù)的應(yīng)用即便在大型業(yè)務(wù)項(xiàng)目中都不應(yīng)該經(jīng)常使用，特別是對(duì)性能要求較高的功能，不建議使用或謹(jǐn)慎使用。任何使用分布式鎖的功能建議進(jìn)行codereview和使用論證。理論上分布式鎖常用于基礎(chǔ)設(shè)施服務(wù)的分布式協(xié)調(diào)，但是一些業(yè)務(wù)對(duì)一致性要求較高，特別對(duì)瞬間并發(fā)導(dǎo)致相同業(yè)務(wù)同時(shí)執(zhí)行的要求特別高，需要采用分布式鎖，否則不采用。

?

配置中心（暫未開源）

主要是解決多項(xiàng)目之間的配置聚合及統(tǒng)一管理，同時(shí)具備配置的及時(shí)更新。若集成任務(wù)調(diào)度服務(wù)可以做到配置的負(fù)載均衡和配置的故障轉(zhuǎn)移等。為什么要解決公司的項(xiàng)目配置？公司項(xiàng)目從頁面前端，采購(gòu)，物流，配送，財(cái)務(wù)，b2b等具有多個(gè)項(xiàng)目，多個(gè)項(xiàng)目各自同樣具有多個(gè)服務(wù)，多個(gè)后臺(tái)任務(wù)，這些程序都互相獨(dú)立，且部分需要負(fù)載均衡（未來數(shù)量將達(dá)到上千個(gè)數(shù)量）但是又經(jīng)常需要公用同一套配置體系。若每個(gè)程序都配置同一個(gè)配置信息，那么未來做某個(gè)配置信息的遷移或者更新，運(yùn)維和開發(fā)人員根本不知道哪里需要更新。故配置的聚集管理在大型項(xiàng)目中是非常有必要的。而且基于配置中心也可以實(shí)現(xiàn)熱切換，自動(dòng)故障轉(zhuǎn)移，軟性負(fù)載等分布式的服務(wù)管理能力。

?

以上這些僅僅是目前公司根據(jù)業(yè)務(wù)發(fā)展需要使用的一些基礎(chǔ)服務(wù)，當(dāng)然很多公司也會(huì)根據(jù)自身的業(yè)務(wù)需求使用分布式存儲(chǔ)，分布式搜索引擎等，也會(huì)根據(jù)自身對(duì)基礎(chǔ)服務(wù)的可靠性要求，穩(wěn)定性要求選擇不同的開源基礎(chǔ)服務(wù)框架進(jìn)行改造，或者直接使用或者二次封裝。從架構(gòu)師的視角，針對(duì)業(yè)務(wù)發(fā)展，要謹(jǐn)慎選擇，又要謹(jǐn)慎考慮是否需要重復(fù)造輪子。

文中介紹的相關(guān)基礎(chǔ)服務(wù)可加入開源QQ群:?.net開源基礎(chǔ)服務(wù),238543768?一起交流心得。

?

私有云、混合云建設(shè)

?????????很多創(chuàng)業(yè)公司初期，特別是電子商務(wù)類型的公司，可以會(huì)優(yōu)先考慮第三方云計(jì)算平臺(tái)來搭建整個(gè)平臺(tái)和架構(gòu)，自然更多的可能是基于成本，資源，人手方面考慮。但是當(dāng)公司發(fā)展到一定程度，建立自己的機(jī)房可能是非常必要的選擇。個(gè)人認(rèn)為云計(jì)算的服務(wù)器（ecs）達(dá)到60-100臺(tái)集群的時(shí)候，考慮搭建公司的機(jī)房已經(jīng)非常有必要了，而當(dāng)機(jī)房的物理機(jī)器達(dá)到20臺(tái)的時(shí)候，可能也需要考慮放棄單純的kvm，轉(zhuǎn)而使用openstack及配合使用docker，container等容器技術(shù)會(huì)更加合適。

?????????公司對(duì)私有云的建設(shè)主要是偏重于物理機(jī)的資源合理利用，及私有云的有效，靈活管理，甚至必要的情況下，修改openstack的源代碼，配合前端的流量和壓力情況進(jìn)行擴(kuò)容和縮容，更加深層次的自動(dòng)的負(fù)載均衡和自動(dòng)的故障切換等等。

?

分布式操作系統(tǒng)

?????????分布式操作系統(tǒng)本身是一種概念思想的，本身未必具體的如何做的執(zhí)行步驟。個(gè)人認(rèn)為它更偏向于在云計(jì)算平臺(tái)搭建后的資源更加有效整合，及平臺(tái)在解決業(yè)務(wù)能力的穩(wěn)定性和擴(kuò)展能力；從架構(gòu)師的視角看，也許更多的站在更高的層次全局的俯視整個(gè)平臺(tái)架構(gòu)，一個(gè)整體的電子商務(wù)的分布式操作系統(tǒng)和解決方案，而非僅僅是云計(jì)算平臺(tái)。在這個(gè)階段我們可以嘗試修改openstack的源碼和基礎(chǔ)服務(wù)的源碼，兩者無縫結(jié)合起來，做到高流量時(shí)候自動(dòng)的擴(kuò)容及低流量時(shí)的自動(dòng)縮容，做到資源的動(dòng)態(tài)調(diào)配合。

?

（本說明基于當(dāng)前公司的實(shí)際情況的部分架構(gòu)簡(jiǎn)要說明，未涉及工作流，搜索引擎，大數(shù)據(jù)挖掘等其他方面，僅作參考）

?

轉(zhuǎn)載于:https://www.cnblogs.com/daxiongblog/p/4935657.html

總結(jié)

以上是生活随笔為你收集整理的.net大型分布式电子商务架构说明(转载来自头条)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。