马斯克开始“整顿”臃肿技术架构？Twitter工程师叫板：先拿个学位再来指手画脚，技术专家纷纷表示支持

　　欢迎关注“新浪科技”的微信订阅号：techsina 

　　整理/Tina

　　来源：AI前线（ID:ai-front)

　　这是一场震惊技术界的混战，但传奇软件建模专家、容器领域专家、基础设施技术主管等众多技术专家都挺身而出，十分一致地站到了马斯克的对立面，为“叫板马斯克的 Twitter 工程师们”表达支持态度。

　　是什么导致 Twitter 刷新缓慢？

　　美国本地时间周一早上，Twitter 工程师被召集参加紧急会议。马斯克下达了一项新命令：冻结 Twitter 系统上的所有生产变更，立即生效。

　　这不仅仅是一次普通的代码冻结，这一次，据媒体获得的一封内部电子邮件，工程师被告知他们甚至不能编写任何代码 —— “直到另行通知” 。如果存在“解决生产服务问题所需的紧急更改”，则将授予为例外情况，并且员工需要获得“副总裁级别的批准”，并向马斯克明确说明需要做出的更改。在 Slack 上，就连参加深夜会议的工程师也一头雾水。“到目前为止，我们还没有太多背景信息，”一位员工回应道，“但这是来自 Elon 团队的指示。”

　　与此同时，在过去的一天里，马斯克就 Twitter 代码和服务的质量发表了几项公开声明。身为 Twitter 的新掌门人，马斯克于上周日发推称“首先为 Twitter 在很多国家的超慢速度道歉。Twitter App 在渲染主页时间线时，会执行 1000 多个性能低下的批量 RPC。”

　　这些声明很快遭到了现任工程师的指责，Twitter 软件工程师 Eric Frohnhoefer 站了出来，押上自己的职业生涯跟马斯克正面对决。他写道，“我参与 Android 版 Twitter 的开发有大概 6 年了，我敢说这种论断是错的。”

　　马斯克随后回复，“那请你纠正我，正确的数字是多少？”

　　但也许问题压根就不在于 RPC（远程过程调用）的数量上。Frohnhoefer 指出，他的团队“做了很多工作来提高性能”，也承认“Android 版应用确实还有很大的性能改进空间。”但他补充称，“我认为请求数量并不是影响性能的主要原因。”

　　“在我看来，Twitter 应用运行缓慢有三个原因。首先，其中包含大量极少使用的功能，导致软件过于臃肿；其次，我们多年以来积累了大量技术债务，所以被迫在速度和功能之间求取平衡；第三，还有很大一部分延迟是网络响应造成的。”

　　“坦率地讲，我们可能应该优先进行几轮大规模重写，先把 10 多年来积累的技术债务干掉、再考虑删除那些几乎没人用的功能。”

　　而当再次被问及 RPC 的“正确数量”时，Frohnhoefer 果断回答：“数量是零。应用程序根本就不调用 RPC。”

　　虽然有人认为，在这种公开平台上跟老板对轰恐怕不是什么好主意，但确实有不少支持者决定站在 Frohnhoefer 这一边。

　　软件工程师 Ben Leib 这样回复马斯克的原帖：“作为 Twitter 时间线基础设施的前技术主管，我可以非常确定地宣布，这家伙根本不知道自己在说什么。”

　　Twitter 核心 API 平台团队的资深软件工程师兼联合技术负责人 Sasha Solomon 也决定发声，而且从技术团队的大量裁员问题上切入：“你不光裁掉了几乎所有基础设施人员，还想对我们的批处理机制大放厥词？”

　　她还出言讥讽道，“会用 GraphQL 吗你？” 所谓 GraphQL，是一种通过 HTTP 请求数据的查询语言。

　　软件工程师届的传奇人物 Grady Booch 也加入了争论，其表示从这次的情况来看，“有更多证据表明，马斯克没有能力领导 Twitter 这样一家运营全球弹性业务、掌握软件密集型网络体系的组织。”

　　生于 1955 年的 Grady Booch 是一位资深软件工程师，以与 Ivar Jacobson 和 James Rumbaugh 一起开发统一建模语言 （UML） 而闻名，并因其在软件架构、软件工程和协作开发环境方面的创新工作而享誉国际。

　　他补充说，“永远不要低估复杂软件密集型系统架构的制度知识（大部分未记录），这些知识由少数久经沙场的人掌握。”

　　马斯克：吵不过你但我可以开除你！

