電商基礎架構建設之路

作者：史海峰 2017-03-03 14:10:50

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

基礎架構不直接實現業務功能，當購物車系統出現故障，沒人會關心是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系統中也有類似的實時展示，通過紅綠燈方式更直觀的顯示應用異常。此類系統的難點是問題分類和分級，需要與各部門使用人員進行溝通，并結合系統現狀，逐步優化體驗，提高效率。