咖啡男孩之SRE之路

需求：当后端服务能力不足时我们希望尽可能为更多优质用户请求提供服务相应，放弃部分劣质请求，待峰值回落或后端扩容后再无差别对待。前提条件：监控（观察）必须要有完备的监控体系能及时发现流量的波动，并能推算出后端剩余的服务能力。网关（控制）必须要有统一的流量入口用于访问统计和访问控制。模块划分：各个模块的作用：网关：流量入口，统计request，控制response。由于网关是高并发、低延时的应用场景，所以对于流量限制部分的判断一定要低运算、短链路，所以限制条件等已经要在网.

背景：基于zuul2开发的网关项目在阿里云上试运行3个月后开始在腾讯云部署，在单机测试过程中没发现任何问题，但是部署网关的实例挂在LB下每次客户端请求都会在网关层打印connect reset by peer的错误，可是客户端并没有任何感知，所以可以确定是腾讯云的lb到lb后面的机器这一段报文出了问题，具体原因是什么？为什么客户端没有感知？请见我后面一步步分析。知识准备：TCP标识：SYN(建立联机) ACK(确认) PSH(传送) FIN(结束) RST(重置) URG(紧急)，一般能了解

前言Http是一种协议，对于header、请求方法、内容传送方式等给出了相关定义和推荐用法，但并不会要求你强制遵循的。我们只所以要把一些细节掌握好是因为“专业性”，要把约定俗成的一些细节用好。需求场景流量入口到统一接入API网关层，当突发洪峰时虽然后端服务具有弹性能力，但毕竟资源的启动和应用预热都需要时间，所以服务能力的扩容具有延后性。用户越是接收不到预期的返回越是会疯狂重试，最终导致洪峰放大N倍后后端雪崩。如果我们想彻底解决这个问题，需要做两手准备。第一，做好后端的限流保护，当服务能力超过预期

基础功能：1 路由转发 路由转发是网关最最基础的功能，没有之一，一个不具备转发功能的网关不具备任何使用价值。转发功能的优劣取决于转发策略的丰富度，常用的转发策略有基于host转发、path转发、加权轮询、根据自己业务场景在request中根据header内容进行转发等等。在实现这些逻辑时我们要注意一些网关层的“潜规则”，例如最长匹配规则（当host或path同时满足多个匹配规则时要把请求路由到匹配度最精确的目的地）、IpSource规则（尽量将同一客户端ip请求路由到同一个目的地）。2 过滤增.

背景： 春节过后公司有个核心部门遭到竞争对手的强力挖角，所谓铁打的营盘流水的兵，人员的流失并不可怕，公司担心的是wiki这类的文档中心里的设计、方案、策划等核心资料外泄。所以必须要加强文档库敏感操作的监控，及时止损。分析： 如果文档库是开源或者自研产品，可以通过修改代码满足上述需求，如果像我们一样使用confluence这样的黑盒产品就比较头疼了。Confluence对内容的导出分为两个维度：项目维度和页面维度。其中项目维度的导出Confluence内置了审计日志，而且我们已经通过权限控...

说明：1 前面加星号，需要重点掌握2 zuul2命名规则： 带sync的就是同步，同样的名称不带sync的就是异步 BaseServerStartup只为我们提供了基础的server，这是个抽象类，需要使用者自己来实现。 同理2种InboundFilter、2种OutboundFilter、1种Endpoint也都是抽象类，需要使用者自己来实现。io.netty | b...

Zuul2的核心架构就是就是两大体系，netty体系和filter体系。1 Netty体系Zuul2底层采用Netty的事件响应模式，要掌握zuul2就必须先要掌握Netty。1.1 Channel、Event、EventLoop、EventLoopGroup、ChannelHandlerChannel：每一次通信就会启动一个channel，一个channel对应一个socket...

最近公司要引入统一网关，自己也参与调研了几种，当在研究Netflix的Zuul2和SpringCloudGateway时被网络上杂七杂八的材料跟震惊了，不客气地说很多国内博客都是在误人子弟，充斥着那些基于SpringCloud全家桶号称自己使用的是zuul2的“专家”。所以下定决心用一个系列好好介绍下第二代NIO的两个网关：SpringCloudGateway和NetflixZuul2。背景介...