　　根据 Frohnhoefer 的说法，Twitter 应用程序启动时，会发出大约 20 个后台请求。似乎是为了澄清自己最初的推文，马斯克随后回应说，“事实上，当有人使用 Twitter 应用程序时，你没有意识到有多达 1200 个‘微服务’被调用，这并不好。”

　　“Twitter 的几位工程师分别告诉我大约 1200 个 RPC，这与微服务的数量相匹配。（所以）前雇员（应该指的是 Frohnhoefer）错了。在美国，同样的应用程序需要大约 2 秒来刷新（太长），但在印度大约需要 20 秒，因为批处理 / 冗长的通信。实际传输的有用数据很少。”Frohnhoefer 再次对马斯克表示不同意此说法，他发推文说“生成时间线所需的数量接近 200，而不是 1200。”

　　马斯克认为 Twitter 使用了过多的“微服务”，导致 App 刷新缓慢，而且他们似乎真的在试图关闭一些“微服务”，以测试哪些“微服务”是运行 Twitter 时所必须的。然后，很多人发现用于 2FA 身份验证的微服务也被关闭了．．．．．．

　　现在很多大型企业的技术架构都会有点臃肿，但 Twitter 的基础架构也不是一个完全的黑匣子，因为已经有大量的讨论、博客文章和其它材料诠释过 Twitter 所使用的技术了。而马斯克似乎是想将 Twitter 缩减为仅保留其核心功能，来验证性能是否能得到提升，他的方法还是直接进行“拉闸”式测试。

　　马斯克和 Frohnhoefer 之间的谈话很混乱，双方用了几个小时，分散在许多线程之中。具有讽刺意味的是，马斯克很快就解雇了 Frohnhoefer。而这名 Twitter 工程师也直接晒出了自己被踢出办公系统之外的图片。

　　而且一同回击马斯克“不会用 GraphQL”的 Sasha Solomon 也发表推文称，自己因为昨天发布的推文已经被解雇。

　　至于客户端、服务器、请求数和微服务的关系，负责 Twitter k8s 基础设施的工程师向马斯克提供了一个示意图，他同时表示，几年前一个叫车服务都可能需要 4000 个服务。

　　写在最后

　　十年前，当 Twitter 开始解决可扩展性和可靠性问题时，能使用的开源工具并不多。随后，这群工程师努力创建了世界一流的存储系统、工作负载调度程序、RPC 框架等，并为世界开源了其中不少的项目。

　　现在，马斯克突然就来“指手画脚”了，也难怪众多工程师不服气。而且个别地区 App 性能体验糟糕，也不仅仅是接口调用问题，手机和数据中心之间数据传输的物理条件也是一大影响因素，特别是在印度这样存在很多低端手机的环境下。

　　至于为什么要代码冻结？没有人确切知道，但有人猜测马斯克已经变得偏执，担心一些心怀不满的工程师可能打算在他们离开时搞些破坏？

　　根据匿名职场论坛 Blind 对数百名 Twitter 员工的调查显示，89% 的人不认为 Twitter 会在马斯克的管理下取得成功。而马斯克面临的压力还不只源于 Twitter 公司内部。自从以 440 亿美元收购这家头部社交媒体平台以来，众多广告商和知名用户开始纷纷退出 Twitter 阵营。

　　与此同时，Twitter 的工程师们则借此机会心情嘲笑这位新任掌门人，想办法让领导班子出丑。“现已倒闭的医疗技术公司 THeranos 也出过类似的状况，工程师们讨论前总裁兼首席运营官 Sunny Balwani，所以大家就会编造一些词汇，看能不能让对方误以为是真的并学着使用。于是他们一直说‘crazing’，直到 Balwani 自信地重复了一遍。”

　　没准马斯克治下的 Twitter 也会在未来成为一座笑话大宝库。到时候当我们感觉无聊了，就会说“在？来点马斯克笑话。”

　　参考链接：

　　https：//www.theregister.com/2022/11/14/musk_twitter_rpc_spat/

　　https：//twitter.com/elonmusk/status/1592177471654604800

　　https：//twitter.com/ahmetb/status/1592189613774602242

　　https：//www.platformer.news/p/elon-only-trusts-elon

　　https：//www.theverge.com/2022/11/14/23458247/elon-musk-fires-engineer-correcting-twitter

　　https：//news.ycombinator.com/item？id=33595520

　　https：//news.ycombinator.com/item？id=33597677

（声明：本文仅代表作者观点，不代表新浪网立场。）