量力而行，聊聊舊系統升級改造那些事兒

本文是聊聊舊系統升級改造那些事兒的第二篇內容，文章分別介紹了改造的三個策劃，包括激進策略、穩健策略和保守策略。點此閱讀第一篇文章。

對於公司而言，不管是對於既存系統進行改造，仍是新開的項目，必定會有相應的預算和人員配置，架構師須要是立足於公司給出的預算，根據團隊的技術水平情況來作出相應的架構設計的，心中的須要創建全流程的成本意識，並與相關人員進行溝通。

咱們看看具體能夠採起的策略：

量力而爲—穩健策略

在這樣的狀況下，你做爲架構師能夠採用更爲激進些的架構策略，對於傳統企業，能夠採用好比買最好的服務器，僱傭最富有經驗的工程師，乃至尋求最專業的公司來幫助升級改造，由他們幫你作更詳盡的技術調研，配置強大的團隊一同來完成改造，然而土豪畢竟是少數，大多數同行還得苦苦求索，尋找投入與產出的平衡點。

與之相對應的是互聯網企業，他們面臨的情形大不相同；因爲用戶增加迅速，系統迭代很是快，業務需求變化巨大，週期也更加短，是難以採用上述這樣複雜，週期長的策略來對既有系統進行改造的，更多的時候是在老系統略顯疲態的時候就須要開始對下一代系統的技術調研和開發，以小步快跑的姿態逐漸替換掉老系統，達到升級換代的做用，如我公司的商城系統短短兩年已經更替三版了。因此行業的不一樣也決定了架構師採起具體架構策略的方向，或是成本優先，或是性能優先，亦或是可靠性安全性優先。

在肯定好改造的目標後，根據現實的資源配置狀況再來肯定架構設計的策略，根據系統面臨的主要問題爲導向，採用與成本相適應的技術方案，並加以驗證。例如上一節的項目中主要問題是運行平臺陳舊，運維昂貴，那麼遷移到相對價廉物美的Windows平臺或者Linux平臺就成了優先考慮的方向，進而去尋找目標平臺上可以實現的技術方案，即轉換IBM COBOL爲MF-COBOL，並利用MF的企業套件完成COBOL程序服務化的這一方案，且隨着相關技術的特性，展開配套工程（Java web 應用）的開發，最終將整個解決方案完善。

這一過程當中採用了商業套件開發，採購了IBM websphere，Hitachi JP1以及MicroFocus企業套件這一些列商業軟件，也採起了對外外包開發的策略，總體付出的成本而言也至關客觀。但綜合來看，所有這些綜合改造升級的投入比起原有環境下采購ibm大型機以及運維費用來說卻不及其十分之一。

有錢才能夠任性—激進策略

咱們也看到雖然在投入有限的狀況下，這個項目仍然採購了諸多成熟的商業軟件，而不是使用開源軟件來替代，這也體現了對成本和技術風險的平衡，使用商業軟件由於有良好的服務，從而避免由於開源軟件帶來的潛在問題，也算是一種下降技術風險措施。

與之相對的是，上述項目並不算是一種激進的升級改造策略，仍是比較穩健的，畢竟有錢任性的項目也不是每家公司能夠隨意開展的。激進的策略是將平臺語言所有替換，所有移植到新的平臺新的語言，採用更多的新技術，新方案。

例如，IBM公司的GIAS系統的升級改造就是如此，他是一我的壽險核心系統，原先運行於小型機as400環境的，由COBOL，RPG等程序開發的，面臨着上述一樣的問題，對於IBM這樣的企業而言產品的升級換代有着重要的意義，所以投入就很是可觀，因此gias系統就直接從COBOL，RPG和jcl等源代碼程序經過工具轉換爲Java，生成各類bean、dao、service等等組件，而後再人工消除一些工具不能作到的細節修改，最終完成平臺的移植。

這個工具的開發就很是重要，也是很是複雜的，從技術難度上，從成本上來說普通公司是難以付出這樣的成本的，況且IBM經過這樣的項目移植升級後還能夠對其客戶的系統提供相應的升級服務，把投入的錢再賺回來，傳統企業在IT上的投入不多又能提供對外服務把自身的IT投入再賺回來的可能的。

