PHP開發(fā)者構(gòu)建分佈式應用需警惕的八大誤區(qū)

Peter Deutsch在1997年提出了七個分佈式計算的誤區(qū)，後來James Gosling（Java之父）又補充了一個。這些誤區(qū)對PHP開發(fā)者來說至關(guān)重要，因為我們每天都在構(gòu)建分佈式應用：mashup、與SOAP和REST服務交互的應用、通過Facebook、Google或Twitter API進行用戶身份驗證、從遠程數(shù)據(jù)庫和緩存服務檢索信息等等。我們構(gòu)建的正是分佈式計算應用。因此，理解這八個誤區(qū)及其影響至關(guān)重要。

關(guān)鍵要點:

• Peter Deutsch和James Gosling提出的八大分佈式計算誤區(qū)對PHP開發(fā)者至關(guān)重要：網(wǎng)絡(luò)可靠、延遲為零、帶寬無限、網(wǎng)絡(luò)安全、拓撲不變、只有一個管理員、傳輸成本為零以及網(wǎng)絡(luò)同構(gòu)。
• 儘管網(wǎng)絡(luò)可靠性和帶寬有了顯著提升，但這些因素並非完美無缺。開發(fā)者必須預見潛在的故障，並在應用程序設(shè)計和部署中納入相應的處理策略。
• 網(wǎng)絡(luò)安全始終是一個重要問題，開發(fā)者必須優(yōu)先考慮良好的安全實踐，並評估其合作廠商的安全措施。
• 開發(fā)者應準備好應對拓撲結(jié)構(gòu)的變化、更換供應商的可能性以及數(shù)據(jù)傳輸相關(guān)的成本。他們還應該採取靈活的方法，能夠處理多個數(shù)據(jù)庫和數(shù)據(jù)源，並且不假設(shè)網(wǎng)絡(luò)是同構(gòu)的。

1. 網(wǎng)絡(luò)可靠

這顯然是不正確的。儘管自1995年以來，網(wǎng)絡(luò)延遲降低，帶寬顯著增加，但說網(wǎng)絡(luò)可靠是錯誤的。假設(shè)我們搭建了一個簡單的應用程序，它不使用太多服務——一個使用MySQL作為後端的PHP應用程序。似乎沒什麼問題。然而，假設(shè)我們後來決定使用像Xeround這樣的MySQL託管服務提供商來滿足我們的數(shù)據(jù)庫需求。即使具有良好的可擴展性和高可用性，如果他們的系統(tǒng)出現(xiàn)問題怎麼辦？如果他們的基礎(chǔ)設(shè)施遭受DDoS攻擊或由於內(nèi)部問題而出現(xiàn)停機怎麼辦？我們經(jīng)常聽說99.999%的正常運行時間，但這仍然不是100%。隨著服務的激增和當今通常高度可用的帶寬，很容易忘記沒有什麼是完美的。您如何在應用程序中考慮服務的故障？

2. 延遲為零

雖然延遲可能很低，確實比幾年前低得多，但它永遠不會為零。引用Arnon Rotem-Gal-Oz在其《分佈式計算誤區(qū)詳解》文章中的話：以大約300,000公里/秒（3.6 * 10E12 teraangstrom/兩週）的速度，即使處理是實時完成的，從歐洲到美國再返回的ping也至少需要30毫秒。

這是壞事嗎？好壞參半。根據(jù)我們應用程序的結(jié)構(gòu)和可用的資源，我們可以很大程度上減輕延遲問題。我們可以使用Amazon Web Services之類的服務託管我們的應用程序，並利用S3，以便我們的數(shù)據(jù)位於世界各地的多個區(qū)域，使其更接近我們的最終用戶，並減少網(wǎng)絡(luò)上應用程序的延遲。但即使我們可以減少延遲，我們也無法消除它。我們可以採用一系列方法和架構(gòu)來減少它對我們的影響，但無論我們做什麼，它都將始終存在。您在設(shè)計應用程序時是否考慮過這一點？

3. 帶寬無限

帶寬真的可以無限嗎？如果是這樣，無限的代價是什麼？當我們考慮到網(wǎng)絡(luò)正日益轉(zhuǎn)向移動化時，一切舊事物都煥發(fā)了新生。我並不是說我們從撥號上網(wǎng)的速度開始重新開始，更新的4G網(wǎng)絡(luò)比早期的2G和3G網(wǎng)絡(luò)快得多。但是，即使是它們的峰值數(shù)據(jù)速率目前也低於標準寬帶連接。此外，隨著移動寬帶的普及，尋求使用我們服務的潛在用戶數(shù)量（我們都想受歡迎，至少取得Facebook的一些成功）正在以驚人的速度增長?？紤]來自mobithinking的這些統(tǒng)計數(shù)據(jù)：

• 有59億移動用戶。
• 有12億擁有3G覆蓋範圍的移動網(wǎng)絡(luò)用戶。
• 移動設(shè)備佔全球點擊量的8.49%。

鑑於此，可以公平地說，儘管帶寬速率及其在世界範圍內(nèi)的普及率正在提高，但用戶增長率卻抵消了這一點。更進一步說，隨著移動寬帶提供的巨大靈活性，自然而然地出現(xiàn)了明確的臨時服務消耗。您是否為服務上潛在的巨大負載做好了準備？你能處理這種可用性帶來的峰值嗎？

4. 網(wǎng)絡(luò)安全

我認為無需過多細節(jié)就可以公平地說，這是，並且將永遠是錯誤的。如果您有任何疑問，也許您應該與LinkedIn或eHarmony成員談談。當我們設(shè)計和部署我們的應用程序時，我們在應用程序的託管位置（例如Rackspace、PagodaBox或cloudControl）以及應用程序本身的設(shè)計中，對安全性投入了多少精力？根據(jù)SecurityAffairs，Prolexic報告：

