hello，大家好呀，我是小楼。今天不写BUG，来聊一聊注册中心。标题本来想叫《如何设计一个注册中心》，但网上已经有好多类似标题的文章了。所以打算另辟蹊径，换个角度，如何组装一个注册中心。组装意味着不必从0开始造轮子，这也比较符合许多公司对待自研基础组件的态度。知道如何组装一个注册中心有什么用呢？第一可以更深入理解注册中心。以我个人经历来说，注册中心的第一印象就是Dubbo的Zookeeper（以下简称zk），后来逐渐深入，学会了如何去zk上查看Dubbo注册的数据，并能排查一些问题。后来了解了Nacos，才发现，原来注册中心还可以如此简单，再后来一直从事服务发现相关工作，对一些细枝末节也有了一些新的理解。第二可以学习技术选型的方法，注册中心中的每个模块，都会在不同的需求下有不同的选择，最终的选择取决于对需求的把握以及技术视野，但这两项是内功，一时半会练不成，学个选型的方法还是可以的。本文打算从需求分析开始，一步步拆解各个模块，整个注册中心以一种如无必要，勿增实体的原则进行组装，但也不会是个玩具，向生产可用对齐。当然在实际项目中，不建议重复造轮子，尽量用现成的解决方案，所以本文仅供学习参考。需求分析本文的注册中心需求很简单，就三点：可注册、能发现、高可用。服务的注册和发现是注册中心的基本功能，高可用则是生产环境的基本要求，如果高可用不要求，那本文可讲解的内容就很少，上图中的高可用标注只是个示意，高可用在很多方面都有体现。至于其他花里胡哨的功能，我们暂且不表。我们这里介绍三个角色，后文以此为基础：提供者（Provider）：服务的提供方（被调用方）消费者（Consumer）：服务的消费方（调用方）注册中心（Registry）：本文主角，服务提供列表、消费关系等数据的存储方接口定义注册中心和客户端（SDK）的交互接口有三个：注册（register），将服务提供方注册到注册中心注销（unregister），将注册的服务从注册中心中删除订阅（subscribe），服务消费方订阅需要的服务，订阅后提供方有变更将通知到对应的消费方注册、注销可以是服务提供方的进程发起，也可以是其他的旁路程序辅助发起，比如发布系统在发布一台机器完成后，可调用注册接口，将其注册到注册中心，注销也是类似流程，但这种方式并不多见，而且如果只考虑实现一个注册中心，必然是可以单独运行的，所以通常注册、注销由提供方进程负责。有了这三个接口，我们该如何去定义接口呢？注册服务到底有哪些字段需要注册？订阅需要传什么字段？以什么序列化方式？用什么协议传输？这些问题接踵而来，我觉得我们先不急着去做选择，先看看这个领域有没有相关标准，如果有就参考或者直接按照标准实现，如果没有，再来分析每一点的选择。服务发现还真有一套标准，但又不完全有。它叫OpenSergo，它其实是服务治理的一套标准，包含了服务发现：OpenSergo

hello，大家好呀，我是小楼。最近无聊（摸）闲逛（鱼）github时，发现了一个阿里开源项目可以贡献代码的地方。不是写单测、改代码格式那种，而是比较有挑战的性能优化，最关键的是还不难，仔细看完本文后，有点基础就能写出来的那种，话不多说，发车！相信大家在日常写代码获取时间戳时，会写出如下代码:long

知道原因后，把RowKey的MD5改成十六进制字符，重新发布，果然没有出现严重热点问题，监控曲线跟之前一样，说明复用了已有的Region，日常倾斜情况需要跑一段时间才可以解决。总结

