在PaaS上編寫故障切換算法時應避免的三大陷阱
譯文云服務停運事件果真發生時，通常會激活故障切換機制，以便從運行不暢的服務器切換到正常運行的服務器。那樣，云服務在故障切換過程中可以正常運行，不會帶來任何破壞或干擾。
不過，故障切換算法并不總是絲毫沒有任何問題。比如說，算法并不總是事先告訴你有沒有足夠的資源讓算法運行。一旦計算資源在故障切換過程中耗盡，最終結果就是云服務停運（比如亞馬遜服務停運）。
在停運期間，平臺即服務（PaaS）開發人員和軟件即服務（SaaS）用戶大聲喊著無法按時完成工作。為了迫切希望讓云服務盡快恢復正常，他們會不斷打電話給信息即服務（IaaS）提供商的技術支持部門。最終，IaaS提供商解決問題。
編寫故障切換算法時要留意的問題
如果你遇到了云服務停運事件，對IaaS提供商的故障切換算法又不滿意，那你可以決定編寫自定義的故障切換算法。你需要在不同的場景下測試算法，確保算法運行起來無誤。一旦所有測試返回了正面的結果，你應該征得IaaS提供商的同意：要是提供商的故障切換算法失效，可以在下一輪云服務停運時在生產環境中激活算法。
你在編寫故障切換算法時，需要避免以下三大陷阱。
1. 閏年日期
上一個閏年日期是2012年2月29日。有人忘了檢查微軟Azure中頒發安全證書的那臺服務器是否能識別這個日期。一旦時鐘滴答滴答地報出那個日期的頭幾分鐘，一個虛擬機無法啟動。管理員想找到并解決這個問題并非易事。
下一個閏年是2016年2月29日，所以你有的是大把時間來避免同樣的不幸事故。你應該在PaaS上測試幾種閏年識別算法；這可以幫助你確保安全證書會識別閏年日期。
2. 不穩定的數值算法
你發現自己編寫的一種數值算法不穩定，可惜發現得太晚。該算法引起了耗費計算機資源的無限循環。由于可供使用的資源越來越少，云服務性能越來越低下。等到一點資源都沒剩下時，云服務就停止運行。
下面這個簡單的場景可以幫助你更清楚地了解數值算法會如何變得不穩定。
為了解2的平方根，你先讓算法從1.4這個初始近似值開始處理。你設定了一個很小的值，算法應該會向該值收斂。達到這個值后，算法給出近似的答案：1.41421（正如預期）。這時候，算法停止運行；它很穩定，因為它釋放了資源，供其他計算任務使用。
你在新算法中建立略有不同的邏輯。你從1.42、而不是1.4這個初始近似值開始處理。你發現，結果并不向預期的值收斂――它與***個數值算法得到的近似答案偏差很大。
答案越來越長。該算法繼續陷入無限循環，不斷消耗資源。等到一點資源都沒剩下時，算法才停止運行，這表明它不穩定。
為了避免這個陷阱，你需要事先做好功課，確定該算法能不能向預期的值收斂。
3. 虛擬機管理程序失效
所有PaaS（無論開源還是閉源）都位于在IaaS下面的虛擬機之上。所有虛擬機的創建和運行由虛擬機管理程序統一負責。物理服務器能托管運行多少個虛擬機，取決于物理服務器的能力/容量。
一旦虛擬機管理程序失效，所有虛擬機停止運行。導致失效的一個根源是，IaaS基礎設施專業公司無法確定一臺物理服務器能托管運行多少個虛擬機。提供商未能精確核實服務器的能力/容量。他試圖添加超出這臺物理服務器資源極限范圍的虛擬機。如果極限范圍是頂多2個虛擬機，提供商又添加一個虛擬機，那么物理服務器托管的所有虛擬機就會停止運行。
為了避免這個陷阱，你需要弄清楚一臺物理服務器能托管運行多少個新的虛擬機。將弄清楚的結果與IaaS提供商或IaaS基礎設施專業公司對比一下。確保你備份了所有虛擬機，這是一項日常任務。
結束語
別一味依賴IaaS提供商的故障切換算法。你可以編寫自己的故障切換算法，不過記得在你運行這些算法之前事先征得IaaS提供商的同意。
