簡(jiǎn)介

作為架構(gòu)師和設(shè)計(jì)者，我們常把手頭的事情作為工作焦點(diǎn)，很少反思過(guò)去如何。我們應(yīng)該溫故而知新。我從作為skype架構(gòu)組領(lǐng)導(dǎo)的55個(gè)月經(jīng)歷中總結(jié)了6個(gè)經(jīng)驗(yàn)。其中一些是技術(shù)性的，另外一些是架構(gòu)師較為軟性的觀點(diǎn)。首先介紹一下Skype的背景資料。

Skype背景

Skype是讓用戶可以進(jìn)行音頻視頻通話的軟件，也可以撥打普通電話以及發(fā)送短消息。公司成立于2003年，從成立以后就有令人難以置信的成長(zhǎng)曲線。公司現(xiàn)在有超過(guò)五億兩千萬(wàn)注冊(cè)用戶，大約650名員工。這些用戶同時(shí)產(chǎn)生平均21萬(wàn)個(gè)通話，其中大約三分之一包含視頻。這個(gè)數(shù)字大致上是全世界國(guó)際通話的 8%。

不用多加說(shuō)明也能知道，這個(gè)通訊量產(chǎn)生了罕見的擴(kuò)展性挑戰(zhàn)。在Skype一直使用端對(duì)端（peer to peer）技術(shù)作為處理類似挑戰(zhàn)的主要武器。對(duì)等網(wǎng)絡(luò)（核心用C語(yǔ)言實(shí)現(xiàn)）主要是由C++編寫的服務(wù)器端服務(wù)及Postgre數(shù)據(jù)庫(kù)支持組成，并結(jié)合強(qiáng)大的Python腳本。Web服務(wù)使用PHP搭建。

技術(shù)方面

經(jīng)驗(yàn)法則不適用

在作為軟件工程師的職業(yè)生涯中，一些模式會(huì)慢慢浮現(xiàn)出來(lái)，一些經(jīng)驗(yàn)規(guī)則會(huì)顯現(xiàn)出來(lái)。顯然，你愿意無(wú)論何時(shí)何地都一直使用這些規(guī)則。畢竟它們過(guò)去都很有效，是不是？

事實(shí)證明，即使你有好用的錘子，也不要把身邊所有東西都當(dāng)成釘子。在快速變更的現(xiàn)代科技社會(huì)，經(jīng)驗(yàn)法則不會(huì)一直適用。例如，我們看看Skype數(shù)據(jù)庫(kù)是如何架構(gòu)的。

傳統(tǒng)智慧說(shuō)永遠(yuǎn)不要在數(shù)據(jù)庫(kù)里面實(shí)現(xiàn)業(yè)務(wù)邏輯。為何這個(gè)說(shuō)法傳播如此廣泛？大多數(shù)架構(gòu)師都有類似經(jīng)驗(yàn)，這會(huì)導(dǎo)致原始數(shù)據(jù)庫(kù)在硬件方面如巨獸般增長(zhǎng)，無(wú)法運(yùn)行，也非常難維護(hù)。

這個(gè)假冒克蘇魯恐怖神出現(xiàn)的原因是主要數(shù)據(jù)庫(kù)平臺(tái)常常缺乏兩個(gè)重要而且立等可用的特性：橫向劃分?jǐn)?shù)據(jù)庫(kù)的能力（比如根據(jù)數(shù)據(jù)實(shí)體劃分?jǐn)?shù)據(jù)）和縱向劃分?jǐn)?shù)據(jù)庫(kù)的能力（不同的數(shù)據(jù)庫(kù)實(shí)體放入不同數(shù)據(jù)庫(kù)中）。當(dāng)然，我們可以自己建立這兩種特性，但是數(shù)據(jù)庫(kù)管理團(tuán)隊(duì)以外的人常常也想處理類似問(wèn)題。對(duì)于DBA來(lái)說(shuō)這是賴以生存的手段而不是用于解決問(wèn)題的能力。也就是說(shuō)，對(duì)數(shù)據(jù)庫(kù)做劃分或者隊(duì)列的技術(shù)常常要存在于數(shù)據(jù)庫(kù)之外，使得開發(fā)者需要自己處理協(xié)議轉(zhuǎn)換、多種接口、數(shù)據(jù)集成等問(wèn)題。

