架桥
MetaERP在马来西亚上线成功，给全体项目成员和公司上上下下都带来了极大的信心。但是，马来西亚子公司的业务只占华为整体业务的不到1%，这个系统还非常脆弱，无法支撑200多家子公司的业务量。就像中央红军抢占了安顺场渡口，但只找到一条小木船一样，这样是无法支撑主力部队快速渡河的。红军必须抢夺泸定桥，才能让大部队安全、快速地通过。
MetaERP的“泸定桥”在哪里？
常栋的设想是由易到难：“等在马来西亚上线后，我们总结沉淀经验，先把100多家销服型子公司全面覆盖，然后辐射到全球4个供应中心，最后来啃中国区这块硬骨头……”
但当时华为正遭受新一波的制裁，形势越发紧张，在ESC会议上，领导说：“我们现在的形势越来越严峻了，工具软件也被禁用，照这个形势下去，ERP系统的切换时间可能比我们原先设想的更紧迫，我们可能要找到整个链条上最关键的那个根节点，优先替换。大家都说说，对于下一步项目计划的看法。”
这是一个艰难的抉择，业界在实施ERP软件新版本时，首先要进行试点，而且保险起见，为了催熟产品，新版本最好能经过一到两年的业务运营试用。也就是说，公司如果直接完成中国区切换，就要冒巨大的风险。
中国地区部销售主管打破了沉默：“从销售侧看，现在海外战场收缩，中国区市场快速增长，整体规模已占到全球近70%。”
大家感受到了70%业务量所带来的压迫感，这更是一次对公司业务而言生死攸关的决策，财经、供应体系主管也各自补充了信息。
“中国区现在是我们连接全球各个节点的关联交易中心，也是我们的全球账务中心。”
“全球生产物料的采购、关键零部件的生产全部集中在这里，如果老ERP系统不能用了，无法保障买得到、造得出、供得上，公司就会真的停摆。”
“那就切中国区！”一个声音打破了沉闷。安静了几秒后，领导组成员纷纷表示支持，ESC主任拍板，“下一阶段我们就上中国区，没有退路！”
中国区的这场硬仗，让常栋想起当年的飞夺泸定桥战役。现在，马来西亚子公司成功上线MetaERP，一支小部队已经渡到了河的“左岸”，但大部队还在“右岸”。接下来，团队要架起一座“铁索桥”，即通过技术攻关，提升MetaERP系统的性能、容量与稳定性，使之具备支持全球业务的能力。
1. 新的基因
第一项技术攻关，是元数据多租的技术架构。
所谓元数据，是指描述系统基本属性的数据。如果把ERP系统比作一张桌子，元数据就是长、宽、高等基本属性。在传统ERP系统中，这些属性的可调整空间是非常有限的。华为老ERP系统也因此构建了490多万行的定制代码，衍生出300多个外部应用，变得越来越庞大，架构难以治理。
而在元数据多租的架构中，具有共性的元数据被标准化，桌子的长、宽、高是基本属性，但用户可以增加颜色、材质等扩展属性，差异化需求可以做到灵活扩展、个性配置，这样就把ERP系统变成了一个开放、可扩展的系统。
元数据多租架构在ERP领域还没有先例，如果华为能够成功应用，这将是一个创举。
但在讨论过程中，也有不少担忧的声音。有人担心，现在进度本来就很紧了，元数据多租和当前任务冲突严重，项目能顺利完成吗？还有人说，以团队现在的能力和软硬件限制，能把ERP系统搞出来并上线，就已经非常了不起了，为什么还要增加难度，引进没有经过验证的新技术，搞砸了怎么办？
为了消除大家的疑虑，在一次研讨会上，常栋提出了“打造通用产品的七大原则”，统一了元数据多租整改的标准与方向。他说：“各位主管和产品经理在思想和意识上一定要统一，我们要抓住历史机遇，基于元数据打造业界领先的企业数字化平台产品，不断提升产品竞争力，支撑公司未来30年的发展。”
为了确保产品质量，项目组决定紧急刹车，将现有开发任务暂停3个月，由于距上线时间仅剩6个月的时间，所有产品团队必须在3个月内完成元数据多租整改。
熊彼特说过，创新就是一个创造性破坏的过程。项目组勇于打破思维惯性的约束，敢于中断本来就捉襟见肘的开发进程，这真是一个疯狂的决定！认准了就勇往直前，所有人奋笔疾书，签下了任务书，开始了覆盖全产品的元数据多租整改。
经过紧张的整改工作，项目团队成功完成了32个业务对象、505个实体、1482个应用服务、544个页面等元数据的构建及发布，元数据就此全面诞生，为MetaERP产品注入了面向未来的基因，让它不再只是一个冷冰冰的软件程序，而是拥有了可以自我分裂和扩展的生命力。
2. 新的底座
第二项攻关，是云原生技术。所谓云原生，是指在云计算环境中构建、部署和管理应用程序的软件方法。原厂ERP系统由一组大机来承载，云原生则意味着ERP系统的数据底座将不再是固定的物理硬件，而是调用云平台的强大计算能力和资源弹性能力，来实现各种场景下的系统功能。
2021年11月的一个晚上。夜已深，ERP研发作战办公区内依旧灯火通明。突然，啪的一声打破了夜晚的宁静，顿时众人的目光不约而同地聚焦在一处。
“算不准，还是算不准，这可怎么办？微服务解耦后数据太碎了，一张多维度科目余额报表，花了4小时计算，结果还有误差。”交易核算团队的技术负责人几近崩溃地拍打着桌子。
“以前老ERP系统在大单体结构下，数据都集中在关键的几张表中，现在七零八落，要从十几张表中汇集，这不光影响数据库的性能，数据的准确性还一直在80%左右徘徊，怎么办？怎么解决业务数据100%一致的问题？”
“MetaERP是分布式系统，按照布鲁尔定理，保证可用性、容错性的情况下，分布式系统的数据一致性是不可能达到100%的。这可是一道世界难题啊！”一位经验丰富的技术人员低声嘀咕，说出了会议室里每一位技术专家的心声。
刘振羽是MetaERP的首席技术架构师，看到大家忧心忡忡，他一时间也想不到好的办法。他想出去抽支烟提提神，于是起身走出办公楼。在经过车库的时候，他看到一辆辆电动汽车在车位上充电，突然有一种茅塞顿开的感觉。
他知道，每台电动汽车都有一个集中的电源管理系统，这个系统负责数千颗锂电池的充电、放电、散热和生命周期管理，非常强大。受此启发，他创造性地提出了ERP“总体控制”的设想，即在各个微服务之上，专门构建一个应用，自动监控数据不一致的现象，一旦发现系统或数据差异，立刻报警，并及时进行干预，这样无限逼近布鲁尔定理的极限，使数据一致性等同于100%。
一致性问题找到了解决思路，但是，还有个性能问题横在大家面前。
随着研发会战不断深入，华为云的技术攻关也在不断告捷。云的容器起弹速度从最初的每分钟1000个容器，提升到每分钟3000个，团队提前达成目标，士气高涨。
但在接下来的采购订单大单处理的性能测试中，结果却全部没有通过。大家十分着急，加班加点进行攻关，想了很多方法，比如加计算资源、数据库扩容、代码优化，但是收效有限，阻塞情况仍未改善。
连续几天的攻关，使采购模块技术架构师徐华非常疲惫，他坐在公司班车上，看着窗外飘着的绵绵细雨和拥堵的车流，喃喃自语道：“今天估计要迟到了。”
大巴车仿佛读懂了他的心思，竟一路畅行，通过了拥堵路段。
“噢，对啊，虽然其他车道很堵，但公交车道是畅通的。”
公交车道——这几个字闪现在徐华的脑海里。
