转载自：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 实现长连接服务过程中的各种难点和可优化点。

什么是 Nacos

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

在接下里的教程中，将使用 Nacos 作为微服务架构中的注册中心，替代 ZooKeeper 传统方案。

1 概述

社区版本 Dubbo 从 2.7.5 版本开始，新引入了一种基于应用粒度的服务发现机制，这是 Dubbo 为适配云原生基础设施的一步重要探索。版本发布到现在已有近半年时间，经过这段时间的探索与总结，我们对这套机制的可行性与稳定性有了更全面、深入的认识；同时在 Dubbo 3.0 的规划也在全面进行中，如何让应用级服务发现成为未来下一代服务框架 Dubbo 3.0 的基础服务模型，解决云原生、规模化微服务集群扩容与可伸缩性问题，也已经成为我们当前工作的重点。

既然这套新机制如此重要，那它到底是怎么工作的，今天我们就来详细解读一下。在最开始的社区版本，我们给这个机制取了一个神秘的名字 - 服务自省，下文将进一步解释这个名字的由来，并引用服务自省代指这套应用级服务发现机制。

熟悉 Dubbo 开发者应该都知道，一直以来都是面向 RPC 方法去定义服务的，并且这也是 Dubbo 开发友好性、治理功能强的基础。既然如此，那我们为什么还要定义个应用粒度的服务发现机制那？这个机制到底是怎么工作的？它与当前机制的区别是什么？它能给我们带来哪些好处那？对适配云原生、性能提升又有哪些帮助？

带着所有的这些问题，我们开始本文的讲解。

前言

近日，有报道称在 HashCorp 的商业软件试用协议上发现，旗下所有商业产品禁止在中国境内使用、部署、安装，这其中就包含了 Terraform, Consul, Vagrant 等众多知名软件，其中 Consul 是一个在微服务领域的开源软件，可以用于做注册发现、配置管理等场景。

该新闻在国内发酵后，有人在 Twitter上咨询了HashCorp 公司的创始人，得到的回复是影响的软件仅限于 Vault 这款加密软件，目前 HashCorp 公司的官方网站上已经更新了相关的条款，明确了受影响的产品仅限 Vault 这一款产品。

Consul 开源版是否收到影响？

上面的条款里只提到了商业软件，那么开源的 Consul 是否受到影响呢？在 Github 的 Consul 仓库上，可以得知项目的 license 是 Mozilla Public License 2.0 ，这款许可证在 Apache 官网上是 Category B , 属于 Weak Copy Left 许可，那么它有哪些特点呢？

1. 任何可以使用，复制，修改，重新分发该代码，包括商业目的使用。
2. 如果修改了 MPL 协议许可下的源码，再重新发布这部分源码的话，必须保留原来 MPL 许可证不得更换。
3. 如果基于该项目衍生出更大的项目，那么这部分工作可以使用新许可证的方式进行分发，只要没有修改原来 MPL 许可下的代码。（这也是为什么 Apache 项目的分发的源码中可以包含 MPL 协议下二进制文件的原因）

可以看到，MPL 通常被认为是介于 Apache License 和 GPL/LGPL 之间的一个折中方案。相对于 Apache License，MPL 2.0 要求修改了源码必须保持相同协议；相对于 GPL/LGPL, MPL 2.0 可以商用，同时衍生的作品在一定条件下也可以更换许可证类型。

总体来看的话，开源版 Consul 无论是私用还是商用都是不受限制的。但这也可能是一个警钟，如果对 Consul 还是有所顾忌的话，如何替代掉它呢？

在微服务领域，Consul 主要被用来做充当注册中心和配置中心，例如 Dubbo 和 SpringCloud 都有对应的支持。本文便以这个事为一个引子，介绍如何平滑地迁移 Dubbo 服务，达到替换注册中心的效果。

前言

2020 是多事的一年，新冠状性病毒的肆虐，其次是自己也生了一场病，希望随着天气暖和起来，一起都能变得更好。

前一段时间真的很忙，一直没有抽出时间，也没有什么思路给大家分享优质的文章，今天这篇文章很久之前就想写了，抓住这次假期的尾巴，总结一下我最近这一年的工作。

1 前言

在此文之前，我写过一篇 《一文聊透 Dubbo 优雅停机》，这篇文章算是一个续集，优雅停机和优雅上线两者都是微服务生命周期中，开发者必须关心的环节。

优雅上线还有很多称呼：「无损上线」，「延迟发布」，「延迟暴露」。它们的对立面自然是：「有损上线」，「直接发布」。

