开发者学堂课程【5天突破 Spring Cloud：熔断限流与关网 Gateway】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/781/detail/13703
熔断限流与关网 Gateway
如上海发生的类似事件，涉及到 ID 行业的案例有很多。上海3、5年之前发生员工由于某种因素离职，发生争执，由于该员工开发程序、网站，此项目为微商项目公司需要做活动在朋友圈转发，抢购。该员工回到家后，使用自己的电脑编写程序不断的发送请求。
一般小型公司的网站没有防护，网站挂到服务器上，挂有域名即可使用。除非有矛盾的公司定位或者类似于公司和员工发生争执将其数据库删除，修改为别的程序。上海事件最终老板进行报案，该程序员被抓受到惩罚。
分析：若在家中两天连续发送请求导致其网站瘫痪，公司报案网警介入很容易调查出大量的请求来源，通过 IP 地址大概可以定位位置，基本上报案就可查。
从中可知，小网站一般没有防护措施，恶意攻击对该类公司的业务造成一定的影响。大公司通常情况下像阿里、腾讯会有一定的保护措施，员工在公司工作会签有保密协议。员工跳槽到竞争对手的公司，除非其放弃经验协议。大型的公司一般不会出现以上小公司赖账的问题，公司强大的老板格局较大。
hystrix 还有控制面板的插件带有可视化的管理界面。与之前的开发模式相类似，基本上注解可以解决大多数问题。有些详细的控制参数较为麻烦，需要注意。
因为熔断的触发条件不一样，比如讲到的调用一秒钟一千个请求中或者一百个请求中有百分之五十，百分之二十或者百分之十的错误，此时该执行什么操作？
还有降级的代码，都可以进行扩充实现，整体也会灵活的允许通过配置文件的方式或者代码配置的方式去实现熔断限流的参数化设置。之后仿照 hystrix 的扩展库 reasoning for java 均支持代码和配置文件的两种方式。
如阿里开发的 sentinel 更加灵活友好。Sentinel 可视化可以直接配置参数，直接并发，比如订单接口不能超过一千次，超过熔断或者拒绝。提示请求过高，像现在的12306的火车票系统放到五年前会有天天抢票的情况，而现在这种情况较少，基本在春节都可以买到票，也不会出现无法买票的情况。
北京可能没有，上海有的拍摄盘，拍摄盘基本被黄胶控制，即每月月末都有拍摄盘行为很多人抢一万张两万张的摄盘，属于政府举行的一个游戏，卖铁皮掌握财富收入。几十万人同时提交其订单时，导致系统可能瘫痪，无法刷出网页。这类问题都有，从技术角度分析，其恶意方发送请求不是网络特别好就是实地输入服务器，靠近拍摄盘的服务器机房。好方面是物理距离很短，在一个机房最好，抢程序在同一个机房，这个消息一般人未可知。
恶意方将价格提高一万转差价，与网络收票时代到来前的十年二十年以前，有关系亲戚在火车站工作的就容易拿到内务票。即老鼠仓，这些人进行内部倒票内部人员参与倒票，这种情况无可避免。
从技术角度来说，要想制作这样的系统，像12306网站也具有限流措施，在买票之前的一系列验证码、图片码，图片码如请识别以下哪个是顺南、哪个是杨成刚。
图片可以自动化进行对比识别，自动录入数据进行抢票对应后台服务器哪个是顺南、哪个是杨成刚的图片挑出，计算机可以识别出。若两人长相相似需要肉眼且很熟悉的人辨别。从技术角度讲这些都是常见的典型的高敏化系统限流措施，之前很容易瘫痪，加固之后问题较少。阿里进行加固改造，大多的请求流量数据均放入到阿里云数据中心，这个数据中心专门起草文件。注意一下建立关系和 Hystrix 底层关系。
在2.5之后发生改变，监控面板配置完成打开面板可见网页，该网图依赖底层配置，采集完进行显示。
另外，值得注意的是 Hystrix 为方便自定义参数的采集监控，提供了 Hystrix stream扩展的数据流，这是第二个网址到前面第二个端口可以动态修改，本地如何开发就如何改。同理该区域进行监控使用的 actuator 组件，在使用 smart2.5 方便做监控数据的暴露，其他程序可以直接扩展包括图形化展示可以直接做出来，并不例外。底层运用到一套方案，当运用到 Hystrix 提供的方案为后续的基础空间的发展，包括之前提到的 reasoning for java 框架也是参考 Hystrix 方向发展的。
像阿里的Sentinel 熔断底层也是应用监控组件，算法和事件原理大同小异，在友好性方面可以存在差异，在国内用户习惯使用 Sentinel ，国外的项目停止维护后，包括之前讲的 rock 和拉库斯集成使用方便，包括动态化的传送配置均可使用。对于大型生态环境下的集群而言做治理较为方便，因为后期涉及到灰度发布的问题，即后台技术更新完之后，替换其中一部分接口，先找几个客户端进行测试，正常以后在进行大规模推送与更新。一些用户使用的 APP ，其发布模式也是灰度发布。
并不是一次更新，而是更新某一部分用户，微信或者淘宝的更新用户的更新时间不是统一的，而是某一地区、某一用户某些人进行测试，先通过测试再大规模推广或者随机挑选测试模式，这是常见的灰度模式。监控数据流叫做 hystrix.stream 后期给监控面板应用，来进行数据流的采集， stream 本身有流，水流的意思，常见的场景。监控数据在接触其他大数据系统包括其他的监控系统会接受这个问题，即监控数据本身会定时采集，如每隔一秒采集一次。
像特斯拉或者其他的物联网设备甚至用户平时用的手环，APP 每隔一秒或者每隔十秒，又或者车载定位器每隔多少秒采集一次。这个数据量如果特别大，采集一台，一小时采集一次，这个频率非常低而且数量也很小，就不需要数据流模式，需要发送再进行数据的推送。若是采集的数据非常多，数据比较密集，形成数据流的概念像雨下的特别大的时候，路面开始出现溪流流淌的样子。
即汇聚成流的状态，监控数据源，当采集数据非常多密集的情况下，数据会源源不断形成一个网络的数据流，是比较好的一种数据传输模式。
之后系统配置完成后，界面可以监控多个服务。 hystrix.stream 放到代理服务器上，网络服务器上，可以放到调用端上直接改。在调用端改完出现上图效果，比如监控客户端对订单服务的调用，监控客户端对支付服务、快递服务、登录服务、评论服务、商业服务等各个不同服务数据的一个监控效果。
图中较为简单拿 orderclient 调用客户端为例，采集数据可以采集后端服务也可以采集前端调用端，代理服务器也作为调用端的一种，负责请求转换。客户端调查调取后端服务，也是客户端，可以监控阵容不同的对象。只要有数据请求类发送均可监控。
比如每次下单进行一个计数，计数的框架比较多，基于 prometheus、tiffany 等框架集合。 ELOK 不一样，之前用的 cat，sky walk 包括 pinpoint 有分式量追踪效果，肯会统计 QBS ，像图中的0.1秒一次指点鼠标进行发送请求的次数，每秒发送0.1次，平均十秒发送一次请求。 thread pools 指性针池，后面可以看到许多的监控数据，其本身的配置看代码可以快速理解。
正常情况下，监控面板放在独立的服务器上，被监控的服务独立的放在一台服务器上，比如监控订单服务，订单的调用客户端代理也可以，注意监控对象需要把其监控数据流暴露出来，地址给明确。它要通过地址采集数据，前提是被监控方的监控程序配置监控的中节点，若不配置无法监控数据。
需要注意除了熔断隔离， hystrix 底层分装大量的命令模式，底层实际使用了叫性能池的隔离策略，即为了保证两个不同的在同一个调用端执行不同任务：调支付、物流、评论、登录等的相互隔离来进行区分。所以每隔调用都有独立的性能池进行隔离。本身是为了解决性能问题也起到隔离作用，互不影响，只负责管理：本身的订单服务、商品服务、支付服务，若是出错暂时关闭或者暂时熔断，相互之间不产生影响，属于策略的一种。
