首页 文章 精选 留言 我的

精选列表

搜索[优化]，共10000篇文章
优秀的个人博客,低调大师

Facebook 将对 React 的优化实现到了浏览器！

点上方蓝字关注公众号「前端从进阶到入院」 精选原创好文、进阶交流群助你进入大厂 想要提高一个网页的加载速度是非常困难的，如果你的网站是在使用 JavaScript 渲染的内容，你必须要在网页的加载速度和网页的输入响应能力之间作出权衡： 一次性执行首屏需要执行的逻辑（负载性能好，输入响应能力差） 将复杂的逻辑拆分成更小块的任务执行，以保证对外界输入的响应（负载性能差，输入响应能力好） 为了避免这种取舍，Facebook 在 Chromium 中提出并实现了 isInputPending() API，它可以提高网页的响应能力，但是不会对性能造成太大影响。 目前 isInputPending API 仅在 Chromium 的 87 版本开始提供，其他浏览器并未实现。 背景 在现今的 JavaScript 生态中，大多数工作都是在一个线程完成的：主线程。这种设计为开发者提供了一个健壮的执行模型，但是如果脚本执行的时间太长，则用户体验（尤其是响应能力）可能会遭受严重损失。例如，用户正在输入一些内容时， JavaScript 正在执行大量的逻辑，则在这些逻辑完成之前，浏览器都不能处理用户的输入事件。 现在的最佳实践是通过将复杂的逻辑拆分成更小块的任务执行来解决这种问题。在页面加载期间，页面可以运行一些 JavaScript 逻辑，然后将控制权转交给浏览器，这时浏览器可以检测自己的事件队列，看看是不是需要响应用户输入，然后再继续运行 JavaScript ，这种方式虽然会有一些帮助，但是同时也可能会带来其他问题。 每次页面将控制权交还给浏览器时，浏览器都会花费一些时间来检查它的事件队列，处理完事件后再获取下一个 JavaScript 代码逻辑。当浏览器更快地响应事件时，页面的整体加载时间会变慢。而且，用户输交互比较多的情况下，页面加载会非常慢。如果我们不那么频繁地进行上面的过程，那么浏览器响应用户事件所花费的时间就会更长。 Facebook 提出的 isInputPending API 是第一个将中断的概念用于浏览器用户交互的的功能，并且允许 JavaScript 能够检查事件队列而不会将控制权交于浏览器。 下面我们来具体看一个例子。 一个例子 假设您需要做很多显示阻塞的工作来加载页面，例如，从组件生成标记，分解质数或仅绘制一个很酷的加载微调器。这些中的每一个都分解为一个离散的工作项。使用调度程序模式，让我们勾勒出如何在假设的processWorkQueue()函数中处理我们的工作： 假设你再首屏加载页面时要处理非常多的阻塞逻辑，例如从组件生成标记，分解质数，或者只是绘制一个很酷的加载器动画。这些逻辑都会被分解成一个独立的工作项。使用 scheduler 模式，让我们在一个假设的 processWorkQueue() 函数中处理我们的逻辑: constDEADLINE=performance.now()+QUANTUM;while(workQueue.length>0){if(performance.now()>=DEADLINE){//Yieldtheeventloopifwe'reoutoftime.setTimeout(processWorkQueue);return;}letjob=workQueue.shift();job.execute();} 通过 processWorkQueue() 延时链式调用 setTimeout()，我们使浏览器能够在某种程度上保持对输入的响应，同时仍然在相对不间断地运行。但是，可能需要很长时间才能完成其他需要控制事件循环的工作，或者使 QUANTUM 事件延迟增加一毫秒。 在RAIL模型下，QUANTUM 一个好的值是<50ms，这取决于要完成的工作类型。该值主要决定了处理能力和延迟之间的平衡。 但是，我们还可以做的更好： constDEADLINE=performance.now()+QUANTUM;while(workQueue.length>0){if(navigator.scheduling.isInputPending()||performance.now()>=DEADLINE){//Yieldifwehavetohandleaninputevent,orwe'reoutoftime.setTimeout(processWorkQueue);return;}letjob=workQueue.shift();job.execute();} 通过调用 navigator.scheduling.isInputPending()，我们可以更快地响应输入，同时仍然确保我们的阻塞逻辑能够不间断地执行。如果在完成这些逻辑之前对用户交互（例如绘画）以外的其他操作不感兴趣，则可以方便地增加输入的长度 QUANTUM。 默认情况下，“连续”的事件类型不会返回 isInputPending()，比如 mousemove，pointermove 等等。如果你对这些也感兴趣的话，没问题。可以通过为 isInputPending() 提供一个包含连续变量为true的字典: constDEADLINE=performance.now()+QUANTUM;constoptions={includeContinuous:true};while(workQueue.length>0){if(navigator.scheduling.isInputPending(options)||performance.now()>=DEADLINE){//Yieldifwehavetohandleaninputevent(anyofthem!),orwe'reoutoftime.setTimeout(processWorkQueue);return;}letjob=workQueue.shift();job.execute();} 像 React 这样的框架正在将 isInputPending() 使用类似的逻辑构建到其核心调度库中。希望这将使使用这些框架的开发人员能够从幕后的 isInputPending() 中受益，而不要进行重大的重写。 React Fiber 让我们回想下 React Fiber 中的时间分片： 把一个耗时长的任务分成很多小片，每一个小片的运行时间很短，虽然总时间依然很长，但是在每个小片执行完之后，都给其他任务一个执行的机会，这样唯一的线程就不会被独占，其他任务依然有运行的机会。 React Fiber 把更新过程碎片化，执行过程如下面的图所示，每执行完一段更新过程，就把控制权交还给 React 负责任务协调的模块，看看有没有其他紧急任务要做，如果没有就继续去更新，如果有紧急任务，那就去做紧急任务。 如果你对该库感兴趣，可以到 https://github.com/WICG/is-input-pending 参与反馈和讨论。 参考：https://web.dev/isinputpending/ 不得不说 React 团队还是非常强的，一个 JavaScript 库能带动浏览器的发展。虽然这还是第一个由 Facebook 贡献给浏览器的能力，不过未来可期，让我们期待更多更强大的 API 吧！ 1.关注「前端从进阶到入院」，获取我分类整理的原创精选面试热点文章。 2. 加我好友，拉你进氛围贼好的前端进阶讨论群，2021 陪你一起度过。 分享给你的朋友是最好的支持~ 本文分享自微信公众号 - 前端从进阶到入院（code_with_love）。如有侵权，请联系 support@oschina.cn 删除。本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
2021-02-01
优秀的个人博客,低调大师

5个规则，确保你的微服务优化运行

云栖号资讯：【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 最近几年好像大家都开始对微服务着迷，与此同时单体架构也在慢慢淡出人们的视线。 当然，热门的趋势总是来来去去，而且它们所受到的关注往往被媒体夸大了，实际情况并不总是如此。不过，对于微服务来说，人们似乎已经达成共识，认为这个趋势会一直存在下去。这是有道理的。从概念的角度来说，微服务扩展了工程师们几十年来采用的相同原则。 一旦你开始使用微服务架构，也许你需要本文中提到的5个规则，帮助你成功运行它们。 微服务的另一面 关注点分离(SoC)是一项设计原则，规定软件的构建应根据 "关注点 "或总体功能来确定不同的部分，30多年来一直被用来决定如何构建技术。在单体应用中，它体现在典型的3层架构中的表现层、业务层和数据层的分离。 微服务采用了这个概念，并将其颠覆。它们将同一个应用程序以这样的方式分离出来，应用程序的单一代码库可以被分解并单独部署。这样做的好处是巨大的，但也是有代价的，通常体现在时间和金钱两方面的运维成本较高。除了将现有的应用程序过渡到容器所带来的巨大的前期投资之外，维护该应用程序也带来了新的挑战。 挑战1：似乎很难监控整体 虽然单体应用程序也有其自身的挑战，但在单体中回滚一个“坏”版本的过程是相当简单的。在容器化应用中，事情就变得复杂许多。无论你是将单体应用逐步分解为微服务，还是从头开始构建一个新系统，你现在都有更多的服务需要监控。其中每一个都可能会： 使用不同的技术和/或语言。 运行在不同的机器和/或容器上 使用K8s或类似的技术进行容器化和编排 随之而来的是，系统变得高度分散，更需要集中监控。遗憾的是，这也意味着需要监控的东西也多了起来。以前只有一个单体进程，而现在可能有几十个容器化进程运行在不同的区域，有时甚至是不同的云。这意味着不再有一套单一的运维指标来统治它们，IT/运维团队可以用它来评估应用程序的一般正常运行时间。取而代之的是，团队现在必须处理数以百计（甚至数以千计）的指标、事件和告警类型，他们需要从中分离出有效信号和无效噪音。 解决方案 DevOps监控需要从扁平化的数据模型转向分层模型，在这种模型中，可以随时观察到一系列高级系统和业务KPI。只要有一点偏差，团队就必须能够进入指标层次结构，查看干扰来自于哪个微服务，并从那里了解实际发生故障的容器。这很可能需要从数据存储和可视化的角度重新调整DevOps工具链。开源的时序DB工具，诸如Prometheus和Grafana 7.0等使得这个目标非常容易实现。 挑战2：跨服务日志记录 在谈论监控应用程序时，首先要提出的事情之一是：日志、日志、日志。服务器每天都会产生的IT日志相当于碳的排放量，最终导致溢出的硬盘驱动器以及疯狂摄取、存储和工具成本。即使采用单体架构，你的日志也可能已经使你的工程师有些头疼。 使用微服务，日志变得更加分散。一个简单的用户业务现在可以通过许多服务进行，所有这些服务都有自己的日志记录框架。要解决问题，你必须从业务可能通过的所有服务中提取所有不同的日志，以了解问题所在。 解决方案 这里的主要挑战是了解单个业务如何在不同服务之间“流动”。为了实现这一点，需要对传统的单体程序在顺序业务执行期间通常如何记录所有事件的方式进行大量修改。尽管已经出现了许多框架来帮助开发人员进行处理（我们特别喜欢Jaeger的方法），但对于希望将单体重构为微服务的企业而言，转向异步、跟踪驱动的日志记录仍需要付出艰巨的努力。 挑战3：部署一项服务会破坏另一项服务 单片机世界中的一个关键假设是，所有代码都是在同一时间部署的，这意味着应用程序处于最脆弱状态的时间范围是一个已知的、相对较短的时间段（即部署后的前24-48小时）。在微服务的世界里，这个假设不再成立：由于微服务本质上是相互交织的，其中一个服务细微的变更可能会导致行为或性能问题，而这些问题会在另一个服务中体现出来。因此所面临的挑战是，当前出现故障的微服务使得另一个开发团队并没有预料到他们的代码会出现中断。这既会导致整个应用意外的不稳定性，也会导致一些组织内部的摩擦。虽然微服务架构可能让部署代码的过程变得更容易，但实际上却让部署后验证代码行为的过程变得更难。 解决方案 企业必须创建共享的发布日历，并且每当部署相关的微服务时，都要分配资源用于密切测试和监控整个应用的行为。在没有跨团队协调的情况下部署新版本的微服务，就像牛油果加吐司一样，是解决这一挑战的成功秘诀。 挑战4：难以找到问题的根本原因 在这一点上，你已经锁定了有问题的服务，提取了所有需要提取的数据，包括堆栈跟踪和日志中的一些变量值。你可能还有一些APM解决方案，比如New Relic、AppDynamics或Dynatrace。从那里，你会得到一些额外的数据，关于一些相关方法的异常高处理时间。但是......问题的根本原因呢？ 你（希望）从日志中得到的前几位变量数据很可能不会是那些移动针的数据。它们通常更像是面包屑，指向下一条线索的方向，而不是更进一步的原因。在这一点上，我们需要尽我们所能，发掘出更多应用程序下的 "魔力"。传统上，这需要发出关于每个失败事务状态的详细信息（即到底为什么失败）。这里的挑战是，需要开发人员具有巨大的预见性，以知道他们需要哪些信息来提前排除问题。 解决方案 当微服务中的错误根源横跨多个服务时，制定一个集中的问题根源检测方法至关重要。团队必须考虑需要哪些信息颗粒来诊断未来的问题，以及它们应该在什么层级上发出日志，以考虑到性能和安全因素——这是一座高高的山，而且是一座永无止境的山。 挑战5：版本管理 我们认为值得强调的问题是，从典型的单体架构中的层模型过渡到微服务的图模型。由于超过80％的应用程序代码通常是第三方代码，因此在公司的不同微服务之间管理第三方代码的共享方式成为避免陷入前所未有的“依赖地狱”的关键因素。 考虑这样一种情况：一些团队在使用第三方组件或共享实例程序的X.Y版本（几乎所有公司都有），而其他团队则使用X.Z版本。这就增加了由于不同版本之间缺乏兼容性而产生的关键软件问题的风险，或者说，不同版本之间行为的轻微变化，可能会导致需要排查最特异和痛苦的软件bug。 而在这一切之前，我们还要提醒自己，任何一个微服务使用第三方代码的旧版本、更脆弱的版本，都会产生安全问题——这是黑客的天堂。允许不同的团队在孤岛般的repo中管理他们的依赖性，在单体世界中可能是可行的，但在微服务架构中，这是绝对不可以的。 解决方案 公司必须在重新设计他们的构建流程方面进行投资，以便为第三方和共享实用程序代码利用集中式artifact仓库（Artifactory将是其中之一）。团队应该只允许将自己的代码存储在单独的仓库中。 最后的思考 与科技行业的大多数进步一样，微服务采用了一个熟悉的概念，并将其颠覆。它们重新思考了大规模应用的设计、构建和维护方式。它们带来了许多好处，但也带来了新的挑战。当我们把这五个主要挑战放在一起看时，我们可以看到它们都源于同一个理念。因此，每当采用像微服务这样的新技术时，底线是既需要重新思考，也需要重新调整代码的构建、部署和观察方式。微服务所带来的优势是难以拒绝的——但风险也是巨大的。 【云栖号在线课堂】每天都有产品技术专家分享！课程地址：https://yqh.aliyun.com/live 立即加入社群，与专家面对面，及时了解课程最新动态！【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间：2020-07-23本文作者：Rancher本文来自：“dockone，了解相关信息可以关注“dockone”
2020-07-23

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

时间: 2025-12-03 大小: 4.36MB 下载: 23次
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2025-12-12 大小: 211.28KB 下载: 54次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2025-12-28 大小: 1MB 下载: 4次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-01-03 大小: 1.42GB 下载: 2次
热门标签
Kubernetes Jdk25 OpenAi Gemini3 DeepSeek SpringBoot4 Redis Docker Nacos3 Rocky Service Mesh SpringCloud HarmonyOS6

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册