编 辑：彭文华
周末跟一位老彭友约了在了一个景色非常优美的地方私聊，没想到一下就聊了3个多小时。跟企业实战大佬毫无保留的深入探讨一个问题，真的非常酣畅淋漓，太过瘾了！
这次聊了很多，其中有一个问题非常有意思，我回家赶紧整理一下，分享给大家。
具体情况是这样的：企业核心业务主干系统已经运行十多年了，一直承担着企业核心业务重任。这十多年间，围绕核心业务主干系统建了上百个子系统，导致主干系统非常庞大和臃肿，就像一副正常人的骨架，却贴上了300斤的肥肉。
这个情况可想而知，光是日常运维就耗费了所有人力物力。更不用说随之而来的沉重负担和各种毛病。整个系统已经到了不得不优化的地步。
那么问题来了，这种情况应该怎么优化？
大号练废了，删号重练！
彭友们技术大咖比较多，遇到技术问题首先想到的就是如何从技术的角度解决这些问题。快刀斩乱麻也许是最佳选择。
老系统是单体架构，在面对众多子系统附着的情况，就显得年老力衰，无能为力了。而现在的市场复杂，用户多变的环境，根本不能再满足要求了。
且不说云原生、业务中台之类的新概念，起码得稍微分分层，做做微服务吧？这样来一个新需求不至于从前端改到后台，还得考虑其他代码的影响。
而且那些大大小小的子系统，也该归置归置。有些子系统都是临时做的，有些则被其他新系统淘汰了，还有些跟主干系统产生大量的数据交互，甚至干脆变成主干系统的一部分了。
所以，我们能想到的第一个方案，也是现在看来最好的方案，就是彻底废弃老系统，新建新系统，删号重练，干干净净做人。
写过代码的彭友都知道，改代码非常痛苦，还不如重写一套来的清爽。上万行的代码看起来真的非常头疼。若是遇到没有注释的代码，那简直比吃了苍蝇还恶心。更不用说比这更痛苦的单体系统中的逻辑梳理和解耦......
删号重练就没这个烦恼了，我们只需要把重心放在业务逻辑的梳理和实现、系统架构的合理性设计以及项目管理上就行了。把各种小接口、小功能抽象成微服务，后续开发功能需要什么，直接调用这个微服务就行了。干干净净，清清爽爽，明明白白。
但是这样一来，也有会面临一些问题，比如需要投入巨大的时间和资金、对现有业务的影响、同时维护双系统且保证数据一致性。
我正好处理过系统切换，实在是太痛苦了。在双系统并行期，我们每天都要对数，那酸爽，简直了！
这些其实都还好，毕竟是技术问题，都是有解的。但是最难解的BUG并不是技术BUG，而是复杂的环境。比如：如何说服老板同意这个旷日持久的项目？因为这个项目很可能比老板的任期还长
减肥！减肥！减肥！
其实还有另外一条路，就是让臃肿的主干系统减肥，剥离所有非核心业务，让主干系统变成一个核心“服务”，让它变得健康、敏捷，做它最擅长的事情就行了。
然后，其他剥离的子系统该优化的优化，该淘汰淘汰，各种接口也都进行统一、标准化。
这些系统进行剥离后，通过简单改造，就可以到服务中心注册成为一个个服务，然后通过ESB、业务中台、微服务中心等形式，把其他各种服务连在一起，形成“服务矩阵”共同对外提供服务。
这样的好处是各系统彻底减负，变得更敏捷，自身效率更高。系统之间彻底解耦，相互间影响可控。最关键的是快速见效，无需漫长的等待。
如果有余力，还可以把数据都集中管控，不管是原生态的“数据湖”，还是归置好的“数据中台”、“数据仓库”，都OK。这样还能对外提供统一的数据服务。
但是这样的坏处也很明显：对现有系统进行改造必然要进行业务入侵，风险很大。而且，从总体费用上看，这种方法不一定会省钱。
战略规划，战术执行
其实上面的两种方法，都是有效的，也各有优缺点。我们讨论到最后，发现决定使用那种方法，最终还得看公司的一把手的态度。
如果一把手亲自操刀，制定长远的战略规划，有足够的耐心，甘愿做继任者的垫脚石，那么建议选择“删号重练”的方式。换一个足够强的“数字化发动机”。
如果一把手只是“重视”，把这事儿交给副总甚至总监负责，则建议选用第二种方式，每个月都让上面看到新变化、新业绩。这样也能让团队积累小成功，走向大成功。
个中微妙关系，还得亲自体会，细细品味，不可言传。你有什么好主意，可以在文末留言，咱一起聊聊~~
