【恩墨學院】摩拜物聯網架構演進之路|資料與架構齊驅，看摩拜創造奇蹟

最近召開的技術長領袖峰會上，網際網路不同行業頂尖技術領導者齊聚一堂，充分交流與碰撞最前沿的技術思想和實踐，探討技術創造商業價值的途徑，推動商業變革與創新。會上有很多有價值的觀點和實踐經驗，感謝iTechPlus的授權，我們在此將一些經典的內容重新編輯整理，分享給各位。希望對大家有幫助和借鑑意義。

今天我們揀選的是來自摩拜的技術副總裁張屹凌的分享。主題圍繞摩拜的架構演進展開。

以下是分享的內容及解讀：

什麼是架構？

在Wikipedia上對架構的定義為The process and the product of planning,designing,and constructing structures.也就是規劃、設計及構建的過程和產物。

架構有很多種，包括研發架構，團隊架構各種，今天分享的主題主要圍繞技術架構展開，具體來講，是圍繞摩拜的系統架構，一起探討軟體技術的演進和發展。

摩拜建立的時間並不久，不像許多已經過了早期的大公司。摩拜在過去一年的增長和發展非常快，一方面表現為使用者數量的增加，已達到最初的500倍，團另一方面則表現為團隊的增長，目前的團隊規模也是以前的十倍。在這樣的增速下，為了保持使用者環境的穩定，提高服務的質量，摩拜的架構經歷了幾代的演進，也做了很多的功能和效能的最佳化。

在整個系統架構演進的過程中，我們本著進中求穩的理念，從兩個方面不斷最佳化改進：一方面是系統的速度和能力，另一方面是系統的穩定性和效能。兩個方面相輔相成，互相促進，既從工具和架構層面不斷創新，也結合流程規範不斷最佳化。

“摩拜的系統架構的演進可以分為四個階段”

第一階段野蠻生長

我們去年8月份的時候開啟了這個專案，專案開始得很順利，我們用了一夜的時間上線了一套資料庫，也沒有測試，但上線後非常順利沒有出什麼問題。跟CEO聊的時候，他談起這件事情表現得很興奮。

當時的系統架構組成為：LB+NGINX+Tomcat+Dubbo+DB。車輛業務端垂直切分，使用Monolith First演算法，擴充套件能力有限，而資料庫是單例項的。

但不久，在我們第二次聊天的中途，可能是因為車輛需求的增加， 伺服器突然因為遭遇bug就當機了，當時還是很嚴重了，整個系統都崩潰了，但在我們的努力下，最終把系統的bug修復了。

在當時，系統主要表現出三大特點：快、糙、猛。即簡單快，隨時釋出，快速落地，多面手。

同時存在以下問題：從業務上來說，不能對各種使用者需求和行為作出合理響應，功能上尚不完善。而效能上，也是常常捉襟見肘，在很多個方面遇到過效能瓶頸，只能在嘗試中去改進，很多時候沒有辦法直接定位問題的根源。這些問題，跟我們上線之前的準備工作不充分有很大的關係。

我們團隊是非常扁平的，這個扁平意思不只是說一個人管多少人，而是一個人既做研發又負責一些iot又做運維上線還要做測試。面對系統的多重問題，就對我們的技術人員提出了新的要求。

我們希望能夠透過監控儘早發現問題，避免線上的誤操作和效率問題，同時要不斷增強系統的IOT容錯能力。

第二階段基礎效能

從八月份到12月，使用者增長很快，每月達到2X的速度。隨著規模的擴大，系統在功能上逐漸完善，我們也更重視系統的效能問題。

於是我們開始設計第二代也就是V1的系統架構。V1的主要改進目標針對V0的問題做修復，並提高穩定性和基礎效能。

從以下四個方面，我們可以看到系統的改進：

第三階段效能最佳化

很快，業務的增長速度達到了3X每月，效能問題日益凸顯。由於沒有做很好的流量管控，整個服務是一套，如果這個加了一百個伺服器以後，後面系統連線數就很多，很可能就爆掉，這時候再加機器也沒用了。

於是我們設計了第三代架構 V2

我們把架構做成兩層，先去Dubbo化，再服務拆分，拆完了以後我們發現整個監控也要簡化，效能測試大大簡化，釋出影響也大大縮小了，之後是資料庫的拆分，我們當時拆一個核心的庫表，拆了一千多個庫，再做的過程中發現不僅是拆的事情，而是把所有的業務都梳理一遍，拆一個庫表一個月，我們後來就不堅持做這個策略了，我們就先拆地域，再分片，這個也是和我們業務有關係的。

4月份做了一個週年的活動，那天基本達到了一個峰值，也被行業內攻擊了一下，之後基本就開掛了，整個服務沒有非常明顯的當機。

從以下四個方面，我們也實實在在看到系統在不斷完善和最佳化：

對物聯網，我們更多是做一些鏈路的分析，當時也是說效能問題很多是由使用者的反饋過來的，我們每次報過來就讓一個人查和分析鏈路是什麼，這個事情非常重，當時稍微做了一些鏈路分析的工作，就把核心鏈路做了分析，就是開關鎖的分析。

第四階段並行迭代能力

現在又到了第四個階段，這個時候我們的系統比較穩定了，但是我們效能穩定了，但是還是會當機，當機的原因很多，很多是因為業務複雜度導致的，業務複雜度是因為需求變多了，很多事情想做，這個架構必須確保很多人同時開包的時候，大家可以很穩定的合作，很穩定的上線，而不是說今天上線明天就回滾。

我們一方面考慮團隊增長，需要確保團隊的能力和興趣匹配，需要一個比較好的結構支援這個事情。

同時整個系統在做更好調優，不是那麼簡單了，要做一個併發的研發環境，做業務無關的資料庫分片方案，還有系統化的IOT方案，國際化的架構方案，我們需要做一些系統化的設計。

我們分為幾步走，一個是基礎架構的東西，做了一個核心業務的拆分，拆分不只是微服務化，更多是需要把一些相關的系統整合到一塊，對子系統的整理。

同時我們還做了一箇中介軟體層的收口，把一些底層依賴收起來。第三是資料庫分片，IOT的核心功能，裝置管理能力，請求鏈路分析，開關鎖的統計分析，我們還有一個O他的能力升級，從效能到能力。同時我們做了國際化設計，這是一個高頻率釋出的事情，有一套適合摩拜的程式碼管理的流程。

到了第三版，功能對比如下，這個迭代的過程，一步一步到今天這個狀態，對我們來說，最重要的就是MoveFast，儘量用工具來提高這些效率。