hello大家好，我是小楼。流量真是个让人捉摸不透的东西，有时候写了一篇自己感觉牛的不行的文章，结果阅读数据惨淡，有时候觉数据可能没那么好的文章，实际数据却出乎意料。之前的文章《惨，给Go提的代码被批麻了》就是这样，我以为就一般吧吧，没想到却“火了”。这篇文章截止目前，发表的20天时间里，在掘金阅读量突破1w，知乎阅读量突破1.8w，头条阅读量破1.7w，微信公众号的阅读加上被转载的阅读也有1w，就连公司内网的阅读都有3k。可以说这个数据是我从写公众号以来最好的了，但我并不觉得它是我写得最好的文章，所以就很迷。好了，以上只是写技术文过程中的一点点惊喜，这样的惊喜是我继续写好文章的最大动力，所以动动你们的小手，点赞+在看+转发安排起来。今天我就顺着这篇文章来聊聊大家可能都比较感兴趣的话题，开源。本文会结合自己的一些看法，从参与开源项目的收益和如何参与开源项目两个方面展开。参与开源项目的好处首先要明确，为什么要参与开源项目？总得对我有点好处吧。每个人可能追求不一样，所以我这里就列举一下我知道的好处，看看有没有戳中你的点。小礼品这点可能是被很多人忽略的点，因为太小了，但确实也算得上一个好处。如果你掌握了一些技巧，每年从开源社区拿点小（薅）礼（羊）物（毛）是很easy的。尤其是国内的社区，T恤、杯子、背包等等是很容易拿到的。比如这两年Nacos、Dubbo社区送我的一些杯具：据我观察，阿里的开源项目只要每年都去提一个PR，很大概率会送你礼物，不管这个PR是大是小，可以大到贡献一点源码，也可以小到format一下代码、修改文档中的一些错误、增加一个单元测试等等，所以是不是学到了薅羊毛的技巧？朋友圈素材这点只是满足一下虚荣心，其实并没有什么卵用，但还是提一嘴，比如下面这些素材，是发朋友圈装x的利器：装饰简历如果你有参与开源项目的经历，写到简历上一般是个加分项，说一般情况是因为我在面试的时候遇到过候选人在简历上这样写：参与贡献过上万star的项目。（后面还贴上了项目地址）一看这句描述就有猫腻，为啥强调上万star却不说出项目名称？于是我打开后面的github地址发现，原来这个上万star的项目是个聚合在线学习资料的项目。不能说参与这样的项目不好，只是简历上这句话让我感觉在打擦边球，所以不但没有加分，反而减分了。一般来说对项目有过贡献，无论大小，都可以称之为Contributor，贡献达到一定程度则称为Committer，达到多少贡献才能称为Committer一般每个社区都有自己的衡量标准，比如Nacos社区有明确的规定：翻译下就是：至少有8个PR，团队协作能力，理解项目的代码风格，能写出优秀的代码。当然也有很多社区没有明文规定，总之就是贡献越多越有可能成为Committer。所以在简历中如果你是某个项目的Committer就很厉害了，一词胜千言。退一步就算不是Committer，如果你有一些比较重要或者核心的代码提交，也可以写上，附上具体的issue。如果只是代码的format、增加一些单元测试，我建议简历上就不要提了。能力提升通常开源项目的代码、设计、规范都是比较优秀的，和优秀的人一起共事能成长更快。一般我们在参与开源项目时，都是使用英文来交流，所以对你的英文书写能力是个提升。其次代码规范、测试能力、考虑事情的全面性都将得到锻炼。以我个人的感受来说，虽然嘴上说写代码要规范，但在公司写代码的时候，有时候就不太注意，都是以快速完成任务为目标，但开源项目不一样，你写的每一行代码都要被众多的大佬一行一行地review，只要有一点点不满意都会要求你修改。测试也是如此，你写的每一行代码都将被代码测试，单元测试、集成测试。开源项目更相信用代码测试，所以这也锻炼了你写测试和写代码的能力，写出代码不难，写出容易测试的代码还是比较困难的。提升影响力这是更高层级的追求，当你想在技术上走的远的时候，需要一些业界影响力，这时，参与开源是个不错的选择，能结识更多的圈内牛人，也让大家能认识你，你的圈子、人脉就会扩张。提升影响力有什么作用呢？最直接的是，让别人知道你的存在，下一次机会来临时，说不定你会被看中或者推荐。当然我离这个层次还很远，只是说一点自己的理解。如何参与开源项目参与开源的方式上文其实也提到了，参与开源项目不一定是直接的贡献源码，也可以是对文档的编写或修正、写一些单元测试或者测试用例、也可以写一些开源项目相关的文章。比如我在去年写《Dubbo为什么要用Go重写？》这篇文章时，就顺手把Dubbo-go项目的README改了还有比如在写《使用dubbo-go搭建dubbo接口测试平台》这篇文章时，把这篇文章投稿给了Dubbo-go官方网站，也被收录进去这些都算是对开源的一种贡献。当然如果你有代码的直接贡献是最好的，这也是获得技术成长最快的方式。从哪里开始如果我们平时工作中用到什么开源项目，没事的时候可以把源码下载下来翻一番，可以按照文档跑起来，打上断点看看是否跟自己想的一样，这时我们便有了一些基础，可以去github上的issue找找，一般的项目会把issue分类，可以从标了good

