reactive system初探
最后更新于
最后更新于
第一次听到reactive这个词还是在几年前，偶然了解到了Rxjava这个项目，仿佛为我打开了一扇新的大门，Rxjava是ReactiveX的java实现，ReactiveX家族除了Rxjava还有RxJS, Rx.NET,RxScala等等。
ReactiveX的本质就是Observer+Iterator+函数编程+异步。是一个事件驱动的，异步的，可观察的序列。
使用RxJava可以将异步的回调改写成为链式调用。在代码上看起来非常简洁明了。当然JDK也提供了CompletionStage提供了类似的解决回调的功能。
Rxjava只是一个java的基本库，如果我们想要构建响应式的服务器，响应式的web,响应式的数据访问，甚至是响应式的微服务，又该如何处理呢？
这个时候我了解到了Vert.x。Vert.x就是用来构建Reactive的应用程序的。
Vert.x是Eclipse基金会旗下的产品，基于事件驱动和非阻塞编程。
Vert.x是模块化的，里面有Core，web，Data access，Reactive，Microservices，MQTT，Authentication and Authorisation，Messaging，Event bus Bridge,Devops,Testing,Clustering,Services和Cloud等模块。可谓是应有尽有。
其实java界一直都在向reactive靠近，除了JDK本身的api新特性意外，比如业界有名的Spring也在spring 5中添加了webflux框架，这就是一款reactive的web框架。
在上一节我们提到了Rxjava和Vert.x,里面有一些共同的关键字，比如异步，事件驱动，观察者模式，函数式编程，消息驱动等，所有的一切都是为了让现代系统更加健壮，运行的更快，更加富有弹性，从而更好。
系统从很久之前的单一服务器，到现在的多服务器架构，从秒级响应到现在的毫秒级响应。从90%可用都现在的99.999%可用。不论从系统设计，架构还是程序编码都发生了极大的变化。
我们迫切的需要一个能够满足以上需求的通用的系统架构解决方案。
那么什么是响应式系统呢？
响应式系统需要具备这些特征：及时响应性（Responsive）、恢复性（Resilient）、有弹性（Elastic）以及消息驱动（Message Driven）。我们把具有上面四个特性的系统就叫做响应式系统。
上面的四个特性中，及时响应性（Responsive）是系统最终要达到的目标，恢复性（Resilient）和有弹性（Elastic）是系统的表现形式，而消息驱动（Message Driven）则是系统构建的手段。
于是我们得到了响应式系统的终极架构图：
使用响应式系统的架构，可以保证系统的可维护性，和可扩展性，并且在系统出现问题的时候能够有更好的可容忍性。
在定义响应式系统的时候，我们提到了及时响应性（Responsive）、恢复性（Resilient）、有弹性（Elastic）以及消息驱动（Message Driven）这四大特点。
接下来我们将会具体描述这四大特点到底有什么奥秘。
Responsive就是系统能够立刻响应请求，这应该包含两个方面的含义。
第一，响应请求的时间要够短，如果用户请求一个页面，等待2秒钟估计已经是极限了。再长的时间估计就要失去这个用户了。
时代在变，技术也在变，十几年前下载一个几百K的文件要一分钟估计就算是很快了，现在没有个几M每秒，肯定会让人抓狂不已。
在现代CPU，服务集群和光纤传输的飞速发展和页面承载信息的巨大变化，一个普通的页面可能就要包含十几二十个请求。每个请求的时间已经提升到了毫秒甚至是微妙级。同时在页面展示方面也产生了很多新的变化，比如异步加载和预加载等技术。
最终是为了创建一个能够及时响应的系统。而系统背后的各种技术和新的请求方式都是为这个目标来服务的。
第二，对于错误的响应时间要短。
一方面对于用户来说，要及时的提醒用户可能出现的错误。不管是系统本身的错误亦或是用户的使用错误，都需要在一个有限的时间内进行响应。
另一方面，对于系统本身来说，要能够快速的定位和响应问题。这是提升系统本身的稳定性和安全性的基本要求。
如何发现和响应系统本身的问题呢？第一要有完善的错误记录系统，让一切都有章可循。第二就是要有相应的监控措施，让系统出现的任何问题都能够及时的进行通知和报警。
可恢复性是指系统在遇到失败或者错误时仍然能够对外提供服务。
首先，要求我们的系统足够稳健，能够抗住正常的访问，并且能够可预见的应对热点访问。
其次，现代系统的功能是各种各样的，一个简单的APP的后台可能有多达几十种服务。所以我们需要区分出来哪些是关键的服务，哪些是非关键的服务。对于关键的服务我们一定要确保其的稳定性，对于非关键性的服务，我们可以在首先保障关键服务的前提下再进行考虑。
比如说一个订单系统，下单肯定就是关键服务了，而商品的点赞数，评论等则就没有那么重要。
区分好了关键服务和非关键服务，就要对他们进行区分和隔离。非关键服务的任何错误或者异常都不能够影响到关键服务。
再次，如果服务发送了错误，我们应该尽可能的缩小影响范围，不要一点小错误影响所有的服务。
最后，对于失败要有恢复措施，并且这个恢复措施不能够影响其他的系统服务。比如我们可以对现有的系统做一个复制，在某个服务失败的时候，可以用备用的服务进行替代。
只有这样，才能够保证系统的可靠性。
弹性的意思就是在需要的时候服务可以动态扩展，在不需要的时候可以停用服务以节约资源。
现在很多云服务都提供了动态扩展的功能，如果系统是我们自己实现的，那就需要区分出热点问题和非热点问题。
只有热点问题才需要考虑弹性，系统不能有瓶颈，并且能够进行分片或者复制，从而实现分布式的动态负载功能。
负载均衡技术可能是我们最常用的弹性功能，但是如何动态的自动的进行负载的均衡可能是一个非常有意义的话题。
弹性可以通过软件或者硬件的方式来实现，当然我们需要在成本和效果之间达成一个平衡。
消息驱动的本质就是发送消息，接收消息然后进行处理。现在大型系统很少有不使用消息中间件的。使用这些消息中间件的好处就是可以解耦和异步驱动。
异步的好处这里就不多讲了，大概就是不用一直傻傻的等待，而是充分利用时间去做更有效率的事情。
解耦的作用就更大了，现代系统基本上都是由很多个服务组成的。要想保证这么多系统的平稳运行，肯定要做解耦操作，否则一个服务的失败就会导致所有服务的不可用，想想都觉得害怕。
而消息驱动，就是这些不同的服务组件之间沟通的桥梁。告诉他们要做什么，等待他们的反馈消息。
或者我们可以把这些服务看做一个一个的人，多人之间的沟通就是通过语言。语言驱动或者也可以叫做消息驱动。
这里再讲一个消息驱动中常见的一个概念：back-pressure。
我们知道发送消息和接收消息的服务其处理速度是有限的，当发送消息的速度快过与接收消息的速度时候，就会发送消息阻塞，当消息阻塞过多的时候，就有可能发送消息丢失或者服务崩溃的情况。并且如果太多消息一直都没有被处理，没有得到响应的话，对于用户体验也是非常不好的。
这里就需要使用到back-pressure的概念，如果消息接收方消息处理不过来，则可以通知消息发送方，告知其正在承受压力，需要降低负载。back-pressure是一种消息反馈机制，从而使系统得以优雅地响应负载， 而不是在负载下崩溃。
reactive是近几年非常流行的一个概念，如何通过reactive来设计出满足我们需要的系统，是我们需要考虑的问题。
欢迎关注我的公众号:程序那些事，更多精彩等着您！ 更多内容请访问 www.flydean.com
