假設一種情況：用戶需要用到他們大型機上的某項應用，但是廠商卻不能再提供服務支持。比如以前負責升級該應用的某個開發(fā)人員/管理員離職了，或者公司決定停止對升級服務的繼續(xù)投入。那么，替代方案是什么？在這里，我們將介紹幾項應用遷移的策略及各自的優(yōu)缺點。例如應用現(xiàn)代化、重組、分布集成。

　　一般來說，可以替換掉應用（希望***能這樣），改用能夠支持的語言/操作系統(tǒng)/平臺?；蛘咧苯影堰@個應用當作“黑匣子”，在它下面建立一個獨立子應用處理所有升級需求。后兩個策略使用到下面這些廣為人知的技術(shù)：

　　1.大型機應用現(xiàn)代化：在應用前端設置一個網(wǎng)頁服務供應商接口，用以處理所有與該應用發(fā)生的交互活動。

　　2.重組：利用應用的原有功能，在另外一個平臺上把它轉(zhuǎn)化為相應功能。

　　3.分布集成：分配眾多子系統(tǒng)在多虛擬機和物理機上運行，使它們猶如一個整體在運轉(zhuǎn)。

　　我們應該把正反兩方面意見，把策略和技術(shù)上難點都納入考慮范圍。

　　一、更換應用

　　理想情況下，應用更換在任何時候都是最棒的替代方案。只要想象一下，新應用能夠神奇地出現(xiàn)在對你來說最省成本的平臺上并能正常運轉(zhuǎn)，不需任何花費，而且能準確復制大型機上已有的應用。而現(xiàn)實世界中，應用更換通常是最糟糕的替代方案。現(xiàn)成的成套應用方案無法模擬現(xiàn)實應用，這讓終端用戶很惱火；但從零開始研發(fā)成本太高，不僅會占用主要的IT項目，而且常常會因為對現(xiàn)有應用的功能知之甚少，且少有記載導致失??；而且，替代方案實施失敗的話，也沒有所謂的B方案可供選用。

　　眾多成功的應用更換在牽涉到“關(guān)鍵業(yè)務大型機應用”時，采取的都是“足夠好”的辦法。也就是，把重新開發(fā)工作外包給一家兼具大型機和替換平臺（通常是linux）專業(yè)知識的應用遷移公司。他們使用的基礎軟件是經(jīng)過時間驗證的（不管是不是開放源）。他們關(guān)注舊大型機應用的主要功能，并盡其所能減少新應用可能帶給用戶的不便感受。而且采用了“平等追蹤”的部署方式，能夠確保只有在新應用“服役”滿一年后舊應用才正式“引退”。

　　與直覺相反，針對上述替換方案現(xiàn)今***的目標操作系統(tǒng)，可能經(jīng)常是“大型機上的Linux”。這里提到“Linux”是因為，它能根據(jù)需要，只作最小的應用修正（大型機Linux與大型機、放大Unix和擴容PC服務器稍有不同，但新應用完全能寫成便攜方式）就能允許對平臺的進一步變更。而這里提到“大型機”的原因則是，直到現(xiàn)在，許多用戶仍反映大型機處理應用擴容最節(jié)約成本。一位技術(shù)執(zhí)行官最近跟我說到了他的認識，他發(fā)現(xiàn)一臺大型機負載達98%但仍有處理冗余，而一臺擴容服務器負載只不過50%時但讓人感覺后勁全無。這僅僅意味著擴容應用在大型機上運行較節(jié)約成本，因為如果在擴容配置中增加常規(guī)服務器花費很大。

　　二、轉(zhuǎn)換與分布集成

　　應用現(xiàn)代化

　　大型機應用的持續(xù)現(xiàn)代化，也包含了對網(wǎng)頁瀏覽器的支持，以及對PC訪問和網(wǎng)頁服務供應商界面的支持。但實際上，許多應用還未達到現(xiàn)代化標準，無法支持此類網(wǎng)頁，這其中可能就包括了你的應用。多數(shù)大型機軟件供應商針對此類問題有許多應對工具和服務。不論客戶是想在遷移應用前，還是在應用遷移到新平臺后，他們都能夠幫助達成添加網(wǎng)頁服務供應商界面這一目標。對于哪種是***的應用遷移方法并無定論。但是對大型機應用結(jié)構(gòu)和操作了解的越多，就越容易將其封裝成“網(wǎng)頁服務供應商”。

　　人們常常低估了大型機應用現(xiàn)代化的效用。不過，應用遷移負責人要明白，如果想要建立內(nèi)部云或者使用外部云平臺，除非大型機應用已經(jīng)被轉(zhuǎn)化成網(wǎng)頁服務模式，否則它在云平臺上是不可用的。如果應用被虛擬成網(wǎng)頁服務形式，那么從長遠來看，云平臺的施行是再簡單不過的事情了。

　　重組