hello大家好，我是小楼。不知道大家还记不记得我上次找到了一个Go的Benchmark执行会超时的Bug？就是这篇文章《我好像发现了一个Go的Bug？》。之后我就向Go提交了一个PR进行修复，本想等着代码被Merge进去，以后也可以吹牛说自己是个Go的Contributor，但事情并不顺利，今天就来分享一下这次失败的代码提交。

几个月前，我在《4个实验，彻底搞懂TCP连接的断开》这篇文章中给自己挖了个坑：文中提到的实际问题就是服务探活，今天来填上这个坑。在微服务架构下，服务提供方（Provider）的节点一般不止一个，消费方（Consumer）根据负载均衡算法挑选一个健康的节点进行调用。识别Provider节点是否健康，这便是服务探活

我觉得要回答好这个问题，得从Dubbo-go的初衷谈起，github主页上它是这样介绍自己的：官方给出的中文翻译是Apache

要说现在工程师最重要的能力，我觉得工程能力要排第一。就算现在大厂面试经常要手撕算法，也是更偏向考查代码工程实现的能力，之前在群里看到这样的图片，就觉得很离谱（大概率是假的~）。算法与工程实现在

的对象池很牛逼就行了，具体原理不是本文重点，也不是一两句话能解释的清楚，有机会再写一篇文章详细说道~但理论归理论，是骡子是马，得拉出来遛遛才知道是不是真的牛逼~Benchmark

反而从72%下降到了41%数据数据包括：监控数据，如APM、metric、JVM监控、分布式链路追踪等等数据程序运行数据：如业务数据、AccessLog、GC

ns/op可以看到性能大概提升了20多倍新写的这个方法，有两个小细节，第一是返回值中区分了参数是否存在，这个后面会用到；第二是字符串的操作用到了

