体系结构的小镇做题家

题记

像我们这样几代人， 从小到大在单一的成功标准下成长，几乎没有退出机制的内卷。读书做题不是为了内心的好奇和无知的羞愧，而只是为了一场高考，即便进了大学，学个数学分析也要找几本吉米多维奇来刷题，甚至为了出国留学还要不停重修去刷分，后来为了找工作开始刷算法题，不管工作是否能用到。在科学面前，我们中的大多数人都是小镇做题家，针对计算机体系架构也是如此。

大多数的时光，我们会把一些大师们的每一句话奉为圭臬，于是便有了大神的称谓，而过往小镇做题的经历让我们似乎忘记了提出问题的能力,倒是在各种大神的光环下多了几份解决提出问题的人的能力.从两弹一星时期：“这个问题和苏联教员教的不一致。”再到现在 “你这个技术，为什么美国没有，为什么Google为什么AWS都没有做”， 所以“你这个技术不在扯淡”

而针对未来十年，在计算机体系架构上，这个我们国家很可能会弯道超车的机会，各路做题家们又开启了抄作业的模式，异构一词打开了潘多拉的魔盒，也放出了各路牛鬼蛇神。有简单粗暴的爆算力，做存储的一定要在存储上放计算单元号称存算一体，另一边数据库又在存算分离。一边大量的微服务在解耦，另一边基础设施又在试图紧耦合提高效率。甚至算力爆完发现没有低挂果了，于是有些厂商开始扯数据的“运力”和“存力”

吐个槽，摊手，然后再来分享一些好玩的事情

DirectCXL

2022 USENIX ATC的一篇paper, Direct Access, High-performance Memory Disaggregation with DirectCXL^[1] 想起去年写的一篇文章

<RDMA ? or NoDMA!>

只可惜小镇做题家只会觉得nVidia都买了Mellanox玩RDMA，大家都说RoCE香，大家都谈IB妙，你凭啥说RDMA是个垃圾。所幸有了这样一篇paper发现自己再也不用跟DPU小镇的做题家们瞎扯why not了…

DirectCXL很不错的工作，在软件架构上直接mmap，和NetDAM做的memif是相通的，当然memif后面还有很多好玩的场景暂时保密

但DirectCXL这玩意也有它的内在局限性，那就是CXL Switch本身的距离和Scale的限制，虽然达到了一些局部的最优化，但是从一个超大规模的部署上来看…另一方面伴随HPC等场景单机800G或者1.6Tbps的接入，还有从内存子系统来看，它还是没有在CPU侧解决一些问题。

紧接着的一个问题， 为什么数据中心会出现第三个socket，必然性是什么，区别是什么？很多DPU厂家都在盲人摸象，做网络的说它是ToR的内置，做计算的说它要果奔…做题家们说P4是最好的DPU开发语言…

回归本源，不忘初心，本质是在一个空间和时间都很紧凑的CPU上，做时空的取舍，做大数据的搬运工。所以高峡(高频率)出平湖(大带宽)，明白为啥需要一个大坝(NetDAM)了吧:)

Java云原生

大概今年前半年一半的时光都在研究一个SDWAN数据湖的项目，主要是对接下来的SDWAN AIOps构建一个更加灵活的OLAP平面。但是前段时间在和vManage控制器整合的时候，发现一些Java相关的问题，Java对大规模数据写入Clickhouse的性能比较差于是看了一段时间JVM的优化，

其实技术栈的选择上，架构师个人的偏见会带来很多影响。例如渣自己以前是非常不喜欢Java的，用过ASP，然后过渡到php，玩了一小段Django，再到大前端所谓的NodeJS(Koa)这样的框架，最后做Nimble的时候用Go(Gin),包括前端，我也是不太喜欢vue和angular，更喜欢react的，毕竟每个厨子都有自己的口味，技术栈之间的撕逼也是蛮好玩的，例如每个时代都有以语言特性构建架构的人， ”PHP是最好的语言“，”Go在很多互联网厂商替代Java“ 似乎Java将死的样子。

