滴滴出行分而治之的架構設計之道

【本文是WOT2016互聯網運維與開發者大會的現場干貨，  新1屆主題為WOT2016企業安全技術峰會將在2016年6月24日⑵5日于北京珠3角JW萬豪酒店隆重召開！】

如今，我們去任何1個地方都要先問問有無Wi-Fi，網絡已明顯影響到我們的生活。

互聯網生下來就是為了服務海量用戶，在這個時期，幾近沒有哪一個利用再為單機而生。每一個公司的每一個產品將要面臨的都是不可預知的用戶海量要求。明顯這個靠散布式程序來解決，比依托單機靠譜很多。但是不幸的是，如果1開始你的架構設計不可擴大，有再多的機器，有再多的云解決方案，對你來講最多是將單機程序跑在了1個虛擬的單機上。下面就讓我們回到WOT2016 互聯網運維與開發者大會現場，跟隨滴滴出行首席架構師1起了解，散布時期架構設計和程序開發面臨著哪些新挑戰，和滴滴出行的應對思路。

李令輝，滴滴出行首席架構師，于2014年中加入滴滴，經歷了滴滴高速成長的階段，見證了滴滴從1個打車軟件變成1個出行平臺。移動互聯網資深從業者，對移動互聯網技術發展趨勢和技術團隊的組建有獨道見解。他具有多年互聯網架構的設計經驗，善于高性能高并發高可用的架構設計工作，主導了滴滴打車技術迭代中的核心服務架構升級。

散布式時期的窘境

為單機而生的利用將不復存在

很少有1個利用能準確預測自己的用戶量有多大，因此，1開始就為上億用戶去設計1個極其復雜的散布式架構，幾近是不可能的。由于這不但會帶來極高的本錢，還會犧牲全部系統的靈活度。其實不是每一個公司都像谷歌1樣，在創業早期就有面對世界上所有數據的雄心壯志，來開發1個散布式文件系統。大多數公司1定是從幾臺服務器起家，在用戶不斷增長，并發要求增加，業務愈來愈復雜的進程中，百臨不得已將程序從單機搬到多臺機器。把單個進程拆成多個服務的問題。

散布式開發工具的缺少

每一個人的工作量無緣無故1個互聯網的多個節點組成的，通過網絡耦合的1個散布式環境。無緣無故的被這類散布式帶來的必定復雜性提高了。但是，真實的散布式開發工具還遠未成熟。 程序員可使用的工具還是古老的VI,410年前的Emacs和10幾年前的Eclipse等單機開發工具，服務之間的依賴關系完全沒法管理，日志格式和日志內容沒法保證1致和可追溯。上線，擴容，降級等運維工作和規范沒有被很好的設計。 任何1次問題或開發，都需要多人協作，效力極其低下。

重造車輪的解決方案

看起來，業界解決方案百花爭鳴。但實際上，大部份都是基于開源的RPC方案，比較成型的幾個方案包括Erlang OTP, Scala Akka等。公司內通過各種定制的方案去耦合，去相互管理關系，相互依賴，把1個事工作起來。大1點的公司會強迫的推行運維規范。而每一個公司或社區都對這類散布式環境用自己的理解。 這帶來的后果是，大家都在開源社區的基礎上重復造一樣的東西，這個是本錢很高的事情。

再者，很多解決方案都依賴于特定的業務場景來制定。比如通訊軟件，對實時性要求很高，對可用性要求非常高，但是電商其實不那末關心1個要求能不能快速返回，而是強調數據的1致性。所以每一個業務特點決定了有不同的解決方案，而且很少有為散布式而生的方案，都是從單機方案演變或漸變來的，這些問題都會讓每個在從中開發的人不能不知道全貌，對研發效力來說是個巨大的傷害。散布式也確切個足夠復雜的領域，很難有1攬子通用解決方案。

那末，在設計散布式系統架構時，應當斟酌哪些方面？

散布式架構設計基本要素

容錯

在散布式環境里，毛病無處不在，并且無時無刻不在產生。而且，毛病不只是機器故障，當幾百人投入研發工作的時候，1定會有人出錯，而且每一個人都會出錯，會常態的出錯。因此，研發團隊不應當只想著如何避免毛病的產生，而是如何在小毛病下，不影響業務，保持服務健康運營。而1但不加斟酌的對架構每一個模塊進行降級，必將帶來1場巨大的災害。

數據格式

數據格式實際面臨的窘境和依賴管理是1樣的。由于每一個人只負責單獨的模塊，而不會去關心全部業務用甚么樣的數據格式通訊。究竟代碼中到底多少是用來Verify Data的？又有多少是用來Pack/Unpack Data的？如果不統1就會墮入泥潭，工作效力低到沒法接受，日志搜集和監控也幾近沒法實現。

路由層

關于路由層的解決方案沒有高低之分，只要能解業務中的問題，下降運維本錢和開發本錢，就是好的方案。

但是，1定要盡可能避免同時存在多種解決方案。函數調用是路由，反射是路由，URL是路由，RPC的IP+Port+Function也是路由。雖然說，其實不是所有業務都能用統1的方法來路由的。路由的靈活性和規范性決定了運維難度，盲目尋求靈活度無緣無故的又把運維提的工作高1個量級。架構本質是控制復雜度，主要方法就是分而治之，解耦，耦合從本質上來講就是路由。

