网站的基本功能,wordpress封装app ios,万网网站备案,网站开发中为什么有两个控制层大家好#xff0c;我是若川。19年我写的 lodash源码 文章投稿到海镜大神知乎专栏竟然通过了#xff0c;后来20年海镜大神还star了我的博客#xff0c;同时还转发了我的微博。时间真快啊。今天分享这篇Node.js的讨论。2021 年上半年早已过去#xff0c;回顾 Node.js 在国内的… 大家好我是若川。19年我写的 lodash源码 文章投稿到海镜大神知乎专栏竟然通过了后来20年海镜大神还star了我的博客同时还转发了我的微博。时间真快啊。今天分享这篇Node.js的讨论。2021 年上半年早已过去回顾 Node.js 在国内的发展和生态建设我们积累了一些经验摸清了一些方向。在所谓的「Node.js 后框架时代」其技术发展将随着语言演进和整体前后端技术架构的升级将会搭上高速快车。这篇文章我们采用实录AMA的方式就和 天猪 关于「Node.js 框架设计及企业 Node.js 基础建设」相关话题的讨论内容进行总结。接近 90mins 的线上讨论这篇文章相信对前端开发者尤其是 Node.js 开发者会有所启示。交流概览EggJS 官方站点分享人介绍阿里-天猪相关周边如何评价阿里开源的企业级 Node.js 框架 EggJSEggJS 一个讨论Egg Node.js 从小工坊走向企业级开发分享人介绍天猪Egg 开源接口人cnpm 接口人。隶属于蚂蚁体验技术部 - 广州分部负责蚂蚁 Node.js 基础设施建设包括 Chair、TNPM、BaaS 服务等。日常工作比较跨界涉及到研发平台PaaS框架包管理。分享内容介绍分享内容我们按照Node.js 框架设计相关Node.js 方向相关生态发展和开源社区相关三大方向展开每一个方向对应若干讨论话题/问题。下面展现部分交流内容。Node.js 框架设计相关话题一关于 Node.js 框架设计如何看待其他 Node.js 框架如 ThinkJS, fastify 等如何看待和对比 farrow-js函数式风格的 Node.js 框架相比较而言设计理念上差异还是很大的。天猪认为定位不一样 Egg 的定位是框架的框架面向的目标用户是团队的架构师或技术负责人帮助他们来定制适合特定的业务场景的上层业务框架。解决的是大规模企业级开发时的生态共建 差异化定制问题。像 Chair Midwaybeidou 这些才是面向一线应用开发者的上层框架我们今年也会开源一个 TEgg 方案提供官方的 TS 方案以及业务逻辑复用能力。从天猪的角度看完全可以用 Egg 封装出一个 ThinkJS 类似风格的框架。编者按不管是 koa 还是 express它们都属于轻量级的 Node.js 框架它们使用起来优点明显使用简单中间件机制灵活社区生态完善。但是在实际使用中随着业务复杂度上升以及不同场景下对于 Node.js 框架的不同诉求在直接依赖 koa 或 express 的实践中我们发现了一些痛点包括但不限于需要业务手动配置各种中间件在上一条条背景下一些基础通用的中间件缺少统一抽象和维护容易出现重复代码以及各造轮子重复中间件逻辑现象koa 和 express 并不约束项目规范比如目录结构等不同水平程序员搭建的 Node.js 项目风格不统一质量参差不齐koa 和 express 并不直接解决 Node.js 项目的基建部分不解决调试、开发配置等关键环节使得生成效率难以最大化提升为了解决上述问题社区上出现不少基于 koa 和 express 的上层 Node.js 框架比如阿里体系基于 EggJS 之上的 Chair、Midway 等框架。Spring 风格的 NestJS360 奇舞团的 ThinkJS这些框架在不同程度上封装了 koa 和 express并给出了各自风格的上层方案但都也不完全是一个开箱即用的企业级 Node.js 框架不能直接满足 XX 企业内场景难以直接融入已有 Node.js 项目理想情况下仍需一道封装。此外社区上还活跃着着fastifyfarrow-jsrestifyhapisails 等 Node.js library/framework各自侧重点性能优先/易用性优先等和分层领域low level/high level 等各不相同。对于一套企业级 Node.js 框架来说设计一套 Node.js MVC 开发框架或在 Egg 之上再封装其目的是保障易用性、稳定性的基础上提升 Node.js 项目开发的效率及服务性能。话题二一个关于 Node.js 框架性能的讨论EggJS 文档中关于特性描述提到了「基于 KoaJS 开发性能优异」。其中前半句「基于 KoaJS 开发」和后半句「性能优异」构成因果关系吗如果构成KoaJS 带来的性能收益体现在哪里如果不构成那么 EggJS 关于性能方面做了哪些事情除了 co 升级为 async/await 之外天猪认为没有因果关系这里当时只是陈述 Egg 的 2 个特点在那个时间点来说Koa 在社区的认知里面还是属于先进的那时候还是 Express 的中期。其实对于大部分的应用来说框架远远不会是性能的影响因素性能更多可能出现在和后端通讯的序列化/反序列化不合理的调用链耗时的 CPU 操作等等。Egg 宣称自己有优异的性能的底气在于在过去 9 年来在线上双十一量级的压力场景下的稳定表现绝大部分性能问题都能被发现并逐一解决AliNode 利器举个例子最近语雀居然发现 Router 成为了性能瓶颈之一1000 路由20ms。同时丰富的实践也让我们很清楚一个事实就是大部分的性能问题都轮不到框架来背锅很多都是业务不合理使用。因此我们在性能上优化主要不体现在 Egg 框架本身。比如fasitfy 基于 Schema 来优化序列化的性能这些好的社区实践我们也一直在吸收如 sofa-hessian-node 针对复杂对象场景的性能有明显的提升。编者按Egg 方面通过相关 benchmark发现去除 co 后堆栈信息更清晰能带来 30% 左右的性能提升不含 Node 带来的性能提升但对于 Egg 本身来说框架并没有着重发力性能细节没有像 fasitfy 等框架内置性能机制优化操作对 perf friendly 锱铢必较。事实上对于一个 Node.js 服务来说服务的响应性能瓶颈往往在业务工程当中在框架设计方面使用便利性和性能的平衡是一个永恒的话题。当然社区上也鼓励和欢迎任何一性能为「卖点」的框架。这里希望大家注意的是脱离业务的性能优化——只会是框架本身的「自嗨」。像 sofa-hessian-node 案例一样由业务中发现性能痛点后端交互的序列化性能瓶颈再去借鉴业界的相关实践最终业务和技术相互促进框架在各个层面也会得到更多发展是一个非常可贵的相互促进结果。话题三仍然是一个关于 Node.js 框架性能的讨论EggJS 加载器的设计看上去在启动时并不很性能友好比如 Egg 会遍历项目中的 loadUnit再比如插件的加载过程这方面有相关的设计考虑吗天猪认为在 Egg 发起时那个时间点甚至包括现在启动的时间其实没那么重要因为都是集群部署的方式来分批滚动升级的。一般应用插件也不会太多我们最复杂的场景 Chair 内置的插件近百个读取文件的耗时其实占比很小更多的启动耗时在于某些插件需要和后端中间件服务建联拉取配置等等初始化上。所以上面提到的『遍历目录』这个其实不会对性能有影响而要看插件本身的自有逻辑复杂度。Serverless 时代做极速启动时可能就会有一定的影响这块可以通过构建期的预分析来帮助框架减少文件系统的遍历但收益不一定大。编者按Node.js 框架启动性能往往是一个被忽略的话题但在容器化和 Severless 大势发展下启动速度逐渐被开发者所关心。这一方面我们将会持续关注相关话题。话题四一个关于框架渐进式设计/发展的讨论EggJS 内置了 static 服务插件在 EggJS 内置哪些插件/能力的设计上考虑有哪些比如为什么 static, i18n, logger 作为内置插件出现这些能力像其他插件一样做成可插拔的不更好么天猪认为由于历史原因当时 Egg 开源的时候没有拆的很干净。其实可以看下 egg-core它其实才是 egg 的最核心部分Koa 在 Node HTTP 之上提供了一层很薄的语法糖封装并提供了洋葱模型。egg-core 在 Koa 之上提供了一套 Loader 机制并基于它延伸出了插件和上层框架。特定场景框架chair-serverless | midway-faas | ↑ ↑ 团队业务框架chair | midway | nut | ... ↑ ↑ ↑ ↑ 阿里统一框架ali/egg ↑ ↑ ↑ ↑ 开源社区框架egg事实上Egg 的应用、插件、框架的目录结构几乎一模一样。实际开发过程中我们也有一套 渐进式的演进方式分享给大家实验性的功能可以先在应用里面实现作为 inline plugin 通过 path 方式来挂载。功能稳定后就抽出来变为独立的插件应用再通过 npm 依赖方式引入只需改两行代码即可。当该功能成熟后成为团队的统一规范时直接把这个插件集成到 Framework 中所有应用只需重新安装下依赖即可立刻享受到。这个过程是闭环的是渐进式而且升级过程几乎无痛。编者按对于任何一个框架的设计来说渐进式是一个重要的课题。比如 Vue.js比如 React.js渐进式的设计能够保证业务开发者更敏捷地迭代更方便快捷地使用框架同时依然保留有对架构进行优化、基础能力进行下沉的能力。对框架设计者来说渐进式的设计更是保障框架本身进步发展的关键。话题五一个关于框架的上层封装讨论关于基于 EggJS 的上层框架方案有没有 Best pratice 建议比如Chair 基于 EggJS 的封装做了哪些「有趣、不一样」的事情吗有哪些值得借鉴的吗天猪认为上层框架是针对特定的业务场景 或 特定的基础设施 的封装而随着一波又一波的需求过来各种阶段性的妥协基础设施的演进它注定是维护和治理的重灾区。一个新的插件该不该内置如何渐进式的推进又如何在它被另一个插件替代时推动下线。业务场景变化的时候框架该不该多套娃一层。锁不锁版本如何推动更新出现问题如何快速止血等等对于这些问题框架的应用规模是 10 和 1000 时的思考点是不一样的。话题六关于设计遗憾和未来计划的讨论关于 EggJS 的进程管理问题以及相关部署、重启等环节在容器化 docker 化的背景下EggJS 的相关设计是否需要跟进和调整天猪认为Egg 的 agent 提出的背景是后端中间件服务曾经被我们 ddos 了当时好像是 diamond 这个远程配置服务我们每一个进程都会在启动的时候向它拉取配置所以需要有个 agent 来统一做这事拉取完后再共享给 workers。在 Serverless 的大背景下类似的配置拉取其实有云原生的内置方案不需要框架层过多考虑。我们也确实有考虑单进程模型并在内部也有一些实践但目前没有看到特别的收益。在 Egg 3.0 里面cluster 不会内置单进程模式也能对 mock 和单测这块带来更清晰的逻辑。EggJS 有不适用的场景吗是否有在设计上的一些遗憾未来有哪些计划天猪认为受限于 Koa目前更适合于 Web 框架。在 3.0 Context 模型后这块应该会更灵活不再受限。据我所知有不少开发者用来当队列处理器或者任务执行器。前者不是不可以用只是总会觉得有一点别扭。后者其实 FC 这类函数计算会更合适。Egg 3.0egg-core 会更纯粹一套 Loader 机制 洋葱模型面向未来。Loader 的生命周期支持异步从而可以支持异步配置不依赖于 Koa可以脱离 Web 框架这个局限我们需要的只是洋葱模型可以自行实现核心是一个 Context根据不同的流量入口实例化为 HttpContext、RPCContext、WSContext 等。我们对 socket.io 等的支持就不会看起来太别扭。以上是 Egg 的后续规划编者按很少有一种技术设计能够完全开启「我在 XX 年后等你」的视角关于 Node.js 的单进程/多进程模型等诸多话题的背后其实是基础服务设施的变迁编程模型趋势的演进浪潮。这一方面前端开发者将会越来越多的「跨界」也只有迈出更多步才能发挥更大的价值。 一个 Node.js 框架设计实在是整个技术链条上的微观的小环节但管中窥豹我们的边界在更远方。下面我们进入整个 Node.js 方向上的讨论。Node.js 方向相关话题一关于下一代 Node.js 框架和 Node.js 趋势未来下一代 Node.js 框架会有什么样的发展趋势你们团队目前探索的方向是比如 BFF - SFF天猪认为框架主要体现在研发模式这块涉及到用户编程界面层。框架是一个重要的点但不是全部藏在冰山之下的还有整个研发生命周期研发平台、迭代模型、部署、前后端研发模式、监控体系等等。Node SDK 这块未来会 ServiceMesh 化掉它们应该回归后端中间件团队的工作范畴毕竟由后端来维护自己的服务对应的 SDK 才是最合理的分工。一个团队的业务可能一下子不需要 Node.js可以不用但团队必须具备随时可以有的准备没有这个储备你们的技术选型视角和话语权会完全不一样。Node.js 是前端的一个可选能力也是一个必要的储备。如上图Node 的一部分场景是聚合逻辑层会往云端一体化方向发展另一部场景是会走微服务方向跟后端的框架没啥区别当今的业界认知是跨语言方向。话题二关于 APM关于 APM我们知道 AliNode除此之外还有其他建议或者经验吗关于 AliNode 目前发展情况比如 runtime 替换掉 Node.js runtime这种方式是否会成为趋势阿里之外有比较成熟的应用吗天猪认为可以考虑用一君的 easy-monitor优点是比 AliNode 更低的维护成本通过 Addon 方式而不是 Runtime 方式从而不绑定 Node Runtime 升级更快的适配。支持私有化部署。虽然 AliNode 的 agent 上报是开源的但人与人的信任还是很难的开源。说到 APM 这里其实我们内部曾经有过一个有趣的讨论Serverless 后 APM 还重要么反方观点内存泄露就内存泄露呗小的泄露无所谓到了阀值直接动态腾挪换机器。我个人认为 APM 还是很重要的工具本身很重要它是查问题的利器和底气。直接腾挪是实际运维的 ROI只是代表了某个时刻暂时可以不用费精力查问题但不代表问题不应该被解决。编者按重点再聊聊 APM上面的辩论「Serverless 后 APM 还重要么」反方其实是在靠中台能力来降维规避问题这背后其实是一个技术态度问题。Node.js 服务自己的问题还需要自己来解决。那么出现了 Node.js 方面的问题如何借助 APM 来进行调试发现并解决问题呢我们又积累了哪些实战场景经验呢请关注我们后续会带来更多线上真实案例。话题三关于 Node.js 原生 http 模块的一个讨论EggJS 基于 urllib 实现了一个 httpclient这个考虑是什么性能吗接上问EggJS 既然实现 httpClient那么如何看待 Node.js undici似乎是一个更贴近官方的方案fastify 一开始就在使用 undici, 如何看待主打性能的 fastifyNode.js 实践经验上性能是否是比较棘手的一环天猪认为因为 urllib 是我们实现的在这么多年的实践中踩了 http 的无数坑跨过之后沉淀到 urllib 里了多年后它的稳定性我们无比相信。所以目前重度使用了 urllib。undici 最近也有关注到也稍微用了下。从现在这个时间点来看 urllib 的代码确实有点乱我也两度想重构它但 ROI 不是很高就没下手。未来也许有机会把它重构掉。编者按Node.js 及其相关的基础建设决定着 Node.js 落地情况也决定了 Node.js 最终价值。这主要可以分为两个方向Node.js 本身语言演进Node.js 对接中台基础其一 Node.js 本身语言的演进比如undici 提供了 Node.js core http 模块的代替方案带来了性能和稳定性的提升解决了 Node.js core http client 历史的重大技术债务。另外 Node.js 对接「更后的后端体系」是基础建设的重要一环比如 ServiceMesh 生态。举个例子通过 Sidecar 模式我们可以在 Kubernetes Pod 中在原有应用容器旁边运行一个伴生容器由 Sidecar 接管进出应用容器的所有流量实现 just work 的应用容器监控。但应用容器本身的运行细节如 CPU ProfileMemory usuage 等依然需要 Node.js 开发者给出答案因此有了 AliNode也有了不侵入 Node.js runtime 的 Easy-monitor。对于企业级 Node.js 解决方案来说不妨经常反问自己「我们还缺什么我们还能做些什么」。毕竟 Node.js 基础建设的发展始终在探索中前进在这方面希望每一名开发者贡献力量。生态发展和开源社区相关话题一锁/不锁版本ESM 和前端生态协作链2021 年对于版本管理和 Node.js ESM 有哪些新的看法比如锁版本Node.js package 对 ESM 的支持程度)天猪认为锁版本 vs 不锁版本一个永恒的话题。天猪的观点是不同团队基础能力下的权衡没有银弹。锁版本是一个保守的方案击鼓传花把炸弹留给后人。前端依赖和后端依赖是 2 个话题。事实上等有空了再统一升级往往是一个美丽的谎言这个在工程上的可执行性不是很看好。这里附上旧文一篇为什么我不使用 shrinkwraplock 后面天猪会写一篇新的。继续这个话题在职责分离维度框架层面可以考虑锁自己的子依赖框架维护者来负责推动升级应用开发者锁自己引入的依赖职责分离。但这一点上需要 npm 工具和研发平台上的紧密配合。给框架维护者提供一种锁内部版本的机制且能由框架维护者来主导应用的框架版本升级当然提供 CITGM 机制来帮助框架维护者回归也是很有必要的。这里附一个「彩蛋图」——「研发平台」中关于版本和生态的「仪表盘」我们不妨继续探索「研发平台」即基于研发平台的依赖生态解决方案我们给出设计如下本地、开发环境不锁版本。信息公开每次迭代构建后依赖的更新情况要让开发者清晰。配套的止血机制未来需要更智能化。紧急迭代测试 → 预发阶段允许开发者在平台锁版本。更多信息编者按在生态发展和开源社区相关部分我们和天猪重点聊了「锁/不锁版本」的问题。这个问题虽然老生常谈但他绝不是一个包管理方案选型的问题「锁/不锁版本」的背后何尝不是整个前端社区生态。这方面不同团队给出的不同答案都在诠释着对前端社区生态的不同理解。同时我们也期待 关于现代包管理器的深度思考——为什么现在我更推荐 pnpm 而不是 npm/yarn 之后的 TNPM以及不断进化的前端技术潮流。话题二关于项目开源和普及度EggJS 在阿里内部是如何推行的推行当中遇到的最大困难是什么可以再透露下目前内部哪些系统使用了 EggJS 吗天猪好像没怎么推行就普及的天时地利人和吧编者按好凡尔赛手动狗头2015.10.13 内部拉通 Node 工作组闭关一周产出一份 RFC基于 RFC 产出 ali/egg 1.02016 年 JSConf 开源年底的时候差不多几个大的 BU 的上层框架都重构为基于 egg 了。目前你能看到的阿里系的页面绝大部分都是基于 Egg 的像蚂蚁大部分流量入口都是基于 render 这个高性能的渲染服务蚂蚁森林天猫那边的斑马还有财富的好几个大的 BFF 有数千个 PODNode 是阿里的第二大语言而 Egg 是唯一的官方框架不是基于 Egg 的框架无法跟内部的各大中间件交互也无法很好地被研发平台和监控平台等支持。阿里有数千个 Node 应用。语雀 - 可能是西湖区最大的 Node 全栈应用。目前这个时间点会遇到一些问题整个大环境变了所以 BFF → SFF总结不管是 Node.js 还是其他前端技术方案我们都期待着一个更友好开阔、更互动交流的氛围。我们和 天猪 的交流名义上是「 Node.js 框架」其实更是对 Node.js 甚至前端未来发展的讨论。个人力量太过有限但我们对技术抱有理想也寻求更多的交流、共创。????关注我们后面将会有更多前端技术方面的想法和积淀产出Happy coding!最近组建了一个江西人的前端交流群如果你是江西人可以加我微信 ruochuan12 私信 江西 拉你进群。推荐阅读我在阿里招前端该怎么帮你可进面试群毕业年限不长的前端焦虑和突破方法前端抢饭碗系列之Vue项目如何做单元测试老姚浅谈怎么学JavaScript················· 若川简介 ·················你好我是若川毕业于江西高校。现在是一名前端开发“工程师”。写有《学习源码整体架构系列》多篇在知乎、掘金收获超百万阅读。从2014年起每年都会写一篇年度总结已经写了7篇点击查看年度总结。同时活跃在知乎若川掘金若川。致力于分享前端开发经验愿景帮助5年内前端人走向前列。点击上方卡片关注我、加个星标今日话题略。欢迎分享、收藏、点赞、在看我的公众号文章~
