電商基礎(chǔ)架構(gòu)建設(shè)之路
在各種技術(shù)大會(huì)的架構(gòu)分享中里，常常能聽到這樣一句話：“一切拋開業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓。”基礎(chǔ)架構(gòu)建設(shè)，看起來正是“與業(yè)務(wù)無關(guān)”的耍流氓。
基礎(chǔ)架構(gòu)不直接實(shí)現(xiàn)業(yè)務(wù)功能，當(dāng)購物車系統(tǒng)出現(xiàn)故障，沒人會(huì)關(guān)心是Redis集群不穩(wěn)定，還是配置中心連接數(shù)太高。因此這方面的工作，只有技術(shù)部門內(nèi)部才能夠意識到有多重要，卻在與業(yè)務(wù)需求的PK中常常敗下陣來，淪為房間里的大象，重要而不緊急，直至火燒眉毛不得不為之的那一天。
什么是基礎(chǔ)架構(gòu)?
基礎(chǔ)架構(gòu)與業(yè)務(wù)無關(guān)么?
電商系統(tǒng)有什么特點(diǎn)?
需要什么樣的基礎(chǔ)設(shè)施?
我國拉動(dòng)經(jīng)濟(jì)的大招之一就是搞基建，俗稱“鐵公基”。前幾年呢都說云計(jì)算是將來互聯(lián)網(wǎng)的基礎(chǔ)設(shè)施。
一個(gè)上規(guī)模的系統(tǒng)，需要更多統(tǒng)一的、專業(yè)分工的、可靠的組件、模塊、框架和平臺來保證整個(gè)體系的高效、可控、值得信賴。
電商，尤其是B2C電商，不同于門戶、社交、游戲、工具，本質(zhì)上是以交易為核心的系統(tǒng)，需要7*24小時(shí)全天候提供服務(wù)，涉及到錢，高度敏感，關(guān)聯(lián)性強(qiáng)，又常常堆積了很多功能(多數(shù)只上不下)，系統(tǒng)龐雜、邊界模糊，積壓了許多技術(shù)債務(wù)，采用多種異構(gòu)技術(shù)，不易維護(hù)，缺乏文檔，各種歷史包袱，攤子越鋪越大，完全符合熵增原理，管理成本越來越高，很難調(diào)整優(yōu)化。
基礎(chǔ)架構(gòu)為整個(gè)體系服務(wù)，也必然受行業(yè)特點(diǎn)影響，電商的基礎(chǔ)設(shè)施一般包含以下部分。
我們?yōu)槭裁匆ㄔO(shè)基礎(chǔ)架構(gòu)?
有四方面原因：
1.夯實(shí)基礎(chǔ)，事半功倍
IT技術(shù)的價(jià)值在于復(fù)用，完善的基礎(chǔ)架構(gòu)將會(huì)為系統(tǒng)快速演進(jìn)提供保障，高效響應(yīng)業(yè)務(wù)需求。
2.提高系統(tǒng)可控性
系統(tǒng)越復(fù)雜，規(guī)模越大越難以管理，需要系統(tǒng)化的手段使之成為一套有機(jī)的整體。
3.隔離業(yè)務(wù)代碼與框架、平臺
人員流動(dòng)率高、新手比例大，提供框架、平臺可以令新手只實(shí)現(xiàn)業(yè)務(wù)代碼，充分合理利用人力資源，提高系統(tǒng)穩(wěn)定性。
4.降低技術(shù)債，提高管理效率
建設(shè)基礎(chǔ)架構(gòu)通過技術(shù)手段減少債務(wù)風(fēng)險(xiǎn)，完善的基礎(chǔ)架構(gòu)能夠降低溝通成本、節(jié)約時(shí)間、提高管理效率。
如前所述，基礎(chǔ)架構(gòu)建設(shè)很難得到重視，需要怎樣實(shí)施推進(jìn)呢?
1.順勢而為，撥亂為治
如果基礎(chǔ)架構(gòu)建設(shè)投入不足，會(huì)在某些時(shí)刻引發(fā)問題，甚至嚴(yán)重影響業(yè)務(wù)，從而被高度關(guān)注，又或者某領(lǐng)域技術(shù)成為熱點(diǎn)，這樣的時(shí)機(jī)要牢牢抓住，順勢而為，實(shí)施適合自己的，接近行業(yè)主流的方案，該怎么做就怎么做，不必過多糾結(jié)。
2.自底向上，由點(diǎn)及面
基礎(chǔ)架構(gòu)建設(shè)是有其規(guī)律的，一般要自底向上，但層層遞進(jìn)全面實(shí)現(xiàn)需要投入大量資源，那么先布點(diǎn)，再以點(diǎn)作為支撐，展開成面更為可行，適當(dāng)重復(fù)建設(shè)是可以接受的。
3.抓住痛點(diǎn)，有備無患
既然不能按部就班，就要把好鋼用在刀刃上，集中優(yōu)勢兵力，解決關(guān)鍵問題。識別關(guān)鍵問題需要有全局觀，并盡可能了解各方面的情況，找到痛點(diǎn)。痛點(diǎn)不一定就是難點(diǎn)，而且多數(shù)的問題，都是有解的，如何解決方向非常明確，提前做好調(diào)研，等待時(shí)機(jī)即可。
4.亡羊補(bǔ)牢，猶未晚矣
理想情況是凡事走在前面，理論上投入資源最少、風(fēng)險(xiǎn)***、收益***，但因?yàn)楦鞣矫嬖?，總有來不及補(bǔ)的窟窿，爆發(fā)問題也很正常，能及時(shí)處理就好，避免進(jìn)一步惡化，也是非常必要的。
接下來，將從三個(gè)方面介紹當(dāng)當(dāng)基礎(chǔ)架構(gòu)建設(shè)的經(jīng)驗(yàn)。
首先是部署運(yùn)維方面。
現(xiàn)在很多公司都搞多機(jī)房災(zāi)備，常見標(biāo)準(zhǔn)是兩地三中心，但經(jīng)常搞著搞著就成了兩地三機(jī)房，系統(tǒng)跨機(jī)房部署，備用不足，機(jī)房之間網(wǎng)絡(luò)通訊問題直接影響系統(tǒng)可用性，多機(jī)房反倒成了不穩(wěn)定因素。試問有多少公司真正進(jìn)行過災(zāi)備切換演練?又有多少人在系統(tǒng)出了問題的時(shí)候敢拍著胸脯說切系統(tǒng)沒問題?
到底應(yīng)該怎樣?撥亂反正，災(zāi)備就災(zāi)備，盡量不跨機(jī)房調(diào)用，技術(shù)實(shí)力夠的話，搞成多活更好。
現(xiàn)在很多創(chuàng)業(yè)公司，甚至大公司都在上云，用公有云或者自建私有云。然而公有云就真的可靠么?一旦出現(xiàn)問題，導(dǎo)致業(yè)務(wù)損失，公有云會(huì)賠償么?要不你再搞跨云部署?這不是給自己找麻煩呢么?本來用公有云是為了省錢省事，你這么牛干脆搞私有云得了，可是私有云真能Hold住么?是否儲備了足夠的技術(shù)人員，能夠及時(shí)處理各種問題?技術(shù)復(fù)雜了，什么都軟件定義，需要更強(qiáng)的運(yùn)維。
一句話，盡量簡化系統(tǒng)部署架構(gòu)，多做演練，不要迷信所謂的高新技術(shù)，最終這些都是需要有人，人才是最寶貴的資產(chǎn)。
再說說數(shù)據(jù)庫管理，數(shù)據(jù)庫本身就是管理系統(tǒng)，然而一個(gè)大型系統(tǒng)，擁有數(shù)以百計(jì)乃至成千上萬的數(shù)據(jù)庫都很正常，而且可能會(huì)根據(jù)場景采用多種類型的數(shù)據(jù)庫，從MySQL、SQLServer、Oracle到MongoDB、Greenplum不一而足。數(shù)據(jù)庫表結(jié)構(gòu)是否合理?數(shù)據(jù)同步、備份、數(shù)據(jù)庫運(yùn)行是否正常，管理分配數(shù)據(jù)庫訪問權(quán)限需要系統(tǒng)管理。搭建數(shù)據(jù)庫管理平臺可以解決這些問題，甚至可以進(jìn)一步通過系統(tǒng)手段發(fā)現(xiàn)問題，比如哪些表空間增長太快需要擴(kuò)容，比如是否有些同樣含義的字段定義類型、長度不一致。
與數(shù)據(jù)庫管理平臺同理，Redis緩存集群也需要這樣的資源管理平臺，而且Redis自身的管理功能有限，又是分布式集群，更需要平臺方式管理。因?yàn)槭褂米藙莶划?dāng)?shù)葐栴}，當(dāng)當(dāng)前兩年在Redis使用上趟過許多坑，為了避免各團(tuán)隊(duì)重復(fù)掉坑，在2016年初上線了Redis資源管理平臺，系統(tǒng)化管理緩存資源、節(jié)點(diǎn)，統(tǒng)一版本，令開發(fā)人員無需關(guān)心底層基礎(chǔ)設(shè)施，簡化運(yùn)維復(fù)雜度，提供統(tǒng)一的系統(tǒng)化運(yùn)維監(jiān)控管理。當(dāng)然，還有一點(diǎn)就是更合理的分配資源，更充分的利用資源。
系統(tǒng)監(jiān)控的重要性無需贅述，這里說一下選型，當(dāng)當(dāng)?shù)南到y(tǒng)監(jiān)控曾經(jīng)用過Nagios，后來改成了Zabbix，作為主流開源產(chǎn)品，從選型角度來講可能區(qū)別并不大，監(jiān)控系統(tǒng)最重要的是落地，需要有人支持和推動(dòng)，切實(shí)的應(yīng)用，真正把每臺服務(wù)器都監(jiān)控起來。
其次是基礎(chǔ)管理方面。
說起來有些可笑，很多互聯(lián)網(wǎng)公司在技術(shù)部門自身的信息化建設(shè)方面投入很少，許多工程師以做業(yè)務(wù)系統(tǒng)，解決分布式、高并發(fā)、大數(shù)據(jù)量問題為榮，不屑于開發(fā)基礎(chǔ)管理系統(tǒng)，結(jié)果造成了技術(shù)團(tuán)隊(duì)協(xié)作效率低下，管理混亂失序。
經(jīng)過幾年的建設(shè)，當(dāng)當(dāng)基本建成了貫穿產(chǎn)品生命周期的基礎(chǔ)管理體系，涵蓋項(xiàng)目管理、自動(dòng)部署、監(jiān)控告警、問題跟蹤幾部分。
PDLC是項(xiàng)目管理系統(tǒng)，通過系統(tǒng)可以發(fā)起需求，跟蹤進(jìn)度，分配任務(wù)，查看人力資源使用情況，對當(dāng)前團(tuán)隊(duì)項(xiàng)目執(zhí)行情況一目了然，心中有數(shù)。配合敏捷開發(fā)功能，電子看板可以很好的支持每天站會(huì)，比物理看板更有技術(shù)范兒。
有系統(tǒng)就比沒有強(qiáng)，有些公司規(guī)模很大，卻連項(xiàng)目管理系統(tǒng)都沒有，不難想象一定會(huì)有很多問題，比如一但發(fā)生項(xiàng)目優(yōu)先級調(diào)整，插入新需求，評估影響重新排期就只能靠人了，每到這個(gè)時(shí)刻項(xiàng)目經(jīng)理就覺得自己就是個(gè)杯具。
系統(tǒng)多了，業(yè)務(wù)大了，甭管是否微服務(wù)，在成千上萬臺服務(wù)器里部署應(yīng)用實(shí)例都是個(gè)大動(dòng)作，偏偏又是天天都要面對的日常，如果都靠年紀(jì)輕輕的運(yùn)維工程師寫腳本執(zhí)行，老板們一定沒法淡定的坐在位子上。人雖然是寶貴的，但也是最靠不住的，穩(wěn)定性比起機(jī)器可差多了。所以必須要有自動(dòng)化部署平臺，支持從開發(fā)到測試到生產(chǎn)各個(gè)環(huán)境的編譯檢查、版本管理、備份、灰度、回滾。
當(dāng)當(dāng)?shù)淖詣?dòng)化運(yùn)維部署平臺叫PANGU，在2015年獲得過總裁認(rèn)同獎(jiǎng)。
前面說的是系統(tǒng)監(jiān)控，應(yīng)用監(jiān)控、業(yè)務(wù)監(jiān)控也同樣重要，監(jiān)控的完善性體現(xiàn)了系統(tǒng)運(yùn)維管理水平。Radar是探測式監(jiān)控系統(tǒng)、APIMonitor是服務(wù)質(zhì)量監(jiān)控。從下圖的統(tǒng)計(jì)對比可以看到，監(jiān)控?cái)?shù)據(jù)量大幅上升，這就是有了工具的好處，想用就用，快速鋪開。接下來要解決的是監(jiān)控更多維度、實(shí)現(xiàn)監(jiān)控系統(tǒng)的自我監(jiān)控以及基于監(jiān)控?cái)?shù)據(jù)提供趨勢分析和關(guān)聯(lián)分析，精準(zhǔn)告警，甚至防患于未然。
無論是告警還是產(chǎn)品系統(tǒng)問題，都需要有人來追蹤解決，Tracker就是這樣的問題跟蹤系統(tǒng)。通過系統(tǒng)可以避免問題因?yàn)檗D(zhuǎn)發(fā)而迷失在郵件服務(wù)器里，能夠分級、跟蹤問題解決的路徑和時(shí)效，還能自動(dòng)超時(shí)升級。下圖為Tracker系統(tǒng)的報(bào)單實(shí)時(shí)刷新展示。Radar系統(tǒng)中也有類似的實(shí)時(shí)展示，通過紅綠燈方式更直觀的顯示應(yīng)用異常。此類系統(tǒng)的難點(diǎn)是問題分類和分級，需要與各部門使用人員進(jìn)行溝通，并結(jié)合系統(tǒng)現(xiàn)狀，逐步優(yōu)化體驗(yàn)，提高效率。
***是技術(shù)架構(gòu)方面。
技術(shù)架構(gòu)方面，當(dāng)當(dāng)架構(gòu)部經(jīng)歷了從組件到框架，再到平臺的自底向上，由點(diǎn)及面，逐步推進(jìn)的過程。
2014年，SOA選型使用Dubbo，考慮當(dāng)當(dāng)?shù)南到y(tǒng)異構(gòu)情況，需要支持HTTP調(diào)用，二次開發(fā)了DubboX，并進(jìn)行了開源，證明了具備開發(fā)基礎(chǔ)組件的能力。
2015年，開發(fā)應(yīng)用框架DDFrame，在其中嵌入DubboX和TBSchedule，以及自研的RDB模塊，在多個(gè)系統(tǒng)中投入應(yīng)用。后來自研分布式彈性作業(yè)調(diào)度框架Elastic-Job和輕量級數(shù)據(jù)庫中間件Sharding-JDBC，這兩個(gè)產(chǎn)品也都進(jìn)行了開源。
2016年，在Elastic-Job基礎(chǔ)上，結(jié)合Mesos，開發(fā)Elastic-Job-Cloud，這已經(jīng)是采用容器領(lǐng)域***技術(shù)，實(shí)現(xiàn)資源自動(dòng)管理調(diào)度的智能作業(yè)云平臺，投入大規(guī)模使用將極大的降低服務(wù)器資源浪費(fèi)，體現(xiàn)云計(jì)算的價(jià)值。
以上幾種組件的開源地址如下，歡迎關(guān)注使用，更歡迎參與開發(fā)。
https://github.com/dangdangdotcom/dubbox
https://github.com/dangdangdotcom/elastic-job
https://github.com/dangdangdotcom/sharding-jdbc
***簡單總結(jié)三句話：
1.用自動(dòng)替代人工
2.用小系統(tǒng)驅(qū)動(dòng)大團(tuán)隊(duì)
3.用基礎(chǔ)平臺支撐上層應(yīng)用
所以沒什么新鮮大道理是大家不知道的，最重要的是做出來，用好，才有價(jià)值。
【本文為51CTO專欄作者“史海峰”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號“IT民工閑話（ITCrossTalker）”獲取聯(lián)系和授權(quán)】