"{\"Version\":\"v1\",\"Sentinel\":{\"App\":{\"Name\":\"roshi-app\",\"Type\":0}}}"err

ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(invokers.get(0).getUrl()

的网络来模拟断网断电情况。可以肯定的是断网，断电后，连接不会立即断开，那么后续连接是否会断开呢？我们分成下面几种情况来看断网时有数据传输断网时如果有数据发送，由于收不到

会被拖死，导致商品详情服务不可用，但仔细想想这些服务不是那么重要，可以进行限流或者直接降级（不再调用），总比直接服务不用要好吧又或者流量实在太高，ProductService

只支持接口级服务发现模型，>=2.7.5的版本提供了接口级与应用级两种服务发现模型，3.0之后的版本应用级服务发现更是非常重要的一个功能。本文将从为什么需要引入应用级服务发现，dubbo

服务器、网关等），为了追求高吞吐，有两种思路：为每个请求开一个线程处理，为了降低线程的创建开销，可以使用线程池技术，理论上线程池越大，则吞吐越高，但线程池越大，CPU

使用临时实例应用级：serviceName为应用名即可服务级（Dubbo）：以provider/consumer:$[service_name]:${version}:${group}为服务名

provider，有这么几种情况需要排查检查consumer的group、version是否和provider完全匹配，不匹配会报No

前言在之前的文章中分析了Nacos配置中心，配置中心的核心是配置的创建、读取、推送。注册中心的核心比配置中心多一个服务探活模块，他俩的相似度非常高，甚至阿里内部的注册中心就叫ConfigServer。Nacos注册中心打算分成几个模块来分析，本文重点在于概要设计，基于2.0.0版本。

背景http接口测试只需要一个curl命令，但dubbo协议没有这样的现成接口测试工具。通常公司内的dubbo控制台或其他平台会集成一个dubbo接口测试工具。调用一个dubbo接口，需要知道服务名service、方法名method和参数args。正常的调用，调用方需引入服务提供方定义的接口jar包。作为接口测试平台，没办法引入所有提供方定义的接口jar包，可以有以下方案来解决：dubbo支持telnet协议调用dubbo接口dubbo的泛化调用可以在不引入提供方接口定义jar包的情况下对接口进行调用对于方案1，实现成本很低，甚至可以在服务器上直接用telnet测试它也有缺点调用无法经过filter无法携带隐式参数attachment刚好我们把方案1的优缺点都踩了，我们的dubbo控制台是go语言编写，短时间快速实现，就采用了telnet的方式。随着业务的发展，流量染色，或标签路由等需要携带隐式参数。没有走自定义filter，导致业务接口执行不符合预期等都迫使我们升级为泛化调用。dubbo接口泛化调用在控制台是go编写的情况下也有两个方案可选：单独起一个java进程，暴露http端口，与go进程进行交互，泛化调用使用dubbo的java

"1621858734778"那么就好办了，能否定时把过期的数据删了，并通知给consumer？又看了一眼代码，发现居然这个想法已经实现了，在启动redis注册中心时，起了一个线程，每隔

配置中心业务上的配置，功能开关，服务治理上对弱依赖的降级，甚至数据库的密码等，都可能用到动态配置中心。在没有专门的配置中心组件时，我们使用硬编码、或配置文件、或数据库、缓存等方式来解决问题。硬编码修改配置时需要重新编译打包，配置文件需要重启应用，数据库受限于性能，缓存丧失了及时性。可能都不完美，但能从中总结出配置中心的需求，相对来说还是比较明确：能够存储、获取并监听配置（必须）配置变更时能及时推送给监听者（必须）有一个可视化的查看变更配置的控制台（必须）配置变更可灰度执行（加分）配置变更可回滚（加分）目前使用最多的配置中心可能是携程开源的Apollo，还有Spring

}}可以看到Sentinel实现的是每隔1毫秒缓存一次。我们修改一下测试代码测试一下Sentinel的实现方式在1-128线程下的性能表现Benchmark

SQL审计的缓存区。优化后的Ringbuffer也回馈给了SkyWalking社区，SkyWalking作者赞赏这是一个“intersting

在Java中，我们用Junit做单元测试，用JMH做性能基准测试（benchmark），用async-profiler剖析cpu性能，用jstack、jmap、arthas等来排查问题。作为一名比较新的编程语言，golang的这些工具是否更加好用呢？单元测试Java的单元测试需要使用第三方库，一般是Junit，配置起来比较复杂。在使用了golang之后发现golang自带的单元测试真的非常简单。如果我们有一个cal.go文件，那么其对应的单元测试文件为cal_test.go，其中的方法命名必须为TestXxx，这种按照命名进行单元测试的方式简单有效，也正是通常所说的“约定大于配置”。来看一个简单的例子：package

http://jm.taobao.org/2018/06/13/%E5%81%9A%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0%EF%BC%9F/