在有限的預算下，技術團隊水平尚可的時候，經過自身的努力，對既存系統進行改造是咱們大多數架構師面臨的狀況。在完成對系統環境，業務流程乃至系統升級目標作出詳盡的分析以後，架構師內心就應該有相應的藍圖了，根據預算給出相適應的架構策略，亦或激進，亦或穩健，亦或保守。

看米下鍋–保守策略

激進和穩健的策略咱們都講過，而保守的策略其實大多數是在預算寥寥，人員有限和團隊技術水平有限的狀況下不得不採起的策略。這樣的狀況下，更多的是通過前面的系統調研，對主要問題了解清楚以後，選取最重要的一個問題點進行局部升級改造，同時注意其改造過程當中是否存在能夠經過系統改造，好比加緩存，使用最新版本性能更好的服務器，增長系統帶寬，使用CDN，優化數據庫服務器等外部手段來提高系統性能，以解決瓶頸問題。若是是新的相對獨立的功能開發，在不得不依賴原有系統的基礎上，視狀況而定作出從新開發亦或是改造的決定。

例如咱們在原有商城的改造的過程當中所作的，原有系統是購買的某公司的一套商城系統，咱們針對咱們的業務需求改造了其原有業務邏輯，這一過程當中發現其源代碼各類混亂，業務邏輯與頁面邏輯相互交織，性能也不佳。與此同時，咱們團隊剛組建，人員技術水平良莠不齊，老闆要求上線的時間緊迫，使得權衡利弊之下，於保守的策略來說，就是隻作功能改修，而不是徹底推翻重來，以下降項目風險。何況，咱們IT團隊分佈於重慶上海兩地，溝通協做也帶來了諸多困難。

這樣的狀況下，咱們難以一開始就採用激進亦或是穩健的策略，只能採起保守的作法。但，在咱們開發微信版商城的時候，就由於原有系統過於繁雜，難以在其基礎上一下支持不一樣平臺，就只是使用了他的數據表，全新開發了微信商城的相關功能，經過前面一階段的功能改修，鍛鍊了團隊，使其明確了商城系統的各個模塊，相關業務流程，因而在微信商城的功能開發上，進度和質量都有着不錯的提高，其性能效果各方面都優於原有系統。

在改造的技術上，咱們針對該商城業務特色，將系統進行集羣化改造。經過使用分佈式緩存Memcache來下降數據庫壓力和提高頁面反應速度。使用Tomcat集羣，並修改原有系統的用戶Session管理，作到用戶狀態與他訪問的具體服務器無關，在訪問量大的狀況下，集羣的負載能力獲得大幅提高。在外部支撐上，使用阿里雲CDN來緩存頁面資源下降IDC帶寬的壓力，提升全國各地用戶訪問速度。CDN的使用使得咱們系統的負載能力獲得有效提高，由於創業公司支付不起更爲充裕的帶寬，在現有條件下，結合自身須要，使用外部雲服務算一個不錯的選擇。好比，開展一些活動的時候，將活動程序獨立開發並部署到雲服務上，來解決自身IDC資源有限，不足以應對短期大量服務請求的問題。

縱然保守的策略是最爲無奈的選擇，但如同有大牛提到的，架構最終是妥協的產物。在系統構建，維護升級過程當中，架構師須要跟需求妥協，跟時間跟團隊技術水平妥協，甚至跟用戶使用習慣妥協，保守的策略更可能是對成本的妥協，花最少的錢辦更多的事架構師此刻要作的就是錙銖必較，力求精打細算，以最大努力挖掘系統的潛力，硬件的潛力，以達到更好的用戶體驗。

做者介紹

王巍，漣拓網絡架構師，先後就任於Achievo、IBM、HP，關注前沿技術，分佈式系統架構，組件化系統開發，機器學習和大數據，如今創業公司負責系統架構，樂於與你們一塊兒聊聊架構