電商基礎架構建設之路

在各種技術大會的架構分享中里，常常能聽到這樣一句話：「一切拋開業務的架構設計都是耍流氓。」基礎架構建設，看起來正是「與業務無關」的耍流氓。

基礎架構不直接實現業務功能，當購物車系統出現故障，沒人會關心是Redis集群不穩定，還是配置中心連接數太高。因此這方面的工作，只有技術部門內部才能夠意識到有多重要，卻在與業務需求的PK中常常敗下陣來，淪為房間里的大象，重要而不緊急，直至火燒眉毛不得不為之的那一天。

什麼是基礎架構?

基礎架構與業務無關么?

電商系統有什麼特點?

需要什麼樣的基礎設施?

拉動經濟的大招之一就是搞基建，俗稱「鐵公基」。前幾年呢都說雲計算是將來互聯網的基礎設施。

一個上規模的系統，需要更多統一的、專業分工的、可靠的組件、模塊、框架和平台來保證整個體系的高效、可控、值得信賴。

電商，尤其是B2C電商，不同於門戶、社交、遊戲、工具，本質上是以交易為核心的系統，需要7*24小時全天候提供服務，涉及到錢，高度敏感，關聯性強，又常常堆積了很多功能(多數只上不下)，系統龐雜、邊界模糊，積壓了許多技術債務，採用多種異構技術，不易維護，缺乏文檔，各種歷史包袱，攤子越鋪越大，完全符合熵增原理，管理成本越來越高，很難調整優化。

基礎架構為整個體系服務，也必然受行業特點影響，電商的基礎設施一般包含以下部分。

我們為什麼要建設基礎架構?

有四方面原因：

1.夯實基礎，事半功倍

IT技術的價值在於復用，完善的基礎架構將會為系統快速演進提供保障，高效響應業務需求。

2.提高系統可控性

系統越複雜，規模越大越難以管理，需要系統化的手段使之成為一套有機的整體。

3.隔離業務代碼與框架、平台

人員流動率高、新手比例大，提供框架、平台可以令新手只實現業務代碼，充分合理利用人力資源，提高系統穩定性。

4.降低技術債，提高管理效率

建設基礎架構通過技術手段減少債務風險，完善的基礎架構能夠降低溝通成本、節約時間、提高管理效率。

如前所述，基礎架構建設很難得到重視，需要怎樣實施推進呢?

1.順勢而為，撥亂為治

如果基礎架構建設投入不足，會在某些時刻引發問題，甚至嚴重影響業務，從而被高度關注，又或者某領域技術成為熱點，這樣的時機要牢牢抓住，順勢而為，實施適合自己的，接近行業主流的方案，該怎麼做就怎麼做，不必過多糾結。

2.自底向上，由點及面

基礎架構建設是有其規律的，一般要自底向上，但層層遞進全面實現需要投入大量資源，那麼先布點，再以點作為支撐，展開成面更為可行，適當重複建設是可以接受的。

3.抓住痛點，有備無患

既然不能按部就班，就要把好鋼用在刀刃上，集中優勢兵力，解決關鍵問題。識別關鍵問題需要有全局觀，並儘可能了解各方面的情況，找到痛點。痛點不一定就是難點，而且多數的問題，都是有解的，如何解決方向非常明確，提前做好調研，等待時機即可。

4.亡羊補牢，猶未晚矣

理想情況是凡事走在前面，理論上投入資源最少、風險最低、收益最高，但因為各方面原因，總有來不及補的窟窿，爆發問題也很正常，能及時處理就好，避免進一步惡化，也是非常必要的。

接下來，將從三個方面介紹噹噹基礎架構建設的經驗。

首先是部署運維方面。

現在很多公司都搞多機房災備，常見標準是兩地三中心，但經常搞著搞著就成了兩地三機房，系統跨機房部署，備用不足，機房之間網路通訊問題直接影響系統可用性，多機房反倒成了不穩定因素。試問有多少公司真正進行過災備切換演練?又有多少人在系統出了問題的時候敢拍著胸脯說切系統沒問題?

到底應該怎樣?撥亂反正，災備就災備，盡量不跨機房調用，技術實力夠的話，搞成多活更好。

現在很多創業公司，甚至大公司都在上雲，用公有雲或者自建私有雲。然而公有雲就真的可靠么?一旦出現問題，導致業務損失，公有雲會賠償么?要不你再搞跨雲部署?這不是給自己找麻煩呢么?本來用公有雲是為了省錢省事，你這麼牛乾脆搞私有雲得了，可是私有雲真能Hold住么?是否儲備了足夠的技術人員，能夠及時處理各種問題?技術複雜了，什麼都軟體定義，需要更強的運維。

一句話，盡量簡化系統部署架構，多做演練，不要迷信所謂的高新技術，最終這些都是需要有人，人才是最寶貴的資產。

