網際網路生下來就是為了服務海量使用者，在這個時代，幾乎沒有哪個應用再為單機而生。每個公司的每個產品將要面臨的都是不可預知的使用者海量請求。顯然這個靠分布式程式來解決，比靠單機靠譜得多。然而不幸的是，如果一開始你的架構設計不可擴充套件，有再多的機器，有再多的雲解決方案，對你來說至多是將單機程式跑在了乙個虛擬的單機上。
2016-05-24 16:47收藏
分享
【本文是wot2016網際網路運維與開發者大會的現場乾貨， 新一屆主題為wot2016企業安全技術峰會將在2023年6月24日-25日於北京珠三角jw萬豪酒店隆重召開！】
如今，我們去任何乙個地方都要先問問有沒有wi-fi，網路已經明顯影響到我們的生活。
網際網路生下來就是為了服務海量使用者，在這個時代，幾乎沒有哪個應用再為單機而生。每個公司的每個產品將要面臨的都是不可預知的使用者海量請求。顯然這個靠分布式程式來解決，比依靠單機靠譜得多。然而不幸的是，如果一開始你的架構設計不可擴充套件，有再多的機器，有再多的雲解決方案，對你來說至多是將單機程式跑在了乙個虛擬的單機上。下面就讓我們回到wot2016 網際網路運維與開發者大會現場，跟隨滴滴出行首席架構師一起了解，分布時代架構設計和程式開發面臨著哪些新挑戰，以及滴滴出行的應對思路。
李令輝，滴滴出行首席架構師，於2023年中加入滴滴，經歷了滴滴高速成長的階段，見證了滴滴從乙個打車軟體變成乙個出行平台。移動網際網路資深從業者，對移動網際網路技術發展趨勢以及技術團隊的組建有獨道見解。他具有多年網際網路架構的設計經驗，擅長高效能高併發高可用的架構設計工作，主導了滴滴打車技術迭代中的核心服務架構公升級。
為單機而生的應用將不復存在
很少有乙個應用能準確**自己的使用者量有多大，因此，一開始就為上億使用者去設計乙個極為複雜的分布式架構，幾乎是不可能的。因為這不僅會帶來極高的成本，還會犧牲整個系統的靈活度。並不是每個公司都像谷歌一樣，在創業初期就有面對世界上所有資料的雄心壯志，來開發乙個分布式檔案系統。大多數公司一定是從幾台伺服器起家，在使用者不斷增長，併發請求增加，業務越來越複雜的過程中，百臨不得已將程式從單機搬到多台機器。把單個程序拆成多個服務的問題。
分布式開發工具的缺乏
每個人的工作量平白無故乙個網際網路的多個節點組成的，通過網路耦合的乙個分布式環境。平白無故的被這種分布式帶來的必然複雜性提高了。但是，真正的分布式開發工具還遠未成熟。 程式設計師可以使用的工具還是古老的vi,四十年前的emacs和十幾年前的eclipse等單機開發工具，服務之間的依賴關係完全無法管理，日誌格式和日誌內容無法保證一致和可追溯。上線，擴容，降級等運維工作和規範沒有被很好的設計。 任何一次問題或者開發，都需要多人協作，效率極為低下。
重造車輪的解決方案
看起來，業界解決方案百花爭鳴。但實際上，大部分都是基於開源的rpc方案，比較成型的幾個方案包括erlang otp, scala akka等。公司內通過各種定製的方案去耦合，去互相管理關係，互相依賴，把乙個事工作起來。大一點的公司會強制的推行運維規範。而每個公司或者社群都對這種分布式環境用自己的理解。 這帶來的後果是，大家都在開源社群的基礎上重複造同樣的東西，這個是成本很高的事情。
再者，很多解決方案都依賴於特定的業務場景來制定。比如通訊軟體，對實時性要求很高，對可用性要求非常高，然而電商並不那麼關心乙個請求能不能快速返回，而是強調資料的一致性。所以每個業務特點決定了有不同的解決方案，而且很少有為分布式而生的方案，都是從單機方案演化或者漸變來的，這些問題都會讓每乙個在從中開發的人不得不知道全貌，對研發效率來講是個巨大的傷害。分布式也確實個足夠複雜的領域，很難有一攬子通用解決方案。
那麼，在設計分布式系統架構時，應該考慮哪些方面？
容錯
在分布式環境裡，錯誤無處不在，並且無時無刻不在發生。而且，錯誤不只是機器故障，當幾百人投入研發工作的時候，一定會有人犯錯，而且每個人都會犯錯，會常態的犯錯。因此，研發團隊不應該只想著如何避免錯誤的發生，而是如何在小錯誤下，不影響業務，保持服務健康運營。而一但不加考慮的對架構每個模組進行降級，勢必帶來一場巨大的災難。
資料格式
資料格式實際面臨的困境和依賴管理是一樣的。因為每個人只負責單獨的模組，而不會去關心整個業務用什麼樣的資料格式通訊。究竟**中到底多少是用來verify data的？又有多少是用來pack/unpack data的？如果不統一就會陷入泥潭，工作效率低到無法接受，日誌收集和監控也幾乎沒法實現。
路由層
關於路由層的解決方案沒有高下之分，只要能解業務中的問題，降低運維成本和開發成本，就是好的方案。
但是，一定要盡量避免同時存在多種解決方案。函式呼叫是路由，反射是路由，url是路由，rpc的ip+port+function也是路由。雖然說，並不是所有業務都能用統一的方法來路由的。路由的靈活性和規範性決定了運維難度，盲目追求靈活度平白無故的又把運維提的工作高乙個量級。架構本質是控制複雜度，主要方法就是分而治之，解耦，耦合從本質上來說就是路由。
服務
為了滿足使用者新的要求，追上市場新的步伐，每個網際網路公司的研發團隊都不曾停下腳步，保證服務不斷進化和公升級。這同時也帶來了許多問題：
看待這些問題一定要從全域性出發，而最重要的是介面的統一，形成一致的標準，讓大家在一條共同的準繩上。
監控
現在大家所做的監控，基本都是在監控機器的狀態。其實在幾百台機器這樣的較小規模下，這樣做的意義並不大。真正應該監控的，應該是程式。而嚴控程式的狀態，只能依賴日誌。
因此，每個架構師都要考慮，如何設計可以監控服務的日誌系統，要提供可監控的介面。是每個架構師要考慮你的服務是怎麼被監控的，你要提供可監控的介面。至於採集間隔，一般來說規模越大，採集粒度越低，規模越小，採集粒度越高。
另外，監控的資訊是pull or push？監控的結果全部需要人來處理麼？日誌是否可以用來作為系統之間互動的資料？這些問題都需要大家根據自己的業務場景不斷探索。
每個公司的運維團隊都在考慮這個問題。你的目的是為了降低你的成本，提高你的效率。請合理的計算你的成本和效率，就是你要把人算進去，而不是就算機器。大家可以通過以下幾個維度來評估：
linux之所以強大，是因為每乙個模組都只負責最簡單的事情，面對輸入和輸出，而輸入和輸出的格式是確定的。分布式架構設計的思路也應如此，同樣的規則，同樣的用法組合在一起是可以發揮巨大作用的。
滴滴出行的分布架構設計想要解決的問題，不只是簡單的機器運維，而是人在研發過程中，如何避免複雜環境中可能面臨的風險，解決由於粗糙的架構設計帶來的效率低下，不可控，不穩定的狀態。
這樣的架構設計帶來的乙個巨大好處是，資訊流在進來的時候進入資訊分發，資訊分發把它分到合適的管道，那個管道處理完再放給下乙個管道。每個管道都只做輸入和輸出的事情，實現高可用、高吞吐。這種方案很多雲服務商都會提供。這樣做的好處時是，我們只需要管理訊息佇列，可以在任意乙個節點把流量複製走。在任何乙個環節中可以拿到它所有的資料，不再依賴日誌，只依賴輸入、輸出。而輸入、輸出是存在硬碟上的，資料不會丟失。
另乙個優點是程序是非同步傳輸的。同步模型乙個很明顯的缺點是在所有的層次中，乙個程序在執行某個請求的時候如果需要一段時間才能返回資訊，那麼這個程序將會一直等待下去，直到收到返回資訊才繼續執行下去。在流量很大的時候，做乙個重試可能某乙個環節就會面臨崩潰了，某個環節的連線數被打滿。
而在這個方案中，連線就只有兩三處，不需要等待資料回報，只需要確認收據接收，而且不需要逐條驗證。成本很低，效能很高。
但這種架構設計顯然不能解決所有的問題。比如用mysql作為儲存等必須同步的服務時，需要給有狀態的服務提供乙個抽象層service，上面的服務可以請求它。大家可以理解為在linux中敲乙個命令要讀乙個檔案，那個檔案是有狀態的，是存在那裡的，而這些模組是沒有狀態的。
滴滴選擇了docker+kubernetes作為分布集群管理解決方案，它的好處是可以直接提供資源管理，資源隔離，部署，公升級，路由等等需求。但是，只有kubernetes是不夠的，kubernetes只能管理那些無狀態的事務。並不是所有的事情都可以完全抽象成無狀態的，有狀態的部分應該如何實現擴容，都要依據具體的業務場景，這是很難的設計。
最後要說的是，沒有完美的方案，如果你自己要開發這個事情，建議大家最好用一種方案，不要每乙個用一種。但是沒辦法，面對不同的研發人員，不同的場景等現實，現在還沒有最終的結論。也希望能借此文，與各位業界同仁共同**。
分布式時代的架構設計（上）
分布式時代的架構設計（下）
京東11.11：商品搜尋系統架構設計解密
網際網路保險o2o平台微服務架構設計
**12306核心模型設計思路和架構設計
九又vr技術負責人官山山：九又vr平台架構設計的深層思考
ophira tel：（010）68476606】
架構設計之道
這個中介軟體系統的本質是希望能夠用分布式的方式來處理一些資料，但是具體的作用涉及到核心技術，所以這裡不能直接說明。但是他的核心思想，就是把資料分發到很多臺機器上來處理，然後需要有一台機器來控制n多台機器的分布式處理 那麼既然是分布式的處理，就肯定涉及到在master中要維護這個集群的一些核心元資料。...
架構之道之軟體架構設計的思想
一 架構師決定著軟體質量 在軟體組織中，架構師的作用舉足輕重。軟體的質量很大程度上是由架構設計的質量來決定的。為了建立高質量的軟體產品 增強產品的競爭力，培養高水平的架構師隊伍，建立有效的架構團隊，提公升架構師隊伍的分析與設計能力，成為企業關注的重心。二 體系結構設計決定著架構的成敗 多年來的實踐告...
架構師之道 面向元件的Web架構設計
一直以來，不斷有工程師詢問我有關架構設計上的問題，很希望能聽聽我的意見。也有工程師原封不動的在自己的專案中引用我的架構設計。最近，部門內的學習小組又在向我約稿 大師，可否分享一些架構設計經驗。說到架構設計，這是架構師最本職的工作。好架構是第一生產力，不良的架構會埋下種種 伏筆 進而讓使用者怨聲載道。...