五年Skype架構(gòu)師之路的感言

0 評(píng)論 2519 瀏覽 4 收藏 21 分鐘

簡(jiǎn)介

作為架構(gòu)師和設(shè)計(jì)者,我們常把手頭的事情作為工作焦點(diǎn),很少反思過去如何。我們應(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)在有超過五億兩千萬注冊(cè)用戶,大約650名員工。這些用戶同時(shí)產(chǎn)生平均21萬個(gè)通話,其中大約三分之一包含視頻。這個(gè)數(shù)字大致上是全世界國(guó)際通話的 8%。

不用多加說明也能知道,這個(gè)通訊量產(chǎn)生了罕見的擴(kuò)展性挑戰(zhàn)。在Skype一直使用端對(duì)端(peer to peer)技術(shù)作為處理類似挑戰(zhàn)的主要武器。對(duì)等網(wǎng)絡(luò)(核心用C語言實(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)出來,一些經(jīng)驗(yàn)規(guī)則會(huì)顯現(xiàn)出來。顯然,你愿意無論何時(shí)何地都一直使用這些規(guī)則。畢竟它們過去都很有效,是不是?

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

傳統(tǒng)智慧說永遠(yuǎn)不要在數(shù)據(jù)庫(kù)里面實(shí)現(xiàn)業(yè)務(wù)邏輯。為何這個(gè)說法傳播如此廣泛?大多數(shù)架構(gòu)師都有類似經(jīng)驗(yàn),這會(huì)導(dǎo)致原始數(shù)據(jù)庫(kù)在硬件方面如巨獸般增長(zhǎng),無法運(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ì)以外的人常常也想處理類似問題。對(duì)于DBA來說這是賴以生存的手段而不是用于解決問題的能力。也就是說,對(duì)數(shù)據(jù)庫(kù)做劃分或者隊(duì)列的技術(shù)常常要存在于數(shù)據(jù)庫(kù)之外,使得開發(fā)者需要自己處理協(xié)議轉(zhuǎn)換、多種接口、數(shù)據(jù)集成等問題。

在Skype,維護(hù)數(shù)據(jù)庫(kù)的這些人恰巧也是Postgre的重要貢獻(xiàn)者。從很早開始他們就拒絕把數(shù)據(jù)庫(kù)看成是系統(tǒng)架構(gòu)角落一個(gè)大而無當(dāng)?shù)墓拮?,反而以積極地態(tài)度去學(xué)習(xí)技術(shù),解決他們遇到的擴(kuò)展性、性能及可維護(hù)性方面的問題。像你猜想的一樣,這些還不夠,即使最好的數(shù)據(jù)庫(kù)架構(gòu)也會(huì)在輕率地編碼中被廢掉。幸運(yùn)的是,Skype數(shù)據(jù)庫(kù)管理員從很早開始就掌控了需要進(jìn)入數(shù)據(jù)庫(kù)層的開發(fā)工作,在執(zhí)行了一系列非功能需求、代碼實(shí)現(xiàn)、同事評(píng)審過程來確保實(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ū)問題(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ā)者不是問題。我們把必要的業(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)證過的常見技術(shù)問題處方是非常重要的事,應(yīng)該小心對(duì)待。Skype的端到端網(wǎng)絡(luò)就是很好的例子。如果問題以“設(shè)計(jì)互聯(lián)網(wǎng)電話”這種方式提出,多數(shù)情況下,人們會(huì)設(shè)計(jì)使用SIP來實(shí)現(xiàn)要求。但是如果Skype通過基于SIP實(shí)現(xiàn)服務(wù)就不會(huì)給通訊工業(yè)帶來變化。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ù)變化來源于功能上的變化。我們很少僅僅為了重構(gòu)而修改系統(tǒng)。通常情況下會(huì)有一些外部驅(qū)動(dòng)力,需要系統(tǒng)在某些行為上表現(xiàn)得不一樣。這可能是市場(chǎng)上有 了新產(chǎn)品,也可能是法律變更或者是運(yùn)營(yíng)部門的人需要更好的擴(kuò)展。無論如何,技術(shù)變更常常伴隨著功能上的變化。

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

我用例子來說明一下。

在過去四年一直常常有人強(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)行,即使有一些問題被發(fā)現(xiàn),緊接著就解決了。

這就是原因。

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

相當(dāng)多的架構(gòu)師沒有仔細(xì)考量技術(shù)變化,結(jié)果導(dǎo)致意大利面條般的混亂,應(yīng)用系統(tǒng)因?yàn)椴患铀伎嫉淖兓诠δ苌献兊没靵y。這不意味著作為軟件架構(gòu)師,我有意從開始就阻止這些問題。但是如果不對(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)單說,任何需要超過三句話來解釋給其他人的事情,都不會(huì)實(shí)際有效的工作。這就是為何REST可以實(shí)際應(yīng)用而SOAP則做不到,也是為什么人們更喜歡Hibernate而不喜歡J2EE bean的原因。

PgQ[1]就是稍微簡(jiǎn)化需求會(huì)產(chǎn)生挺好結(jié)果的例子。對(duì)于所有消息系統(tǒng)來說,消息可靠性是主要性能問題之一。為不同客戶端標(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ì)問題,比如在哪些類型哪些對(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)的流行語

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

溝通很重要

我們前面看到過,如何制定架構(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)單,就是溝通。兩方面都需要伸手跨過文化阻隔開始交談。架構(gòu)師的工作是把業(yè)務(wù)策略翻譯成技術(shù)。這正意味著溝通。

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

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

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

圖三展示了skype架構(gòu)師的一般組織圖,沒有必須的團(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)然,你需要找到適合你們組織的模型,無論解決方案如何,都需要促進(jìn)你的架構(gòu)師與重要客戶之間的溝通。

總而言之,與人交流!

結(jié)論

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

  1. 無論你過去工作如何,比如為Facebook或者Skype這樣的巨頭工作,或者曾經(jīng)跟你本地的CIO社區(qū)聊過天,應(yīng)該只作為幫助你們組織找到解決方案的起點(diǎn),不多,也不少。
  2. 技術(shù)技能是架構(gòu)師的必備條件。你需要有技術(shù)技能來獲取這個(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


感謝曹云飛對(duì)本文的審校。

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

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 目前還沒評(píng)論,等你發(fā)揮!