您打开生产应用程序，发现它正在停止运行。前端没有响应。后端 api 超时。 mongodb 查询似乎无限期地运行。您的收件箱里充满了用户投诉。您的团队挤在一起尝试对情况进行分类。
去过吗？是的，我也是。
我是一名高级全栈开发人员，我厌倦了一些应用程序，这些应用程序在您仅作为单个用户使用时很好，或者问题空间很简单，但在实际流量或任务要求稍高。
请跟着我，我将向您介绍我如何使用 react、node.js 和 mongodb 解决这些问题。
我不会只是给你另一个简单的旧教程，我会分享一个故事。一个关于如何解决现实世界问题以及如何构建快速、高可扩展性应用程序的故事，该应用程序可以通过时间和任何挑战的考验。
1：当 react 成为瓶颈
我们刚刚在我的工作中推出了使用 react 开发的 web 应用程序的更新。我们充满信心，相信用户会喜欢这些新功能。
然而，不久之后我们就开始收到投诉：应用程序加载速度极其缓慢，转换时断断续续，用户变得越来越沮丧。尽管知道新功能很有用，但它们无意中导致了性能问题。我们的调查发现了一个问题：该应用程序将其所有组件捆绑到一个包中，这迫使用户每次访问该应用程序时都下载所有内容。
修复：我们实现了一个非常有用的概念，称为延迟加载。我以前曾遇到过这个想法，但这正是我们所需要的。我们彻底改造了应用程序的结构，确保它只在需要时加载必要的组件。
以下是我们如何实施此解决方案的一瞥：
const dashboard = react.lazy(() => import('./dashboard'));const profile = react.lazy(() => import('./profile'));<suspense fallback={loading...}>
结果：这一变化的影响是非常显着的。我们发现我们的捆绑包缩减了 30%，用户体验到了更快的初始加载速度。最好的部分是用户不知道应用程序的某些部分仍在加载，我们明智地使用了 suspense 并显示了一个简单的非侵入式加载消息。
2：驯服 react 中的状态管理猛兽
随着时间快进几个月，我们的开发团队正在大踏步前进并推出许多新功能。但随着业务的增长，我们无意中开始构建我所说的更复杂的应用程序。 redux 很快就成为促进简单交互的负担而不是助手。
所以，我花了一些时间创建一个 poc，以获得更好的替代方案。我记录了它的原理，并主持了多次知识共享会议，讨论该方法可能是什么样子。我们最终决定作为一个团队尝试使用 react hooks（特别是 usereducer）作为我们提出的管理状态的解决方案，因为最终我们想要更简单的代码和更少的大量运行时占用空间，而新版本的 redux 因许多较小的独立组件而导致开销不断增加状态。
接下来的转变简直就是革命性的。我们发现自己用简洁、易于理解的钩子逻辑替换了数十行样板代码。以下是我们如何实施这种新方法的说明性示例：
const initialstate = { count: 0 };function reducer(state, action) { switch (action.type) { case 'increment': return { count: state.count + 1 }; case 'decrement': return { count: state.count - 1 }; default: throw new error(); }}const countercontext = react.createcontext();function counterprovider({ children }) { const [state, dispatch] = usereducer(reducer, initialstate); return ( {children} );}
结果：这一转变的影响是深远的。我们的应用程序变得更加可预测并且更容易推理。代码库现在更精简、更直观，使我们的团队能够以更快的速度进行迭代。也许最重要的是，我们的初级开发人员报告说，他们浏览和理解代码库的能力有了显着提高。最终结果是双赢的：需要维护的代码更少，需要解决的错误更少，开发团队明显更快乐、更高效。
3：征服后端战场 – 优化 node.js api 以获得最佳性能
虽然我们能够对前端进行很多改进，但不久之后我们在后端遇到了多个问题。我们的 api 性能变得很糟糕，而且很少有端点开始表现得很糟糕。这些端点对不同的第三方服务进行一系列调用，并且随着用户群的不断增长，系统无法处理此负载。
这是非常常识性的问题：我们不是平行的！即，对每个端点的请求都是按顺序处理的，即每个下一个调用都将等待上一个调用完成。在这个大规模（数十万个请求）的系统中，事实证明这是灾难性的。
解决方案：为了解决这个问题，我们决定重写大量代码，并使用 promise.all() 的强大功能以并发方式发出 api 请求。这意味着您启动多个请求，而不必等到每个调用完成才启动下一个请求。
为此，我们不会启动 api 调用，等待其完成，再进行另一个调用等等……
不是简单地使用 promise.all()，所有内容都会立即启动，而且速度更快。
以下是我们如何实施此解决方案的一瞥：
const getuserdata = async () => { const [profile, posts, comments] = await promise.all([ fetch('/api/profile'), fetch('/api/posts'), fetch('/api/comments') ]); return { profile, posts, comments };};
结果：此优化的影响是立竿见影且巨大的。我们观察到响应时间显着减少了 50%，并且我们的后端在重负载下的弹性显着提高。用户不再遇到令人沮丧的延迟，我们看到服务器超时的数量急剧减少。此增强功能不仅改善了用户体验，还允许我们的系统在不影响性能的情况下处理更多的请求。
4：mongodb 探索 — 驯服数据野兽
随着我们的应用程序获得关注并且我们的用户群数量级增长，我们不得不面对一个新的障碍：如何扩展其数据？当我们不得不处理数百万个文档时，我们曾经响应迅速的 mongodb 实例开始出现阻塞。过去以毫秒为单位运行的查询需要几秒钟才能完成，或者超时。
我们花了几天时间研究 mongodb 的性能分析工具，并发现了最大的坏蛋：未索引的查询。我们的一些最常见的查询（例如对用户配置文件的请求）正在扫描整个集合，他们可以使用坚如磐石的索引。
解决方案：根据我们掌握的信息，我们知道我们需要做的就是在那些最需要的字段上创建复合索引，这将永久修复我们的数据库正文查找时间。以下是我们在“用户名”和“电子邮件”字段中的做法。
db.users.createindex({ "username": 1, "email": 1 });
结果：此优化的影响非常显着。以前需要 2 秒才能执行的查询现在可以在 200 毫秒内完成，性能提高了十倍。我们的数据库恢复了快速响应能力，使我们能够处理显着增加的流量，而不会出现任何明显的速度下降。
但是，我们并没有就此止步。认识到我们的快速增长轨迹可能会持续下去，我们采取了积极措施来确保长期的可扩展性。我们实现了分片来将数据分布到多个服务器上。这一战略决策使我们能够横向扩展，确保我们处理数据的能力与不断扩大的用户群同步增长。
5。拥抱微服务——解决可扩展性难题
随着我们的用户群不断增加，越来越明显的是，我们不仅需要扩展我们的基础设施，而且还必须发展我们的应用程序，以便能够自信地扩展。当我们是一个较小的团队时，单体架构非常适合我们，但随着时间的推移，它变得相当麻烦。我们知道我们需要迈出一大步，开始构建微服务架构——这对任何工程团队来说都是一项艰巨的任务，但具有很大的可扩展性和可靠性优势。
最大的问题之一是服务之间的通信。 http 请求确实不适合我们的情况，它给我们的系统留下了又一个瓶颈，因为大量的操作都在焦躁地等待响应，并且在需要时杀死程序，因为有太多事情要做。此时我们意识到使用 rabbitmq 是显而易见的答案，因此我们没有考虑太多就应用了它。
以下是我们如何实施此解决方案的一瞥：
const amqp = require('amqplib/callback_api');amqp.connect('amqp://localhost', (err, conn) => { conn.createChannel((err, ch) => { const queue = 'task_queue'; const msg = 'Hello World'; ch.assertQueue(queue, { durable: true }); ch.sendToQueue(queue, Buffer.from(msg), { persistent: true }); console.log(`Sent ${msg}`); });});
结果：从我们的角度来看，过渡本身以及通过 rabbitmq 进行的通信看起来就像魔术一样……数字证实了这一点！我们成为松散耦合微服务的幸运拥有者，其中每个服务都可以自行扩展。突然间，具体 dns 区域上的真实流量峰值并不涉及系统崩溃的担忧（因为无论哪个服务操作都会提出相同的要求，因为它们总是级联），而是工作得很好，因为其余部分/操作只是平静地举起手说“我可以睡觉了，亲爱的。”维护也变得更容易，问题更少，同时添加新功能或更新使操作更快、更自信。
结论：规划未来创新路线
这段激动人心的旅程中的每一步都是一个教训，提醒我们全栈开发不仅仅是编写代码。它理解并解决复杂的相互关联的问题——从让我们的前端更快、构建后端以承受故障，到处理随着用户群爆炸而扩展的数据库。
展望 2024 年下半年及以后，对 web 应用程序的需求增长不会放缓。如果我们继续专注于构建可扩展、性能优化和架构良好的应用程序，那么我们就有能力解决今天的任何问题，并在未来利用这些其他挑战。这些现实生活中的经历极大地影响了我进行全栈开发的方式——我迫不及待地想看看这些影响将继续推动我们的行业走向何方！
但是你呢？您是否遇到过类似的障碍，或者是否有幸通过其他创造性的方法来克服这些问题？我很想听听您的故事或见解 – 请在评论中告诉我或与我联系！
以上就是使用 React、Nodejs 和 MongoDB 构建高性能全栈应用程序：可扩展性、速度和解决方案之旅的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1493098.html
微信扫一扫 
支付宝扫一扫 
