ITPub博客

2011 年 10 月 27 日，阿里巴巴开源了自己服务化治理方案的核心框架 Dubbo，服务治理的设计理念开始逐渐在国内软件行业中落地，并被广泛应用。自开源后，许多非阿里系公司选择使用 Dubbo，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。

最近有朋友问我这么一个面试题目：现在有一个非常庞大的数据，假设全是 int 类型。现在我给你一个数，你需要告诉我它是否存在其中(尽量高效)。

我们已经聊过了 TCP 中的 KeepAlive，以及在应用层设计心跳的意义，但却对长连接心跳的设计方案没有做详细地介绍。事实上，设计一个好的心跳机制并不是一件容易的事，就我所熟知的几个 RPC 框架，它们的心跳机制可以说大相径庭，这篇文章我将探讨一下如何设计一个优雅的心跳机制，主要从 Dubbo 的现有方案以及一个改进方案来做分析。

可能很多 Java 程序员对 TCP 的理解只有一个三次握手，四次挥手的认识，我觉得这样的原因主要在于 TCP 协议本身稍微有点抽象（相比较于应用层的 HTTP 协议）；其次，非框架开发者不太需要接触到 TCP 的一些细节。其实我个人对 TCP 的很多细节也并没有完全理解，这篇文章主要针对微信交流群里有人提出的长连接，心跳的问题，做一个统一的整理。

在不谈及 dubbo 时，我们中的大多数人对 URL 这个概念并不会感到陌生。统一资源定位器 (RFC1738――Uniform Resource Locators (URL)）应该是最广为人知的一个 RFC 规范，它的定义也非常简单

dubbo功能非常完善，很多时候我们不需要重复造轮子，下面列举一些你不一定知道，但是很好用的功能。在开发及测试环境下，可能需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直连模式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表（说明：官方只建议开发&测试环境使用该功能），用法如下，url指定的地址就是直连地址：