反应式编程在好几年前就已经出现了，它原理是基于反应式编宣言。可是，因为反应式编程推广速度比较缓慢，致使不少人如今对其不是很了解。react
反应式编宣言：golang
https://www.reactivemanifesto.orgweb
本文将从微服务角度阐述反应式编程，在深刻解读以前，先为你们简单地介绍一些反应式编程的基本概念。编程
反应式编程概念简化版
1. 设计思想
反应式编程的提出，是在分布式编程刚兴起不久。当时没有各类 PaaS 平台，而分布式系统中，经常出现一个节点出问题，致使整个系统瘫痪的状况。因此，反应式编程的思想是：不等不靠，即当有一个节点慢下来的时候，整个系统都放慢，以此来避免灾难性的后果。微信
这样的想法，固然是有局限性的。一方面，虽然整个系统获得保全，可是系统的处理能力却大大下降，做为这个系统以外的用户或者其它应用仍是受到影响的。另外，随着 PaaS 相关技术的发展，如今若是出现一个节点放慢的问题，咱们既能够用熔断、限流，甚至扩容来处理，处理的选择有多种。网络
2. 组成架构
反应式编程的宣言是指导框架，具体的实现是有不一样的版本。可是，它们都有两个共同的特征。app
异步编程，非阻塞流：这是实现反应式编程的基础。负载均衡
可是，不少人把反应式编程和函数式编程混淆了。如 Java 这部分语言 ，选用函数式编程来实现非阻塞式的异步编程。可是，其它的语言，如 golang, goroutine 和 channel 已是异步和非阻塞的，那么它们不用函数式编程也同样能够实现反应式编程。
框架
背压：背压是另外一个本身把本身难倒的概念。
背压就是处理数据的接收方指挥发送方什么时候发送信息和发多少信息，好比咱们排队过安检，安检的人招手了，咱们才走过去。原本都是发送方有数据就发送，那么压力就在接收方，由于处理不了就挂了。如今压力反过来了，在发送方，就叫背压。这个名字很差，若是我起，就叫“憋呀”，简单易懂。发送方数据多了怎么办？憋着。正是这个憋，是背压形象直观的解释，而它保障了系统不会挂。
因此，用不是很准确的方式总结反应式编程的主要部分，就是异步编程、非阻塞流和背压。
微服务环境对分布式应用架构带来的挑战
一直以来不少人都会对反应式编程有这样的疑问：这样的设计，真的有用吗？
微服务已经算是很成熟的技术了，而且微服务是分布式系统的一员，因此不少人也会理所固然的以为分布式系统也应该很成熟了。可是结果却偏偏相反。
我我的的理解，并非微服务走错方向了，而正是因为微服务的普及，产生了许多之前没有遇到过的新问题。
而其中最主要的问题，就是微服务之间的通讯问题。首先，与单体应用不一样，微服务之间谁也没法控制谁，是没法保障通信的顺序的， 这就要求是异步编程。同理也会要求通信是采起非阻塞方式，否则一旦I/O被一个线程占了，其它线程就无法用了。而后就是微服务之间如何协调通信速度的问题。没错，如今有service mesh, 有熔断，限流，也有扩容。可是，这些还不够。由于这些手段都是要先观察到异常，而后才能处置。而不少时候异常是很不容易察觉的。好比K8s的扩容，每30秒采集一次。还要算平均值。这些都很难及时反应。等到算出有问题，时间已通过了好久。并且不少的时候，故障就是小抖动，忽然慢下来，但没法体如今平均值上。吞吐量的匹配，是一个棘手的问题。
这个时候，反应式编程的优势就体现出来了。它无论什么缘由，处理不了就不请求发送。并且是马上的。
微服务环境对反应式编程的新要求
不能觉得反应式编程好像就是能够在微服务环境下安枕无忧。其实，它也面临改进的要求。
端到端的背压
过去的反应式编程通常只考虑两个分布应用之间的通信。可是随着微服务架构的复杂化，从A到B也许中间要通过其余的环节。这个时候，怎么传递背压的信息，而不是在中间环节丢失；怎么从端到端执行背压，就显得特别重要。这对不少现有的反应式编程框架都是挑战。与云原生环境的整合
一些早期反应式编程框架，有本身的集群管理功能。并且这些功能，是以胖SDK的方式捆绑在反应式编程基本功能上的。可是在强调云原生的今天，这彷佛不是优点而是缺点。相反，把基本的反应式编程功能与服务注册，发现，以及负载均衡等功能分离，充分利用云原生的优点，与之协调互补，则是将来的趋势。
性能
最后咱们谈一下很重要的一环：性能。一直以来，不少人都有疑问：背压的通信方式真的好吗？若是一切环境是可控的，网络带宽是无限的，那么传统的阻塞通信是有优点的。这就是为何JVM费那么大劲实现这些功能的缘由。由于Linux实际上是非阻塞的，而20多年前，应用大可能是单体的。可是在现实的环境下，对于分布式应用，在数据量较大的时候，非阻塞通信的优点就体现出来了。特别当有合适的网络通信方式支持背压的时候，这种优点更加明显。
总结
最近的趋势告诉咱们，在分布式应用架构变成熟的过程当中，反应式编程的做用慢慢被从新认识。事实上，反应式编程自身也在发展中，特别是在网络传输方面的进展，必定会在将来分布式应用架构中发挥更大的做用。
本文做者：
Andy Shi :
GitHub ID szihai，阿里巴巴中间件高级技术专家，长期从事 Service Mesh 和微服务框架的技术推广工做。
若是你们以为这篇文章对你有帮助，你的关注和转发是对我最大的支持，O(∩_∩)O:
本文分享自微信公众号 - 咖啡拿铁（close_3092860495）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。