在Skype，維護(hù)數(shù)據(jù)庫(kù)的這些人恰巧也是Postgre的重要貢獻(xiàn)者。從很早開始他們就拒絕把數(shù)據(jù)庫(kù)看成是系統(tǒng)架構(gòu)角落一個(gè)大而無(wú)當(dāng)?shù)墓拮樱炊苑e極地態(tài)度去學(xué)習(xí)技術(shù)，解決他們遇到的擴(kuò)展性、性能及可維護(hù)性方面的問(wèn)題。像你猜想的一樣，這些還不夠，即使最好的數(shù)據(jù)庫(kù)架構(gòu)也會(huì)在輕率地編碼中被廢掉。幸運(yùn)的是，Skype數(shù)據(jù)庫(kù)管理員從很早開始就掌控了需要進(jìn)入數(shù)據(jù)庫(kù)層的開發(fā)工作，在執(zhí)行了一系列非功能需求、代碼實(shí)現(xiàn)、同事評(píng)審過(guò)程來(lái)確保實(shí)現(xiàn)代碼適合數(shù)據(jù)庫(kù)層以及其他相關(guān)部分的設(shè)計(jì)之前，Skype的DBA不放棄控制。

圖一解釋了他們?nèi)绾问褂眠@些工具建立Skype數(shù)據(jù)庫(kù)架構(gòu)。

這里由四層構(gòu)成：

• 接入層提供了接入數(shù)據(jù)庫(kù)的能力，而且也處理數(shù)據(jù)庫(kù)分區(qū)問(wèn)題（pIProxy）和連接池（pgBouncer）。并且讓開發(fā)者可以透明的使用這些功能。
• 聯(lián)機(jī)事務(wù)處理層，是OLTP數(shù)據(jù)庫(kù)存在的地方。
• 隊(duì)列層，負(fù)責(zé)層與層之間數(shù)據(jù)庫(kù)傳送數(shù)據(jù)和復(fù)制數(shù)據(jù)。
• 內(nèi)部服務(wù)器層，包含了用于記錄、統(tǒng)計(jì)、檢視、批處理和ETL目的的數(shù)據(jù)庫(kù)。

所有這些都是為了保證數(shù)據(jù)庫(kù)可擴(kuò)展性對(duì)于開發(fā)者不是問(wèn)題。我們把必要的業(yè)務(wù)邏輯盡量貼近數(shù)據(jù)，讓它最有效的工作，也就是”業(yè)務(wù)邏輯應(yīng)該遠(yuǎn)離數(shù)據(jù)庫(kù)”的經(jīng)驗(yàn)法則并不適用。當(dāng)然會(huì)有類似發(fā)布、調(diào)試以及單元測(cè)試之類的困難，但是我們不害怕原始數(shù)據(jù)庫(kù)肆虐發(fā)威。

圖一：數(shù)據(jù)庫(kù)層

架構(gòu)模式也是一樣。在工程師之間建立通用技術(shù)詞匯表、提供驗(yàn)證過(guò)的常見技術(shù)問(wèn)題處方是非常重要的事，應(yīng)該小心對(duì)待。Skype的端到端網(wǎng)絡(luò)就是很好的例子。如果問(wèn)題以“設(shè)計(jì)互聯(lián)網(wǎng)電話”這種方式提出，多數(shù)情況下，人們會(huì)設(shè)計(jì)使用SIP來(lái)實(shí)現(xiàn)要求。但是如果Skype通過(guò)基于SIP實(shí)現(xiàn)服務(wù)就不會(huì)給通訊工業(yè)帶來(lái)變化。Skype早期的工程師不愿把自己限制于這件事通常如何完成，而是找到他們能建立的最佳可能方案。

總之，略微不同的組織和技能，就可能有必要建立完全不同的架構(gòu)模式的應(yīng)用。你應(yīng)該隨時(shí)歡迎這些差異對(duì)自己的傳統(tǒng)思維挑戰(zhàn)。

忽視功能架構(gòu)吃盡苦頭

