相信大家碰到源码时经常无从下手🙃,不知道从哪开始阅读,面对大量代码晕头转向,索性就读不下去了,又浪费了一次提升自己的机会😭。
我认为有一种方法,可以解决大家的困扰!那就是通过阅读某一次开源的【commit】、【ISSUE】,从这个入口出发去阅读源码!!
至此,我们发现自己开始从大量堆砌的源码中脱离开来😀。豁然开朗,柳暗花明又一村🍀。
ShenYu是一个异步的,高性能的,跨语言的,响应式的 API 网关。有关ShenYu的介绍可以戳这。
一、前瞻
今天我们来攻克这一次开源提交:commit链接
本次commit的核心内容就在下图红框中,意思很清晰明了:替换当前的ZooKeeper客户端。

看看Magic Header是什么
Magic Header 通常指的是文件开头的一段特定字节序列,用来标识或确认文件的格式和类型。这些字节序列是预先定义的,不同的文件格式有不同的 Magic Header。操作系统和应用程序通过读取这些特定的字节序列来识别文件的格式,即使文件扩展名被更改或丢失。
简单来说就是用来标识文件。
我们先整体看下本次所有提交的内容,虽然看起来涉及了大量的模块、大量的代码,但核心其实就是红框对应的内容。既然是要替换当前的ZooKeeper客户端,那便是要新建Curator这个新的客户端,同时修改调用端的调用对象!

下面我们就来看看贡献者是怎么实现替换的!!同时上文提到并将数据保存在没有 magic header 的 zk 中,正确翻译应该是保存数据在zk时,不使用magic header来标识数据,那他又是怎么做的??
二、探索
我们参照上图,先看下ZookeeperClient类,该类很显眼的引入了本次提交的主角CuratorFramework,ZookeeperClient封装了CuratorFramework作为ZooKeeper新的客户端。
public class ZookeeperClient {
private static final Logger LOGGER = LoggerFactory.getLogger(ZookeeperClient.class);
private final ZookeeperConfig config;
private final CuratorFramework client;
private final Map<String, CuratorCache> caches = new ConcurrentHashMap<>();
public ZookeeperClient(final ZookeeperConfig zookeeperConfig) {
this.config = zookeeperConfig;
ExponentialBackoffRetry retryPolicy = new ExponentialBackoffRetry(config.getBaseSleepTimeMilliseconds(), config.getMaxRetries(

本文通过分析ShenYu项目中的一次开源commit,指导读者如何通过阅读commit和ISSUE来理解代码,特别关注了如何替换ZooKeeper客户端并处理MagicHeader。作者解释了替换过程和关键代码段,以及为何需要移除MagicHeader以避免序列化问题。
最低0.47元/天 解锁文章

被折叠的 条评论
为什么被折叠?