❝本文原发表于公司内网，现重新整理，略去一些公司相关的信息。❞背景随着公司业务的飞速发展，基于php的模块化架构难以支持未来业务的发展：php模块化架远远落后于行业主流架构（微服务–>云原生），而php生态的服务治理开源组件匮乏，研发投入过大杭州php人才匮乏，导致新鲜血液招聘困难基于php的多进程架构难以支撑电商高并发业务场景尽管很早我们就做了会员、商品、交易的服务化，但流量入口还是php主站，php实际上仍是一个单体应用，单体应用无需网关。当全站java化之后，单体应用将被拆分为微服务，自然需要一个网关来负责统一流量入口、鉴权、安全防护、业务统一处理等。在2019年3月，我们发起了代号为诺曼底的全站java化项目，将微服务网关项目命名为airborne101，第101空降师（101st

背景在多线程下的生产者-消费者模型中，需求满足如下情况：对生产者生产投递数据的性能要求非常高多个生产者，单个（多个也可以，本文只介绍单个的情况）消费者当消费者跟不上生产者速度时，可容忍少部分数据丢失生产者是单条单条地生产数据举个日志采集的例子，日志在不同的线程上生产，在日志生产速度远超消费者速度时，可以丢弃部分数据，要求打日志的性能损耗最小，这种情况下可采用本文提供的极致性能的缓冲队列。实现细节多个生产者向一个缓冲队列提交消息，说到底是线程安全问题，如果不考虑线程安全，性能必然是最高的，但出现的问题是，数据经常被覆盖。虽然可以容忍少部分数据丢失，但也是在消费者跟不上生产者速度时。缓冲区必然有界，无界可能导致内存泄露，如果缓冲区满，再生产新数据，可选的策略一般有如下几种：阻塞直到被消费覆盖旧数据丢弃新数据在要求对生产者性能损耗最小的情况下一般不选1，通常采取覆盖策略。环形队列有一种环形队列的数据结构（ring

http://www.ruanyifeng.com/blog/2017/09/flame-graph.html❞简单来说：x轴是抽样数，x轴越长说明被这个方法被抽样的次数越多，消耗cpu时间也越长

技术选型公司的RPC框架是dubbo，配合使用的服务发现组件一直是zookeeper，长久以来也没什么大问题。至于为什么要考虑换掉zookeeper，并不是因为它的性能瓶颈，而是考虑往云原生方向演进。云原生计算基金会（CNCF）对云原生的定义是：❝云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。❞想要落地云原生，关键步骤就是mesh化，当前主要讨论service

强悍的LongAdderLongAdder是jdk8引入的适用于统计场景的线程安全的计数器。在此之前，实现一款线程安全的计数器要么加锁，要么使用AtomicLong，加锁性能必然很差，AtomicLong性能要好很多，但是在高并发、多线程下，也显得吃力。于是就有了LongAdder，LongAdder有两个重要的方法：add和sum，add是线程安全的加，sum是返回结果，之所以叫sum是因为LongAdder通过分段的思想维护了一组变量，多线程并发更新时被散列到不同的变量上执行，减少冲突，所以最后获取返回值是将这些变量求和。通过这点也能看出sum获取的结果是不准确的，所以它只适用于统计场景，如果要获取精确的返回值，还是得用AtomicLong，性能和准确不可兼得。通过JMH测试LongAdder、AtomicLong以及加锁的计数器的性能，感受一下LongAdder的强大。（如无特殊说明，本文后续JMH测试均以此为标准：fork1进程，4线程，预热2次，正式测量2次，测试机器4核，完整代码已上传github，文末有地址）

简介基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。而JMH是一个用来构建，运行，分析Java或其他运行在JVM之上的语言的

背景介绍最近写的关于dubbo内存泄露稍微复杂了一点，很多人表示看不明白，想到之前遇到的比较简单的内存泄露问题，更容易入门，于是拿出来分享一下。为了做微服务的熔断降级限流，引入了sentinel组件，对于sentinel引入到公司内部使用只是做了一些简单的定制化，如持久化配置规则，监控数据收集展示，后台登录权限整合等等。在功能验证通过的情况下，也做了压测，性能符合要求，于是就推上了生产做线上灰度。刚开始没问题，直到有一天线上配置了一条降级规则，并且触发了，监控告警就炸了锅。开始是服务出现大量慢请求，后来服务完全僵死。查看监控，慢请求很多，cpu飙升，full

