PHP開發者構建分佈式應用需警惕的八大誤區
Peter Deutsch在1997年提出了七個分佈式計算的誤區，後來James Gosling（Java之父）又補充了一個。這些誤區對PHP開發者來說至關重要，因為我們每天都在構建分佈式應用：mashup、與SOAP和REST服務交互的應用、通過Facebook、Google或Twitter API進行用戶身份驗證、從遠程數據庫和緩存服務檢索信息等等。我們構建的正是分佈式計算應用。因此，理解這八個誤區及其影響至關重要。
關鍵要點:
這顯然是不正確的。儘管自1995年以來，網絡延遲降低，帶寬顯著增加，但說網絡可靠是錯誤的。假設我們搭建了一個簡單的應用程序，它不使用太多服務——一個使用MySQL作為後端的PHP應用程序。似乎沒什麼問題。然而，假設我們後來決定使用像Xeround這樣的MySQL託管服務提供商來滿足我們的數據庫需求。即使具有良好的可擴展性和高可用性，如果他們的系統出現問題怎麼辦？如果他們的基礎設施遭受DDoS攻擊或由於內部問題而出現停機怎麼辦？我們經常聽說99.999%的正常運行時間，但這仍然不是100%。隨著服務的激增和當今通常高度可用的帶寬，很容易忘記沒有什麼是完美的。您如何在應用程序中考慮服務的故障？
雖然延遲可能很低，確實比幾年前低得多，但它永遠不會為零。引用Arnon Rotem-Gal-Oz在其《分佈式計算誤區詳解》文章中的話：以大約300,000公里/秒（3.6 * 10E12 teraangstrom/兩週）的速度，即使處理是實時完成的，從歐洲到美國再返回的ping也至少需要30毫秒。
這是壞事嗎？好壞參半。根據我們應用程序的結構和可用的資源，我們可以很大程度上減輕延遲問題。我們可以使用Amazon Web Services之類的服務託管我們的應用程序，並利用S3，以便我們的數據位於世界各地的多個區域，使其更接近我們的最終用戶，並減少網絡上應用程序的延遲。但即使我們可以減少延遲，我們也無法消除它。我們可以採用一系列方法和架構來減少它對我們的影響，但無論我們做什麼，它都將始終存在。您在設計應用程序時是否考慮過這一點？
帶寬真的可以無限嗎？如果是這樣，無限的代價是什麼？當我們考慮到網絡正日益轉向移動化時，一切舊事物都煥發了新生。我並不是說我們從撥號上網的速度開始重新開始，更新的4G網絡比早期的2G和3G網絡快得多。但是，即使是它們的峰值數據速率目前也低於標準寬帶連接。此外，隨著移動寬帶的普及，尋求使用我們服務的潛在用戶數量（我們都想受歡迎，至少取得Facebook的一些成功）正在以驚人的速度增長。考慮來自mobithinking的這些統計數據：
鑑於此，可以公平地說，儘管帶寬速率及其在世界範圍內的普及率正在提高，但用戶增長率卻抵消了這一點。更進一步說，隨著移動寬帶提供的巨大靈活性，自然而然地出現了明確的臨時服務消耗。您是否為服務上潛在的巨大負載做好了準備？你能處理這種可用性帶來的峰值嗎？
我認為無需過多細節就可以公平地說，這是，並且將永遠是錯誤的。如果您有任何疑問，也許您應該與LinkedIn或eHarmony成員談談。當我們設計和部署我們的應用程序時，我們在應用程序的託管位置（例如Rackspace、PagodaBox或cloudControl）以及應用程序本身的設計中，對安全性投入了多少精力？根據SecurityAffairs，Prolexic報告：
鑑於網絡並不安全，我們需要確保我們正在將良好的安全實踐作為當然的事情來使用。鑑於Chris Shiflett的博客、Essential PHP Security、PHP安全聯盟等來源的大量良好建議，很難不知道如何在我們的應用程序核心融入安全性以及為什麼要這樣做。您的安全實踐是什麼？您是否評估了您部署的供應商？
不會嗎？真的嗎？它不會改變，還是我們只是不知道？當我們將應用程序託管給其他人時，我們只是不知道。如果提供商重新配置他們的數據中心、升級它、調整它，無論出於何種原因，拓撲結構都會發生變化。鑑於前面提到的智能手機使用率的提高，拓撲結構經常發生變化。從用戶和提供商的角度來看，拓撲結構幾乎每天都在變化！如果拓撲結構發生變化，並且它依賴的外部服務無法再訪問，導致例如無法訪問數據庫，那麼這肯定是一個問題。但是，如果在我們的提供商內部發生變化，並且應用程序繼續運行，那麼它可能不是問題。當然，編寫一個小型且以簡單配置託管的應用程序很容易。但應用程序會發生變化，那些越來越受歡迎的應用程序更是如此。您是否在設計中考慮了拓撲結構的變化？您如何解釋或處理應用程序設計和部署設計中的故障？
“但是我的應用程序由單個服務提供商託管。他們提供操作系統、數據庫和Web服務器支持，”你說。好吧，假設那是您的應用程序，真的只有一個管理員嗎？如果真的只有一個管理員，你會真的相信提供商會處理你的應用程序嗎？如果他們生病或休假，我會討厭想到會發生什麼。通常，至少會有幾個管理員，儘管每個管理員的技術和更廣泛的敏銳程度可能不同。應該制定策略，例如網絡入侵檢測和其他安全策略，但不能保證他們都會以相同的徹底性和盡職盡責來遵守這些策略。鑑於當今可用的眾多託管提供商以及更新DNS記錄所需的時間很少，我們有很多選擇和靈活性，如果一個提供商沒有滿足我們的需求和期望，我們可以轉向另一個提供商。您是否考慮過這會如何影響您？如果您無法輕鬆更換供應商怎麼辦？如果您有大量的供應商鎖定，或者移動成本很高怎麼辦？如果您的應用程序架構不夠靈活怎麼辦？您可以採取哪些措施來減輕此類風險？
與迄今為止的所有陳述一樣，這的有效性也很不可能。如果支持我們應用程序的服務器位於同一數據中心的同一機架中，那麼傳輸成本可以大大降低，但就時間成本而言。貨幣成本呢？是的，我們可以根據需要無限地彈性地向上和向下擴展，並且可以在地理位置分散的數據中心之間存儲我們的應用程序數據，以便它盡可能接近我們的最終用戶，但代價是什麼？您的應用程序或服務的架構組成是什麼？就成本或時間而言，它是否接近於零？如果您能減少一個，它是否會增加另一個？
與其他誤區不同，我認為作為PHP開發者，我們天生就理解這一點。我們在Windows、Linux、Solaris、BSD和Mac OS X服務器上託管我們的應用程序。我們使用MySQL、SQLServer、SQLite、PostgreSQL、mongoDB、Hadoop和Oracle來存儲數據。我們通過需要不同接口的XML或JSON使用外部服務。作為一個多操作系統和多服務社區，可以說從早期開始，我們就從未期望過同構網絡。但問題仍然需要提出，您的方法是否靈活？您可以處理多個數據庫和數據源嗎？您是否使用相關的設計模式，例如抽象工廠，來使用透明的代碼接口從各種來源和類型消費數據？或者如果需要執行像從XML切換到JSON這樣簡單的事情，您的代碼是否會中斷？
結論
我認為，作為PHP開發者，分佈式計算的八大誤區與以往一樣重要。鑑於大量可用的信息和資源，我們處於一個非常有利的地位來理解它們並減輕由此產生的風險。您怎麼看？在開發應用程序和服務時，您是否考慮到了它們？您認為這八個誤區如何影響您的應用程序？
(圖片保持不變)
以上是PHP開發人員分佈式計算的8個謬誤的詳細內容。更多資訊請關注PHP中文網其他相關文章！
