十二月了。
    老周的第二版方案在十一月最后一天跑通了。
    方远用了一周时间重写了余额镜像模块的核心逻辑，把镜像同步的频率从每笔交易实时同步改成了批量异步同步，每500毫秒同步一次。
    这样做减少了单笔交易的等待时间，把延迟从最初的800多毫秒压到了一个相对稳定的区间。
    相对稳定的区间是多少呢。
    老周在邮件里附了一张测试报告。
    单笔交易延迟：平均793毫秒，最低612毫秒，最高1247毫秒。
    793毫秒。
    央行的性能指標要求是500毫秒以內。
    demo里跑出来的37毫秒是纯逻辑层的数据，不含清算系统对接。
    加上对接之后，延迟翻了二十多倍。
    第二版比第一版好了一点，从“完全不能用“变成了“能用但不达標“。
    差了將近300毫秒。
    300毫秒听起来不多，0.3秒，一眨眼的功夫。
    但在冬奥的场景里，这0.3秒可能是灾难性的。
    冬奥期间数字人民幣的核心支付场景是什么？
    便利店、餐饮、纪念品商店、交通。
    冬奥村的便利店在比赛日的尖峰时段，一个小时可能有几百人排队结帐。
    每一笔支付如果多等0.3秒，几百笔就是几十秒到一两分钟的排队延长。
    运动员和记者不会等。
    他们会掏出信用卡，或者打开手机用微信支付宝。
    数字人民幣在冬奥的第一印象就是“慢“。
    这不是技术问题。
    这是政治问题。
    冬奥是数字人民幣面向全球的第一次亮相，亮相的第一印象是“慢“，对整个dcep项目的推广是毁灭性的。
    央行不会允许这种事发生。
    更糟糕的是，赵铭远的同步清算方案不存在这个问题。
    同步架构的延迟完全取决於清算引擎本身的处理速度，工行的清算引擎经过了几十年的优化，单笔交易確认时间在200毫秒以內。
    如果央行看到的测试数据是微光610毫秒对工行200毫秒，结论不需要討论。
    793毫秒，不达標，而且对手在达標。
    …………
    十二月第一周，老周的团队开始了密集的优化叠代。
    方向有三个。
    第一个是压缩镜像同步的批量间隔，从500毫秒试著压到300毫秒。
    压下去了，但延迟只降了40毫秒左右，从793降到了大约750。
    第二个方向是优化回调通信的协议，减少每次回调的数据包大小和握手次数。
    这个方向有效果，延迟又降了大概60毫秒，到了690左右。
    第三个方向是方远提出的，在逻辑层和清算系统之间加一个缓衝队列，把回调请求排队处理，减少並发衝突。
    这个方向花了三天写代码，跑出来的结果是延迟降了30毫秒，代价是在高並发场景下缓衝队列会堆积，堆积到一定程度延迟反而会飆升。
    三个方向加起来，延迟从793降到了大约660。
    还是超標，超了160毫秒。
    …………
    十二月第二周，又试了两个方向。
    一个是把逻辑层的规则引擎从解释执行改成预编译执行，把规则在第一次加载的时候就编译成机器码，后续执行的时候不再需要实时解析。
    这个改动很大，方远带著两个人花了五天重写了规则编译器。
    跑出来的效果：延迟降了大约50毫秒，到了610左右。
    另一个是老周自己想的，把清算系统的模擬环境从单机改成了分布式集群，更接近真实的央行架构。
    改完之后重新跑测试，延迟反而上升了，因为分布式集群的网络延迟比单机高。
    这个结果说明之前的优化有一部分是建立在模擬环境不够真实的基础上的。
    实际部署到真实环境里，延迟可能比测试数据更高。
    老周把这个结论写在了白板上，红色马克笔，三个字：“不乐观。“
    …………
    两周过去了。
    从十二月初到十二月中旬，十四天，七次测试叠代，延迟从793毫秒降到了610毫秒。
    降了183毫秒，但还是超標110毫秒。
    而且这110毫秒不是“再优化优化就能压下去“的那种差距。
    方远在最后一次测试之后做了一个分析，把延迟拆成了五个环节：规则编译18毫秒，规则执行22毫秒，镜像同步310毫秒，回调通信195毫秒，清算確认65毫秒。
    五个环节加起来610毫秒。
    每个环节的优化都已经接近各自的理论极限了，规则执行从37毫秒压到22毫秒已经是三次重写的结果，回调通信从280毫秒压到195毫秒是协议层面的极限。
    瓶颈在镜像同步，310毫秒，占了总延迟的一半以上。
    镜像同步的310毫秒是余额镜像方案的先天代价。
    要维护一份本地的余额副本，就必须定期跟清算系统的真实帐本同步。
    同步频率越高，镜像越准，但延迟越大。
    同步频率越低，延迟越小，但双花风险越高。
    这是一个蹺蹺板，两头不能同时落地。
    老周在最新的邮件里说，现有架构下的优化空间已经接近极限。
    余额镜像方案的核心逻辑决定了延迟的下限，不改架构就压不下去。
    不改架构。
    改架构意味著推倒重来。
    第二版方案跑了两周，方远重写了规则编译器，老周重搭了模擬集群，十二个人每天干十四五个小时。
    这些工作如果全部作废，从零开始，时间不够了。
    离冬奥实战测试还有不到一个月。
    …………
    林彻看完了老周的邮件。
    十二月十五號的晚上，七楼办公室。
    窗外的杭州在下雨，不是大雨，是那种密密的细雨，看不清雨丝但能听到雨打在窗户上的声音，沙沙的，连成一片。
    路灯的光被雨雾打散了，变成一团一团的晕。
    对面楼的灯灭了大半，只有零星几间还亮著，加班的人或者忘了关灯。
    桌上的茶凉了，他没喝。
    610毫秒。
    白板上那五个时间节点，11月15日的架构设计完成了，11月30日的核心引擎原型跑通了，但跑通不等於达標。
    12月15日是今天，规则编译器对接完成了，延迟没有压到500以內。
    下一个节点是12月31日，全链路测试通过。
    还有十六天。
    十六天里要做的事：要么把现有架构的延迟从610压到500以內，要么找到一个全新的架构思路。
    前者老周说已经穷尽了。
    后者意味著在十六天內完成从设计到开发到测试的全流程。
    老周的邮件最后没有写“在想办法“或者“还在优化“。
    他写的是一句话：
    “现有架构下的优化空间已经穷尽。需要新的思路。“
    需要新的思路。
    这句话从老周嘴里说出来，比从任何人嘴里说出来都重。
    老周不是会轻易认输的人。
    他说穷尽了就是真的穷尽了，他说需要新思路就是现有的路真的走不通了。
    窗外的雨还在下。
    沙沙的声音不断，像白噪音，填满了整间办公室。
    800毫秒，压到了610，压不下去了。
    他没办法。