背景介绍在微服务架构中，不同的微服务有不同的网络地址，而客户端则是通过统一的地址进行调用，在客户端与服务端之间需要有一个通信的桥梁，这就产生了微服务网关。微服务网关可以连接客户端与微服务，提供统一的认证方式，管理接口的生命周期，做更好的负载均衡、熔断限流，提供方便的监控，提供统一的风控入口。今天要介绍的主角是dubbo微服务网关，来自公司内部自研的提供http协议到dubbo协议转换的微服务网关，跟本文相关的就是它的核心点：dubbo泛化调用。dubbo官网对泛化调用的描述为“泛化接口调用方式主要用于客户端没有

nacos介绍nacos在它的官网上是这样介绍自己的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台它可作为服务的注册中心，也可用于配置的管理。作为注册中心强调了“更易于构建云原生应用”。注册中心我们可能更加熟悉zookeeper，这里做一个简单的对比特性zookeepernacos一致性协议CPCP

背景介绍今天的主角是标签路由和dubbo的多注册中心。标签路由在之前的文章《以为是青铜，没想到是王者的dubbo标签路由》中已经详细介绍过，多注册中心是dubbo可以使用多个注册中心来提供或者消费服务，利用多注册中心的特性可以搭建多机房。然而很不幸，当多注册中心遇上标签路由，却产生了一个bug。bug复现在复现bug前需要介绍一下dubbo的版本，dubbo社区目前主力维护的有

标签路由简介在开发测试中我们通常会遇到多项目并行开发测试，假设应用ABCDE均为dubbo应用，需求1修改了应用A、C代码，需求2修改了应用A、B、E代码，此时如果并行测试，需求1可能会调用到需求2修改的代码上，造成测试混乱。常见的解决方法有如下几种：每个项目单独部署一整套系统，注册中心也单独部署，优点是实现简单，缺点是机器资源占用太多；在消费方应用中通过硬编码或者配置文件的方式指定调用的接口机器ip和端口，优点也是实现简单，缺点是依赖配置复杂。此方案在简单的依赖中可以使用，但在依赖复杂的环境中较难实施；通过逻辑上的分组将请求正确的路由，优点是逻辑清晰机器资源占用少，缺点是实现困难。此方案也正是本文需要探讨的方案。如果使用的是dubbo，那么在dubbo

Sentinel简介微服务治理中限流、熔断、降级是一块非常重要的内容。目前市面上开源的组件也不是很多，简单场景可以使用Guava，复杂场景可以选用Hystrix、Sentinel。今天要说的就是Sentinel，Sentinel是一款阿里开源的产品，只需要做较少的定制开发即可大规模线上使用。从使用感受上来说，它有以下几个优点：轻量级，对性能损耗几乎可以忽略不计，只有在单机上万QPS才稍有体现；开箱即用的控制台，可以动态灵活地配置各种限流降级规则，持久化规则需要定制插件；支持单机、集群限流，支持无侵入接入多种框架，如dubbo、grpc、springMVC，几种reactive的网关框架、甚至最新版本支持的Envoy限流等；丰富的限流规则，可按qps、线程数、热点参数限流、系统自适应限流；熔断规则同样丰富，可按响应时间，异常数，异常比例等。docker中获取cpu利用率的BUG经典的使用场景是服务消费方在调用提供方时，如果提供方是弱依赖，则可设置一个异常比例的降级规则；对于服务提供方提供的接口可设置一个qps或者线程数的限流规则，并再设置一个“保命”的系统自适应限流。系统自适应限流是系统根据自身的情况，如入口qps，总线程数，cpu

上周遇到一个有意思的问题，拿出来分享一下。问题可以简单地描述如下：在springboot中以starter的方式引入dubbo，但注册中心的配置使用javaConfig的方式，先贴出配置代码@Configurationpublic