最近一段时间发现一些国内客户在跟我吐槽Cisco Viptela SDWAN控制器部署很难的问题。某种意义上来看，它算是一个比较大的分布式应用，而每个组件宏观来看都是一个庞大的单体应用。其实技术栈的选择，不光完全是技术本身的事情，也是做技术的人的事情。与其推倒重来，不如考虑如何保留已有资产，尝试着对整个Cisco Viptela SDWAN做云原生改造，架构上来自于Ruta和很多年前写ThinCPE的一系列经验，于是安静的坐下来写了一个月的Spring Boot的code，倒是对Java有了几分改观。

对于大多数企业而言，都是在面向成本编程，计算资源成本和人力成本的取舍，让一般人都能够参与进来，通过一些简单的不易出错的代码定义商业逻辑，这是正路。而对于大量的云原生应用，本质上也是在降低人类的心智的负担。例如Spring自身的事务支持，以及Seata这样的分布式事务，Sentinel限流熔断降级等。虽然Spring的框架约束了一些灵活性，但是在这些约束下已经可以在心智负担很轻的情况下做一些事情了，但是性能的确是有一系列问题要处理，一些业务逻辑用Java写是很舒服的，但是针对一些数据密集型的应用，例如SDN控制器的遥测数据分析这些，自然就…. 当然还有一些看法和要做的事情涉及到公司机密，就此打住吧..

范畴论

知识领域的融合是一件非常有趣的事情。看到Spring IOC本质上其实就是一个依赖的对偶，而对于AOP更多的感觉就是一个Functor然后充分利用自然变换。而对于很多编程语言的泛型模板所谓的covariant和contravariant然后又不得不在脑子里补一个锥和极限、余极限出来。至于DDD，本质上就是一个以范畴论的视角来构造软件架构和服务。

FinOps和新数据中心税

微信公众号上看到一个做FinOps的公司，渣笑了一下，其实很多人吧，既不懂Fin也不懂Ops。从Fin的角度来看，本质上这是一个内部资金转移定价（Funds Transfer Pricing,FTP）的问题.

而从Ops的角度来看，最开始的第一步还是在测量和多云连接上， 这一点思科倒是走的早了好多年，Viptela SDWAN已经完全可以支持AWS TGW和Azure vWAN以及阿里云TR的完全互联，workload可以完全无缝安全的在三个云多个AZ之间随意迁移，再配合AppDynamics和ThousandEye对工况进行全栈监控，然后CWOM(Cisco Workload Optimization Manager)也可以非常容易地对IT资源实际的消耗和利用率进行监控并优化。

这件事对于思科这样的设备厂家卖个增值服务讲圆整个故事是不错的，但是通常很难有一个第三方公司作为服务提供出来，因为ToB的生意中给客户省钱是最难做的生意，因为客户最终还会省掉划给你钱，然后一群小镇做题家会以更低的价格成为你的竟对。

那么对于这些新的FinOps公司而言，机会在哪呢？想想Ruta你就明白了。传统的设备厂商一定是原来私有云有啥东西全部类比往云端搬，而针对云原生，更多的是需要站在应用的角度考虑，API GW和SideCar以及边缘和终端及多云的融合。可惜有人只看到了SRv6，有人只看到了MP-QUIC，有人看到了SASE和零信任。

过去很多DPU公司喜欢说一个Datacenter Tax， 云原生场景下的DC、Cloud tax又是什么呢？

小镇的喧嚣敌不过时代的变迁，体系结构的变化需要的不是做题家而是出题人，其实我们更需要那种T字型的人，在某一个专业领域专研很深，同时又需要更加广泛的视野。很多时候我和做基础设施的各种同学讨论，大家对上层应用的理解都是陌生的，而陌生的基础上带来一种不要改一行代码的恐慌，实际上当你看清楚很多应用的问题，自顶而下的去看，让应用以极小的心智去适应你的基建，这才是正确的出路…

共勉之…

Reference

[1]

Direct Access, High-Performance Memory Disaggregation with DirectCXL: https://www.usenix.org/conference/atc22/presentation/gouk