五年 Skype 架構師之路的感言（轉)

https://www.infoq.cn/article/learnings-five-years-skype-architect

簡介

作為架構師和設計者，我們常把手頭的事情作為工作焦點，很少反思過去如何。我們應該溫故而知新。我從作為 skype 架構組上司的 55 個月經曆中總結了 6 個經驗。其中一些是技術性的，另外一些是架構師較為軟性的觀點。首先介紹一下 Skype 的背景資料。

Skype 背景

Skype 是讓使用者可以進行音頻視訊通話的軟體，也可以撥打普通電話以及發送短消息。公司成立于 2003 年，從成立以後就有令人難以置信的成長曲線。公司現在有超過五億兩千萬注冊使用者，大約 650 名員工。這些使用者同時産生平均 21 萬個通話，其中大約三分之一包含視訊。這個數字大緻上是全世界國際通話的 8%。

不用多加說明也能知道，這個通訊量産生了罕見的擴充性挑戰。在 Skype 一直使用端對端（peer to peer）技術作為處理類似挑戰的主要武器。對等網絡（核心用 C 語言實作）主要是由 C++ 編寫的伺服器端服務及 Postgre 資料庫支援組成，并結合強大的 Python 腳本。Web 服務使用 PHP 搭建。

技術方面

經驗法則不适用

在作為軟體工程師的職業生涯中，一些模式會慢慢浮現出來，一些經驗規則會顯現出來。顯然，你願意無論何時何地都一直使用這些規則。畢竟它們過去都很有效，是不是？

事實證明，即使你有好用的錘子，也不要把身邊所有東西都當成釘子。在快速變更的現代科技社會，經驗法則不會一直适用。例如，我們看看 Skype 資料庫是如何架構的。

傳統智慧說永遠不要在資料庫裡面實作業務邏輯。為何這個說法傳播如此廣泛？大多數架構師都有類似經驗，這會導緻原始資料庫在硬體方面如巨獸般增長，無法運作，也非常難維護。

這個假冒克蘇魯恐怖神出現的原因是主要資料庫平台常常缺乏兩個重要而且立等可用的特性：橫向劃分資料庫的能力（比如根據資料實體劃分資料）和縱向劃分資料庫的能力（不同的資料庫實體放入不同資料庫中）。當然，我們可以自己建立這兩種特性，但是資料庫管理團隊以外的人常常也想處理類似問題。對于 DBA 來說這是賴以生存的手段而不是用于解決問題的能力。也就是說，對資料庫做劃分或者隊列的技術常常要存在于資料庫之外，使得開發者需要自己處理協定轉換、多種接口、資料內建等問題。

在 Skype，維護資料庫的這些人恰巧也是 Postgre 的重要貢獻者。從很早開始他們就拒絕把資料庫看成是系統架構角落一個大而無當的罐子，反而以積極地态度去學習技術，解決他們遇到的擴充性、性能及可維護性方面的問題。像你猜想的一樣，這些還不夠，即使最好的資料庫架構也會在輕率地編碼中被廢掉。幸運的是，Skype 資料庫管理者從很早開始就掌控了需要進入資料庫層的開發工作，在執行了一系列非功能需求、代碼實作、同僚評審過程來確定實作代碼适合資料庫層以及其他相關部分的設計之前，Skype 的 DBA 不放棄控制。

圖一解釋了他們如何使用這些工具建立 Skype 資料庫架構。

這裡由四層構成：

接入層提供了接入資料庫的能力，而且也處理資料庫分區問題（pIProxy）和連接配接池（pgBouncer）。并且讓開發者可以透明的使用這些功能。

聯機事務處理層，是 OLTP 資料庫存在的地方。

隊列層，負責層與層之間資料庫傳送資料和複制資料。

内部伺服器層，包含了用于記錄、統計、檢視、批處理和 ETL 目的的資料庫。

