更新100％正常運行時間的應用程序

Question

在過去的一次採訪中，有人問我如何編寫關鍵任務Windows服務，該服務必須保持100％的正常運行時間，響應速度非常快，並且可以更新。該服務被描述爲基於遠程處理的應用程序，它接收請求，執行計算併發迴響應。

我的解決方案是有一個非常通用的服務，它只是作爲一個網關。這項服務永遠不會停止。它會將這些請求排隊並將它們轉發到另一個應用程序域中的另一個服務，該應用程序域將實際處理請求。這些處理服務中至少需要兩個處理服務，這樣可以降低一個處理服務的數量，而另一個處理服務可以響應傳入的請求。服務之間的接口將包括握手能力以查看服務是否正在運行。一個非常小的超時會存在，所以如果一個服務完成了，它不會保持請求。我還強調這個解決方案可以很好地擴展，因爲您可以在不同的盒子上添加更多這些服務。

面試官對這個想法並不是太瘋狂，因爲跨應用程序域甚至整個網絡進行通信的延遲問題。我爲一個關鍵任務應用程序表示，你應該建立一個穩固的基礎架構，因爲軟件本身不能成爲答案。他還表示，他們目前已經建立了一個使用重感染的系統。我曾想過將程序集加載到應用程序域並觀察目錄中的程序集更改，但這似乎太容易出錯。

有沒有人有類似的要求建立任何東西？你用什麼解決方案？什麼不行？反射是一種可用的選擇嗎？

Answer 1

.Net在構建時支持在使用時更新程序集。它被稱爲Shadow Copy，並在加載它們之前有效地將程序集複製到單獨的目錄。在加載新版本之前，您仍然需要卸載AppDomain，但其他AppDomains仍然可以使用舊版本的程序集。這樣，一個appdomain可以在新的appdomain加載時爲請求提供服務。這也是IIS和ASP.Net處理事物的方式。

Answer 2

100％正常運行時間？ 「五個九」意味着每年停機315秒。如果你能做到這一點，你的確會做得很好。

聽起來像一個不可能的面試問題。 「...保持100％的正常運行時間，響應速度非常快，而且可以更新......」 - 給出了一個正常運行時間指標，但沒有一個用於響應速度。

延遲是一個值得擔心的問題，但後來他們說這是一個遠程應用程序，所以你無法擺脫它。我認爲面試官可能會爲了自己的利益而不同意，也許看看你會如何處理它。

Answer 3

Spring dm Server宣稱能夠對OSGi bundle進行熱部署/取消部署。如果硬件可以保持足夠長的時間，您就可以更新應用程序，而無需關閉服務器。如果這種情況發生，它將成爲所有Java EE應用服務器的標準功能。

Answer 4

有沒有這樣的事情，100％的時間。即使是最好的系統，停機時間也是「5 9」，這意味着99.999％的正常運行時間。

此外，一個關鍵點：此測量適用於未計劃的停機時間，如同失敗一樣。它不包括您定期維護系統的時間。

無論如何，我們的目標是安裝/更新軟件而不會導致停機，計劃或其他情況。如果Web服務器本身不支持動態重新加載，那麼您的解決方案似乎是正確的，但我認爲這些內容現在已被嵌入到很多服務器中。也就是說，您只需要將新文件放到服務器上，它就會自動查看某些內容已更改並開始使用它們。

但是，具體取決於可能導致會話狀態問題的更改的性質。也就是說，現有的用戶會話可能會以與新代碼不兼容的會話中存儲的對象結束。同樣，服務器可能足夠聰明，可以保留原始代碼的緩存副本，直到所有使用舊代碼的會話都終止，但也許您需要自己處理。你的「影子服務器」方法應該很好地處理。

Answer 5

好吧，我很少背景，我在Wireless Telecom工作，我們的平臺需要絕對的正常運行時間，並且看到了所有不同的策略，絕對不應該使用基於軟件的方法，它增加了軟件複雜性，要做的是添加一些硬件。

因爲他們要求進行無中斷升級，所以必須有冗餘系統，而使服務器應用程序變得冗餘的絕對最佳方式是使用硬件負載平衡器。在工作中，我們有代工廠，我們所有的新產品都在思科Ace負載均衡器上。

因此，您需要的是兩臺思科負載均衡器，在它們之間建立HSRP以實現負載均衡器之間的故障切換。您可以對故障轉移設置非常積極，但根據我們的經驗，對這些設置過於激進可能會導致不必要的故障轉移。另外，請確保關閉proxy-arp（它會爲你節省心痛，因爲默認情況下cisco已啓用它）。

現在，你有一個應用程序服務器集羣的權利？因此，您擁有負載均衡器ping，端口ping和監視應用程序響應時間。您只需要至少兩臺服務器，但您可以稍後添加更多容量計劃？所以，現在來看一下在你維護期間的無損升級，從負載均衡器你可以管理你的其中一個服務器。但負載平衡器可以做到真正的維基管理員權限，其中任何當前的連接都會保留，直到自然結束。

在這種狀態下，任何請求都會轉到第二臺服務器上，並且您有足夠的時間在您要升級的服務器上執行任何操作。與真的一樣，爲什麼編寫一個應用程序具有一個花哨的應用程序域重新加載的東西，當你將不得不重新啓動服務器每3個月應用一個關鍵的Windows補丁呢？只需花費現金購買硬件，並且可以在100％的時間內正常工作，即使出現計劃外問題，也可以讓您在5倍9的範圍內工作。

現在這是下一步，地理冗餘。思科確實有一個可以進行地理負載平衡的負載平衡產品，但我從未見過它。我所見過的最好的地理模型實際上是基於請求的應用程序。這不是一次無懈可擊的升級，但絕對是可靠的。你所做的是在請求應用程序中配置一個主服務器和故障轉移服務器的IP地址。其請求中的應用程序會查看服務器是否不可用，是否會向備用服務器發起相同的請求，在這種情況下，服務器可能位於同一服務器機房或備用位置。理想應該是一種組合，應用程序可以在一個位置或備份位置定位負載平衡器虛擬IP，並且可以使用負載均衡器在每個位置保持100％。另外，如果他擔心應用程序域之間的延遲或網絡中的延遲，那麼這個人就會出現問題，因爲使用了適當的思科設備，因此在演出鏈接上的延遲只有微秒，並且不會是你弱點。

祝你好運。