大家好,今天小编来为大家解答以下的问题，关于限流方案快速落地指南：应对大规模项目接入挑战，这个很多人还不知道，现在让我们一起来看看吧！
那么我们可以更进一步吗？此外，我们还需要考虑经验积累、通用性和整体效益三个方面。
经验积累：有没有什么经验总结可供其他项目参考？通用性：该解决方案可以直接用于其他项目吗？整体效益：团队整体成本能否降低？
2、问题与目标
我们的解决方案设计需要考虑不同项目之间的差异，因为我们可能需要访问十几个甚至更多的项目。不同项目之间的差异会体现在开发语言、请求类型、生命周期、部署环境、链接节点等方面。
我们需要特别关注的是生命周期。有的项目可能是十几年前就存在的老项目，有的可能是近两三年较新的项目，有的可能是未来将要建立的全新项目。我们的解决方案需要能够同时匹配这三个项目，并消除其他几个差异。
除此之外，我们的解决方案还有一些其他期望的目标，比如低成本、高效率、高质量，以及专业性、稳定性、可扩展性、高性能。
低成本：接入所需成本较低，包括开发、运维、硬件等成本。高效率：可以快速完成接入和登陆工作。高质量：提供整套限流解决方案，接入方在使用前后都能得到有效的技术支持和指导。其他点都比较容易理解，那么摆在我们面前的问题是项目的数量多，差异性大，期望目标和要求也多，那么我们应该如何设计这个解决方案呢？
3、协作方式
在介绍具体的技术方案之前，我先简单介绍一下我们的协作方式。
在公司内部推广一项技术的落地，我们通常采用单项目的方式，即单个项目了解需求、设计、开发，然后在这个项目落地后逐步推广到其他项目。这种做法虽然没有任何问题，但是却有几个缺点：
需求的全面性：无法充分考虑其他项目的需求，方案设计可能存在差距，导致后期推广困难，因为只考虑了本项目的需求和场景。成本负担：费用由单个项目承担，可能会影响项目组原有的工作，对项目本身也有比较大的影响。基于以上情况，我们设计了专业的群体机制，希望让专业的人做专业的事。工作流程如下：
首先，从多个有需要的项目团队中招募感兴趣或有经验的成员加入专业组。例如，图中，从项目组1、项目组2、项目组3各选出一个人组成专业团队，然后根据这几个项目设计总体方案来满足其需求。项目实施后，逐步推广至其他项目。
与单一项目推广相比，专业团体机制的优势如下：
充分兼顾到了典型场景的需求。因为我们会满足原来三个项目组的需求，所以这三个项目组的场景都比较清晰。成本由多个项目分摊。每个项目仅需1~2人，对项目组原有工作影响较小。专业组的进出机制可以充分发挥成员的技术积累优势和主观能动性。能够加入专业组的成员一般对专业问题有比较的技术积累，或者对问题非常感兴趣，会主动研究问题。专业团队在解决现有特征的整个过程中发挥了很大的作用。
二、技术方案
下面我们介绍一下具体的技术方案。
1、限流实现层
第一个问题是我们的限流应该在哪一层实现？一般来说，我们可以在应用层进行限流，即在API服务节点添加一个Web中间件，在请求进入API服务时判断该请求是否限流。这是比较常用的方法，成本是针对单个项目的。也是最低的。
除了在应用层实现限流之外，还有在接入层实现限流的做法。在原来的LB和API节点之间，我们可以增加一个网关层，在网关层实现限流功能。
对比两种方法，应用层限流有以下缺陷：的异常流量仍然落在API服务上。如果突发大量流量进来，压力仍然会落在API服务身上，所以效果会比较差。逻辑耦合，限流功能不能独立改变。职责不明确增加了服务的复杂性。难以在多个项目中复用，可行性低，无法满足我们的需求。比如我们前面提到的差异包括不同项目的开发语言不同、部署方式不同等。如果我们在应用层实现限流，需要针对每个项目单独进行适配，所以成本比较高。基于以上情况，我们选择接入层来实现限流。为了在接入层实现，我们需要一个网关作为统一的记录层。
2、Kong网关
根据官方的说法，Kong网关是一个轻量级、快速、灵活的云原生API网关。 Kong是基于OpenResty和Nginx实现的。当我们解决这个问题的时候，为什么要选择Kong呢？也是基于我们共同的高性能、高可用、灵活、易扩展等方面。其中，我们特别关注以下两点：
一是轻量灵活，在最轻量级部署的情况下，只需要1个主流程和1个yaml配置文件。二是易扩展，Kong的插件机制可以在请求生命周期的每个阶段实现自定义逻辑，这意味着我们可以做很多我们需要的工作。
3、Kong插件
Kong的插件机制可以支持多种语言，例如Golang、Lua、Python、JS。我们选择Lua和Golang作为我们的开发插件。两者的区别在于Lua插件是直接在Kong进程中执行的，即和Kong是同一个进程，而每个Go插件都是一个单独的插件，并与主Kong通信过程需要IPC。执行。
与Lua和Golang相比，Golang在团队技术栈匹配、生态、工程难度、开发维护成本等方面都有明显优势，而Lua在性能方面会更高。由于Golang每次执行插件时都需要进行IPC通信，因此当IPC通信次数较多时，性能会受到很大影响。但我们在实践中发现，在现有场景下，我们的IPC通信数量比较少，对性能的影响也比较小。因此，如果Golang无法实现总体上我们是优先使用Golang开发插件，那么下一个最佳选择就是使用Lua进行开发。
4、插件模块化
之前我们通过Kong作为接入层解决了不同项目的环境差异。那么我们就可以利用插件机制来解决不同项目的需求差异。
我们可以将一个项目的限流需求分为两部分：业务需求模块和限流功能模块。
业务需求模块迭代比较频繁。这方面的需求包括解析用户名等，每个项目根据不同的路径、IP、请求方式等都会有不同的需求，限流功能模块比较稳定。比如我们需要限制短连接的频率，限制并发数等。在具体的限流算法的实现之上，还有策略的应用，即对于相同的限流方法，例如令牌桶，我们可以针对应用设计不同的策略。
基于上述模块划分，我们在实际开发时分为三层。从下往上分别是限流算法层、限流插件层、业务插件层。
1）限流算法层限流算法层主要是SDK的形式。因为我们的限流场景很多，算法也不同，所以我们会针对每个不同的场景单独开发SDK。例如，短连接频率限制的场景可能会导致一些问题。卡桶或者时间窗口等，短连接的并发数，长连接也有具体的实现。
需要特别注意客户端限流场景。在实际应用过程中，我们发现这种场景除了访问Kong服务器性能外，还需要在客户端请求时进行限流。客户端限流是指客户端主动发起调用第三方频率的请求。我们也希望能够控制频率并保护第三方服务。
限流算法的SDK以代码嵌入的形式嵌入限流插件层。
2）限流插件层限流插件层会调用SDK，针对不同的场景需要设置不同的策略。比如我们的令牌桶限制了短连接的频率。一个插件可以实现令牌预测功能，而另一个插件可以执行限制功能。流量配额、动态控制等，这意味着它向业务层迈出了一步。
3）业务插件层业务插件层会根据项目组的不同需求，开发单独的业务场景。例如，不同的项目组可能有不同的限流维度进行分析，这就需要项目组自行适应。
例如业务组的监控等业务定制功能的配置也可以在这一层完成。
我们的分层主要分为三层。在实际的Kong执行中，会有两个插件，分别是业务插件和限流插件。这里的插件是指Kong本身自带的执行插件。
接下来以长轮询场景为例，描述需要限制客户端连接数的场景。
当第一次请求进入Kong网关时，在业务插件中我们会解析它的限流维度，比如用户、路径、方法、ip，然后从这些维度生成一个字符串限流KEY，可能是一个相对较长的字符串。
然后就会匹配具体的限流策略。如果不能匹配，则进入覆盖策略并根据该信息生成限流协议数据。业务插件的配置会记录请求的维度，比如路径、方法等，匹配限流策略后，会生成其限流协议。限流协议中会设置最大并发请求数、请求超时时间等。然后，业务插件会将这些信息组装成协议。协议的格式如图右下角所示。
然后这些数据通过Kong的Context机制传递给限流插件。限流插件会解析协议数据，然后进行限流逻辑判断，以确定该请求是应该限流还是透传给上游服务。
5、分工
如果现有插件能够满足项目组的需求，则直接使用；如果没有，您可以定制自己的业务插件。定制插件时，项目组只需关注项目所需的业务逻辑即可。相关生态已由专业团队提供。专业组负责所有限流插件和部分通用业务插件的开发，网关和插件公共功能的开发，以及安全性、稳定性保障的建立、设计和实现不同场景下的限流算法。插件开发完成后，提交到插件库。如果以后其他项目组有同样的项目，也可以直接使用。
6、分发与使用
接下来我们简单了解一下插件的分布和使用机制。
首先，插件开发完成后，我们会在GitLab上打标签，并触发CI流程。 CI流程所做的工作主要是编译、写入参数信息、压缩打包，将插件打包成标签压缩文件，上传到文件服务，然后发布到git发布接口，然后项目团队可以在发布界面中使用它查看我们可以使用的插件及其功能。
项目组具体使用时，需要Fork部署仓库，然后设置多个需要使用的插件和版本。然后触发CI流程，我们会再次下载插件，解析、解包等，然后将这些插件及其信息写入Kong，构建并推送成完整的镜像，而获得镜像后，我们可以将其部署到部署平台上，项目组已经完成了Kong和插件的使用。
7、接入方式
接下来简单介绍一下项目组实际的接入方式。前面我们提到，项目团队之间存在很多差异，因此我们将其分为5种情况：
1）如果是全新项目，直接连接。
2）如果已有项目但没有网关，则主要考虑业务场景，综合评估后即可接入。
3）已有一个项目，并且有一个Kong网关。这种情况下，只需安装并使用我们的限流插件即可。因为我们开发的插件也是Kong的标准插件，所以项目组在使用限流插件时只需要连接其限流协议即可。
4）如果已有项目，还有其他网关，那么Kong网关不能使用，可以直接连接限流算法的SDK。
5）客户端限流情况下，不需要Kong网关，直接连接客户端限流SDK即可。
8、整体架构
该方案整体结构比较简单，很容易适应不同的项目。
一般来说，LB和API节点之间会添加Kong网关。在网关方面，首先我们会插入一个跟踪插件，该插件嵌入了Open-Tracing的实现。然后项目组根据自己的需求选择业务插件和限流。插件。
业务插件的一个功能是动态监控限流配置，需要外部配置中心来实现。动态监控主要考虑到当异常流量进来时，我们可能需要动态调整配额。例如，情况可能是项目原来设定的配额已经不能满足其需要。最近该项目的用户数量激增，所以这里我们无法限制它的流量，所以我们需要增加配额，以避免对业务造成不利影响。
限流插件也根据不同限流算法的实现而具有不同的依赖关系。例如，大多数情况下我们会进行分布式限流。我们选择通过Redis添加Lua脚本来实现分布式限流。这种情况下Dependency也需要添加一个Redis。少数情况下，可能会作为局部限流器使用，需要根据项目组的具体实施情况来实施。
三、实施方案
实施计划是指一个项目组从0接触到完成整个计划的过程。早期阶段包括需求、评估和开发步骤。
1、需求
在需求阶段，项目组根据我们提供的模板提出Issue，模板中将包含以下内容：
限流场景、类型限流维度、项目组需要专业化的战略业务需求、现有的插件是否能够满足项目组的需求。
2、评估
然后进行总体评价工作。评估的方面包括：
开发、维护、硬件等成本部署架构性能、链路影响
3、开发（若需要）
如果我们现有的插件不能满足项目组的需求，那么就需要进行开发工作。对于开发工作，我们有比较详细的指南，所以上手成本比较低。项目组需要了解以下几个方面：
本地环境部署：我们提供了docker-compose环境，可以一键启动本地开发环境。快速了解相关知识：包括Kong的一些概念等。完整的开发文档：包括如何编写具体的插件等。简单来说，我们提供了一步一步的文档，教项目组开发。接下来是测试、部署和上线阶段。
4、测试
我们在测试过程中的目的是保证Kong和插件连接后的质量。
首先，我们需要确保我们的限流功能符合预期。返回后原API服务的功能需要与之前保持一致。镜像流量和故障演练对我们来说更重要。
镜像流量是指将生产环境的流量导入到测试环境中，可以用来提前验证限流后我们的流量是否异常。也就是说，我们需要一个单独的环境来镜像流量，并在这个环境中提前验证生产环境的流量。因为我们添加了新的网关，所以变化的影响比较广，我们可能会遇到奇怪的事情。问题。如果我们提前从生产环境导入流量，就可以提前发现这些问题。故障演练也是为了提前发现可能出现的问题和风险。关于这两点，我们有两个内部最佳实践指令，分别是《如何做好镜像流量》和《如何做好从场景出发的故障演练》。
5、部署
接下来是部署步骤。
我们基于内部一致交付系统实现了模板部署，即不同的部署平台，比如物理机或者公有云、私有云，都可以使用一致交付平台实现统一部署，所以项目组不需要考虑太多细节。其次，我们在部署时可以一键访问监控、日志、报警、链接等功能。我们部署的时候，有一个完整的部署指南，会介绍各个方面的问题，比如接入Kong网关后，如何处理原来的服务拆分问题。
6、上线
最后一步是上网。我们还提供了详细的在线步骤，以及清单和最重要的灰度和回滚技术解决方案。
总体来说，我们在这些环节实现了全流程的分步指导和落实。
四、小结
我们前面提到的目标是低成本、高效率、高质量。
1、低成本
1）开发成本：项目组对接时，成本基本为零，或者只有少量的开发工作。
2）维护成本：后续维护、升级工作均由专业团队负责。
3）硬件成本：主要是Kong的集群部署。根据项目组本身的流量大小，可以部署不同数量的副本。如果选择分布式限流，还需要部署Redis。我们一般建议部署一个新的Redis，但为了节省成本，您也可以与原项目现有的Redis共享。
2、高效率
1）接入时间：我们在练习项目的时候，最快的访问时间是三天。三天是项目组没有定制化需求，不需要开发来完成我们之前介绍的步骤，即Evaluate、测试、部署、上线。
2）硬件配置：我们有一个推荐的配置，就是根据我们不同的流量进行单独的测试，并且我们提供了比较完整的性能测试数据作为参考。
3）高效部署：网易内部平台比较完善，借助我们的CI自动化、配置管理系统、容器云系统和一致性交付系统，可以实现高效部署。
4）文档建设：我们的文档建设比较完整。从限流方案开始到上线整个过程，我们都有非常详细的文档指导。如果遇到问题可以在文档中查找或者专业组的同事了解。
3、高质量
1）技术支持：专业组同事提供技术支持。
2）多样场景：我们的插件机制适应多种限流场景和业务需求。
3）经验复用：每个项目对接使用过程中的经验或者优化问题都可以进行总结和复用，因为我们不同的项目使用相同的技术体系，这样有利于经验的积累。
4）自定扩展：虽然我们定制了一些插件和Kong的一些部署流程，但在实际开发过程中我们也考虑到了Kong原生态的兼容性，这意味着项目组仍然可以使用Kong原生态提供的丰富功能。
5）运维体系：连接的是与运维设施相关的整个功能系统，也就是我们前面提到的监控、报警、日志等。
6）充分验证：我们的插件功能和性能都经过充分的测试，上线流程也比较完整，可以保证我们的可靠性。
通过以上环节，可以保证服务限流方案的低成本、高效率、高质量。
QAQ1：这个限流方案在哪些类型的项目上具有通用性？A1：这个问题其实又回到了我们项目的差异。一般来说，我们无论是普通的http短连接项目，还是一些长轮询场景、长连接场景，都没有问题。我们都单独做适应。因为Kong本身就可以支持这几种类型的请求，即我们只需要针对这些场景开发相应的插件即可。
Q2：Kong和插件对性能的影响大吗？A2：我们在实际设计时也考虑到了这一点，通过实践发现对性能的影响比较小。一方面，性能影响我们请求的耗时。经过我们的测试，耗时约为5毫秒。另一方面是QPS，因为Kong以及插件本身支持水平扩展，而且Kong本身的性能也比较高，所以对QPS的影响比较小。在我们的测试过程中，最高达到了5万或6万以上的QPS，所以基本上不需要太担心这个问题。
Q3：如何实现长轮询连接数限制？A3：长轮询本质上是并发请求数的一个属性，但它是一个http请求，可能处于暂停状态，需要暂停例如一分钟。这个场景的实现过程大致如下：Kong本身有一个插件机制，保证我们可以在请求前后插入钩子函数。在请求之前，我们的钩子函数会在Redis的Zset中设置一个请求状态。那么Zset的值就是请求的唯一ID，比如是雪花ID，然后就是请求的过期时间。这个过期时间是当前的时间加上请求配置中的TTL（请求超时），两者之和就是请求过期的实际时间。当有请求进来时，我们会将请求的数据记录到Zset中，表示当前并发请求数增加了1。那么Redis Lua脚本执行时，首先会消除已经过期的请求数。请求完成后，请求的数据将从Zset中移除，这意味着并发请求数减少1。这是一般原则。
关于限流方案快速落地指南：应对大规模项目接入挑战，的介绍到此结束，希望对大家有所帮助。
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/6990.html
用户评论
感觉现在网站要做的东西好多，都得想办法怎么处理啊
有19位网友表示赞同！
限流一直都是互联网企业永恒的痛点，希望能有更好的解决方案。
有10位网友表示赞同！
接入新老项目确实会产生很多差异，这是考验技术团队的地方
有6位网友表示赞同！
快速落地的限流方案很重要，能提高效率，节省成本啊！
有20位网友表示赞同！
51CTO的文章还是比较权威的，看这一篇应该能学到不少东西。
有19位网友表示赞同！
之前没留意到这个问题，看来以后要好好研究一下限流技术了。
有14位网友表示赞同！
希望能够看到一些实用的案例和经验分享，这样更有参考价值。
有5位网友表示赞同！
项目规模越大，限流方案越重要，否则会影响整个系统稳定性
有16位网友表示赞同！
技术发展太快了，要跟上时代节奏，不断学习新知识！
有5位网友表示赞同！
解决限流问题确实需要全面的考虑和策略设计
有18位网友表示赞同！
想要做大规模的网站，限流管理是必不可少的环节啊！
有20位网友表示赞同！
有好的限流方案可以保证网站正常运营，用户体验也会更好！
有8位网友表示赞同！
项目接入速度快，限流策略要灵活多变才能应对！
有9位网友表示赞同！
期待解决方案能兼顾效率和鲁棒性，避免出现潜在风险。
有13位网友表示赞同！
限流是一个复杂的系统工程，需要专业的团队进行设计与实施！
有19位网友表示赞同！
好的限流方案可以有效提升系统的安全性和稳定性
有12位网友表示赞同！
通过文章学习到新的限流技术和方法，希望能应用到实际项目中。
有19位网友表示赞同！
网站运营过程中遇到的各种问题都需要不断总结经验，才能做得更好！
有17位网友表示赞同！
关注网站性能优化一直是必不可少的，限流也是其中重要的一环！
有19位网友表示赞同！