汉滨网站建设,php网站开发环境,华久网站建设,煤棚网架多少钱一平方说在前面 在40岁老架构师 尼恩的读者社区(50)中#xff0c;很多小伙伴拿到一线互联网企业如阿里、网易、有赞、希音、百度、滴滴的面试资格。 最近#xff0c;尼恩指导一个小伙伴简历#xff0c;写了一个《API网关项目》#xff0c;此项目帮这个小伙拿到 字节/阿里/微博/…说在前面 在40岁老架构师 尼恩的读者社区(50)中很多小伙伴拿到一线互联网企业如阿里、网易、有赞、希音、百度、滴滴的面试资格。 最近尼恩指导一个小伙伴简历写了一个《API网关项目》此项目帮这个小伙拿到 字节/阿里/微博/汽车之家 面邀 所以说这是一个牛逼的项目。 为了帮助大家拿到更多面试机会拿到更多大厂offer 尼恩决定9月份給大家出一章视频介绍这个项目的架构和实操《33章: 10Wqps 高并发 Netty网关架构与实操》预计月底发布。然后提供一对一的简历指导这里简历金光闪闪、脱胎换骨。 《33章: 10Wqps 高并发 Netty网关架构与实操》 海报如下 配合《33章: 10Wqps 高并发 Netty网关架构与实操》 尼恩会梳理几个工业级、生产级网关案例作为架构素材、设计的素材。 前面梳理了 《日流量200亿携程网关的架构设计》《千万级连接知乎如何架构长连接网关》 这里又是一个漂亮的生产级案例《喜马拉雅自研亿级API网关技术实践》又一个非常 牛逼的工业级、生产级网关案例。 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF请到公号【技术自由圈】获取 文章目录 说在前面喜马拉雅自研亿级API网关技术实践1、第1版Tomcat NIOAsync Servlet2、第2版Netty全异步2.1 接入层2.2 业务逻辑层2.3 服务调用层2.3.1 异步 Push2.3.2 连接池2.3.3 Connection:close2.3.4 写超时 3、全链路超时机制4、监控报警5、性能优化实践5.1 对象池技术5.2 上下文切换5.3 GC优化5.4 日志 6、未来规划说在最后有问题可以找老架构取经推荐阅读 喜马拉雅自研亿级API网关技术实践 网关作为一种发展较为完善的产品各大互联网公司普遍采用它作为中间件以应对公共业务需求的不断浮现并能迅速迭代更新。 如果没有网关要更新一个公共特性就得推动所有业务方都进行更新和发布这无疑是效率极低的。然而有了网关之后这一切都不再是问题。 喜马拉雅也如此用户数量已增长到 6 亿级别Web 服务数量超过 500 个目前我们的网关每天处理超过 200 亿次的调用单机 QPS 峰值可达 4w。 除了实现基本的反向代理功能网关还具备许多公共特性如黑白名单、流量控制、身份验证、熔断、API 发布、监控和报警等。根据业务方的需求我们还实现了流量调度、流量复制、预发布、智能升级、流量预热等相关功能。 从技术上来说喜马拉雅API网关的技术演进路线图大致如下 注意请点击图像以查看清晰的视图 本文将介绍在喜马拉雅 API 网关面临亿级流量的情况下我们如何进行技术演进以及我们的实践经验总结。 1、第1版Tomcat NIOAsync Servlet 在架构设计中网关的关键之处在于接收到请求并调用后端服务时不能发生阻塞Block否则网关的处理能力将受到限制。 这是因为最耗时的操作就是远程调用后端服务这个过程。 如果此处发生阻塞Tomcat 的工作线程会被全部 block 住了等待后端服务响应的过程中无法处理其他请求因此这里必须采用异步处理。 架构图如下 注意请点击图像以查看清晰的视图 在这个版本中我们实现了一个单独的 Push 层用于在网关接收到响应后响应客户端并通过此层实现与后端服务的通信。 该层使用的是 HttpNioClient支持业务功能包括黑白名单、流量控制、身份验证、API 发布等。 然而这个版本仅在功能上满足了网关的要求处理能力很快成为瓶颈。当单机 QPS 达到 5K 时会频繁发生 Full GC。 通过分析线上堆我们发现问题在于 Tomcat 缓存了大量 HTTP 请求。因为 Tomcat 默认会缓存 200 个 requestProcessor每个处理器都关联一个 request。 另外Servlet 3.0 的 Tomcat 异步实现可能会导致内存泄漏。后来我们通过减少这个配置效果明显。 然而这种调整会导致性能下降。总结一下基于 Tomcat 作为接入端存在以下问题 Tomcat 自身的问题 1缓存过多Tomcat 使用了许多对象池技术在有限内存的情况下流量增大时很容易触发 GC2内存 CopyTomcat 的默认内存使用堆内存因此数据需要从堆内读取而后端服务是 Netty使用堆外内存需要经过多次 Copy3Tomcat 还有个问题是读 body 是阻塞的, Tomcat 的 NIO 模型和 reactor 模型不同读 body 是 block 的。 这里再分享一张 Tomcat buffer 的关系图 注意请点击图像以查看清晰的视图 从上图中我们能够明显观察到Tomcat 的封装功能相当完善但在内部默认设置下会有三次 copy。 HttpNioClient 的问题在获取和释放连接的过程中都需要进行加锁针对类似网关这样的代理服务场景会导致频繁地建立和关闭连接这无疑会对性能产生负面影响。 鉴于 Tomcat 存在的这些难题我们在后续对接入端进行了优化采用 Netty 作为接入层和服务调用层也就是我们的第二版成功地解决了上述问题实现了理想的性能。 2、第2版Netty全异步 基于 Netty 的优势我们构建了全异步、无锁、分层的架构。 先看下我们基于 Netty 做接入端的架构图 注意请点击图像以查看清晰的视图 2.1 接入层 Netty 的 IO 线程主要负责 HTTP 协议的编解码工作同时也监控并报警协议层面的异常情况。 我们对 HTTP 协议的编解码进行了优化并对异常和攻击性请求进行了监控和可视化处理。 例如我们对 HTTP 请求行和请求头的大小都有限制而 Tomcat 是将请求行和请求头一起计算总大小不超过 8K而 Netty 是分别对两者设置大小限制。 如果客户端发送的请求超过了设定的阀值带有 cookie 的请求很容易超过这个限制一般情况下Netty 会直接响应 400 给客户端。 在优化后我们只取正常大小的部分并标记协议解析失败这样在业务层就可以判断出是哪个服务出现了这类问题。 对于其他攻击性的请求例如只发送请求头而不发送 body 或者只发送部分内容都需要进行监控和报警。 2.2 业务逻辑层 这一层负责实现一系列支持业务的公共逻辑包括 API 路由、流量调度等采用责任链模式这一层不会进行 IO 操作。 在业界和大型企业的网关设计中业务逻辑层通常都被设计成责任链模式公共的业务逻辑也在这一层实现。 在这一层我们也执行了相似的操作并支持以下功能 1用户认证和登录验证支持接口级别的配置2黑白名单包括全局和应用的黑白名单以及 IP 和参数级别的限制3流量控制提供自动和手动控制自动控制可拦截过大流量通过令牌桶算法实现4智能熔断在 Histrix 的基础上进行改进支持自动升降级我们采用全自动方式也支持手动配置立即熔断即当服务异常比例达到设定值时自动触发熔断5灰度发布对于新启动的机器的流量我们支持类似于 TCP 的慢启动机制为机器提供一段预热时间6统一降级我们对所有转发失败的请求都会执行统一降级操作只要业务方配置了降级规则都会进行降级我们支持将降级规则细化到参数级别包括请求头中的值非常细粒度此外我们还会与 varnish 集成支持 varnish 的优雅降级7流量调度支持业务根据筛选规则将流量分配到对应的机器也支持仅让筛选的流量访问该机器这在排查问题/新功能发布验证时非常有用可以先通过小部分流量验证再大面积发布上线8流量 copy我们支持根据规则对线上原始请求 copy 一份将其写入 MQ 或其他 upstream用于线上跨机房验证和压力测试9请求日志采样我们对所有失败的请求都会进行采样并保存到磁盘以供业务方排查问题同时也支持业务方根据规则进行个性化采样我们采样了整个生命周期的数据包括请求和响应相关的所有数据。 上述提到的所有功能都是对流量进行管理我们每个功能都作为一个 filter处理失败都不会影响转发流程而且所有这些规则的元数据在网关启动时就会全部初始化好。 在执行过程中不会进行 IO 操作目前有些设计会对多个 filter 进行并发执行由于我们的操作都是在内存中进行开销并不大所以我们目前并未支持并发执行。 另外规则可能会发生变化所有需要进行规则的动态刷新。 我们在修改规则时会通知网关服务进行实时刷新我们对内部自己的这种元数据更新请求通过独立的线程处理防止 IO 操作时影响业务线程。 2.3 服务调用层 服务调用对于代理网关服务非常关键这个环节性能必须很高必须采用异步方式 我们利用 Netty 实现了这一目标同时也充分利用了 Netty 提供的连接池实现了获取和释放的无锁操作。 2.3.1 异步 Push 在发起服务调用后网关允许工作线程继续处理其他请求而无需等待服务端返回。 在这个设计中我们为每个请求创建一个上下文发送请求后将该请求的 context 绑定到相应的连接上当 Netty 收到服务端响应时会在连接上执行 read 操作。 解码完成后再从连接上获取相应的 context通过 context 可以获取到接入端的 session。 这样push 通过 session 将响应写回客户端这个设计基于 HTTP 连接的独占性即连接和请求上下文绑定。 2.3.2 连接池 连接池的原理如下图 注意请点击图像以查看清晰的视图 服务调用层除了异步发起远程调用外还需要管理后端服务的连接。 HTTP 与 RPC 不同HTTP 连接是独占的所以在释放连接时需要特别小心必须等待服务端响应完成后才能释放此外连接关闭的处理也需要谨慎。 总结如下几点 1Connection:close2空闲超时关闭连接3读超时关闭连接4写超时关闭连接5Fin、Reset。 上面几种需要关闭连接的场景下面主要说下 Connection:close 和空闲写超时两种其他情况如读超时、连接空闲超时、收到 fin、reset 码等都比较常见。 2.3.3 Connection:close 后端服务采用的是 Tomcat它对连接的重用次数有规定默认为 100 次。 当达到 100 次限制时Tomcat 会在响应头中添加 Connection:close要求客户端关闭该连接否则再次使用该连接发送请求会出现 400 错误。 还有就是如果前端的请求带了 Connection:close那 Tomcat 就不会等待该连接重用满 100 次即一次就关闭连接。 在响应头中添加 Connection:close 后连接变为短连接。 在与 Tomcat 保持长连接时需要注意这一点如果要利用该连接需要主动移除 close 头。 2.3.4 写超时 首先网关在何时开始计算服务的超时时间 如果从调用 writeAndFlush 开始计算实际上包含了 Netty 对 HTTP 的编码时间和从队列中发送请求即 flush 的时间这样对后端服务不公平。 因此需要在真正 flush 成功后开始计时这样最接近服务端当然还包含了网络往返时间和内核协议栈处理时间这是无法避免的但基本稳定。 因此我们在 flush 成功回调后启动超时任务。 需要注意的是如果 flush 不能快速回调例如遇到一个大的 POST 请求body 部分较大而 Netty 发送时默认第一次只发送 1k 大小。 如果尚未发送完毕会增大发送大小继续发送如果在 Netty 发送 16 次后仍未发送完成将不再继续发送而是提交一个 flushTask 到任务队列待下次执行后再发送。 此时flush 回调时间较长导致此类请求无法及时关闭后端服务 Tomcat 会一直阻塞在读取 body 部分基于上述分析我们需要设置写超时对于大的 body 请求通过写超时及时关闭连接。 3、全链路超时机制 注意请点击图像以查看清晰的视图 上图是我们在整个链路超时处理的机制 1协议解析超时2等待队列超时3建连超时4等待连接超时5写前检查是否超时6写超时7响应超时。 4、监控报警 对于网关的业务方来说他们能看到的是监控和警报功能我们能够实现秒级的报警和监控将监控数据定时上传到我们的管理系统由管理系统负责汇总统计并存储到 InfluxDB 中。 我们对 HTTP 协议进行了全面的监控和警报涵盖了协议层和服务层的问题。 协议层 1针对攻击性请求只发送头部不发送或只发送部分 body我们会进行采样并记录还原现场并触发警报2对于 Line 或 Head 或 Body 过大的请求我们会进行采样记录还原现场并及时发出警报。 应用层 1监控耗时包括慢请求超时请求以及 tp99tp999 等2监控 OPS并及时发出警报3带宽监控和报警支持对请求和响应的行头body 单独监控4响应码监控特别是 400和 4045连接监控我们对接入端的连接以及与后端服务的连接以及后端服务连接上待发送字节大小都进行了监控6失败请求监控7流量抖动报警这是非常必要的流量抖动可能是出现问题或者是问题即将出现的预兆。 总体架构 注意请点击图像以查看清晰的视图 5、性能优化实践 5.1 对象池技术 针对高并发系统不断地创建对象不仅会占用内存资源还会对垃圾回收过程产生压力。 为了解决这个问题我们在实现过程中会对诸如线程池的任务、StringBuffer 等频繁使用的对象进行重用从而降低内存分配的开销。 5.2 上下文切换 在高并发系统中通常会采用异步设计。异步化后线程上下文切换的问题必须得到关注。 我们的线程模型如下 注意请点击图像以查看清晰的视图 我们的网关没有涉及 I/O 操作但在业务逻辑处理方面仍然采用了 Netty 的 I/O 编解码线程异步方式。 这主要有两个原因 1防止开发人员编写的代码出现阻塞现象2在突发情况下业务逻辑可能会产生大量的日志记录我们允许在推送线程时使用 Netty 的 I/O 线程作为替代。这种做法可以减少 CPU 上下文切换的次数从而提高整体吞吐量。我们不能仅仅为了异步而异步Zuul2 的设计理念与我们的做法相似。 5.3 GC优化 在高并发系统中垃圾回收GC的优化是必不可少的。 我们采用了对象池技术和堆外内存使得对象很少进入老年代同时年轻代的设置较大SurvivorRatio 设置为 2晋升年龄设置最大为 15以尽量让对象在年轻代就被回收。 但监控发现老年代的内存仍在缓慢增长。通过dump分析我们每个后端服务创建一个链接都时有一个socketsocket的AbstractPlainSocketImpl而AbstractPlainSocketImpl就重写了Object类的finalize方法。 实现如下 /*** Cleans up if the user forgets to close it.*/ protected void finalize() throws IOException {close(); }是为了我们没有主动关闭链接做的一个兜底在gc回收的时候先把对应的链接资源给释放了。 由于finalize 的机制是通过 JVM 的 Finalizer 线程处理的其优先级不高默认为 8。它需要等待 Finalizer 线程把 ReferenceQueue 的对象对应的 finalize 方法执行完并等到下次垃圾回收时才能回收该对象。这导致创建链接的这些对象在年轻代不能立即回收从而进入了老年代这也是老年代持续缓慢增长的原因。 5.4 日志 在高并发系统中尤其是 Netty 的 I/O 线程除了执行 I/O 读写操作外还需执行异步任务和定时任务。如果 I/O 线程处理不过队列中的任务可能会导致新进来的异步任务被拒绝。 在什么情况下可能会出现这种情况呢异步读写问题不大主要是多耗点 CPU。最有可能阻塞 I/O 线程的是日志记录。目前 Log4j 的 ConsoleAppender 日志 immediateFlush 属性默认为 true即每次记录日志都是同步写入磁盘这对于内存操作来说速度较慢。 同时AsyncAppender 的日志队列满了也会阻塞线程。Log4j 默认的 buffer 大小是 128而且是阻塞的。即当 buffer 大小达到 128 时会阻塞写日志的线程。在并发写日志量较大且堆栈较深的情况下Log4j 的 Dispatcher 线程可能会变慢需要刷盘。这样 buffer 就不能快速消费很容易写满日志事件导致 Netty I/O 线程被阻塞。因此在记录日志时我们需要注意精简。 6、未来规划 目前我们都在使用基于 HTTP/1 的协议。 相对于 HTTP/1HTTP/2 在连接层面实现了服务即在一个连接上可以发送多个 HTTP 请求。 这就意味着 HTTP 连接可以像 RPC 连接一样建立几个连接即可完全解决了 HTTP/1 连接无法复用导致的重复建连和慢启动的开销。 我们正在基于 Netty 升级到 HTTP/2除了技术升级外我们还在不断优化监控报警以便为业务方提供准确无误的报警。此外我们还在作为统一接入网关与业务方实施全面的降级措施以确保全站任何故障都能通过网关第一时间降级这也是我们的重点工作。 说在最后有问题可以找老架构取经 架构之路充满了坎坷 架构和高级开发不一样 架构问题是open/开放式的架构问题是没有标准答案的 正由于这样很多小伙伴尽管耗费很多精力耗费很多金钱但是遗憾的是一生都没有完成架构升级。 所以在架构升级/转型过程中确实找不到有效的方案可以来找40岁老架构尼恩求助. 前段时间一个小伙伴他是跨专业来做Java现在面临转架构的难题但是经过尼恩几轮指导顺利拿到了Java架构师大数据架构师offer 。所以如果遇到职业不顺找老架构师帮忙一下就顺利多了。 推荐阅读 《百亿级访问量如何做缓存架构设计》 《多级缓存 架构设计》 《消息推送 架构设计》 《阿里2面你们部署多少节点1000W并发当如何部署》 《美团2面5个9高可用99.999%如何实现》 《网易一面单节点2000WtpsKafka怎么做的》 《字节一面事务补偿和事务重试关系是什么》 《网易一面25Wqps高吞吐写Mysql100W数据4秒写完如何实现》 《亿级短视频如何架构》 《炸裂靠“吹牛”过京东一面月薪40K》 《太猛了靠“吹牛”过顺丰一面月薪30K》 《炸裂了…京东一面索命40问过了就50W》 《问麻了…阿里一面索命27问过了就60W》 《百度狂问3小时大厂offer到手小伙真狠》 《饿了么太狠面个高级Java抖这多硬活、狠活》 《字节狂问一小时小伙offer到手太狠了》 《收个滴滴Offer从小伙三面经历看看需要学点啥》 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF请到下面公号【技术自由圈】取↓↓↓