同步操作将从 柠檬夕桐/neural 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
#微服务神经元(Neural)
分布式服务框架中的神经组织,主要为分布式架构提供:放通率控制、流量控制、服务降级、幂等机制、泛化容错、SLA熔断、隔离舱壁、超时控制和慢性尝试功能。
QQ交流群:191958521(微服务神经元)
##源码结构介绍
##一、功能介绍 ###1.核心功能
分布式依赖协调指挥组织(neural,即神经元):在分布式环境下,将多个系统之间的依赖进行有序的指挥调度与组织协调。如:
异步回调服务
^
|
mock服务<---服务A--->服务B
|
v
失败通知服务
如上如所示,简单的服务A调用服务B,就可能需要同时协调5个(剩至更多)不同系统的服务,而该神经元则就是专门使用在该场景下,其不做具体的业务,只为指挥当前请求该调度谁,只协调各个服务之间的依赖关系。同时在该场景下,还引用该了Hystrix来提供了服务调度的错误隔离、舱壁隔离、超时控制,同时提供了失败重试、重试呼叫、调用链记录、耗时监控统计、放通率控制...
###2.次要功能
##二、目标定位 专业解决微服务场景下的指挥协调组织,为分布式依赖提供丰富的各类机制与监控协调链路。
##三、放通率控制
当后端服务的不稳定性达到一定程度时,如果继续接收大量的请求,会严重影响服务的质量,大量的请求也会使脆弱的后端更加容易宕机,而后端应用突然宕机,则会将原本该进入该应用的所有请求分配至其他应用,进而增加了其他应用的压力。原本不稳定的应用突然增加了流量后,更加容易宕机,而流量如此不断的反复迁移,最终将会导致整个应用集群全部宕机。因此,应用为了自生“保命”,可以选择将部分流量拒绝,从而提供存活的概率。
##四、流量控制
###1.使用场景 当某一片区的服务整体失败率较高时,我们可以选择拒绝部分请求,从而防止该片区集体宕掉或下线的问题;或者使用与流量的迁移过程。
###2.市场上主流的流量控制方式
自研:当你觉得自己的技术足够厉害,选择自行研发个性化的流控方案也是不错的选择。即自研的结果好坏与技术能力和经验程度成正比。
漏斗流控:
令牌桶流控:通常情况下的优先选择方案
**反压流控:**灵感来自于alibaba的开源项目jstorm,开源地址:https://github.com/alibaba/jstorm/wiki/Backpressure
因此,通常情况下流控方案的优略档次为:自研<漏斗流控<令牌桶流控<反压流控。
##五、服务降级
##六、幂等机制 ###1.背景 在业务开发中,我们常会面对防止重复请求的问题。当服务端对于请求的响应涉及数据的修改,或状态的变更时,可能会造成极大的危害。重复请求的后果在交易系统、售后维权,以及支付系统中尤其严重。前台操作的抖动,快速操作,网络通信或者后端响应慢,都会增加后端重复处理的概率。重复消息是SOA服务实现中非常常见的问题,你永远不要指望调用方每次请求消息不一样,对于读操作,重复消息可能无害,可对于写操作很可能就是灾难。
因此,可以通过幂等(Idempotent)机制处理重复的消息,基本处理思路是:
###2.使用场景
###3.定义 在指定的时间窗(一段时间)内,失败后使用重复提交的方式来保证服务的高可靠性。当服务的一致性做得足够好,则可以使用幂等机制来实现所有请求的高可靠,否则该机制只能删除、查询、部分修改的操作,而针对新增是致命的。
###4.幂等方案 对时间全局性要求高的,可能就必须选择DB这种持久化方案比较可靠,但是性能不够好啊(然后就要考虑loadmemory,以及数据同步的问题,就一步还要考虑实时性要求了)。在空间的要求中,根据不同的幂等范围,可以考虑分布式数据库(分布式集群全局流水号幂等)。还是某种少量数据幂等(可能只需要单台,做好主备)。
###5.数据的对象和范围 你要考虑你的幂等的全局性:空间全局性和时间全局性。
##七、泛化容错
###1.设计场景:
###2.泛化容错核心设计:
###3.使用场景 主要用于分布式系统之间进行交互的代码模块,即容错有依赖的代码模块。当分布式系统之间发生远程通信时,需要对代码模块实现容错处理(不保证事务的一致性)。
##八、SLA熔断 ###1.使用场景 在一定的时间窗内,当分布式远程通信中的某一条线路的失败率达到一定的阀值时,系统需要暂时断掉该条线路,以保证后续的服务质量。在熔断一定的时间后,需要尝试线路是否正常,正常则恢复熔断,否则周期性检查是否恢复。
##九、隔离舱壁 ###1.使用场景 分布式服务在远程调用时,可为会发生未知的异常,进而可能会引起整个主服务进程都宕掉,则会导致大面积的服务瘫痪。为了防止单个服务依赖异常而引发其他服务一起陪葬的问题,需要对每一个远程依赖进行隔离。
##十、超时控制 ###1.使用场景 在分布式依赖的模块,为防止服务端长时间等待远程响应的结果,而使用超时设置来控制远程消费异常的情况。
##十一、慢性尝试
TODO
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。