所有這些都是為了保證資料庫可擴充性對于開發者不是問題。我們把必要的業務邏輯盡量貼近資料，讓它最有效的工作，也就是"業務邏輯應該遠離資料庫”的經驗法則并不适用。當然會有類似釋出、調試以及單元測試之類的困難，但是我們不害怕原始資料庫肆虐發威。

圖一：資料庫層

架構模式也是一樣。在工程師之間建立通用技術詞彙表、提供驗證過的常見技術問題處方是非常重要的事，應該小心對待。Skype 的端到端網絡就是很好的例子。如果問題以“設計網際網路電話”這種方式提出，多數情況下，人們會設計使用 SIP 來實作要求。但是如果 Skype 通過基于 SIP 實作服務就不會給通訊工業帶來變化。Skype 早期的工程師不願把自己限制于這件事通常如何完成，而是找到他們能建立的最佳可能方案。

總之，略微不同的組織和技能，就可能有必要建立完全不同的架構模式的應用。你應該随時歡迎這些差異對自己的傳統思維挑戰。

忽視功能架構吃盡苦頭

我們很少有機會在項目初期搭建階段就作為首席設計師參與工作。大多數工作是修改已有的系統，變更管理就成為架構師工作中很重要的部分。現在我們大多數變更管理關注在技術架構和有效地設計系統，以確定在實作變化以後設計依然有意義。

可惜是這不是故事的全部。

所有技術變化來源于功能上的變化。我們很少僅僅為了重構而修改系統。通常情況下會有一些外部驅動力，需要系統在某些行為上表現得不一樣。這可能是市場上有 了新産品，也可能是法律變更或者是營運部門的人需要更好的擴充。無論如何，技術變更常常伴随着功能上的變化。

是以我們的系統和流程需要保證技術變化更容易，我們也希望這個管理過程比較有序，對于接手的人來說不是象意大利面條一樣雜亂。可是什麼是功能性變化？誰來關注系統的功能性以及確定變化不會讓系統更混亂？

我用例子來說明一下。

在過去四年一直常常有人強烈要求我修改 Skype 的網絡存儲架構，即使我證明每個微小的變化都會伴随痛苦。在網際網路上銷售四個産品不是什麼複雜的事情，大多數時間整個系統就是照常運作，即使有一些問題被發現，緊接着就解決了。

這就是原因。

圖 2 展示所有 Skype 網絡存儲的功能元件。大約有 200 個。圖表不是很清晰準确，隻想展示整個應用系統的功能性和複雜度。這是不計其數的變化、添加、修改、法律問題、微調造成的結果。所有這些當然是都有事出有因和有價值的。

相當多的架構師沒有仔細考量技術變化，結果導緻意大利面條般的混亂，應用系統因為不加思考的變化在功能上變得混亂。這不意味着作為軟體架構師，我有意從開始就阻止這些問題。但是如果不對系統功能性架構足夠小心，就會導緻功能架構的支離破碎。結果隻能是淩亂的技術架構。

圖 2：網絡存儲功能架構

總而言之，應該時刻對你要維護的系統功能保持關注。修改技術架構，也要經常維護功能架構。

簡單的事情有效果

簡單說，任何需要超過三句話來解釋給其他人的事情，都不會實際有效的工作。這就是為何 REST 可以實際應用而 SOAP 則做不到，也是為什麼人們更喜歡 Hibernate 而不喜歡 J2EE bean 的原因。

PgQ[1] 就是稍微簡化需求會産生挺好結果的例子。對于所有消息系統來說，消息可靠性是主要性能問題之一。為不同用戶端标記消息是”已使用“是很讓人頭 疼的，需要存儲這些消息而且保證它們不會阻塞還未消費的資料存儲。可是當承諾每個消息至少分發一次而不是僅僅一次，這些頭疼消失了一大半。這對大多數情況下的用戶端應用是可以接受的，隻要允許它們自由實作自己需要的校驗機制。

