前面一节我们将Hystrix集成到了项目中,这一小节,我们就来聊聊Hystrix的前途问题。
架构师不得不面对的问题,当开源项目停止更新 - 图1
当山峰没有棱角的时候

当河水不再流

当时间停住日夜不分

当天地万物化为虚有
当当当当当当当,生活里哪有这么多当?当开源项目停止更新怎么办?着急什么,我们先来细数一下那些年状况频出的开源项目:

  • ReactJS协议再起争端:2016年7月Facebook在ReactJS开源许可协议中的附加专利条款,使用ReactJS的公司不能做构成与Facebook竞争的事情,引发广泛争议
  • Java8更新收费:Oracle Java 8 的公开更新将不向没有商用许可证的业务、商用或生产用途提供
  • Netty5被废弃:2015年11月份,Netty5主干分支被删除。使用ForkJoinPool增加了复杂性,并且没有显示出明显的性能优势。同时保持所有的分支同步是相当多的工作,没有必要
  • Hystrix休眠:2018年11月份,Netflix公司宣布Hystrix将从active development阶段转入维护模式,从全面进攻转为战略防御阶段

我滴个神额,憋说了大兄die,你就直接说怎么办吧!

Hysrix为何断更?

官方正史:最后的一个Release版本v1.5.18已经足够的稳定,足以满足Netflix现有系统的需要。官宣详见https://github.com/Netflix/Hystrix
半仙野史:Hystrix写的太复杂了,接手的人维护不下去了(摊手)
架构师不得不面对的问题,当开源项目停止更新 - 图2

技术选型的几个维度

在Eureka的章节我们探讨过Eureka 2.0开源计划搁置对我们技术选型的影响,那么这次我们从更high-level的角度,谈一谈在已经上线的项目中碰到开源组件断更的情况该怎么办

昨天,今天和明天

我们要正确评估一个开源项目断更的影响,不妨想想它的昨天今天和明天

  • 昨天:有的时候即便官方项目停止更新,但在开源协议的开放性下,有的活跃社区甚至会创建分支来开发社区版本。我们可以参考项目原先的孵化路径,开源机构的支撑力度(比如是否Apache孵化器),社区力量(开源社区活跃度),重点是从这些过去的项目发展路程里,评估未来可以从开源社区获取的支持程度
  • 今天:对当前的业务支持程度,现有组件是否可以支撑当前业务运行。有哪些目前掣肘业务的问题,这些问题是否有可替代的开源方案,替代后给当前项目带来的收益是什么,这部分收益是否大于替换组件的成本
  • 明天:估算业务增量(比如一年后每日交易单数,或者日均访问请求数等),判断当前组件是否可以支撑起未来业务量。评估未来1-2年的业务规模,建议根据预估值乘以2或者一个合理的系数,来保证系统架构有足够的设计余量(避免出现业务爆发,冲破架构设计所能支撑的业务量上限)。在这个预估的业务量级下,评估组件的指标:
    • 性能:是否在业务增量下仍然可以满足性能要求
    • 场景能力:当前组件的功能是否能够满足未来业务的新场景
    • 稳定性:评估系统可用性和负载压力的关系,若是线性相关,需要评估业务增量下系统可用性是否达到公司要求(很多公司在核心系统上要求99.9%以上的可用性,也就是说,全年宕机时间小于9个小时)

性能和稳定性可以借助压测来获取准确数值,系统评估不能只靠猜,也要通过压测等手段获得准确的量化数据。经过以上量化标准,你可以做出一个心理预估:

  1. 更换技术栈的紧急程度
  2. 当前技术栈在多少业务量范围内可以稳定支撑系统运行

对待更换技术组件这个问题,我们不要为了更换而更换,如果说不出来新技术对当前项目可见的利益,单纯只是因为新技术更“新”,那么就不要轻易做替换的决定。

外部依赖

评估系统对上下游业务的依赖和被依赖的程度。
对Hystrix来说情况还好,毕竟这是一个存在于“客户端”的限流控件。假如我们在考虑替换一个在上下游系统都有广泛使用的组件,比如Eureka,我们就不得不考虑更多的问题

  1. 上下游系统的对接:更换组件对上下游系统的影响,是否需要同步更换
  2. 中间件的依赖:通常来说,业务层要和底层组件隔离。就拿消息组件来说,不管你使用的是ActiveMQ还是RabbitMQ,对业务代码应该是无感知的,这样在替换底层组件的时候不需要引入业务层的变动,能显著降低替换成本。但对于Eureka这样无法做“隔离”的中间件,替换成本非常巨大。

早些年有很多公司选择使用了重量级商用产品,而且广泛在上下游系统中应用开来。到如今,这类早年间国际巨头开发的商用产品已经颓势尽显,不管在性能和维护成本上都不如直接使用开源项目来的划算。对这些使用了此类产品的公司来说,除非下了壮士断腕的勇气,否则绝不可能从这些又笨又重的组件上迁移下来。因为上下游的依赖太深了,牵一发而动全身。老师目前的公司就深受其害,因为使用了IBM的ILog组件做决策树,说多了都是泪。
这也反过来说明了一个问题,设计系统的时候一定要把业务层和底层基础组件隔离开来,就像SpringCloud中的Stream组件一样,业务代码不用关心后台的中间件是什么,Stream作为适配层已经屏蔽了底层组件,这样一来即便打算更换底层组件,只要搞定了数据迁移方案,对业务系统的影响就是可控的。

未雨绸缪

不能押宝在一处,积极关注活跃的开源项目,做好技术储备,对技术的替代方案也做到心中有数。

  1. 替换成本:对替换组件来说,有这么几个需要考虑的成本项,团队学习成本,运维成本,迁移成本(数据迁移等)。很多同学以为团队学习成本不是一个很大的考量点,非也,打个比方,如果做前端项目是使用UI5还是ReactJS?想必ReactJS的学习成本和目前的从业程序员基数是处于绝对优势的。除非很专业的特殊领域,否则尽量不要去选择小众技术,不然招人都可能是个问题
  2. POC:Proof of Concept,即概念验证。适当考虑将备选技术方案应用到新项目中。基于微服务架构的项目,特别适合做技术替换,因为每个服务相对独立。打个比方,你可以在商品服务中使用Hystrix,在订单服务中使用Sentinel

    替代方案

    总的来说,Hystrix作为一款开发6年之久的组件,可以满足绝大多数项目在服务容错领域的需求。如果你喜欢追逐新技术,也可以关注另外两个Hystrix的可替代方案:
  • Resilience4j:它是Hystrix的小迷弟,是受Hystrix设计理念启发,但面向Java8和函数式编程理念的服务容错组件。它是功能完备,使用起来也很的轻巧的框架,甚至Hystrix的Github主页也表达了观点:Netflix在新的内部系统中尝试使用Resilience4j
  • Sentinel:它是SpringCloud-Alibaba组件库的成员,除了降级熔断以外,还提供了强大的限流功能(比如基于调用量,调用链路关系的限流)和流量整形功能(相当于流量缓冲,主动调整流量速率的功能),在后面将安排一个完整章节讲解Sentinel的限流功能

    小结

    今天我们探讨了开源项目断更的情况下,技术选型的几个需要考量的方面。下一小节,我们看看Hystrix都有哪些替代方案。
    学习Tips:从我个人的使用感受来说,真正牛掰的组件还是来自于各大互联网公司自己的中间件团队。就拿阿里来说,集团内部的中间件随便拿出一个都是可以独步武林的存在,可惜大部分都是“敝帚自珍”,并没有开源计划。老师希望同学们一定要去互联网公司体验一番,确实可以打开眼界。