产品经理需要了解的技术知识:后台宕机

      最后更新:2020-05-22 12:47:20 手机定位技术交流文章

      一旦产品的数据量迅速增加,停机时间就变成几分钟的事情。作为一名成熟优秀的产品经理,你必须做的是首先了解背景逻辑,并在制定产品计划时考虑所有可能的风险。本文阐述了后台停机的原因、机理及解决方案,希望能加深产品经理对后台停机的理解,从而控制风险。

      世界上最痛苦的事情不是产品流量没有上升,而是流量上升,后台服务挂起。世界上最痛苦的事情不是版本没有如期上线,而是程序员在上线后被牺牲了。

      任何爆炸性增长的产品几乎总是在后台服务时折叠起来。公司的一般运作方法是杀一个首席技术官来祭天。但是崇拜天堂有用吗?这真的与产品经理无关吗?

      今天丽莎阿姨将和你一起谈论后台服务。听完之后,我希望你能理解程序员兄弟,并和他在同样的认知维度上思考。更重要的是,也许你的一个小动作可以拯救一只猿的生命。

      俗话说,程序员有三个困难:

      安卓:折叠,挖洞,邦奇苹果:证书,架子,热更新前端开发:IE 6,7,8,9,10后端开发:并发,数据库编写,操作和维护与其他开发相比,后端开发的最大困难是在有限的资源上高效地处理海量数据。

      你怎么理解这个句子?

      资源有限:例如,一台强大的88核/710GB后台服务器实际上是世界上最大的移动电话华为P40Pro(8核/8克)的十倍。海量数据:就我们的产品而言,随便选择的任何数据库都已经有几个t的大小。高效处理:一旦后台处理变慢,用户体验就会变得非常糟糕,不敢懈怠。因此,一旦产品的数据量迅速增加,停机时间就变成几分钟的事情。

      一个普通猿类局外人的第一个想法是:为什么不扩大容量?不是钱能解决问题吗?

      首先,扩展能解决停机问题吗?

      1.并非所有资源都可以简单地扩展

      12306已经足够富有了,但是上网是一个疯狂的崩溃,所以花钱不能直接解决问题。那么为什么我们不能简单地水平扩展呢?

      原因很简单:如果系统使用一些资源,但有单点限制,扩展其他系统是没有用的。什么是常见的单点资源?通常,核心依赖的是数据库、缓存、第三方服务等。

      2.你永远不知道哪一个更重要,停工还是不忠

      如上图所示,随着用户数量的增加,服务器的成本也会增加,但用户数量的增长往往取决于命运。就像微博上的一个突发事件一样,用户数量猛增了XXXX百万,事后有很多悲伤。

      如果你不扩张,你就不是人;如果你扩张,你就是一头猪。因此,对于产品经理来说,能够非常准确地预测即将到来的流量尤为重要。数据监测、模型推导和历史事件的对比分析都是非常有效的方法。

      这时,猿外人可能也会想,为什么程不进行动态扩张和收缩呢?

      丽莎阿姨举了一个非常生动的例子:将后台服务视为奶茶店,假设销售人员的兄弟通常在一分钟内处理一个用户,可能会遇到以下情况:

      特种工艺奶茶:制作过程非常复杂,制作一个杯子需要5分钟,然后这个销售人员在5分钟内不能接受顾客。水龙头开得很慢:每次都要花很长时间才能喝到一杯水,与用户打交道的时间自然会变得很长。另一群匪徒:那些不知道是谁雇了他们的人,来排队但没有买他们。这些问题都是在后台开发过程中会遇到的实际问题。每一个都很难处理,并且不能通过雇佣和解雇几个弟弟来解决。

      第二,为什么后台服务会挂起?

      有两个常见的原因:

      单点系统可能会挂起或处理能力有限。典型:数据库和Redis缓存(10W qps)第三方依赖可能会失败,包括核心依赖和非核心依赖。后台程序员可以做什么来使服务更加稳定?

      1.分解

      拆卸是一种常见的方法。下面的分解通常是根据可伸缩的立方体和微服务进行的。

      水平分裂

      这种方法很常见。它可以被认为是一个简单的水平扩展。简而言之,它意味着一个人不能做它,一个人可以跑和携带它。

      功能解析

      根据不同的功能模块,该方案将后台服务分开,不把鸡蛋放在一个篮子里。如果出现服务故障,其他服务的运行将不会受到影响。

      数据分割

      如前所述,数据库经常成为单点瓶颈。一般来说,在功能拆分的同时,我们还会进行数据拆分,以防止数据变得过大。

      2。找到一个更强的单点

      如果一个点暂时有一个瓶颈,那么可以考虑:是否有一个点具有相同的功能,但是有更强的性能可以替代?

      常见的方式是改变组件,而不是自己的云服务,独立版本不能改变集群版本。

      例如,关于数据库,阿里云上的极化数据库声称比传统的MySQL提高了6倍的性能。

      3。牺牲及时性

      因为很难解决数据库编写的单点问题,所以我们会找到一种方法来阅读它。这就像问秘书老板是否太忙。虽然新闻的传播有一些延迟,但它可以分享老板的精力。如果秘书太忙,他可以要求更多。

      如下图所示,对于家校沟通的产品,教师可以通过释放作业来牺牲部分时效性。

      4。更快地处理单个请求

      在后台,缓慢的请求总是噩梦。一旦大量的请求被非常缓慢地处理,这是非常危险的。因此,在开发过程中,程序员兄弟经常为了更快地处理请求而重构、优化和进行架构演化。

      5.提前算好,不要等用户来了再算。

      对于一个企业来说,会有一些与数据统计相关的服务。如果一个用户计算一次,服务质量和对数据库的压力将非常大。

      最好的方法是计算所有可以在清晨计算的数据。当用户到来时,数据就准备好了,简单的阅读就能得到他想要的结果。

      然而,如果所有这些都完成了,服务仍然崩溃,我们能做什么?

      三、最终大动作:不利于服务和降级

      在后台设计和开发产品时,我们需要知道你的系统是“强依赖”还是“弱依赖”。

      用户不会感到弱依赖或强依赖。有了以上概念,他们可以做出一些相应的设计:

      牺牲用户体验:静态数据被用来取代“成千上万的人和成千上万的面孔”的动态数据;降低流量进入速度,增加验证码机制;简单而粗糙,直接挂一个页面来显示“XX功能在XX时间内暂时关闭”牺牲了功能的完整性:有些功能是“防御性的”,如果你愿意冒“裸奔”一段时间的风险,这也将带来可观的资源节约。“风控”暂时关闭;取消对某些“条件是否得到满足”的判断会牺牲及时性:减慢甚至推迟一些原本异步操作的处理效率一段时间。例如,奖励积分和优惠券等每种产品的背景开发都是一项非常复杂的系统工程。服务器死了。向天堂牺牲程序员是没有用的。

      作为一名成熟优秀的产品经理,你必须做的是首先了解背景逻辑,并在制定产品计划时考虑所有可能的风险。然后,即使后台被挂起,我们也可以和后台兄弟一起从上述想法中思考和解决问题。

      做后台很难,请善待搬砖工人。如果背景中相关技术术语的描述有任何错误,请在评论区指出更正。谢谢你。

      作者:lisadeng微信公众号:丽莎·D的产品说明

      这篇文章最初由@Lisa Deng发表。每个人都是产品经理。未经作者许可,禁止转载。

      主题图来自Unsplash,基于CC0协议。

      本文由 在线网速测试 整理编辑,转载请注明出处,原文链接:https://www.wangsu123.cn/news/7305.html

          热门文章

          文章分类