我們很少有機(jī)會(huì)在項(xiàng)目初期搭建階段就作為首席設(shè)計(jì)師參與工作。大多數(shù)工作是修改已有的系統(tǒng)，變更管理就成為架構(gòu)師工作中很重要的部分?，F(xiàn)在我們大多數(shù)變更管理關(guān)注在技術(shù)架構(gòu)和有效地設(shè)計(jì)系統(tǒng)，以確保在實(shí)現(xiàn)變化以后設(shè)計(jì)依然有意義。

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

所有技術(shù)變化來(lái)源于功能上的變化。我們很少僅僅為了重構(gòu)而修改系統(tǒng)。通常情況下會(huì)有一些外部驅(qū)動(dòng)力，需要系統(tǒng)在某些行為上表現(xiàn)得不一樣。這可能是市場(chǎng)上有 了新產(chǎn)品，也可能是法律變更或者是運(yùn)營(yíng)部門的人需要更好的擴(kuò)展。無(wú)論如何，技術(shù)變更常常伴隨著功能上的變化。

所以我們的系統(tǒng)和流程需要保證技術(shù)變化更容易，我們也希望這個(gè)管理過(guò)程比較有序，對(duì)于接手的人來(lái)說(shuō)不是象意大利面條一樣雜亂?？墒鞘裁词枪δ苄宰兓?？誰(shuí)來(lái)關(guān)注系統(tǒng)的功能性以及確保變化不會(huì)讓系統(tǒng)更混亂？

我用例子來(lái)說(shuō)明一下。

在過(guò)去四年一直常常有人強(qiáng)烈要求我修改Skype的網(wǎng)絡(luò)存儲(chǔ)架構(gòu)，即使我證明每個(gè)微小的變化都會(huì)伴隨痛苦。在互聯(lián)網(wǎng)上銷售四個(gè)產(chǎn)品不是什么復(fù)雜的事情，大多數(shù)時(shí)間整個(gè)系統(tǒng)就是照常運(yùn)行，即使有一些問(wèn)題被發(fā)現(xiàn)，緊接著就解決了。

這就是原因。

圖2展示所有Skype網(wǎng)絡(luò)存儲(chǔ)的功能組件。大約有200個(gè)。圖表不是很清晰準(zhǔn)確，只想展示整個(gè)應(yīng)用系統(tǒng)的功能性和復(fù)雜度。這是不計(jì)其數(shù)的變化、添加、修改、法律問(wèn)題、微調(diào)造成的結(jié)果。所有這些當(dāng)然是都有事出有因和有價(jià)值的。

相當(dāng)多的架構(gòu)師沒(méi)有仔細(xì)考量技術(shù)變化，結(jié)果導(dǎo)致意大利面條般的混亂，應(yīng)用系統(tǒng)因?yàn)椴患铀伎嫉淖兓诠δ苌献兊没靵y。這不意味著作為軟件架構(gòu)師，我有意從開始就阻止這些問(wèn)題。但是如果不對(duì)系統(tǒng)功能性架構(gòu)足夠小心，就會(huì)導(dǎo)致功能架構(gòu)的支離破碎。結(jié)果只能是凌亂的技術(shù)架構(gòu)。

圖2：網(wǎng)絡(luò)存儲(chǔ)功能架構(gòu)

總而言之，應(yīng)該時(shí)刻對(duì)你要維護(hù)的系統(tǒng)功能保持關(guān)注。修改技術(shù)架構(gòu)，也要經(jīng)常維護(hù)功能架構(gòu)。

簡(jiǎn)單的事情有效果

簡(jiǎn)單說(shuō)，任何需要超過(guò)三句話來(lái)解釋給其他人的事情，都不會(huì)實(shí)際有效的工作。這就是為何REST可以實(shí)際應(yīng)用而SOAP則做不到，也是為什么人們更喜歡Hibernate而不喜歡J2EE bean的原因。

PgQ[1]就是稍微簡(jiǎn)化需求會(huì)產(chǎn)生挺好結(jié)果的例子。對(duì)于所有消息系統(tǒng)來(lái)說(shuō)，消息可靠性是主要性能問(wèn)題之一。為不同客戶端標(biāo)記消息是”已使用“是很讓人頭 疼的，需要存儲(chǔ)這些消息而且保證它們不會(huì)阻塞還未消費(fèi)的數(shù)據(jù)存儲(chǔ)?？墒钱?dāng)承諾每個(gè)消息至少分發(fā)一次而不是僅僅一次，這些頭疼消失了一大半。這對(duì)大多數(shù)情況下的客戶端應(yīng)用是可以接受的，只要允許它們自由實(shí)現(xiàn)自己需要的校驗(yàn)機(jī)制。