• 針對金融服務行業(yè)的惡意數(shù)據(jù)包流量環(huán)比增長3000%。
• 2011年第四季度針對金融服務行業(yè)的惡意流量數(shù)據(jù)量為19.1TB，數(shù)據(jù)包為140億個，2012年有所增加。
• 2012年識別並緩解的數(shù)據(jù)量為65TB，數(shù)據(jù)包為1.1萬億個，是2011年的80倍。

鑑於網(wǎng)絡(luò)並不安全，我們需要確保我們正在將良好的安全實踐作為當然的事情來使用。鑑於Chris Shiflett的博客、Essential PHP Security、PHP安全聯(lián)盟等來源的大量良好建議，很難不知道如何在我們的應用程序核心融入安全性以及為什麼要這樣做。您的安全實踐是什麼？您是否評估了您部署的供應商？

5. 拓撲不變

不會嗎？真的嗎？它不會改變，還是我們只是不知道？當我們將應用程序託管給其他人時，我們只是不知道。如果提供商重新配置他們的數(shù)據(jù)中心、升級它、調(diào)整它，無論出於何種原因，拓撲結(jié)構(gòu)都會發(fā)生變化。鑑於前面提到的智能手機使用率的提高，拓撲結(jié)構(gòu)經(jīng)常發(fā)生變化。從用戶和提供商的角度來看，拓撲結(jié)構(gòu)幾乎每天都在變化！如果拓撲結(jié)構(gòu)發(fā)生變化，並且它依賴的外部服務無法再訪問，導致例如無法訪問數(shù)據(jù)庫，那麼這肯定是一個問題。但是，如果在我們的提供商內(nèi)部發(fā)生變化，並且應用程序繼續(xù)運行，那麼它可能不是問題。當然，編寫一個小型且以簡單配置託管的應用程序很容易。但應用程序會發(fā)生變化，那些越來越受歡迎的應用程序更是如此。您是否在設(shè)計中考慮了拓撲結(jié)構(gòu)的變化？您如何解釋或處理應用程序設(shè)計和部署設(shè)計中的故障？

6. 只有一個管理員

“但是我的應用程序由單個服務提供商託管。他們提供操作系統(tǒng)、數(shù)據(jù)庫和Web服務器支持，”你說。好吧，假設(shè)那是您的應用程序，真的只有一個管理員嗎？如果真的只有一個管理員，你會真的相信提供商會處理你的應用程序嗎？如果他們生病或休假，我會討厭想到會發(fā)生什麼。通常，至少會有幾個管理員，儘管每個管理員的技術(shù)和更廣泛的敏銳程度可能不同。應該制定策略，例如網(wǎng)絡(luò)入侵檢測和其他安全策略，但不能保證他們都會以相同的徹底性和盡職盡責來遵守這些策略。鑑於當今可用的眾多託管提供商以及更新DNS記錄所需的時間很少，我們有很多選擇和靈活性，如果一個提供商沒有滿足我們的需求和期望，我們可以轉(zhuǎn)向另一個提供商。您是否考慮過這會如何影響您？如果您無法輕鬆更換供應商怎麼辦？如果您有大量的供應商鎖定，或者移動成本很高怎麼辦？如果您的應用程序架構(gòu)不夠靈活怎麼辦？您可以採取哪些措施來減輕此類風險？

7. 傳輸成本為零

與迄今為止的所有陳述一樣，這的有效性也很不可能。如果支持我們應用程序的服務器位於同一數(shù)據(jù)中心的同一機架中，那麼傳輸成本可以大大降低，但就時間成本而言。貨幣成本呢？是的，我們可以根據(jù)需要無限地彈性地向上和向下擴展，並且可以在地理位置分散的數(shù)據(jù)中心之間存儲我們的應用程序數(shù)據(jù)，以便它盡可能接近我們的最終用戶，但代價是什麼？您的應用程序或服務的架構(gòu)組成是什麼？就成本或時間而言，它是否接近於零？如果您能減少一個，它是否會增加另一個？

8. 網(wǎng)絡(luò)同構(gòu)

與其他誤區(qū)不同，我認為作為PHP開發(fā)者，我們天生就理解這一點。我們在Windows、Linux、Solaris、BSD和Mac OS X服務器上託管我們的應用程序。我們使用MySQL、SQLServer、SQLite、PostgreSQL、mongoDB、Hadoop和Oracle來存儲數(shù)據(jù)。我們通過需要不同接口的XML或JSON使用外部服務。作為一個多操作系統(tǒng)和多服務社區(qū)，可以說從早期開始，我們就從未期望過同構(gòu)網(wǎng)絡(luò)。但問題仍然需要提出，您的方法是否靈活？您可以處理多個數(shù)據(jù)庫和數(shù)據(jù)源嗎？您是否使用相關(guān)的設(shè)計模式，例如抽象工廠，來使用透明的代碼接口從各種來源和類型消費數(shù)據(jù)？或者如果需要執(zhí)行像從XML切換到JSON這樣簡單的事情，您的代碼是否會中斷？

結(jié)論

我認為，作為PHP開發(fā)者，分佈式計算的八大誤區(qū)與以往一樣重要。鑑於大量可用的信息和資源，我們處於一個非常有利的地位來理解它們並減輕由此產(chǎn)生的風險。您怎麼看？在開發(fā)應用程序和服務時，您是否考慮到了它們？您認為這八個誤區(qū)如何影響您的應用程序？

(圖片保持不變)

以上是PHP開發(fā)人員分佈式計算的8個謬誤的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！