服務

為了滿足用戶新的要求，追上市場新的步伐，每一個互聯網公司的研發團隊都不曾停下腳步，保證服務不斷進化和升級。這同時也帶來了許多問題：

• 如何穩定高效的迭代？
• 依賴剛迭代的服務的舊服務怎樣辦？
• 我想給某個服務/模塊做AB Test怎樣辦？
• 多個模塊可以同時做AB Test么？
• 如果不能，研發變成串行上線真的好么？

看待這些問題1定要從全局動身，而最重要的是接口的統1，構成1致的標準，讓大家在1條共同的準繩上。

監控

現在大家所做的監控，基本都是在監控機器的狀態。其實在幾百臺機器這樣的較小范圍下，這樣做的意義其實不大。真正應當監控的，應當是程序。而嚴控程序的狀態，只能依賴日志。

因此，每一個架構師都要斟酌，如何設計可以監控服務的日志系統，要提供可監控的接口。是每一個架構師要斟酌你的服務是怎樣被監控的，你要提供可監控的接口。至于收集間隔，1般來講范圍越大，收集粒度越低，范圍越小，收集粒度越高。

另外，監控的信息是Pull or Push？監控的結果全部需要人來處理么？日志是不是可以用來作為系統之間交互的數據？這些問題都需要大家根據自己的業務場景不斷探索。

你的運維方案完善嗎？

每一個公司的運維團隊都在斟酌這個問題。你的目的是為了下降你的本錢，提高你的效力。請公道的計算你的本錢和效力，就是你要把人算進去，而不是就算機器。大家可以通過以下幾個維度來評估：

• 資源利用率如何？對大部份團隊來講，研發的人力本錢要遠遠高于機器本錢，你要首先斟酌的是你的人都并發起來了，而不是你的CPU都被吃掉了
• 解決方案是不是簡單？這對應著人材招聘的門坎。對新人來講，總要讓他快速的上手做1個項目，驗證自己的能力，所以解決方案1定要相對簡單。怎樣擴容，怎樣縮容，都應當有成型的1整套方案
• 開發測試上線流程是不是需要人工參與？
• 小流量測試的支持如何？
• 回滾、限流、斷流方案是不是統1提供等等問題 ？

滴滴出行的散布式設構設計思路

Linux之所以強大，是由于每個模塊都只負責最簡單的事情，面對輸入和輸出，而輸入和輸出的格式是肯定的。散布式架構設計的思路也應如此，一樣的規則，一樣的用法組合在1起是可以發揮巨大作用的。

滴滴出行的散布架構設計想要解決的問題，不只是簡單的機器運維，而是人在研發進程中，如何避免復雜環境中可能面臨的風險，解決由于粗糙的架構設計帶來的效力低下，不可控，不穩定的狀態。

這樣的架構設計帶來的1個巨大好處是，信息流在進來的時候進入信息分發，信息分發把它分到適合的管道，那個管道處理完再放給下1個管道。每一個管道都只做輸入和輸出的事情，實現高可用、高吞吐。這類方案很多云服務商都會提供。這樣做的好處時是，我們只需要管理消息隊列，可以在任意1個節點把流量復制走。在任何1個環節中可以拿到它所有的數據，不再依賴日志，只依賴輸入、輸出。而輸入、輸出是存在硬盤上的，數據不會丟失。

另外一個優點是進程是異步傳輸的。同步模型1個很明顯的缺點是在所有的層次中，1個進程在履行某個要求的時候如果需要1段時間才能返回信息，那末這個進程將會1直等待下去，直到收到返回信息才繼續履行下去。在流量很大的時候，做1個重試可能某1個環節就會面臨崩潰了，某個環節的連接數被打滿。

而在這個方案中，連接就只有兩3處，不需要等待數據回報，只需要確認收據接收，而且不需要逐條驗證。本錢很低，性能很高。

但這類架構設計明顯不能解決所有的問題。比如用MySQL作為存儲等必須同步的服務時，需要給有狀態的服務提供1個抽象層Service，上面的服務可以要求它。大家可以理解為在Linux中敲1個命令要讀1個文件，那個文件是有狀態的，是存在那里的，而這些模塊是沒有狀態的。

滴滴選擇了Docker+Kubernetes作為散布集群管理解決方案，它的好處是可以直接提供資源管理，資源隔離，部署，升級，路由等等需求。但是，只有Kubernetes是不夠的，Kubernetes只能管理那些無狀態的事務。其實不是所有的事情都可以完全抽象成無狀態的，有狀態的部份應當如何實現擴容，都要根據具體的業務場景，這是很難的設計。

最后要說的是，沒有完善的方案，如果你自己要開發這個事情，建議大家最好用1種方案，不要每個用1種。但是沒辦法，面對不同的研發人員，不同的場景等現實，現在還沒有終究的結論。也希望能借此文，與各位業界同仁共同探討。

【演講視頻】

散布式時期的架構設計（上）

 散布式時期的架構設計（下）

【作者推薦】

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