簡(jiǎn)單解決方案的另一個(gè)效果是促使你思考，而多思多想總是好的。設(shè)計(jì)有界面的WSDL是很有趣，但是有多大程度真正關(guān)注本質(zhì)問(wèn)題，比如在哪些類型哪些對(duì)象應(yīng)該進(jìn)入其他對(duì)象以及你希望是什么樣子的？就是如此。

總之，朝著讓系統(tǒng)應(yīng)用更為簡(jiǎn)單的目標(biāo)去迎接所有需求、定律以及標(biāo)準(zhǔn)，毫不留情的去掉所有導(dǎo)致系統(tǒng)緩慢的多余脂肪。

非技術(shù)角度

危險(xiǎn)的流行語(yǔ)

時(shí)常會(huì)有些人以這樣一種“很不錯(cuò)”的方式構(gòu)建軟件：發(fā)明一個(gè)吸引人的名字，在大家知道底細(xì)之前，在PowerPoint上到處描畫這個(gè)名字。不幸的是，大多數(shù)這些想法都非常復(fù)雜，很少有實(shí)用性。比如J2EE、CORBA、SOA，都不是為了解決日常問(wèn)題而設(shè)計(jì)的，它們有時(shí)候能起作用，但那是很偶然的。

在Skype，我們?cè)?jīng)多次出現(xiàn)類似問(wèn)題，也相當(dāng)成功地處理了它們。盡管我們聽說(shuō)某個(gè)組織有非常不同的經(jīng)歷。在某些時(shí)候，我們看到不少大型應(yīng)用開發(fā)商最近發(fā)現(xiàn)它們的整個(gè)工程管理系統(tǒng)被替代了。

某個(gè)專家說(shuō)了這個(gè)故事。

管理高層在表面上有一些時(shí)間需要處理特定的問(wèn)題，比如聽從某些咨詢師告訴他們的建議，定制主要產(chǎn)品和全面進(jìn)入云計(jì)算以及SOA這些決策會(huì)幫助他們。所以他們開始跟工程領(lǐng)導(dǎo)者談話，盡管后者報(bào)之以空洞的眼神。就跟呆波特四格漫畫畫出來(lái)的一樣，這些不過(guò)就是一大泡騙人的萬(wàn)靈油。過(guò)了一陣，不可避免的事情發(fā)生了，管理層厭倦了像是傻瓜一樣被蒙騙（咨詢師收費(fèi)是很昂貴的），當(dāng)下一步都開始了，還是沒(méi)人去解決開始時(shí)的問(wèn)題。即使擺脫了那些不勝任且總唱反調(diào)的人，這個(gè)公司也可能無(wú)法恢復(fù)元?dú)狻?/p>

這是架構(gòu)師的失敗，真的。

這個(gè)故事展現(xiàn)了架構(gòu)師責(zé)任的二元性：首先是我們需要仔細(xì)考慮這些想法，只把實(shí)際上有意義的東西放入系統(tǒng)，讓系統(tǒng)繼續(xù)運(yùn)行。另一方面，我們不能忽略這些常常是無(wú)意義的術(shù)語(yǔ)，因?yàn)檎鎸?shí)問(wèn)題可能就隱藏在后面。不容易找到根源問(wèn)題的原因是客戶的管理層缺少一些我們能理解的詞匯來(lái)表達(dá)需求。另外，當(dāng)某個(gè)概念跳出來(lái)，就好像已經(jīng)解決了困擾客戶很久的問(wèn)題。他們撿起這根繩子就變得自以為有力量，從而在組織里面大肆使用它。從技術(shù)角度 回應(yīng)這些情況（比如宣稱整個(gè)事情是假的）不能解決運(yùn)行中碰到的根本問(wèn)題，也很沒(méi)有建設(shè)性。當(dāng)領(lǐng)導(dǎo)發(fā)現(xiàn)組織有問(wèn)題并且相信他找到了解決方案，而你拒絕實(shí)現(xiàn)這個(gè)方案甚至拒絕討論，你也就出局了。如果你自己不讓這些流行語(yǔ)變得有意義，就會(huì)有一堆顧問(wèn)沒(méi)完沒(méi)了幫你定義它們。