簡單解決方案的另一個效果是促使你思考，而多思多想總是好的。設計有界面的 WSDL 是很有趣，但是有多大程度真正關注本質問題，比如在哪些類型哪些對象應該進入其他對象以及你希望是什麼樣子的？就是如此。

總之，朝着讓系統應用更為簡單的目标去迎接所有需求、定律以及标準，毫不留情的去掉所有導緻系統緩慢的多餘脂肪。

非技術角度

危險的流行語

時常會有些人以這樣一種“很不錯”的方式建構軟體：發明一個吸引人的名字，在大家知道底細之前，在 PowerPoint 上到處描畫這個名字。不幸的是，大多數這些想法都非常複雜，很少有實用性。比如 J2EE、CORBA、SOA，都不是為了解決日常問題而設計的，它們有時候能起作用，但那是很偶然的。

在 Skype，我們曾經多次出現類似問題，也相當成功地處理了它們。盡管我們聽說某個組織有非常不同的經曆。在某些時候，我們看到不少大型應用開發商最近發現它們的整個工程管理系統被替代了。

某個專家說了這個故事。

管理高層在表面上有一些時間需要處理特定的問題，比如聽從某些咨詢師告訴他們的建議，定制主要産品和全面進入雲計算以及 SOA 這些決策會幫助他們。是以他們開始跟工程上司者談話，盡管後者報之以空洞的眼神。就跟呆波特四格漫畫畫出來的一樣，這些不過就是一大泡騙人的萬靈油。過了一陣，不可避免的事情發生了，管理層厭倦了像是傻瓜一樣被蒙騙（咨詢師收費是很昂貴的），當下一步都開始了，還是沒人去解決開始時的問題。即使擺脫了那些不勝任且總唱反調的人，這個公司也可能無法恢複元氣。

這是架構師的失敗，真的。

這個故事展現了架構師責任的二進制性：首先是我們需要仔細考慮這些想法，隻把實際上有意義的東西放入系統，讓系統繼續運作。另一方面，我們不能忽略這些常常是無意義的術語，因為真實問題可能就隐藏在後面。不容易找到根源問題的原因是客戶的管理層缺少一些我們能了解的詞彙來表達需求。另外，當某個概念跳出來，就好像已經解決了困擾客戶很久的問題。他們撿起這根繩子就變得自以為有力量，進而在組織裡面大肆使用它。從技術角度 回應這些情況（比如宣稱整個事情是假的）不能解決運作中碰到的根本問題，也很沒有建設性。當上司發現組織有問題并且相信他找到了解決方案，而你拒絕實作這個方案甚至拒絕讨論，你也就出局了。如果你自己不讓這些流行語變得有意義，就會有一堆顧問沒完沒了幫你定義它們。

總而言之，使用者很少有意糊弄你，你也不應該糊弄使用者。你應該跟使用者一起找到并解決真正的問題。因為信賴你，你的總裁會有更好的事情去做，而不是丢一些聽了讓人發抖的無意義的廣告詞給你。

架構師需要配合你的組織

大多數人每天工作是為了把事情盡可能做到最好。架構師則是為了建立可無限擴充及子產品化的偉大系統架構而工作。

實際這不是付錢讓我們做的事情。

每個系統都存在特定的上下文環境。這個環境包括已有技術系統，也包括技能、态度和人們處理問題的企業文化。甚至更為重要的是，所有系統存在于特定商業環境 中。初創企業與巨型電信營運商是不一樣的，銀行與政府機關是不一樣的。很顯然，沒有一個好的或優美的架構能适合不同商業群組織結構的變化。架構需要适應組織，幫助他們達到目标（或者沒有達到）。這往往意味着需要壓抑自己建立優美系統的渴望，因為通常情況下你所認為優美的系統群組織需要是兩回事。

現實就是，把技術負債 [2] 的概念放在一邊，不要帶着債務去工作。可能技術上不十分先進，也沒有非常完美，但是能很好幫助你的組織。