我最近写的「一文聊透 Dubbo xx」系列文章，都有一个特点，即当你不注重文章中实践，你的 Dubbo 应用依旧可以正常运行，但总归在某些场景 case 下，你的系统会出现问题。做不到优雅上线，你的系统将会出现：在应用刚启动时，就有流量进入，而此时应用尚未初始化完毕，导致调用失败，在集群规模较大时，影响会变得很明显。

前言

如果让你在本地构建一个 Dubbo 应用，你会需要额外搭建哪些中间件呢？如果没猜错的话，你的第一反应应该是注册中心，类 Dubbo 的大多数服务治理框架都有注册中心的概念。你可以部署一个 Zookeeper，或者一个 Nacos，看你的喜好。但在 Apache Dubbo 的 2.7 版本后，额外引入了两个中间件：元数据中心和配置中心。

在今年年初 Dubbo 2.7 刚发布时，我就写了一篇文章 《Dubbo 2.7 三大新特性详解》，介绍了包含元数据中心改造在内的三大新特性，但一些细节介绍没有详细呈现出来，在这篇文章中，我将会以 Dubbo 为例，跟大家一起探讨一下服务治理框架中元数据中心的意义与集成细节。

1 前言

一年之前，我曾经写过一篇《研究优雅停机时的一点思考》，主要介绍了 kill -9，kill -15 两个 Linux 指令的含义，并且针对性的聊到了 Spring Boot 应用如何正确的优雅停机，算是本文的前置文章，如果你对上述概念不甚了解，建议先去浏览一遍，再回头来看这篇文章。这篇文章将会以 Dubbo 为例，既聊架构设计，也聊源码，聊聊服务治理框架要真正实现优雅停机，需要注意哪些细节。

本文的写作思路是从 Dubbo 2.5.x 开始，围绕优雅停机这个优化点，一直追溯到最新的 2.7.x。先对 Dubbo 版本做一个简单的科普：2.7.x 和 2.6.x 是目前官方推荐使用的版本，其中 2.7.x 是捐献给 Apache 的版本，具备了很多新的特性，目前最新的 release 版本是 2.7.4，处于生产基本可用的状态；2.6.x 处于维护态，主要以 bugfix 为主，但经过了很多公司线上环境的验证，所以求稳的话，可以使用 2.6.x 分支最新的版本。至于 2.5.x，社区已经放弃了维护，并且 2.5.x 存在一定数量的 bug，本文介绍的 Dubbo 优雅停机特性便体现了这一点。

1 前言

说道性能测试工具，你会立刻联想到哪一个？ab（ApacheBench）、JMeter、LoadRunner、wrk…可以说市面上的压测工具实在是五花八门。那如果再问一句，对 Dubbo 进行性能压测，你会 pick 哪一个？可能大多数人就懵逼了。可以发现，大多数的压测工具对开放的协议支持地比较好，例如：HTTP 协议，但对于 Dubbo 框架的私有协议：dubbo，它们都显得力不从心了。

如果不从通用的压测工具上解决 Dubbo 的压测需求问题，可以自己写 Dubbo 客户端，自己统计汇总结果，但总归不够优雅，再加上很多开发同学没有丰富的测试经验，很容易出现一些偏差。说到底，还是压测工具靠谱，于是便引出了本文的主角 —— **jmeter-plugins-for-apache-dubbo**。这是一款由 Dubbo 社区 Commiter – 凝雨 同学开发的 JMeter 插件，可以非常轻松地对 Dubbo 实现性能测试。

太阳红彤彤，花儿五颜六色，各位读者朋友好，又来到了分享 Dubbo 知识点的时候了。说到 Dubbo 框架支持的协议，你的第一反应是什么？大概会有 Dubbo 默认支持的 dubbo 协议，以及老生常谈的由当当贡献给 Dubbo 的 rest 协议，或者是今天的主角 http。截止到目前，Dubbo 最新版本演进到了 2.7.3，已经支持了：dubbo，hessain，http，injvm，jsonrpc，memcached，native-thrift，thrift，redis，rest，rmi，webservice，xml 等协议，有些协议的使用方式还没有补全到官方文档中。原来 Dubbo 支持这么多协议，是不是有点出乎你的意料呢？

这么多 RPC 协议，可能有人会产生如下的疑问：rest，jsonrpc，webservice 不都是依靠 http 通信吗？为什么还单独有一个 http 协议？先不急着回答这个问题，而是引出今天的话题，先来介绍下 Dubbo 框架中所谓的 http 协议。