總而言之，用戶很少有意糊弄你，你也不應(yīng)該糊弄用戶。你應(yīng)該跟用戶一起找到并解決真正的問(wèn)題。因?yàn)樾刨嚹悖愕目偛脮?huì)有更好的事情去做，而不是丟一些聽了讓人發(fā)抖的無(wú)意義的廣告詞給你。

架構(gòu)師需要配合你的組織

大多數(shù)人每天工作是為了把事情盡可能做到最好。架構(gòu)師則是為了建立可無(wú)限擴(kuò)展及模塊化的偉大系統(tǒng)架構(gòu)而工作。

實(shí)際這不是付錢讓我們做的事情。

每個(gè)系統(tǒng)都存在特定的上下文環(huán)境。這個(gè)環(huán)境包括已有技術(shù)系統(tǒng)，也包括技能、態(tài)度和人們處理問(wèn)題的企業(yè)文化。甚至更為重要的是，所有系統(tǒng)存在于特定商業(yè)環(huán)境 中。初創(chuàng)企業(yè)與巨型電信運(yùn)營(yíng)商是不一樣的，銀行與政府機(jī)關(guān)是不一樣的。很顯然，沒(méi)有一個(gè)好的或優(yōu)美的架構(gòu)能適合不同商業(yè)和組織結(jié)構(gòu)的變化。架構(gòu)需要適應(yīng)組織，幫助他們達(dá)到目標(biāo)（或者沒(méi)有達(dá)到）。這往往意味著需要壓抑自己建立優(yōu)美系統(tǒng)的渴望，因?yàn)橥ǔＧ闆r下你所認(rèn)為優(yōu)美的系統(tǒng)和組織需要是兩回事。

現(xiàn)實(shí)就是，把技術(shù)負(fù)債[2]的概念放在一邊，不要帶著債務(wù)去工作?？赡芗夹g(shù)上不十分先進(jìn)，也沒(méi)有非常完美，但是能很好幫助你的組織。

在Skype的環(huán)境中，這一直是個(gè)很重要的問(wèn)題。我們大量用戶使用的主要服務(wù)由對(duì)等網(wǎng)絡(luò)提供。對(duì)等網(wǎng)絡(luò)是非常漂亮的東西，但不一定是所謂的“干凈 “或”簡(jiǎn)單“。對(duì)于擁有傳統(tǒng)web應(yīng)用背景的人來(lái)說(shuō)端對(duì)端是非?？尚Φ?。搭建、維護(hù)、調(diào)試、上線、測(cè)試和解釋這事是比較困難的，特別是在這個(gè)量級(jí)上，我們是唯一運(yùn)營(yíng)對(duì)等網(wǎng)絡(luò)的公司。而且，總有咨詢師施加壓力要我們回退到象其他人一樣基于服務(wù)器的架構(gòu)。

從技術(shù)角度來(lái)說(shuō)，這個(gè)壓力可以理解，而且有一堆原因說(shuō)明做這種切換是合理的。當(dāng)看到這個(gè)改變可能影響到我們的業(yè)務(wù)模型的時(shí)候，決定就變得困難。例如，我們的用戶在視頻通話流量上同YouTube的視頻流量是同一數(shù)量級(jí)。由于使用了端對(duì)端架構(gòu)，Skype并沒(méi)有在硬件上大量投入。對(duì)端對(duì)端架構(gòu)的更改很大幾率上意味著免費(fèi)視頻電話服務(wù)的結(jié)束，也就意味著沒(méi)有補(bǔ)貼費(fèi)形式的商業(yè)模式的結(jié)束。因此，無(wú)論我如何考量和是否喜歡使用端對(duì)端架構(gòu)，它都會(huì)在比較中占上風(fēng)。

總之，所有你架構(gòu)方面的決定都需要根據(jù)組織所處環(huán)境而不是個(gè)人喜好來(lái)制定。

溝通很重要