　　如果能夠?qū)帽旧磉M行提取程序模型（確定程序?qū)嶋H運行方式），那么重組對于應用遷移來說就是一個好方法。對大型機應用進行重組的副作用通常是出現(xiàn)一個標準化模式，允許在開發(fā)設計階段（例如UML）進行修改。這類提取不僅允許生成面向所有主要編程語言和環(huán)境（例如，所有平臺上的Java）的應用實例，而且使得程序的修改和升級變得更容易。它不是對應用本身進行修改，而是通過修改設計來達到目的。

　　因此，“重組專家”的主要任務是利用IBM，CA Clerity公司和Micro Focus公司這類廠商的重組工具生成一個適合企業(yè)現(xiàn)有開發(fā)流程的標準模式。從而確保今后企業(yè)若想把應用遷移到另外的平臺，或是計劃對其進行現(xiàn)代化，擴展或合并時（例如，使其成為復合應用的一部分），此類操作會更快捷和更安全。

　　分布集成

　　分布集成是關(guān)于讓大型機應用（作為“黑匣子”或轉(zhuǎn)型應用）在兩個或兩個以上的目標平臺運行的理念，就像IBM的zEnterprise（Linux在刀片上，也在大型機系統(tǒng)上）。對于“黑匣子”型分布集成，使用z/OS或大型機Linux作為其中一個平臺以減小平臺移動的風險通常是有道理的。然而更具典型意義的是，分布集成涉及到的是向兩個平臺遷移而不是一個，不過平臺之間（例如，虛擬機管理，網(wǎng)絡和調(diào)度）的集成工具使得實際中對產(chǎn)生的子應用的集成變得更簡單。

　　分布集成取得成功的關(guān)鍵在于爭取到一個能使應用性能***化的目標應用分布。比如，一個能從放大中受益的應用，要盡可能把重負荷放在放大服務器上處理（放大或大型機Linux），并利用應用的擴容元件執(zhí)行“邊緣”任務，例如緩沖。擴容型應用則應把多平行復本放到網(wǎng)格型或刀片型網(wǎng)絡中的多重虛擬機上，同時把不易發(fā)生故障的放大機作為管理重點。

　　很多應用屬于zEnterprise方案的“折衷”版本，分別由放大和擴容來處理各自擅長的部分。在這種情況下，用戶要尋求跨平臺管理工具的***化支持。我們可以看到，通過一些努力，現(xiàn)在有可能讓Windows成為目標平臺之一--通過在z/OS上安裝Windows模擬器，以“黑匣子”方式部署或重新編譯Linux版本以兼容Windows（需要重新編寫多達20%的原代碼）。

　　分布集成的另一個關(guān)鍵任務是建立隨時可以與其它分布應用進行分布通訊和集成的應用。這點經(jīng)常被錯誤理解為在各應用之間建立起標準化通訊。實際上，分布集成的主要目標是要建立起應用之間數(shù)據(jù)交換的標準化方式--更具體來說，要界定應用里的元數(shù)據(jù)并使其涵蓋進全球元數(shù)據(jù)池。然后，類似ETL和IBM’s Information Server的數(shù)據(jù)合并解決方案就可以利用這些數(shù)據(jù)掌握數(shù)據(jù)管理，跨企業(yè)報告等等。

　　轉(zhuǎn)換

　　就像前面所指出的那樣，轉(zhuǎn)換就是要改變現(xiàn)有大型機應用的代碼，以使其能適應在不同平臺上運行和升級。因此，轉(zhuǎn)換的目標是盡可能少作變動，盡可能自動化運行。也許還需要把它分解到多平臺上，或是在轉(zhuǎn)換過程中進行升級以便支持復合應用或適應更高級的云和網(wǎng)頁功能。

　　有三種基本途徑可以對此類大型機應用進行轉(zhuǎn)換：

　　1.建立一個包含基礎軟件型目標平臺的目標環(huán)境，并重寫不受支持部分。例如，依賴CICS,MQSeries和DB2的大型機COBOL應用可以利用廠商的轉(zhuǎn)換程序，雖然要重寫交叉匯編碼?？梢詮膹S商和Clerity Solutions這樣的應用遷移外包商那里獲得Linux基礎支持。

　　2.上面已經(jīng)介紹過大型機應用重組。這里補充一點，雖然應用遷移外包商在這方面做得越來越好，但是也存在一些情況會讓他們感到無能為力或困難重重。

　　3.根據(jù)需要逐項重新編寫應用。經(jīng)驗表明，這很可能與更換應用一樣冒險，甚至代價會更大。無論如何，對于業(yè)務關(guān)鍵性應用，這可能是***的選擇了。

　　從長遠看，應用重組可能是***的方案。因為應用重組從根本上對代碼進行了現(xiàn)代化處理，使得對應用的進一步變更有更大靈活性。在上述三個例子中，轉(zhuǎn)換應用時，使應用現(xiàn)代化無疑是個好主意。因為類似的用途會是網(wǎng)頁型組織的一部分，甚至可能是云平臺的一部分。分布集成是可以自由選擇的。許多案例可以證明，要把轉(zhuǎn)換過程包含在分布集成內(nèi)將會過于復雜。

