系統更換技術

Question

我有一些問題，我希望有人能夠爲我解答。

我們的情況是，我們正在考慮對現有系統進行全面替代。首先我要描述我們現有的系統。

我們目前正在純粹的對象堆棧上運行。環境是面向對象，數據庫是面向對象。我們目前有2-3百萬行代碼，由2-3人開發，目前我們有一個6人的開發團隊，這個團隊繼續發展。最初的發展始於1997年，我們安裝了許多客戶。環境是64位，語言和數據庫，多語言，並且是UNICODE。我們使用的操作系統是Windows（最新版本）。我們有許多通過瘦客戶端（而非瀏覽器）交付的模塊，並且帶寬使用率非常低（在64KB WAN網絡性能水平上運行，這在我們運營的一些國家仍然普遍存在，即基礎設施差）。我們最大的實施是面向全球最大的公司之一，目標是爲該客戶從一個系統實例（一個物理分貝）向30多個國家/地區提供功能，並使用瘦客戶端向所有國家一組應用程序服務器（應用程序服務器位於數據庫服務器並執行所有處理），瘦客戶端處理與用戶的交互以及數據的顯示和數據的收集。在瘦客戶機上，該系統被1000多名用戶使用。我們也有移動和門戶組件，它們是用C＃開發的，它們是整個系統的一小部分，並使用AP進行連接。可能有1000個移動應用用戶，最終數量預計爲5000個移動用戶。在該系統中，將有50萬到100萬個供應商，每個供應商預計每天至少有兩筆交易。

數據庫本身被分區，並實時複製到多個位置。實施完成後數據庫的最終大小預計將在2TB範圍內，目前的系統將處理這個問題，沒有問題。複製工作的方式是在熱備份上有多個複製環境，即，所有應用程序服務器和API服務器都將被複制。我們最大的客戶端會定期（每月一次）執行預定的Windows更新，當發生這種情況時，主環境會自動轉移到次服務器，因此係統始終保持可用狀態。在接下來的幾個月中，系統回滾到初選狀態，這種轉換非常快，即實時。

在我們最大的客戶端，系統安裝在2014年，從那時起它沒有經歷過任何中斷，除了由於該時間段內服務器維護維護的計劃中斷，即它沒有崩潰或故障前三年的運作。爲了向目標組織提供更新和增強功能，或者特別是在其運營所在國的其中一個補貼，我們可以通過在線加載功能更新來對系統進行更改。這是我的問題的一個非常重要的組成部分，因爲很多年以來，我們都能夠在一箇中心位置進行更新，並且在所有國家的所有用戶都可以使用新應用程序的同時，可以持續使用新功能。這不會改變任何.EXE或.DLL或最終用戶操作的任何文件。這對我們目前來說是一個巨大的優勢，因爲許多我們提供服務的組織不會允許對最終用戶設備上的EXE或DLL文件進行任何更改，並且通常會有一些批准過程需要幾天時間並需要人工干預用戶使這一過程發生。

如需瞭解更多信息，我們有一支由6人組成的支持團隊，爲所有這些國家的所有客戶提供支持服務，我們經營三班兩人提供這些服務。所以這應該給你一些系統穩定性和我們提供的支持水平的背景。我們的服務水平被描述爲傑出。我們當然有SLA協議，我們並沒有違反任何SLA條款。

所以，現在我的問題。人們選擇什麼樣的技術來取代這樣的系統，以及需要多少人才能取代？我曾經建議使用C＃和SQL服務器來取代它，並且一年或兩年將需要幾個優秀人員從頭開始重新開發（我們擁有最後一個功能規範20年的工作）。但是，如果沒有深入瞭解這個技術堆棧，我非常關心時間段（我認爲這非常樂觀），但我擔心SQL Server的可擴展性，最重要的是我非常擔心我們會放棄我們享受的這一優勢使我們能夠通過在線更新來更改當前系統的功能，而不會影響登錄用戶。我被告知，這種事情在C＃中是不可能的，如果我們必須提供更新來修復錯誤或提供新功能，那麼所有用戶將不得不替換受影響的EXE和DLL文件，即所有這些文件，每次我們更新時，數千用戶將不得不這樣做。這將通過名爲OneClick的流程自動完成，但我假設在客戶端環境中是否存在不允許EXE更改的公司策略，則OneClick將不可行。我被告知，如果我們採用瀏覽器方式進行新的開發，那麼任何更新都將是服務器端（這更好），但仍然需要停機來應用更新。

最後，現在可以在線更新的更多信息。目前，所有系統都在進行災難恢復時進行復制，並在更新期間100％正常運行。當我們目前正在更新我們的系統（在一箇中央位置）時，這些邏輯更新將自動應用到所有複製系統，而無需用戶干預。我的另一個擔憂是，以及我們面臨的與更新多個位置相同的問題，它似乎是C＃中的一個要求，或者我被告知，我們也將使所有複製的系統手動更新以及。正如你可以看到我們的支持團隊很小，所以我擔心維護所有這些所需的維護資源的未來爆炸，以及隨着時間的變化修復可能會出現的所有這些額外任務中可能出現的錯誤的成本需要執行我們目前只做過一次的相同練習。

最後，關於我們目前如何進行更新的最終信息。如果更新本質上是結構性的，即改變數據庫的物理結構，則需要中斷，完全系統停機。當我們應用更新時，會進行結構更改，並自動在所有輔助環境（備用環境）上進行復制。用戶不受瘦客戶端或瀏覽器軟件的影響。他們只需在中斷完成後重新登錄即可。我們目前有一個設定時間的窗口，每月一次執行這些更新，但是，它很少需要。每週一次，我們有一個應用功能變化的窗口，這些應用程序在網上申請，而用戶都在線執行他們的日常和定期任務。因此，如果任何人都可以給我一些洞察，瞭解可用於這種系統替換的技術，或者C＃和SQL服務器是否可以提供我們實際需要的必要服務和性能，即我會特別感興趣知道無論實際上C＃應用程序是否可以實時更新，那都太棒了。我們顯然處於這個過程的最初階段，所以您可以提供的任何信息都將不勝感激，並且可以節省數小時的研究時間。

預先感謝您。

Answer 1

根據您描述的基本要求，我的第一個想法是您應該爲您的系統採用完整的基於Web的解決方案，這樣所有更新都可以集中完成，而不會對客戶端訪問造成太多負面影響。

但是，如果我正確理解您的問題，您需要的一個方面是在客戶端準備好可執行代碼（因此純Web解決方案將無法工作）。

在這種情況下，需要快速在客戶端更新的東西。

我們幾年來一直在使用node.js和MongoDB堆棧，現在有一些使用純腳本的業務邏輯非常有趣的效果：除了易於開發之外，腳本本身在設計時某些指導方針可以即時執行「熱重新加載」以更新您的業務邏輯。所以這是我建議嘗試/看的。

Node.js的效率和NoSQL DB（如MongoDB）提供的靈活性在很多地方都有很好的描述，如果你做一個簡單的Google搜索。