【技术干货】跨境茶话会第4期丨响应式编程的应用

大师兄说

许多场景下为了更迅速的响应客户端的请求，将问题转化为实时反映业务状态的变化，能更好地提升用户体验以及支撑更大量的用户请求，于是催生了响应式编程，本期跨境茶话会仍旧邀请了中美两地的相关专家来谈谈响应式编程的应用。

全网首发·技术干货·大咖对话

整理：魔窗丨 7728字丨15分钟阅读

来源：本文整理自跨境茶话会线上分享，为魔窗（magic-window）原创首发，转载需获得授权，可联系微信：tina_1903

【主持丨大师兄】：这期为什么要选响应式编程这样一个主题？因为前两期我们做了一个性能优化方面的主题和微服务方面的主题。性能优化本质上会解决高并发情况下同步延时的一些问题，但是可能另外有一些业务和架构上的模式，采取一些消息驱动的方式可以解决后端即使不能实时处理相应，也可以低延迟的保证客户端体验的场景。这样的场景就是响应式编程的系统架构。首先介绍一下这期的嘉宾，首先是徐鹏程，他目前任职于谷歌，是负责广告技术方面的专家。

【嘉宾丨徐鹏程】：大家好，我是徐鹏程，现在在上海谷歌。我在谷歌上海做了大概七年的时间，前六年我都是在做广告优化的一些工作。最近这一年我开始做安卓的开发。在谷歌上海之前我还在谷歌北京本部也待过一段时间，中间也出来创过业。

【主持丨大师兄】：接下来我介绍一下童奎松，他现在在Snapchat，负责Snapchat数据方面的工作。

【嘉宾丨童奎松】：我叫童奎松，2002年浙江大学毕业之后，我在国内写了差不多十年的代码，在2012年加入LinkedIn，主要负责和数据分析相关工具的开发。今年年初加入到Snapchat，做数据分析相关工具的开发。

【主持丨大师兄】：接下来我介绍一下徐焱飞，他现在是磐石科技的CEO，磐石科技也是一款投顾金融平台的产品，他本身在一些CQRS，Eveint Sourcing等相关技术方面非常有经验。

【嘉宾丨徐焱飞】：大家好，我是徐焱飞。我最早在Wipro做零售的一些跨国项目。后来加入爱立信上海研究院，一直做通信方面后台的一些工作。之后加入普兰金融在做分布式后台的开发。今年现在开始出来创业，是一个投顾平台。

【主持丨大师兄】：接下来我们进入这期茶话会第一个环节，首先想请各位嘉宾谈一下关于他们在工作中关于响应式编程的实践。

 【嘉宾丨徐鹏程】：我在谷歌内部假如现在从事的安卓开发，我们在响应式编程上会有更多的实践，在之前的广告优化的地方，因为我长期是在做后台的工作，我们反而在这方面做的实践相对少一点。但是安卓这边因为涉及到很多前端的交互，所以我们在编程上的实践更多一些，因为应用的场景会更多一些。

【主持人丨大师兄】：能不能举一些你们在具体工作中用到的响应式编程的业务的场景和技术方面实践的经验呢？

【嘉宾丨徐鹏程】：比如我最近在做APP的时候，里面有一个常见的webview控件，他是一个事件驱动型的方式，比如你可以给它加载和定制化一些事件client，比如这个webviewclient上你可以做一些事件处理。但是，这个有一个比较不好的地方就是事件处理client是很难被重用的，因为两个不同的webview上面可能有不同的事件处理方式。但是它的业务逻辑可能80%是类似的，20%是不一样的，但是你没有办法重用这80%的代码，除非你做一个级层的关系，那这样两个完全不相关的webview可能就会存在一个依赖关系。我们并不想要这样的耦合方式，所以我们把wenview的事件完全改造成了observer模式的这种方式。所以每个事件我们都可以把事件相对应的observer提出来，这样的话最终在不同的webview的情况下我们就可以把80%类似的observer组装在一起，通过这样的方式来解耦，使得这个代码能够得到重用，也比较易于管理。

【主持人丨大师兄】：谢谢鹏程，鹏程刚刚从一个客户端的角度帮我们介绍了怎么样通过一些响应式编程，就是事件驱动的方式把真正的事件处理的逻辑给解耦。接下来奎松帮我们介绍一下吧。

【嘉宾丨童奎松】：我最近在做一个项目，Snapchat对user ID其实管得很严的，当时在我们所有处理的数据里面，所有的雇员都可以看到User ID的，所以我们想把它转化成全部用一个叫自动生成的Ghost ID来替代所有的user ID，在我们分析的数据库里面。然后这里我们就要做一个系统，让所有其他第三方系统能通过User ID查到对应的Ghost ID，然后把User ID换掉。它其实就是一个User ID和Ghost ID的对应关系，已经在数据库里面有了。但是因为它的吞吐量非常大，基本上所有的因为是事件都会有user ID，每天的事件基本上在T的量级。所以，为了应付这么大量级的查询，我们在前面做了一个cache。但这就是一个典型的高吞吐，它基本也没有什么CPU预算，基本是高吞吐、高IO的运用，所以我们就想到用响应式编程来解决它。其实我们在这里用响应式编程主要是解决的因为它大部分都是IO，所以我们不想把IO等待来占用CPU的时间。这样的话，同时我们就采用了全译步非阻塞的方式来响应请求，这样基本在单台机器可以达到100K以上的吞吐率。

在这之前，我在LinkedIn的时候，整个系统都是基于事件驱动的，它是基于Kafka架构上的事件驱动的响应式系统，这个对系统来说是一样的，就是所有的编程全是异步。我先不说这个异步编程在整个应约上带来的高吞吐率、低延迟，其实延迟不会低，就是容错率有一个好处，另外带来一个好处，从我们数据分析来说，因为所有业务中的事件，所以你在做业务分析的时候只要基于事件来做，其实你能解决大部分数据分析的问题。这是我在这两个公司用响应式编程的一些经验。

【主持人丨大师兄】：刚刚谈到在LinkedIn上你们所有的数据分析都是用事件，用一些事件无非就是一些状态的改变，按照这样的模式去做，你能举个具体的例子吗？

【嘉宾丨童奎松】：我举个例子，比如最典型的PageView的事件，比如我的任何一个LinkedIn的用户查看我的profile页面，就有一个profile的PageView事件。但是这个Page view 的事件发到Kafka，它会返回我的相关信息，然后生成Profile页面。同时这个事件因为它是发的Kafka的，所以Kafka可以把它存到HDFS上，然后我们做数据分析的时候只要从HDFS把这个PageView的事件拉出来，我们就能算出当天的每个页面的PageView是多少。

【主持人丨大师兄】：你们如何对这种事件做一些抽象的？因为可能你们定义了一个具体的状态，但是真正处理这个状态变化的不仅仅一个业务模块，还会有一些其他业务上的模块会针对这个状态变化做处理。

【嘉宾丨