我們前面看到過(guò)，如何制定架構(gòu)需要根據(jù)業(yè)務(wù)功能而定。因?yàn)橄到y(tǒng)架構(gòu)正確與否決定了業(yè)務(wù)功能正確與否，很合理的得出結(jié)論：人們對(duì)系統(tǒng)架構(gòu)很感興趣，是因?yàn)樯虡I(yè)利益的緣故。但是系著粉絲巾的市民如何了解開發(fā)者發(fā)現(xiàn)的錯(cuò)綜復(fù)雜的系統(tǒng)，以及軟件工程師如何能找到業(yè)務(wù)功能？

答案極為簡(jiǎn)單，就是溝通。兩方面都需要伸手跨過(guò)文化阻隔開始交談。架構(gòu)師的工作是把業(yè)務(wù)策略翻譯成技術(shù)。這正意味著溝通。

這非常不容易，要知道獲得管理層的尊重是很困難的。但是如果沒(méi)有彼此尊重和溝通，工程師只能忍受武斷的技術(shù)決定，業(yè)務(wù)也不得不同限制其發(fā)展的系統(tǒng)打交道。如果沒(méi)有溝通，也就沒(méi)有理解，更談不上合作。

圖三：架構(gòu)師組織

溝通對(duì)于架構(gòu)的另一個(gè)很明顯用戶，也就是開發(fā)者也是很重要的。如果沒(méi)有開發(fā)者盡善盡美的實(shí)現(xiàn)，架構(gòu)就不能變成服務(wù)用戶的實(shí)際代碼，也就無(wú)法為業(yè)務(wù)產(chǎn)生價(jià)值。再重復(fù)一次，信任與互相尊重是很關(guān)鍵的。

圖三展示了skype架構(gòu)師的一般組織圖，沒(méi)有必須的團(tuán)隊(duì)或者匯報(bào)層次界定，就是非常簡(jiǎn)單的關(guān)聯(lián)模型。中心部分是架構(gòu)師組，主要維護(hù)關(guān)系和制定通用方向。 業(yè)務(wù)部門架構(gòu)師（稱為解決方案架構(gòu)師，非常類似分析師的角色）和開發(fā)組架構(gòu)師（稱為技術(shù)架構(gòu)師）對(duì)他們作補(bǔ)充。前者負(fù)責(zé)幫助業(yè)務(wù)部門把想法整理成為技術(shù)可 行的形式，以及提供解釋技術(shù)合理與否的反饋。后者負(fù)責(zé)監(jiān)督開發(fā)及細(xì)化架構(gòu)師提供的高層設(shè)計(jì)。

這個(gè)架構(gòu)師組織在不同利益關(guān)系方提供了足夠的組織結(jié)構(gòu)和協(xié)調(diào)，同時(shí)還有一定的自由度。當(dāng)然，你需要找到適合你們組織的模型，無(wú)論解決方案如何，都需要促進(jìn)你的架構(gòu)師與重要客戶之間的溝通。

總而言之，與人交流！

結(jié)論

像你看到的，這些年的經(jīng)驗(yàn)教會(huì)我很多。如果你感覺(jué)熟悉和瑣碎，你可能已經(jīng)有過(guò)類似經(jīng)驗(yàn)了。希望能比我經(jīng)歷過(guò)的好一些。總結(jié)一下架構(gòu)師需要在這個(gè)時(shí)間和年齡達(dá)到成功的兩個(gè)主要領(lǐng)悟：

1. 無(wú)論你過(guò)去工作如何，比如為Facebook或者Skype這樣的巨頭工作，或者曾經(jīng)跟你本地的CIO社區(qū)聊過(guò)天，應(yīng)該只作為幫助你們組織找到解決方案的起點(diǎn)，不多，也不少。
2. 技術(shù)技能是架構(gòu)師的必備條件。你需要有技術(shù)技能來(lái)獲取這個(gè)職位，但是情商和理解組織業(yè)務(wù)的能力才定義了你有多優(yōu)秀。

References

[1] “Skytools page at pgfounry.”

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

查看英文原文：Learnings from Five Years as a Skype Architect

給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請(qǐng)郵件至editors@cn.infoq.com。也歡迎大家加入到InfoQ中文站用戶討論組中與我們的編輯和其他讀者朋友交流。