在 Skype 的環境中，這一直是個很重要的問題。我們大量使用者使用的主要服務由對等網絡提供。對等網絡是非常漂亮的東西，但不一定是所謂的“幹淨 “或”簡單“。對于擁有傳統 web 應用背景的人來說端對端是非常可笑的。搭建、維護、調試、上線、測試和解釋這事是比較困難的，特别是在這個量級上，我們是唯一營運對等網絡的公司。而且，總有咨詢師施加壓力要我們回退到象其他人一樣基于伺服器的架構。

從技術角度來說，這個壓力可以了解，而且有一堆原因說明做這種切換是合理的。當看到這個改變可能影響到我們的業務模型的時候，決定就變得困難。例如，我們的使用者在視訊通話流量上同 YouTube 的視訊流量是同一數量級。由于使用了端對端架構，Skype 并沒有在硬體上大量投入。對端對端架構的更改很大幾率上意味着免費視訊電話服務的結束，也就意味着沒有補貼費形式的商業模式的結束。是以，無論我如何考量和是否喜歡使用端對端架構，它都會在比較中占上風。

總之，所有你架構方面的決定都需要根據組織所處環境而不是個人喜好來制定。

溝通很重要

我們前面看到過，如何制定架構需要根據業務功能而定。因為系統架構正确與否決定了業務功能正确與否，很合理的得出結論：人們對系統架構很感興趣，是因為商業利益的緣故。但是系着粉絲巾的市民如何了解開發者發現的錯綜複雜的系統，以及軟體工程師如何能找到業務功能？

答案極為簡單，就是溝通。兩方面都需要伸手跨過文化阻隔開始交談。架構師的工作是把業務政策翻譯成技術。這正意味着溝通。

這非常不容易，要知道獲得管理層的尊重是很困難的。但是如果沒有彼此尊重和溝通，工程師隻能忍受武斷的技術決定，業務也不得不同限制其發展的系統打交道。如果沒有溝通，也就沒有了解，更談不上合作。

圖三：架構師組織

溝通對于架構的另一個很明顯使用者，也就是開發者也是很重要的。如果沒有開發者盡善盡美的實作，架構就不能變成服務使用者的實際代碼，也就無法為業務産生價值。再重複一次，信任與互相尊重是很關鍵的。

圖三展示了 skype 架構師的一般組織圖，沒有必須的團隊或者彙報層次界定，就是非常簡單的關聯模型。中心部分是架構師組，主要維護關系和制定通用方向。 業務部門架構師（稱為解決方案架構師，非常類似分析師的角色）和開發組架構師（稱為技術架構師）對他們作補充。前者負責幫助業務部門把想法整理成為技術可 行的形式，以及提供解釋技術合理與否的回報。後者負責監督開發及細化架構師提供的高層設計。

這個架構師組織在不同利益關系方提供了足夠的組織結構和協調，同時還有一定的自由度。當然，你需要找到适合你們組織的模型，無論解決方案如何，都需要促進你的架構師與重要客戶之間的溝通。

總而言之，與人交流！

結論

像你看到的，這些年的經驗教會我很多。如果你感覺熟悉和瑣碎，你可能已經有過類似經驗了。希望能比我經曆過的好一些。總結一下架構師需要在這個時間和年齡達到成功的兩個主要領悟：

無論你過去工作如何，比如為 Facebook 或者 Skype 這樣的巨頭工作，或者曾經跟你本地的 CIO 社群聊過天，應該隻作為幫助你們組織找到解決方案的起點，不多，也不少。

技術技能是架構師的必備條件。你需要有技術技能來擷取這個職位，但是情商和了解組織業務的能力才定義了你有多優秀。

References

[1] “Skytools page at pgfounry.”

[2] M. Fowler, “Technical debt,” August 2004. 12

檢視英文原文：Learnings from Five Years as a Skype Architect