架构师（2022年8月）
架构师 2022年08月刊 本期主编罗燕珊 流程编辑丁晓昀发行人霍泰稳 反馈feedback@geekbang.com 商务合作hezuo@geekbang.org 内容合作editors@geekbang.com CONTENTS/目录 掚挿])PU 搞不定移动端性能，全球爆火的Notion从Hybrid转向了Native 放弃GitHub，现在正是时候？ 这群WebAssembly大佬创业失败了：有时从JS迁移到Wasm并不值当？ 椚雿崣]5IFPSZ 详解“洋葱架构” 下一代负载均衡的思考与实践 䲀虛俒畎]ASUJDMF 编程不适合12小时工作制，“我有灵感才工作”|专访《Java编程思想》作者 BruceEckel 多领域试水，WebAssembly距离大规模应用还有多远？ 錜挿]0QJOJPO RustforLinux要来了，这对我们意味着什么 卷首语 前端团队做技术决策的五条原则 作者：宝玉编辑：辛晓亮 今年上半年我曾经做过一个关于如何做架构设计的分享，其中有个很重要的话题是“如何更好地做技术决策“，针对我们的前端团队，我整理了5条做技术决策的原则。 原则0：遵守公认的好的设计原则 •DRY-Don'tRepeatYourself（不要重复自己） •KISS-KeepItSimple,Silly（让设计尽可能的简单） •YAGNI-Youaren'tgonnaneedit（只做刚刚好的设计，不要过度设计） •其他 原则1：找出最本源的需求，而不应该局限于当前的技术实现和资源 很多时候我们很容易被表面需求所误导，就像乔布斯的名言：“如果亨利福特在发明汽车之前去做市场调查，他得到的答案一定是大家想要一辆更快的马车”，如果我们在做设计和技术决策的时候，没有找出用户的真实需求，就会很容易在错误的方向上狂奔，做很多无用功。 要找出本源的需求，就需要多问为什么，多和干系人沟通，少考虑技术细节，少被 现有的技术所误导或局限。 案例：设计部门希望设计系统支持Angular 我们设计部门最近希望我们的设计系统ᨀ供Angular版本，因为当前只支持React版本。 从这个需求来看，表面上是要我们开发Angular版本，如果仔细追问他们到底为什么需要Angular版本，是因为有一个团队还在用Angular。他们希望这个团队能使用我们的设计系统，但是对方表示用不了。 其实本源的需求是希望有更多的团队使用我们的设计系统，而不是要单纯支持 Angualr。 那要满足团队的这个需求，是不是非要做一个Angular版本不可呢？当然不需要。如果我ᨀ供一个类似于BootStrap的HTML和CSS版本，他们一样能用起来，而这么做成本不高，并且其他的团队也可以用。 （更多案例可参考下图） 原则2：聚焦于“收益”、“成本”和“风险”三者之间的平衡，而不是技术本身 每一次技术决策，其实本质上就是一次取舍（Trade-Offs）。 每一次取舍（Trade-Offs），本质上就是在“收益”、“成本”和“风险”三者之间的平衡。 既然每一个决策都涉及到收益成本风险，那么就不能只看收益而无视成本和风险。就像前一个案例中ᨀ到的，设计部门考虑的是Angular版本带来的收益，但是他们却忽略了打造一套Angular版本的设计系统所需要的成本，以及可能带来的巨大风险。 所以在做技术决策的时候，理性考虑一下决策背后的收益、成本和风险的关系是很必要的，而不是仅靠喜好或者直觉来做决策。 原则3：选择某个技术背后的生态系统而不是某个技术 这条原则特别适用于前端领域，在前端，各种新技术、框架、工具层出不穷，如果总是追新，或者被某个软文吸引轻易选择了某个技术，往往最终会带来巨大的成本。 案例：我们为什么从Preact迁移到React 在早些年的时候，我们前端选择了Preact作为UI渲染技术，这有早年ReactLicense的原因，也有Preact体积更小、性能更好的原因。 然而在这几年的使用过程中，发现很多不足的地方，核心原因其实都是生态不够好。 比如说Preact调试很麻烦，它不像React有一个强大的DevTools；比如说我们遇到过Preact在服务端渲染的内存泄漏问题，如果像我们这样大规模访问量的用户多一点，可能早就有人踩过坑了，不需要我们去花很长时间定位并最终去解决这个问题；再比如最近我们在集成Nextjs，Nextjs是完全为React设计的，对Preact兼容性并不好。 这样的案例还很多（如下图），所以选择技术，它背后的生态和社区活跃度很重要。 原则4：不仅要考虑如何构建，还要考虑如何维护 这是一个常见的问题，很多人只管搭建新项目的时候爽，而不管后续维护是不是困难，用了一堆自己喜欢的新技术，最后难以维护。下一个人接手了，搞不好会推翻重写一遍，这样的循环一次又一次。 这样的错误我也常犯，比如2年前ReactHooks刚出的时候，我就迫不及待用它来替代Redux。结果上线后发现不好维护，有Bug也不好定位，不像以前Redux，数据流特别清晰，借助工具非常方便重现和定位问题，最终上线没多久就改回去了。 所以现在在做技术决策的时候，我们很注意的一个问题就是将来的维护会不会很麻烦。包括我在做代码审查的时候，有时候看到一些功能能运行得很好的PR、但是代码写得比较难懂的，或者说没有遵守最佳实践的，但只要会给未来的维护带来麻烦的，我都会毫不犹豫要求重写，尽可能避免增加日后的维护成本。 最后简单总结一下上面就是我们现在实践的五个技术决策原则： •原则0：遵守公认的好的设计原则； •原则1：找出最本源的需求，而不应该局限于当前的技术实现和资源； •原则2：聚焦于“收益”、“成本”和“风险”三者之间的平衡，而不是技术本身； •原则3：选择某个技术背后的生态系统而不是某个技术； •原则4：不仅要考虑如何构建，还要考虑如何维护。 这些原则绝大部分时候都可以很好地帮助我们做出正确的决策，避免踩坑。我也会一直在反思曾经做过的决策，对于不太好的决策，会反过来考虑是否要修订这些原则，最终通过不断完善决策原则，帮助我和团队更好地做出技术决策。 关于作者 宝玉，前微软Asp.Net最有价值专家，互联网科技博主。 搞不定移动端性能，全球爆火的Notion从 Hybrid转向了Native 作者Tina 7月20日，Notion笔记程序发布了版本更新，并表示更改了移动设备上的技术栈，将从webview逐步切换到本机应用程序，以获得更快更流畅的性能。 该团队声称该应用程序现在在iOS上的启动速度ᨀ高了2倍，在Android上的启动速度ᨀ高了3倍。 Notion发布的这条Twitter也得到了广泛的关注，几天之内就有了上千条转发。由于前几年Notion的技术栈一直没有公开，开发者对此充满了各种猜测，很多人认为Notion使用的是ReactNative或Electron，因此这次Notion宣称切换为原生iOS和原生Android，再一次引发了“框架之争”。 其中有不少人发表了“贬低”跨平台开发的看法，对ReactNative等框架产生了质疑，毕竟现在向跨平台过渡是不可避免的，这些框架是对原生工具包的一个“威胁”，而Notion恰恰又切换到了“原生”开发模式。 实际上，在2020年之前Notion使用的是ReactNative，随后切换到了Hybrid混合开发模式：使用Kotlin/Swift+运行网络应用程序的Web视图。但移动端的性能一直是一个问题，2年之后，Notion再次切换到了原生开发模式。 有网友认为，像Notion这样重UI和交互的产品，如果不知道如何掌握Web技术，那么对他们的产出速度表示担忧。面对这种吵翻天的状况，Notion的前端工程师也因此再度出面回应这次切换的原因和一些思考。 Notion的发展和理念 Notion是一款将笔记、知识库和任务管理无缝衔接整合的多人协作平台。Notion打破了传统的笔记软件对于内容的组合方式，将文档的内容分成一个个Block，并且能够以乐高式的方式拖动组合这些Block，让它使用起来十分灵活。 Notion由IvanZhao、SimonLast于2013年在旧金山创立。去年底，Notion获得了2.75亿美元的C轮融资。截至2021年10月，Notion估值103亿美元，在全球拥有超2000万用户。Notion的创始人和CEOIvanZhao是一位80后华人。他出生于中国新疆，曾就读于清华附中，中学时随家人移居加拿大，现在被很多人认为将成为硅谷的下一个袁征（Zoom的创始人）。Ivan在大学时期主修认知科学，学习的是人的大脑怎么运作，外加对计算机也很感兴趣。 “我想分享一个Notion创始人的故事。2013年的时候，我在一家咖啡馆遇到了Ivan，他对我的钥匙复制服务感兴趣，但他很不喜欢这个服务的网站。于是他用一晚上的时间，用HTML和CSS重写了它”。 Ivan也曾表示“我的很多朋友都是艺术家。我是他们中唯一会编码的人。我想开发一款软件，它不仅可以为人们ᨀ供文档或网页。”因此，在2012年大学毕业后，在文档共享初创公司Inkling工作期间，他创办了Notion。原本的目标是构建一个无代码应用构建工具，不过项目很快失败了。随后Ivan与Simon迁往了日本京都，待了一年左右，小而安静的地方能“让我们专注在写代码”，在相对无压力和与世隔绝的环境下，构思并设计出了现在的Notion原型。用Reddit论坛上的一条获得高赞的网友总结就是：一个Notion=Googledocs+Evernote+Trello+Confluence+Github+Wiki+…… “工具应该模仿人脑的工作方式。但由于每个人的思维和工作方式都不同，这意味着工具需要非常灵活。”Ivan解释道。而Notion创建的目的，就是将用户从一堆各式各样的生产力工具之中解放出来，给予一个干净清爽、简便易行的AllinOne工作平台。企业用户也可以在Notion上基本实现公司的内部管理所需要涉及到的所有功能。包括公司 知识库和资料库的创建与管理、项目进度管理、信息共享、工作日志、内部社交、协作办公等等。 有人甚至说，Notion堪比办公软件届的苹果。在2016年发布1.0版本后，因其独特的设计、专注于将事情做得更好、对投资人的冷淡态度，外加疫情远程办公潮，多方面因素让Notion迅速火遍全球。作为一款Allinone的概念型工具，Notion一直被众多企业抄作业，但它目前几乎未逢敌手。 Notion为什么要两次更换技术栈？ Notion在2017年、2018年分别发布了iOS客户端和Android客户端。在发布2.0版本之后，该公司于2019年以8亿美元的估值筹集了1000万美元的资金。但也许和创始人的发展理念相关，Notion的员工数量一直不多。 2019年3月的时候，工程团队总共才4个人，当时Notion用ReactNative来渲染web视图。Notion在Twitter上解释说，这是为了更快地部署新功能和进行一些其他修复。 但如果这个系统适合开发者，那么它对用户来说远非最佳：许多人抱怨移动版本非常缓慢。“即使是新iPhone也非常慢-大约6-7秒后我才能开始输入笔记。到那时我都快忘记了我之前想写什么。它基本上是一个非常重的web应用程序视图。”“如果Notion不选择改变，那么它将迅速被其它同类产品取代。”...... 2020年，Notion第一次因这个问题，更改了技术栈，放弃ReactNative，切换到了Hy-brid开发环境。 Notion前端负责人JakeTeton‑Landis表示，“ReactNative的优势在于允许Web开发人员构建手机应用程序。如果我们已经有了webview，那么ReactNative不会增加价值。对我们来说，它让一切变得更加困难：性能、代码复杂性、招聘等等。用ReactNative快速完成任务的同时，也