#p#　　三、“黑匣子”分布應用

　　應對撤消大型機應用支持，“黑匣子”方案并不是一個理想的長遠解決辦法。它會加大應用再變更的難度，但它卻是風險最小、最省成本的辦法?；舅枷胧?，不觸動應用本身，但要用網(wǎng)頁服務供應商界面把應用包圍起來，使得在開發(fā)人員，管理員和終端用戶看來，它就像Linux或Unix應用一樣在運行。需要升級時，界面會把終端用戶需求轉(zhuǎn)化成新代碼并交付給新平臺來處理。

　　這個辦法行得通的原因在于，在現(xiàn)實世界中，從現(xiàn)在起，即使不是全部亦是大多數(shù)大型機應用漏洞將會成為調(diào)整的問題，遠超出以前的麻煩程度。網(wǎng)頁服務界面處理這類問題的辦法是暫緩需求處理，重寫功能代碼。這么做肯定會造成問題，所以這不是一個優(yōu)越的執(zhí)行方案，存在自身風險--假設問題被解決了，然后又發(fā)現(xiàn)那并不是最糟糕情況--但是精心做的話，它卻是快速節(jié)約的實施方案，風險也極低。

　　從定義看，“黑匣子”分布應用實施包括，應用現(xiàn)代化（供應商界面），分布集成（供應商界面代碼和新平臺的新代碼，但是“黑匣子”在老平臺上），但并不包括重組。這意味著大型機環(huán)境要有網(wǎng)頁服務供應商界面的開發(fā)支持和跨虛擬機網(wǎng)絡和管理--現(xiàn)在多數(shù)大型機環(huán)境都具備這點，在機箱外。所以，如果把大型機型Linux作為新平臺，可以自己動手操作，也可以從IBM獲取一點幫助。當然，所有其它環(huán)境也同樣支持網(wǎng)頁服務供應商界面，虛擬機，跨平臺網(wǎng)絡和開發(fā)；只不過，跨平臺管理可能要多花點力氣。

　　成本低的緣故，自己動手安裝“黑匣子”的想法很有吸引力。但是，預算足夠的話，我還是建議把活外包給IBM，CA Technologies，或Clerity這樣專業(yè)的公司。即使這樣，還是比其它方案來得省錢。這些公司憑借與其它IT大型機應用長期打交道的經(jīng)驗，了解難點在哪里，所以能給出諸如該類型應用架構(gòu)未來可能出現(xiàn)的漏洞之類有價值的建議。這些建議對于業(yè)務關(guān)鍵性應用可以說是無價之寶。

　　大型機應用現(xiàn)代化的現(xiàn)實情況

　　關(guān)于上述所有的策略還有一則警示：代碼轉(zhuǎn)移到新平臺，意味著性能損失。損失可能不大，就像“黑匣子”方案中出現(xiàn)的；損失也可能很大，遭遇到重新編寫多數(shù)甚至全部代碼的情況。但經(jīng)驗表明，很少出現(xiàn)新應用一開始就在新環(huán)境出運行順暢的情況。

　　那么該如何在這些策略中做出選擇呢？首先，剔除那些不可行選項。很多情況下，無法做到有效替換。有時候，代碼過于定制化或無法滲透，那么根本不能進行重組。這時，你要問問自己這個應用到底有多重要，撤消支持的需求有多急迫。對于不是特別關(guān)鍵的應用，如果時間允許的話，重組或者別的形式的轉(zhuǎn)換可能正是需要的手段。如果需求很急切，“黑匣子”可能是唯一出路。

　　只有到這個時候你才需要考慮費用。這是因為現(xiàn)實生活中經(jīng)常出現(xiàn)這樣的情形，“要么現(xiàn)在付錢，要么回頭多付”。初期投入最少方案似乎很有吸引力，例如根據(jù)需要逐項重寫應用，或是直接啟用號稱能起到同樣作用的新型開放源應用。但是據(jù)調(diào)查，很多項目都是由于終端用戶對于新應用，及伴隨出現(xiàn)的停機時間和無法修復的故障等情況產(chǎn)生了極大不滿而最終失敗。所以仔細權(quán)衡承擔的風險和后續(xù)將產(chǎn)生的維護費用后再做出合理的初始投入決定才是明智的。

　　***一個忠告：一些把大型機應用重新配置到新平臺的應用遷移項目從長遠看確實是值得的。通常是因為，網(wǎng)頁服務供應商界面允許大型機代碼在復合應用中得以重新使用，或者重組讓終端新用戶能夠獲取所需功能，而代碼也能為新應用所用。所以不要把應用遷移看作逃不掉的苦差事，像人體的牙根管。它也可能是沙子里的鉆石，蘊含著優(yōu)秀的潛質(zhì)。