前面一节我们将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：从我个人的使用感受来说，真正牛掰的组件还是来自于各大互联网公司自己的中间件团队。就拿阿里来说，集团内部的中间件随便拿出一个都是可以独步武林的存在，可惜大部分都是“敝帚自珍”，并没有开源计划。老师希望同学们一定要去互联网公司体验一番，确实可以打开眼界。