前言

过去一年，我的工作重心投入到了 API 网关（阿里云 CSB）中，这对于我来说是一个新的领域，但和之前接触的微服务治理方向又密不可分。API 网关适配微服务场景需要完成一些基础能力的建设，其一便是对接注册中心，从而作为微服务的入口流量，例如 Zuul、SpringCloud Gateway 都实现了这样的功能。实际上很多开源网关在这一特性上均存在较大的局限性，本文暂不讨论这些局限性，而是针对服务发现这一通用的场景，分享我对它的一些思考。

前言

路由（Route）的设计广泛存在于众多领域，以 RPC 框架 Dubbo 为例，就有标签路由、脚本路由、权重路由、同机房路由等实现。

在框架设计层面，路由层往往位于负载均衡层之前，在进行选址时，路由完成的是 N 选 M（M <= N），而负载均衡完成的是 M 选一，共同影响选址逻辑，最后触发调用。

在业务层面，路由往往是为了实现一定的业务语义，对流量进行调度，所以服务治理框架通常提供的都是基础的路由扩展能力，使用者根据业务场景进行扩展。

今天这篇文章将会围绕路由层该如何设计展开。

转载自：https://www.dozer.cc/2014/12/netty-long-connection.html

原文作者：dozer

推送服务

还记得一年半前，做的一个项目需要用到 Android 推送服务。和 iOS 不同，Android 生态中没有统一的推送服务。Google 虽然有 Google Cloud Messaging ，但是连国外都没统一，更别说国内了，直接被墙。

所以之前在 Android 上做推送大部分只能靠轮询。而我们之前在技术调研的时候，搜到了 jPush 的博客，上面介绍了一些他们的技术特点，他们主要做的其实就是移动网络下的长连接服务。单机 50W-100W 的连接的确是吓我一跳！后来我们也采用了他们的免费方案，因为是一个受众面很小的产品，所以他们的免费版够我们用了。一年多下来，运作稳定，非常不错！

时隔两年，换了部门后，竟然接到了一项任务，优化公司自己的长连接服务端。

再次搜索网上技术资料后才发现，相关的很多难点都被攻破，网上也有了很多的总结文章，单机 50W-100W 的连接完全不是梦，其实人人都可以做到。但是光有连接还不够，QPS 也要一起上去。

所以，这篇文章就是汇总一下利用 Netty 实现长连接服务过程中的各种难点和可优化点。

我曾经写过一篇和本文标题类似的文章《研究优雅停机时的一点思考》，上文和本文都有一个共同点：网卡地址注册和优雅停机都是一个很小的知识点，但是背后牵扯到的知识点却是庞大的体系，我在写这类文章前基本也和大多数读者一样，处于“知道有这么个东西，但不了解细节”的阶段，但一旦深挖，会感受到其中的奇妙，并有机会接触到很多平时不太关注的知识点。

另外，我还想介绍一个叫做”元阅读“的技巧，可能这个词是我自己造的，也有人称之为”超视角阅读“。其内涵指的是，普通读者从我的文章中学到的是某个知识点，而元阅读者从我的文章中可能会额外关注，我是如何掌握某个知识点的，在一个知识点的学习过程中我关注了哪些相关的知识点，又是如何将它们联系在一起，最终形成一个体系的。这篇文章就是一个典型的例子，我会对一些点进行发散，大家可以尝试着跟我一起来思考”网卡地址注册“这个问题。

前言

一致性哈希算法在很多领域有应用，例如分布式缓存领域的 MemCache，Redis，负载均衡领域的 Nginx，各类 RPC 框架。不同领域场景不同，需要顾及的因素也有所差异，本文主要讨论在 ** 负载均衡 ** 中一致性哈希算法的设计。

在介绍一致性哈希算法之前，我将会介绍一些哈希算法，讨论它们的区别和使用场景。也会给出一致性哈希算法的 Java 通用实现，可以直接引用，文末会给出 github 地址。

友情提示：阅读本文前，最好对一致性哈希算法有所了解，例如你最好听过一致性哈希环这个概念，我会在基本概念上缩短篇幅。

天池中间件大赛的初赛在今早终于正式结束了，公众号停更了一个月，主要原因就是博主的空余时间几乎全花在这个比赛上，第一赛季结束，做下参赛总结，总的来说，收获不小。

RPC 框架的讨论一直是各个技术交流群中的热点话题，阿里的 dubbo，新浪微博的 motan，谷歌的 grpc，以及不久前蚂蚁金服开源的 sofa，都是比较出名的 RPC 框架。RPC 框架，或者一部分人习惯称之为服务治理框架，更多的讨论是存在于其技术架构，比如 RPC 的实现原理，RPC 各个分层的意义，具体 RPC 框架的源码分析…但却并没有太多话题和“如何设计 RPC 接口”这样的业务架构相关。

dubbo2.js 是 千米网 贡献给 dubbo 社区的一款 nodejs dubbo 客户端，它提供了 nodejs 对原生 dubbo 协议的支持，使得 nodejs 和 java 这两种异构语言的 rpc 调用变得便捷，高效。

微服务跨语言调用

微服务架构已成为目前互联网架构的趋势，关于微服务的讨论，几乎占据了各种技术大会的绝大多数版面。国内使用最多的服务治理框架非阿里开源的 dubbo 莫属，千米网也选择了 dubbo 作为微服务治理框架。另一方面，和大多数互联网公司一样，千米的开发语言是多样的，大多数后端业务由 java 支撑，而每个业务线有各自开发语言的选择权，便出现了 nodejs，python，go 多语言调用的问题。

上一篇文章分析了服务的注册与发现，这一篇文章着重分析下 RPC 框架都会用到的集群的相关知识。

集群 (Cluster) 本身并不具备太多知识点，在分布式系统中，集群一般涵盖了负载均衡（LoadBalance），高可用（HA），路由（Route）等等概念，每个 RPC 框架对集群支持的程度不同，本文着重分析前两者 – 负载均衡和高可用。

在我们之前 RPC 原理的分析中，主要将笔墨集中在 Client 和 Server 端。而成熟的服务治理框架中不止存在这两个角色，一般还会有一个 Registry（注册中心）的角色。一张图就可以解释注册中心的主要职责。

• 注册中心，用于服务端注册远程服务以及客户端发现服务
• 服务端，对外提供后台服务，将自己的服务信息注册到注册中心
• 客户端，从注册中心获取远程服务的注册信息，然后进行远程过程调用

目前主要的注册中心可以借由 zookeeper，eureka，consul，etcd 等开源框架实现。互联网公司也会因为自身业务的特性自研，如美团点评自研的 MNS，新浪微博自研的 vintage。

本文定位是对注册中心有一定了解的读者，所以不过多阐述注册中心的基础概念。