編 輯：彭文華
周末跟一位老彭友約了在了一個景色非常優美的地方私聊，沒想到一下就聊了3個多小時。跟企業實戰大佬毫無保留的深入探讨一個問題，真的非常酣暢淋漓，太過瘾了！
這次聊了很多，其中有一個問題非常有意思，我回家趕緊整理一下，分享給大家。
具體情況是這樣的：企業核心業務主幹系統已經運作十多年了，一直承擔着企業核心業務重任。這十多年間，圍繞核心業務主幹系統建了上百個子系統，導緻主幹系統非常龐大和臃腫，就像一副正常人的骨架，卻貼上了300斤的肥肉。
這個情況可想而知，光是日常運維就耗費了所有人力物力。更不用說随之而來的沉重負擔和各種毛病。整個系統已經到了不得不優化的地步。
那麼問題來了，這種情況應該怎麼優化？
大号練廢了，删号重練！
彭友們技術大咖比較多，遇到技術問題首先想到的就是如何從技術的角度解決這些問題。快刀斬亂麻也許是最佳選擇。
老系統是單體架構，在面對衆多子系統附着的情況，就顯得年老力衰，無能為力了。而現在的市場複雜，使用者多變的環境，根本不能再滿足要求了。
且不說雲原生、業務中台之類的新概念，起碼得稍微分分層，做做微服務吧？這樣來一個新需求不至于從前端改到背景，還得考慮其他代碼的影響。
而且那些大大小小的子系統，也該歸置歸置。有些子系統都是臨時做的，有些則被其他新系統淘汰了，還有些跟主幹系統産生大量的資料互動，甚至幹脆變成主幹系統的一部分了。
是以，我們能想到的第一個方案，也是現在看來最好的方案，就是徹底廢棄老系統，建立新系統，删号重練，幹幹淨淨做人。
寫過代碼的彭友都知道，改代碼非常痛苦，還不如重寫一套來的清爽。上萬行的代碼看起來真的非常頭疼。若是遇到沒有注釋的代碼，那簡直比吃了蒼蠅還惡心。更不用說比這更痛苦的單體系統中的邏輯梳理和解耦......
删号重練就沒這個煩惱了，我們隻需要把重心放在業務邏輯的梳理和實作、系統架構的合理性設計以及項目管理上就行了。把各種小接口、小功能抽象成微服務，後續開發功能需要什麼，直接調用這個微服務就行了。幹幹淨淨，清清爽爽，明明白白。
但是這樣一來，也有會面臨一些問題，比如需要投入巨大的時間和資金、對現有業務的影響、同時維護雙系統且保證資料一緻性。
我正好處理過系統切換，實在是太痛苦了。在雙系統并行期，我們每天都要對數，那酸爽，簡直了！
這些其實都還好，畢竟是技術問題，都是有解的。但是最難解的BUG并不是技術BUG，而是複雜的環境。比如：如何說服老闆同意這個曠日持久的項目？因為這個項目很可能比老闆的任期還長
減肥！減肥！減肥！
其實還有另外一條路，就是讓臃腫的主幹系統減肥，剝離所有非核心業務，讓主幹系統變成一個核心“服務”，讓它變得健康、靈活，做它最擅長的事情就行了。
然後，其他剝離的子系統該優化的優化，該淘汰淘汰，各種接口也都進行統一、标準化。
這些系統進行剝離後，通過簡單改造，就可以到服務中心注冊成為一個個服務，然後通過ESB、業務中台、微服務中心等形式，把其他各種服務連在一起，形成“服務矩陣”共同對外提供服務。
這樣的好處是各系統徹底減負，變得更靈活，自身效率更高。系統之間徹底解耦，互相間影響可控。最關鍵的是快速見效，無需漫長的等待。
如果有餘力，還可以把資料都集中管控，不管是原生态的“資料湖”，還是歸置好的“資料中台”、“資料倉庫”，都OK。這樣還能對外提供統一的資料服務。
但是這樣的壞處也很明顯：對現有系統進行改造必然要進行業務入侵，風險很大。而且，從總體費用上看，這種方法不一定會省錢。
戰略規劃，戰術執行
其實上面的兩種方法，都是有效的，也各有優缺點。我們讨論到最後，發現決定使用那種方法，最終還得看公司的一把手的态度。
如果一把手親自操刀，制定長遠的戰略規劃，有足夠的耐心，甘願做繼任者的墊腳石，那麼建議選擇“删号重練”的方式。換一個足夠強的“數字化發動機”。
如果一把手隻是“重視”，把這事兒交給副總甚至總監負責，則建議選用第二種方式，每個月都讓上面看到新變化、新業績。這樣也能讓團隊積累小成功，走向大成功。