再說說資料庫管理，資料庫本身就是管理系統，然而一個大型系統，擁有數以百計乃至成千上萬的資料庫都很正常，而且可能會根據場景採用多種類型的資料庫，從MySQL、SQLServer、Oracle到MongoDB、Greenplum不一而足。資料庫表結構是否合理?數據同步、備份、資料庫運行是否正常，管理分配資料庫訪問許可權需要系統管理。搭建資料庫管理平台可以解決這些問題，甚至可以進一步通過系統手段發現問題，比如哪些表空間增長太快需要擴容，比如是否有些同樣含義的欄位定義類型、長度不一致。

與資料庫管理平台同理，Redis緩存集群也需要這樣的資源管理平台，而且Redis自身的管理功能有限，又是分散式集群，更需要平台方式管理。因為使用姿勢不當等問題，噹噹前兩年在Redis使用上趟過許多坑，為了避免各團隊重複掉坑，在2016年初上線了Redis資源管理平台，系統化管理緩存資源、節點，統一版本，令開發人員無需關心底層基礎設施，簡化運維複雜度，提供統一的系統化運維監控管理。當然，還有一點就是更合理的分配資源，更充分的利用資源。

系統監控的重要性無需贅述，這裡說一下選型，噹噹的系統監控曾經用過Nagios，後來改成了Zabbix，作為主流開源產品，從選型角度來講可能區別並不大，監控系統最重要的是落地，需要有人支持和推動，切實的應用，真正把每台伺服器都監控起來。

其次是基礎管理方面。

說起來有些可笑，很多互聯網公司在技術部門自身的信息化建設方面投入很少，許多工程師以做業務系統，解決分散式、高併發、大數據量問題為榮，不屑於開發基礎管理系統，結果造成了技術團隊協作效率低下，管理混亂失序。

經過幾年的建設，噹噹基本建成了貫穿產品生命周期的基礎管理體系，涵蓋項目管理、自動部署、監控告警、問題跟蹤幾部分。

PDLC是項目管理系統，通過系統可以發起需求，跟蹤進度，分配任務，查看人力資源使用情況，對當前團隊項目執行情況一目了然，心中有數。配合敏捷開發功能，電子看板可以很好的支持每天站會，比物理看板更有技術范兒。

有系統就比沒有強，有些公司規模很大，卻連項目管理系統都沒有，不難想象一定會有很多問題，比如一但發生項目優先順序調整，插入新需求，評估影響重新排期就只能靠人了，每到這個時刻項目經理就覺得自己就是個杯具。

系統多了，業務大了，甭管是否微服務，在成千上萬台伺服器里部署應用實例都是個大動作，偏偏又是天天都要面對的日常，如果都靠年紀輕輕的運維工程師寫腳本執行，老闆們一定沒法淡定的坐在位子上。人雖然是寶貴的，但也是最靠不住的，穩定性比起機器可差多了。所以必須要有自動化部署平台，支持從開發到測試到生產各個環境的編譯檢查、版本管理、備份、灰度、回滾。

噹噹的自動化運維部署平台叫PANGU，在2015年獲得過總裁認同獎。

前面說的是系統監控，應用監控、業務監控也同樣重要，監控的完善性體現了系統運維管理水平。Radar是探測式監控系統、APIMonitor是服務質量監控。從下圖的統計對比可以看到，監控數據量大幅上升，這就是有了工具的好處，想用就用，快速鋪開。接下來要解決的是監控更多維度、實現監控系統的自我監控以及基於監控數據提供趨勢分析和關聯分析，精準告警，甚至防患於未然。

無論是告警還是產品系統問題，都需要有人來追蹤解決，Tracker就是這樣的問題跟蹤系統。通過系統可以避免問題因為轉發而迷失在郵件伺服器里，能夠分級、跟蹤問題解決的路徑和時效，還能自動超時升級。下圖為Tracker系統的報單實時刷新展示。Radar系統中也有類似的實時展示，通過紅綠燈方式更直觀的顯示應用異常。此類系統的難點是問題分類和分級，需要與各部門使用人員進行溝通，並結合系統現狀，逐步優化體驗，提高效率。

最後是技術架構方面。

技術架構方面，噹噹架構部經歷了從組件到框架，再到平台的自底向上，由點及面，逐步推進的過程。

2014年，SOA選型使用Dubbo，考慮噹噹的系統異構情況，需要支持HTTP調用，二次開發了DubboX，並進行了開源，證明了具備開發基礎組件的能力。

2015年，開發應用框架DDFrame，在其中嵌入DubboX和TBSchedule，以及自研的RDB模塊，在多個系統中投入應用。後來自研分散式彈性作業調度框架Elastic-Job和輕量級資料庫中間件Sharding-JDBC，這兩個產品也都進行了開源。

2016年，在Elastic-Job基礎上，結合Mesos，開發Elastic-Job-Cloud，這已經是採用容器領域最新技術，實現資源自動管理調度的智能作業雲平台，投入大規模使用將極大的降低伺服器資源浪費，體現雲計算的價值。

以上幾種組件的開源地址如下，歡迎關注使用，更歡迎參與開發。

最後簡單總結三句話：

1.用自動替代人工

2.用小系統驅動大團隊

3.用基礎平台支撐上層應用

所以沒什麼新鮮大道理是大家不知道的，最重要的是做出來，用好，才有價值。