上周五遇到了一个 Bug，没有任何异常，困扰了我一个小时，差点连周末都过不好了。最后没办法，请教了组内的同学，没想到竟被他 1 分钟解决了！

事情的起因，只是因为我把一个接口从 @GetMapping 改成了 @PostMapping ，然后接口就报以下的错误:

没有任何的 WARN 或者 ERROR 日志！

网上搜了一下，也没有什么有效的信息，万能的 AI 给出了下面这样的回答：

404 的错误太常见了，有很多原因造成这一结果。

但可以确定的是，我的请求路径和控制器配置都是没有问题的，因为只要要把 @PostMapping 改回 @GetMapping ，一切都运行正常。

在这种情况下，搜索引擎和AI，除了给我造成干扰误导排查方向外，不能起到什么实质性的作用。

无奈，我只能硬着头皮打开 DEBUG 日志，尝试对照源码，去解决问题了。

不幸的是，DEBUG 日志实在太多了，里面也没有任何异常。我刚学 SpringBoot 不久，这些碎片化的日志，不能引起我的任何联想，因此，实质上也起不到辅助排查的作用。

折腾了一个多小时，还是没有什么头绪，明天就周末了，带着这个 Bug，周末恐怕都休息不好。于是，我就硬着头皮找了组内一个比较有经验的同学帮忙看一下。

他过来翻了翻日志，查看了一下配置类，淡淡地说到，你打开了 Csrf 验证，但是请求却没带 Token。说罢，指导我加上了一行代码：

.csrf().disable()

然后，再次访问，竟然就真的可以了！整个过程也就 1 分钟左右！

我这个小弱鸡的心灵着实有些触动。于是追问到，大神你是怎么看出来的呀。

“没什么，就是经验多了。日志里面有些信息，比如 token 相关的， 其实已经提示了你答案。不过，需要你对框架比较了解，才能 get 到这些信息。新手遇到这种没有明显异常的问题，确实会比较费劲。”

“那有没有什么办法，可以快速搞懂这种框架问题啊，每次遇到都挺烦躁的，不仅影响研发进度，也影响心情” ， 上进的我还是想从大神这里获取更多的经验。

“额….我想想”，大神迟疑了一会儿，“你可以试试这个 XCodeMap 插件“，”它可以提供更丰富的信息，图形化的形式，可以较为容易看出可能存在的问题。实在看不出，你也可以基于这些信息再去问搜索引擎或者AI”。

“感谢大神，我去试一下”。

试用了一下，这个工具画出了下面的序列图：

我虽然不懂什么 Csrf 的原理，但是这个图已经可以清晰地表达出问题了，在 SpringBoot 的FilterChain 中，走到 CsrfFilter 就终止了，并且调用了一个 AccessDeniedHandler。

看起来，这个序列图是实时动态采集的，而且做了很多剪枝，把一些关键调用给标记了出来。对于 SpringBoot 系列，其会把各种 Filter 的调用情况展示出来，可以让人一眼看出来是哪个 Filter 出了问题。

点击 CsrfFilter 的 doFilter 方法，可以看到以下代码：

这个代码可以看出来，Csrf 的原理（以CookieCsrfToken为例）就是取两个token进行比对。其中一个从请求的 Header 或者 Parameter 中读出。另外一个，从 Cookie 中读出。

由于浏览器的同源策略，攻击网站无法获取本网站的Cookie，也即其无法完成下面这样的JS操作：

但是本网站可以通过上面的操作，把 Cookie 中的token设置到 Header 中，这样就达到了避免 CSRF 攻击的效果。

不过，这里还有一个小插曲，csrf 验证失败，本意应该是报 403 错误码，然后转发到 “/403” 页面，只是因为我没有配置 “/403” 页面，最终才报了404 错误。

这次由 Csrf 引起的 404 错误，就到此为止了。

我独自完成了后面的排查，还是很开心的。我没有大神那样丰富的经验，可以凭借只言片语的日志信息，就可以推断出问题所在。但我借助 XCodeMap 绘制的动态序列图，按图索骥，搞清楚了问题的来龙去脉。这让我想起了下面的一句话：

人类有了弓箭，拳头就不再是绝对硬实力了。好的工具，可以削平人与人的差距！

感觉自己与大神接近了不少！

参考资料：

以前听过过一个有趣的说法：不要编写没有明显bug的代码，要去编写明显没有bug的代码。这里提到的两个概念：“没有明显bug的代码”和“明显没有bug的代码”。同样的文字，只是调换了下顺序，表达的就是完全不同的概念了。前者“没有明显bug的代码”大概是最常见的代码了，特征就是：

平时工作中到处缝缝补补的代码大概就是这种代码吧。背后的原因一般比较复杂，有时还不可追溯，项目工期紧，人员交接等等都有可能。因此，与其思考“如何避免没有明显bug的代码”，还不如思考“如何写出明显没有bug的代码”。本文就何为“明显没有bug的代码”总结一些个人的思的胡思乱想，阐述这类代码的几个特征。

特征1：代码简短

“明显没有xx”意味着一眼能看出来，而“一眼”这个条件就有很大的限制。如果给我一个函数，包含1000多行代码，我鼠标滚轮要滚好久，才能过完一遍代码，那么这种代码一定不是“明显没有bug的代码”。那么，反过来说，“明显没有bug的代码”一定是短小的代码。比如，Java中的Objects.equals方法：

public static boolean equals(Object a, Object b) {

    return (a == b) || (a != null && a.equals(b));

}

这一段代码简短到，代码跟功能定义的文字篇幅差不多，连写文档注释的必要都没有了。还有一个更极端的例子是Java的Objects.isNull方法：

public static boolean isNull(Object obj) {

    return obj == null;

}

简直就是一段“废话”。

特征2：功能完整且连贯

“一眼能看出”还意味着功能不能太分散，如果一个功能，分散在十多个函数或文件中，那么看这段功能就得在很多代码片段中跳来跳去，这个就需要开发者来阅读代码时充当一个“人肉解释器”的角色，在大脑中把各个代码片段组合起来才能明白整个流程和细节，这无疑降低阅读代码的效率，bug也容易隐藏在各个代码片段的“缝隙”中。举个常见的例子：在图形界面应用中，用户登录后，弹出登录成功的提示，然后关闭登录页面。一种普通的实现是：

//1. 在登录按钮触发登录操作

loginButton.setOnClickListener(v -> controller.login(username, poassword))



//2. 在登录成功的回调中展示弹窗

public void onLoginSuccess(User user){

    LoginSuccessDialog.show("login success")

}



//3. 在失败的回调中展示错误信息

public void onLoginFailed(String errorMsg){

    MessageDialog.showMessage(errorMsg);

}



//4. 在LoginSuccessDialog确认后关闭页面

public void onLoginDialogConfirmed(){

    loginPage.close();

}

看上去好像解耦很不错，但功能都变得七零八落。要拼凑出完整的功能大概得仔细阅读整段代码，更别提“一眼看出”了。那么一眼能看出的代码大概长啥样呢？我想，大概是这样：

loginButton.setOnClickListener(v -> {

    controller.login(username, poassword)

            .onSuccess(user ->

                    LoginSuccessDialog.总而言之，解耦需谨慎，不要因过度解耦而牺牲了内聚性和连贯性。show("login success")

                            .onConfirmed(() -> loginPage.close()))

            .onFailed(errorMsg ->

                    MessageDialog.showMessage(errorMsg));

});

这是对该视图流程的一个连贯的描述，而且篇幅更短。至于获取到用户数据存储到本地数据库、通知其他页面更新等操作，跟当前视图没有关系，也就不需要放在这段代码里。总而言之，解耦需谨慎，不要因过度解耦而牺牲了内聚性和连贯性。

特征3：良好的表达

代码的篇幅得到控制后，要让人一眼看懂，还需要容易理解才行。设计心理学提出“设计传达所有必要的信息，创造一个良好的系统概念模型，引导用户理解系统状态，带来掌控感”。程序设计也是如此，代码是程序功能的文本表达，需要传达对应信息来让人产生该功能正确的概念模型。

以一个常见的上传图片的弹窗为例，思考一个菜单弹窗，包含取消和两个功能按钮：从相册选择和拍照上传，例如下图这样。

那么对应的代码可以表达为：

MenuDialog.create()

        .withAction("拍照上传", dialog -> {

            takePhoto();

        })

        .withAction("本地上传", dialog -> {

            chooseFromGallery();

        })

        .onCancel(() -> {

            //do something

        })

        .show();

或者

MenuDialog.create()

        .withAction("拍照上传", controller::takePhoto)

        .withAction("本地上传", controller::chooseFromGallery)

        .onCancel(() -> {

            //do something

        })

        .show();

没有多余的代码，该有的信息都表达到位，而且和实际功能有良好的对应关系。

4. 特征4：可验证正确性

代码可以让人一眼看懂之后，那么判断其有没有bug，还有一个重要前提：这个代码是有正确性可言的，可以被验证。

例如，来看下面这段随意的代码：

int type;

boolean isClosed;



void doSomething(String text) {

    if (type == 0) {

        if (isClosed) {

            println(text);

        } else {

            error("something wrong");

        }

    } else if (type == 1) {

        //do something

    }

}

这段程序简短、易读，但是doSomething函数的行为依赖两个外部变量，而这两个外部变量又容易被其他地方随意改动。比如，type的定义域为1、2、3，但如果type新增类型4的时候或者被错误地赋值为-1的时候，这个doSomething函数的行为还是正确的吗？doSomething函数的正确性依赖于type变量的正确性，那么又依赖于读写type变量的程序的正确性，这样的程序是难以验证的。而且，对上下文依赖越多的程序，越难以产生明确的定义，因为这个定义也依赖上下文的定义。定义不明确，更难以验证内容的正确性。

相比之下，Objects.equals和Objects.isNull方法有着明确的定义，而且不受上下文影响，可以一眼就看出对错。而下面这段代码：

MenuDialog.create()

        .withAction("拍照上传", controller::takePhoto)

        .withAction("本地上传", controller::chooseFromGallery)

        .onCancel(() -> {

            //do something

        })

        .show();

表达明确，可以快速判断出程序行为是否正确、符合期望。即便MenuDialog出现异常，或者takePhoto和chooseFromGallery出了什么问题，也不需要来修改这段程序。

不过，程序验证是一个有点高深的科研方向，要严格验证一个程序的正确性是很困难的一件事，不过我们仍然可以试着去编写一些“看起来”正确的程序。（利用函数式编程思想写出来的代码通常容易验证一些）

大家好，我是二哥呀。

对于 Java 初学者来说，多线程的很多概念听起来就很难理解。比方说：

• 进程，是对运行时程序的封装，是系统进行资源调度和分配的基本单位，实现了操作系统的并发。


• 线程，是进程的子任务，是 CPU 调度和分派的基本单位，实现了进程内部的并发。

很抽象，对不对？打个比喻，你在打一把王者（其实我不会玩哈 doge）：

• 进程可以比作是你开的这一把游戏


• 线程可以比作是你所选的英雄或者是游戏中的水晶野怪等之类的。

带着这个比喻来理解进程和线程的一些关系，一个进程可以有多个线程就叫多线程。是不是感觉非常好理解了？

进程和线程

❤1、线程在进程下进行

（单独的英雄角色、野怪、小兵肯定不能运行）

❤2、进程之间不会相互影响，主线程结束将会导致整个进程结束

（两把游戏之间不会有联系和影响。你的水晶被推掉，你这把游戏就结束了）

❤3、不同的进程数据很难共享

（两把游戏之间很难有联系，有联系的情况比如上把的敌人这把又匹配到了）

❤4、同进程下的不同线程之间数据很容易共享

（你开的那一把游戏，你可以看到每个玩家的状态——生死，也可以看到每个玩家的出装等等）

❤5、进程使用内存地址可以限定使用量

（开的房间模式，决定了你可以设置有多少人进，当房间满了后，其他人就进不去了，除非有人退出房间，其他人才能进）

创建线程的三种方式

搞清楚上面这些概念之后，我们来看一下多线程创建的三种方式：

继承 Thread 类

♠①：创建一个类继承 Thread 类，并重写 run 方法。

public class MyThread extends Thread {

    @Override

    public void run() {

        for (int i = 0; i < 100; i++) {

            System.out.println(getName() + ":打了" + i + "个小兵");

        }

    }

}

我们来写个测试方法验证下：

//创建MyThread对象

MyThread t1=new  MyThread();

MyThread t2=new  MyThread();

MyThread t3=new  MyThread();

//设置线程的名字

t1.setName("鲁班");

t2.setName("刘备");

t3.setName("亚瑟");

//启动线程

t1.start();

t2.start();

t3.start();

来看一下执行后的结果：

实现 Runnable 接口

♠②：创建一个类实现 Runnable 接口，并重写 run 方法。

public class MyRunnable implements Runnable {

    @Override

    public void run() {

        for (int i = 0; i < 10; i++) {

            try {//sleep会发生异常要显示处理

                Thread.sleep(20);//暂停20毫秒

            } catch (InterruptedException e) {

                e.printStackTrace();

            }

            System.out.println(Thread.currentThread().getName() + "打了:" + i + "个小兵");

        }

    }

}

我们来写个测试方法验证下：

//创建MyRunnable类

MyRunnable mr = new MyRunnable();

//创建Thread类的有参构造,并设置线程名

Thread t1 = new Thread(mr, "张飞");

Thread t2 = new Thread(mr, "貂蝉");

Thread t3 = new Thread(mr, "吕布");

//启动线程

t1.start();

t2.start();

t3.start();

来看一下执行后的结果：

实现 Callable 接口

♠③：实现 Callable 接口，重写 call 方法，这种方式可以通过 FutureTask 获取任务执行的返回值。

public class CallerTask implements Callable<String> {

    public String call() throws Exception {

        return "Hello,i am running!";

    }



    public static void main(String[] args) {

        //创建异步任务

        FutureTask<String> task=new FutureTask<String>(new CallerTask());

        //启动线程

        new Thread(task).start();

        try {

            //等待执行完成，并获取返回结果

            String result=task.get();

            System.out.println(result);

        } catch (InterruptedException e) {

            e.printStackTrace();

        } catch (ExecutionException e) {

            e.printStackTrace();

        }

    }

}

关于线程的一些疑问

❤1、为什么要重写 run 方法？

这是因为默认的run()方法不会做任何事情。

为了让线程执行一些实际的任务，我们需要提供自己的run()方法实现，这就需要重写run()方法。

public class MyThread extends Thread {

  public void run() {

    System.out.println("MyThread running");

  }

}

在这个例子中，我们重写了run()方法，使其打印出一条消息。当我们创建并启动这个线程的实例时，它就会打印出这条消息。

❤2、run 方法和 start 方法有什么区别？

• run()：封装线程执行的代码，直接调用相当于调用普通方法。


• start()：启动线程，然后由 JVM 调用此线程的 run() 方法。

❤3、通过继承 Thread 的方法和实现 Runnable 接口的方式创建多线程，哪个好？

实现 Runable 接口好，原因有两个：

• ♠①、避免了 Java 单继承的局限性，Java 不支持多重继承，因此如果我们的类已经继承了另一个类，就不能再继承 Thread 类了。


• ♠②、适合多个相同的程序代码去处理同一资源的情况，把线程、代码和数据有效的分离，更符合面向对象的设计思想。Callable 接口与 Runnable 非常相似，但可以返回一个结果。

控制线程的其他方法

针对线程控制，大家还会遇到 3 个常见的方法，我们来一一介绍下。

1）sleep()

使当前正在执行的线程暂停指定的毫秒数，也就是进入休眠的状态。

需要注意的是，sleep 的时候要对异常进行处理。

try {//sleep会发生异常要显示处理

    Thread.sleep(20);//暂停20毫秒

} catch (InterruptedException e) {

    e.printStackTrace();

}

2）join()

等待这个线程执行完才会轮到后续线程得到 cpu 的执行权，使用这个也要捕获异常。

//创建MyRunnable类

MyRunnable mr = new MyRunnable();

//创建Thread类的有参构造,并设置线程名

Thread t1 = new Thread(mr, "张飞");

Thread t2 = new Thread(mr, "貂蝉");

Thread t3 = new Thread(mr, "吕布");

//启动线程

t1.start();

try {

    t1.join(); //等待t1执行完才会轮到t2，t3抢

} catch (InterruptedException e) {

    e.printStackTrace();

}

t2.start();

t3.start();

来看一下执行后的结果：

3）setDaemon()

将此线程标记为守护线程，准确来说，就是服务其他的线程，像 Java 中的垃圾回收线程，就是典型的守护线程。

//创建MyRunnable类

MyRunnable mr = new MyRunnable();

//创建Thread类的有参构造,并设置线程名

Thread t1 = new Thread(mr, "张飞");

Thread t2 = new Thread(mr, "貂蝉");

Thread t3 = new Thread(mr, "吕布");



t1.setDaemon(true);

t2.setDaemon(true);



//启动线程

t1.start();

t2.start();

t3.start();

如果其他线程都执行完毕，main 方法（主线程）也执行完毕，JVM 就会退出，也就是停止运行。如果 JVM 都停止运行了，守护线程自然也就停止了。

小结

本文主要介绍了 Java 多线程的创建方式，以及线程的一些常用方法。最后再来看一下线程的生命周期吧，一图胜千言。

好了，如果你想学好 Java，GitHub 上标星 10000+ 的《二哥的 Java 进阶之路》不容错过，据说每一个优秀的 Java 程序员都喜欢她，风趣幽默、通俗易懂。内容包括 Java 基础、Java 并发编程、Java 虚拟机、Java 企业级开发（Git、Nginx、Maven、Intellij IDEA、Spring、Spring Boot、Redis、MySql 等等）、Java 面试等核心知识点。学 Java，就认准二哥的 Java 进阶之路😄。

Github 仓库：github.com/itwanger/to…

码云仓库（国内访问更快）：gitee.com/itwanger/to…

star 了这个仓库就等于你拥有了成为了一名优秀 Java 工程师的潜力。

把二哥的座右铭送给你：没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。

前言

假如有一天我们要按代码量来算工资，那怎样才能写出一手漂亮的代码，同时兼顾代码行数和实际意义呢？

要在增加代码量的同时提高代码质量和可维护性，能否做到呢？

答案当然是可以，这可难不倒我们这种摸鱼高手。

耐心看完，你一定有所收获。

正文

1. 实现更多的接口：

给每一个方法都实现各种“无关痛痒”的接口，比如Serializable、Cloneable等，真正做到不影响使用的同时增加了相当数量的代码。

为了这些代码量，其中带来的性能损耗当然是可以忽略的。

public class ExampleClass implements Serializable, Comparable<ExampleClass>, Cloneable, AutoCloseable {



    @Override

    public int compareTo(ExampleClass other) {

        // 比较逻辑

        return 0;

    }



    // 实现 Serializable 接口的方法

    private void writeObject(ObjectOutputStream out) throws IOException {

        // 序列化逻辑

    }



    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {

        // 反序列化逻辑

    }



    // 实现 Cloneable 接口的方法

    @Override

    public ExampleClass clone() throws CloneNotSupportedException {

        // 复制对象逻辑

        return (ExampleClass) super.clone();

    }



    // 实现 AutoCloseable 接口的方法

    @Override

    public void close() throws Exception {

        // 关闭资源逻辑

    }



}

除了示例中的Serializable、 Comparable、 Cloneable、 AutoCloseable，还有Iterable

2. 重写 equals 和 hashcode 方法

重写 equals 和 hashCode 方法绝对是上上策，不仅增加了代码量，还为了让对象在相等性判断和散列存储时能更完美的工作，确保代码在处理对象相等性时更准确、更符合业务逻辑。

public class ExampleClass {

    private String name;

    private int age;



    // 重写 equals 方法

    @Override

    public boolean equals(Object obj) {

        if (this == obj) {

            return true;

        }



        if (obj == null || getClass() != obj.getClass()) {

            return false;

        }



        ExampleClass other = (ExampleClass) obj;

        return this.age == other.age && Objects.equals(this.name, other.name);

    }

    

    // 重写 hashCode 方法

    @Override

    public int hashCode() {

        return Objects.hash(name, age);

    }

}

3. 增加配置项和参数：

不要管能不能用上，梭哈就完了，问就是为了健壮性和拓展性。

public class AppConfig {

    private int maxConnections;

    private String serverUrl;

    private boolean enableFeatureX;



    // 新增配置项

    private String emailTemplate;

    private int maxRetries;

    private boolean enableFeatureY;



    // 写上构造函数和getter/setter

}

4. 增加监听回调：

给业务代码增加监听回调，比如执行前、执行中、执行后等各种Event，这里举个完整的例子。

比如创建个 EventListener ，负责监听特定类型的事件，事件源则是产生事件的对象。通过EventListener 在代码中增加执行前、执行中和执行后的事件。

首先，我们定义一个简单的事件类 Event：

public class Event {

    private String name;



    public Event(String name) {

        this.name = name;

    }



    public String getName() {

        return name;

    }

}

然后，我们定义一个监听器接口 EventListener：

public interface EventListener {

    void onEventStart(Event event);



    void onEventInProgress(Event event);



    void onEventEnd(Event event);

}

接下来，我们定义一个事件源类 EventSource，在执行某个业务方法时，触发事件通知：

public class EventSource {

    private List<EventListener> listeners = new ArrayList<>();



    public void addEventListener(EventListener listener) {

        listeners.add(listener);

    }



    public void removeEventListener(EventListener listener) {

        listeners.remove(listener);

    }



    public void businessMethod() {

        Event event = new Event("BusinessEvent");



        // 通知监听器：执行前事件

        for (EventListener listener : listeners) {

            listener.onEventStart(event);

        }



        // 模拟执行业务逻辑

        System.out.println("Executing business method...");



        // 通知监听器：执行中事件

        for (EventListener listener : listeners) {

            listener.onEventInProgress(event);

        }



        // 模拟执行业务逻辑

        System.out.println("Continuing business method...");



        // 通知监听器：执行后事件

        for (EventListener listener : listeners) {

            listener.onEventEnd(event);

        }

    }

}

现在，我们可以实现具体的监听器类，比如 BusinessEventListener，并在其中定义事件处理逻辑：

public class BusinessEventListener implements EventListener {

    @Override

    public void onEventStart(Event event) {

        System.out.println("Event Start: " + event.getName());

    }



    @Override

    public void onEventInProgress(Event event) {

        System.out.println("Event In Progress: " + event.getName());

    }



    @Override

    public void onEventEnd(Event event) {

        System.out.println("Event End: " + event.getName());

    }

}

最后，我们写个main函数来演示监听事件：

public class Main {

    public static void main(String[] args) {

        EventSource eventSource = new EventSource();

        eventSource.addEventListener(new BusinessEventListener());



        // 执行业务代码，并触发事件通知

        eventSource.businessMethod();



        // 移除监听器

        eventSource.removeEventListener(businessEventListener);

    }

}

如此这般那般，代码量猛增，还顺带实现了业务代码的流程监听。当然这只是最简陋的实现，真实环境肯定要比这个复杂的多。

5. 构建通用工具类：

同样的，甭管用不用的上，定义更多的方法，都是为了健壮性。

比如下面这个StringUtils，可以从ApacheCommons、SpringBoot的StringUtil或HuTool的StrUtil中拷贝更多的代码过来，美其名曰内部工具类。

public class StringUtils {

    public static boolean isEmpty(String str) {

        return str == null || str.trim().isEmpty();

    }



    public static boolean isBlank(String str) {

        return str == null || str.trim().isEmpty();

    }



    // 新增方法：将字符串反转

    public static String reverse(String str) {

        if (str == null) {

            return null;

        }

        return new StringBuilder(str).reverse().toString();

    }



    // 新增方法：判断字符串是否为整数

    public static boolean isInteger(String str) {

        try {

            Integer.parseInt(str);

            return true;

        } catch (NumberFormatException e) {

            return false;

        }

    }

}

6. 添加新的异常类型：

添加更多异常类型，对不同的业务抛出不同的异常，每种异常都要单独去处理

public class CustomException extends RuntimeException {

    // 构造函数

    public CustomException(String message) {

        super(message);

    }



    // 新增异常类型

    public static class NotFoundException extends CustomException {

        public NotFoundException(String message) {

            super(message);

        }

    }



    public static class ValidationException extends CustomException {

        public ValidationException(String message) {

            super(message);

        }

    }

}

// 示例：添加不同类型的异常处理

public class ExceptionHandling {

    public void process(int value) {

        try {

            if (value < 0) {

                throw new IllegalArgumentException("Value cannot be negative");

            } else if (value == 0) {

                throw new ArithmeticException("Value cannot be zero");

            } else {

                // 正常处理逻辑

            }

        } catch (IllegalArgumentException e) {

            // 异常处理逻辑

        } catch (ArithmeticException e) {

            // 异常处理逻辑

        }

    }

}

7. 实现更多设计模式：

在项目中运用更多设计模式，也不失为一种合理的方式，比如单例模式、工厂模式、策略模式、适配器模式等各种常用的设计模式。

比如下面这个单例，大大节省了内存空间，虽然它存在线程不安全等问题。

public class SingletonPattern {

    // 单例模式

    private static SingletonPattern instance;



    private SingletonPattern() {

        // 私有构造函数

    }



    public static SingletonPattern getInstance() {

        if (instance == null) {

            instance = new SingletonPattern();

        }

        return instance;

    }



}

还有下面这个策略模式，能避免过多的if-else条件判断，降低代码的耦合性，代码的扩展和维护也变得更加容易。

// 策略接口

interface Strategy {

    void doOperation(int num1, int num2);

}



// 具体策略实现类

class AdditionStrategy implements Strategy {

    @Override

    public void doOperation(int num1, int num2) {

        int result = num1 + num2;

        System.out.println("Addition result: " + result);

    }

}



class SubtractionStrategy implements Strategy {

    @Override

    public void doOperation(int num1, int num2) {

        int result = num1 - num2;

        System.out.println("Subtraction result: " + result);

    }

}



// 上下文类

class Context {

    private Strategy strategy;



    public Context(Strategy strategy) {

        this.strategy = strategy;

    }



    public void executeStrategy(int num1, int num2) {

        strategy.doOperation(num1, num2);

    }

}



// 测试类

public class StrategyPattern {

    public static void main(String[] args) {

        int num1 = 10;

        int num2 = 5;



        // 使用加法策略

        Context context = new Context(new AdditionStrategy());

        context.executeStrategy(num1, num2);



        // 使用减法策略

        context = new Context(new SubtractionStrategy());

        context.executeStrategy(num1, num2);

    }

}

对比下面这段条件判断，高下立判。

public class Calculator {

    public static void main(String[] args) {

        int num1 = 10;

        int num2 = 5;

        String operation = "addition"; // 可以根据业务需求动态设置运算方式



        if (operation.equals("addition")) {

            int result = num1 + num2;

            System.out.println("Addition result: " + result);

        } else if (operation.equals("subtraction")) {

            int result = num1 - num2;

            System.out.println("Subtraction result: " + result);

        } else if (operation.equals("multiplication")) {

            int result = num1 * num2;

            System.out.println("Multiplication result: " + result);

        } else if (operation.equals("division")) {

            int result = num1 / num2;

            System.out.println("Division result: " + result);

        } else {

            System.out.println("Invalid operation");

        }

    }

}

8. 扩展注释和文档：

如果要增加代码量，写更多更全面的注释也不失为一种方式。

/**

 * 这是一个示例类，用于展示增加代码数量的技巧和示例。

 * 该类包含一个示例变量 value 和示例构造函数 ExampleClass(int value)。

 * 通过示例方法 getValue() 和 setValue(int newValue)，可以获取和设置 value 的值。

 * 这些方法用于展示如何增加代码数量，但实际上并未实现实际的业务逻辑。

 */

public class ExampleClass {



    // 示例变量

    private int value;



    /**

     * 构造函数

     */

    public ExampleClass(int value) {

        this.value = value;

    }



    /**

     * 获取示例变量 value 的值。

     * @return 示范变量 value 的值

     */

    public int getValue() {

        return value;

    }



    /**

     * 设置示例变量 value 的值。

     * @param newValue 新的值，用于设置 value 的值。

     */

    public void setValue(int newValue) {

        this.value = newValue;

    }

}

结语

哪怕是以代码量算工资，咱也得写出高质量的代码，合理合法合情的赚票子。

背景

小盟 AI 助手项目中需要服务端把 AI 模型回调回来内容，实时推送到客户端，展示给用户；整个流程需要一个能够快速支持上线的服务端推送方案。经过对现有的一些服务端推送方案进行调研，并结合项目的周期、实现成本、用户体验等多方综合考量，最终选择了 Server-Sent Events（SSE）方案进行实践。

首先服务端推送，是一种允许应用服务器主动将信息发送到客户端的能力，为客户端提供了实时的信息更新和通知，增强了用户体验。

服务端推送主要基于以下几个诉求：

（1）实时通知：在很多情况下，用户期望实时接收到应用的通知，如新消息提醒、活动提醒等。

（2）节省资源：如果没有服务端推送，客户端需要通过轮询的方式来获取新信息，会造成客户端、服务端的资源损耗。通过服务端推送，客户端只需要在收到通知时做出响应，大大减少了资源的消耗。

（3）增强用户体验：通过服务端推送，应用可以针对特定用户或用户群发送有针对性的内容，如优惠活动、个性化推荐等。这有助于提高用户对应用的满意度和黏性。

方案对比

轮询： 是一种较为传统的方式，客户端定时地向服务端发送请求，询问是否有新数据。服务端只需要检查数据状态，然后将结果返回给客户端。轮询的优点是实现简单，兼容性好；缺点是可能产生较大的延迟，且对服务端资源消耗较高。

长轮询（Long Polling）： 轮询的改进版。客户端向服务器发送请求，服务器收到请求后，如果有新的数据，立即返回给客户端；如果没有新数据，服务器会等待一定时间（比如30秒超时时间），在这段时间内，如果有新数据，就返回给客户端，否则返回空数据。客户端处理完服务器返回的响应后，再次发起新的请求，如此反复。长轮询相较于传统的轮询方式减少了请求次数，但仍然存在一定的延迟。   

WebSocket： 一种双向通信协议，同时支持服务端和客户端之间的实时交互。WebSocket 是基于 TCP 的长连接，和HTTP 协议相比，它能实现轻量级的、低延迟的数据传输，非常适合实时通信场景，主要用于交互性强的双向通信。

SSE： 是一种基于 HTTP 协议的推送技术。服务端可以使用 SSE 来向客户端推送数据，但客户端不能通过 SSE 向服务端发送数据。相较于 WebSocket，SSE 更简单、更轻量级，但只能实现单向通信。

小盟 AI 助手项目需要快速上线且保证要用户较好的使用体验。鉴于 SSE 技术的轻量、实现简单、不增加额外的资源成本；当前业务场景也只需要服务端到用户端的单向的字符推送。非常适合项目需要。所以决定使用 SSE 来实现内容推送。****

深入 SSE

SSE 服务端推送，它基于 HTTP 协议，易于实现和部署，特别适合那些需要服务器主动推送信息、客户端只需接收数据的场景。有以下特点：

1、简单：基于 HTTP，无须额外的协议或者类库支持。主流浏览器都支持。

2、事件流：使用"事件流"（Event Stream）将数据从服务器发送到客户端。每个事件都可以包含一个事件标识符、事件类型和数据字段。客户端可以根据这些信息来解析和处理接收到的数据。

3、自动重连：意外断开时会自动尝试重新连接。可以确保了在网络故障或连接中断后能够及时恢复通信，为用户提供连续的数据流。重连时会在 HTTP 头中的Last_Event_ID 带上上一次的数据 ID，便于服务端返回后续数据。

4、单向推送：只能从服务端推送数据到客户端。

SSE 消息体介绍：

SSE消息体示例：

服务端主要使用 Spring，其对 SSE 主要提供了两种支持：

• Spring WebMVC：传统的基于 Servlet 的同步阻塞编程模型，即 同步模型 Web 框架。


• Spring WebFlux：异步非阻塞的响应式编程模型，即 异步模型 Web 框架。          

项目基于springboot，所以选择使用前者实现。SseEmitter emitter = new SseEmitter(); 一句代码就可以建立一个 SSE 连接。

实践

后端实现

建立一个SseEmitterManger，统一管理当前服务 SSE 连接的创建、释放以及数据推送。结合 Redis 缓存可实现集群环境 SSE 连接的管理。

核心逻辑如下：

• 连接池维护，设定一个上限，避免过大，导致内存问题。

static final Map<String, SseEmitter> sseCache =     new ConcurrentHashMap<>(300)          

• 建立SSE连接，为每个连接建立一个唯一的MsgId，用来维护SSE连接与客户端的关系了；在 Redis 缓存中存入MsgId和当前机器节点的IP和Port，这样可以找到SSE 连接所在的服务结点，然后通过 HTTP 请求转发需要发送的数据到对应的服务节点上进行处理。

sse = new SseEmitter()sseId = "sse_xxx";redisKey= "aisse:" + bosId + "_" + wid ipPort = "10.10.10.10:8080"redis.hset(redisKey, msgId, ipPort)sseCache.put(msgId, sseEmitter);

• 获取持有连接的 pod ipPort；根据 IP 发起请求。

ipPort = redisUtil.hashGet(redisKey, msgId)

• 获取当前服务结点的SSE连接，发送数据。

sseEmitter = sseCache.get(msgId)sseEmitter.send(msgJson)          

• 释放SSE连接

SseEmitter sseEmitter = sseCache.get(msgId);sseEmitter.complete();sseCache.remove(msgId);redisUtil.hashDel(redisKey, msgId);

**核心流程图如下： **  

需要注意的是开启 SSE 连接接口的整个链路都要支持长连接。例如使用 Nginx 则要开启长连接的配置：

• keepalive 用于控制可连接整个 upstream servers 的 HTTP 长连接的个数，即控制总数。


• proxy_http_verion 用于控制代理后端链接时使用的 HTTP 版本，默认为 1.0。要想使用长连接，必须配置为 1.1。


• proxy_set_header 需要设置为 Connection ""，否则则发往 upstream servers 的请求中，Connection header 的值将为close，导致无法建立长连接。   

http {        upstream keepAliveService {            server 10.10.131.149:8080;            keepalive 20;        }            server {            listen 80;            server_name keepAliveService;            location /keep-alive/hello {                proxy_http_version 1.1;                proxy_set_header Connection "";                proxy_pass http://keepAliveService;            }        }}

**前端实现 **  

前端可以使用组件 @microsoft/fetch-event-source 来实现。

npm i @microsoft/fetch-event-source

import { fetchEventSource } from '@microsoft/fetch-event-source';let controller = new AbortController();  let eventSource = fetchEventSource('apiUrl', {  method: 'POST',  headers: {    'Content-Type': 'application/json',    'token': '....'  },  signal: controller.signal,  body: JSON.stringify({    ... // 传参  }),  onopen() {    // 建立连接  },  onmessage(event) {    // 接收信息    // 成功之后满足某些条件可以使用AbortController关闭连接        controller.abort()        eventSource?.close && eventSource.close();  },  onerror() {    // 服务异常        controller.abort()        eventSource?.close && eventSource.close();  },  onclose() {    // 服务关闭  },})

总结

SSE 轻量级的服务端单向推送技术；具有支持跨域、使用简单、支持自动重连等特点。相对于 WebSocket 更加轻量级，如果需求场景客户端和服务端单向通信，那么 SSE 是一个不错的选择。

是的, 你没听错! 网络开发中无处不在的数据交换格式JSON, 可能会拖慢你的应用程序. 在这个速度和响应速度至上的世界里, 检查 JSON 的性能影响至关重要, 而我们对此却常常忽略. 在本博客中, 我们将深入探讨 JSON 成为应用程序瓶颈的原因, 并探索更快的替代方案和优化技术, 以确保你的应用程序以最佳状态运行.

JSON 是什么? 为何我要关注这个问题?

JSON 教程 | w3resource

JSON是JavaScript Object Notation的缩写, 是一种轻量级数据交换格式, 已成为Web应用中传输和存储数据的首选. 它的简洁性和人类可读格式使人类和机器都能轻松使用. 但是, 为什么要在Web开发项目中关注 JSON 呢?

JSON 是应用中数据的粘合剂. 它是服务器和客户端之间进行数据通信的语言, 也是数据库和配置文件中存储数据的格式.

JSON 的流行以及人们使用它的原因…

JSON 在Web开发领域的受欢迎程度怎么强调都不为过. 它已成为数据交换的事实标准, 这其中有几个令人信服的原因:

它易于使用!

鉴于这些优势, 难怪全球的开发人员都依赖 JSON 来满足他们的数据交换需求. 然而, 随着我们在本博客的深入探讨, 我们将发现与 JSON 相关的潜在性能挑战, 以及如何有效解决这些挑战.

速度需求

🚀🚀🚀

应用的速度和响应的重要性

在当今快节奏的数字环境中, 应用的速度和响应能力是不可或缺的. 用户希望在Web和移动应用中即时获取信息, 快速交互和无缝体验. 对速度的这种要求是由以下几个因素驱动的:

JSON 会拖慢我们的应用吗?

现在, 让我们来讨论核心问题: JSON 是否会拖慢我们的应用?

如前所述, JSON 是一种非常流行的数据交换格式. 它灵活, 易用, 并得到广泛支持. 然而, 这种广泛的应用并不意味着它不会面临性能挑战.

在某些情况下, JSON 可能是导致应用慢的罪魁祸首. 解析 JSON 数据的过程, 尤其是在处理大型或复杂结构时, 可能会耗费宝贵的毫秒时间. 此外, 低效的序列化和反序列化也会影响应用的整体性能.

在接下来的内容中, 我们将探讨 JSON 成为应用瓶颈的具体原因, 更重要的是, 探讨如何缓解这些问题. 在深入探讨的过程中, 请记住我们的目标不是诋毁 JSON, 而是了解其局限性并发现优化其性能的策略, 以追求更快, 反应更灵敏的应用.

LinkedIn将Protocal Buffers与Rest.li集成以提高微服务性能| LinkedIn工程

JSON 为什么会变慢

尽管 JSON 被广泛使用, 但它也难逃性能挑战. 让我们来探究 JSON 可能会变慢的原因, 并理解为什么 JSON 并不总是数据交换的最佳选择.

1. 解析带来的开销

当 JSON 数据到达应用时, 它必须经过解析过程才能转换成可用的数据结构. 解析过程可能相对较慢, 尤其是在处理大量或深度嵌套的 JSON 数据时.

2. 序列化和反序列化

JSON 要求在从客户端向服务器发送数据时进行序列化(将对象编码为字符串), 并在接收数据时进行反序列化(将字符串转换回可用对象). 这些步骤会带来开销, 影响应用的整体速度.

在微服务架构的世界里, JSON 通常用于在服务之间传递消息. 但是, 很关键的是, 我们必须认识到, JSON 消息需要序列化和反序列化, 这两个过程会带来巨大的开销.

在有大量微服务不断通信的场景中, 这种开销可能会增加, 并有可能使应用变慢, 以至于影响用户体验.

我们面临的第二个挑战是, 由于 JSON 的文本性质, 序列化和反序列化的延迟和吞吐量都不理想.
— LinkedIn

序列化和反序列化

3. 字符串操作

JSON 基于文本, 在连接和解析等操作中严重依赖字符串操作. 与处理二进制数据相比, 处理字符串的速度会慢一些.

4. 缺乏数据类型

JSON 的数据类型(如字符串, 数字, 布尔值)非常有限. 复杂的数据结构可能需要效率较低的表示法, 从而导致内存使用量增加和处理速度减慢.

5. 冗余

JSON 的人类可读性设计可能会导致冗余. 不需要的键和重复的结构增加了有效载荷的大小, 导致数据传输时间延长.

第一个挑战是 JSON 是一种文本格式, 往往比较冗余. 这导致网络带宽使用量增加, 更高的延迟, 效果并不理想.
— LinkedIn

6. 不支持二进制

JSON 缺乏对二进制数据的本地支持. 在处理二进制数据时, 开发人员通常需要将其编解码为文本, 而这可能会降低效率.

7. 深度嵌套

在某些情况下, JSON 数据可能是深嵌套的, 需要递归解析和遍历. 这种计算复杂性会降低应用的运行速度, 尤其是在没有优化的情况下.

JSON的替代方案

虽然 JSON 是一种通用的数据交换格式, 但由于其在某些情况下的性能限制, 人们开始探索更快的替代格式. 让我们深入探讨其中的一些替代方案, 了解何时以及为何选择它们:

1. Protocol Buffers(protobuf)

Protocal Buffers通常被称为protobuf, 是由谷歌开发的一种二进制序列化格式. 它的设计宗旨是高效, 紧凑和快速. Protobuf 的二进制性质使其在序列化和反序列化方面的速度明显快于 JSON.

• 何时选择: 当你需要高性能的数据交换时, 尤其是在微服务架构, 物联网应用或网络带宽有限的情况下, 请考虑使用Protobuf.

GitHub - vaishnav-mk/protobuf-example

2. MessagePack

MessagePack 是另一种二进制序列化格式, 以速度快, 结构紧凑而著称. 它比 JSON 更有效率, 同时与各种编程语言保持兼容.

• 何时选择: 当你需要在速度和跨语言兼容性之间取得平衡时, MessagePack 是一个不错的选择. 它适用于实时应用和对减少数据大小至关重要的情况.

3. BSON (二进制 JSON)

BSON 或二进制 JSON 是一种从 JSON 衍生出来的二进制编码格式. 它保留了 JSON 的灵活性, 同时通过二进制编码提高了性能. BSON 常用于 MongoDB 等数据库.

• 何时选择: 如果你正在使用 MongoDB, 或者需要一种格式来弥补 JSON 和二进制效率之间的差距, 那么 BSON 是一个很有价值的选择.

4. Apache Avro

Apache Avro 是一个数据序列化框架, 专注于提供一种紧凑的二进制格式. 它基于schema, 可实现高效的数据编解码.

• 何时选择: Avro 适用于schema演进非常重要的情况, 如数据存储, 以及需要在速度和数据结构灵活性之间取得平衡的情况.

与 JSON 相比, 这些替代方案提供了不同程度的性能改进, 具体选择取决于你的具体使用情况. 通过考虑这些替代方案, 你可以优化应用的数据交换流程, 确保将速度和效率放在开发工作的首位.

JSON, Protobufs, MessagePack, BSON 和 Avro 之间的差异

每个字节都很重要: 优化数据格式

在效率和速度至上的数据交换世界中, 数据格式的选择会产生天壤之别. 本节将探讨从简单的 JSON 数据表示到更高效的二进制格式(如 Protocol Buffers, MessagePack, BSON 和 Avro)的过程. 我们将深入探讨每种格式的细微差别, 并展示为什么每个字节都很重要.

开始: JSON 数据

我们从简单明了的 JSON 数据结构开始. 下面是我们的 JSON 数据示例片段:

{

  "id": 1,                                 // 14 bytes

  "name": "John Doe",                      // 20 bytes

  "email": "johndoe@example.com",          // 31 bytes

  "age": 30,                               // 9 bytes

  "isSubscribed": true,                    // 13 bytes

  "orders": [                              // 11 bytes

    {                                      // 2 bytes

      "orderId": "A123",                   // 18 bytes

      "totalAmount": 100.50                // 20 bytes

    },                                     // 1 byte

    {                                      // 2 bytes

      "orderId": "B456",                   // 18 bytes

      "totalAmount": 75.25                 // 19 bytes

    }                                      // 1 byte

  ]                                        // 1 byte

}                                          // 1 byte

JSON 总大小: ~ 139 字节

虽然 JSON 用途广泛且易于使用, 但它也有一个缺点, 那就是它的文本性质. 每个字符, 每个空格和每个引号都很重要. 在数据大小和传输速度至关重要的情况下, 这些看似微不足道的字符可能会产生重大影响.

效率挑战: 使用二进制格式减小尺寸

现在, 让我们提供其他格式的数据表示并比较它们的大小:

Protocol Buffers (protobuf):

syntax = "proto3";



message User {

  int32 id = 1;

  string name = 2;

  string email = 3;

  int32 age = 4;

  bool is_subscribed = 5;

  repeated Order orders = 6;



  message Order {

    string order_id = 1;

    float total_amount = 2;

  }

}

0A 0E 4A 6F 68 6E 20 44 6F 65 0C 4A 6F 68 6E 20 44 6F 65 65 78 61 6D 70 6C 65 2E 63 6F 6D 04 21 00 00 00 05 01 12 41 31 32 33 03 42 DC CC CC 3F 05 30 31 31 32 34 34 35 36 25 02 9A 99 99 3F 0D 31 02 42 34 35 36 25 02 9A 99 99 3F

Protocol Buffers 总大小: ~ 38 bytes

MessagePack:

(注意:MessagePack 是一种二进制格式, 此处的表示法非人工可读.)

二进制表示(十六进制):

a36a6964000000000a4a6f686e20446f650c6a6f686e646f65406578616d706c652e636f6d042100000005011241313302bdcccc3f0530112434353625029a99993f

MessagePack 总大小: ~34 字节

BSON (二进制 JSON):

(注意:BSON 是一种二进制格式, 此处的表示法非人工可读.)

二进制表示法 (十六进制):

3e0000001069640031000a4a6f686e20446f6502656d61696c006a6f686e646f65406578616d706c652e636f6d1000000022616765001f04370e4940

BSON 总大小: ~ 43 字节

Avro:

(注: Avro使用schema, 因此数据与schema信息一起编码.)

二进制表示法 (十六进制):

0e120a4a6f686e20446f650c6a6f686e646f65406578616d706c652e636f6d049a999940040a020b4108312e3525312e323538323539

Avro 总大小: ~ 32 字节

(这些替代方案的实际字节数可能会有所不同, 提供这些数字只是为了让大家有个大致的了解.)

现在你可能会感到奇怪, 为什么我们的程序会有这么多的字节数?

现在你可能想知道为什么有些格式输出的是二进制, 但它们的大小却各不相同. Avro, MessagePack 和 BSON 等二进制格式具有不同的内部结构和编码机制, 这可能导致二进制表示法的差异, 即使它们最终表示的是相同的数据. 下面简要介绍一下这些差异是如何产生的:

1. Avro:

• Avro 使用schema对数据进行编码, 二进制表示法中通常包含该schema.


• Avro 基于schema的编码可提前指定数据结构, 从而实现高效的数据序列化和反序列化.


• Avro 的二进制格式设计为自描述格式, 这意味着schema信息包含在编码数据中. 这种自描述性使 Avro 能够保持不同版本数据模式之间的兼容性.

2. MessagePack:

• MessagePack 是一种二进制序列化格式, 直接对数据进行编码, 不包含schema信息.


• 它使用长度可变的整数和长度可变的字符串的紧凑二进制表示法, 以尽量减少空间使用.


• MessagePack 不包含schema信息, 因此更适用于schema已预先知道并在发送方和接收方之间共享的情况.

3. BSON:

• BSON 是 JSON 数据的二进制编码, 包括每个值的类型信息.


• BSON 的设计与 JSON 紧密相连, 但它增加了二进制数据类型, 如 JSON 缺乏的日期和二进制数据.


• 与 MessagePack 一样, BSON 不包含schema信息.

这些设计和编码上的差异导致了二进制表示法的不同:

• Avro 包含模式信息并具有自描述性, 这导致二进制大小稍大, 但提供了schema兼容性.


• MessagePack 因其可变长度编码而高度紧凑, 但缺乏模式信息, 因此适用于已知模式的情况.


• BSON 与 JSON 关系密切, 包含类型信息, 与 MessagePack 等纯二进制格式相比, 会增加大小.

总之, 这些差异源于每种格式的设计目标和功能. Avro 优先考虑schema兼容性, MessagePack 注重紧凑性, 而 BSON 则在保持类似 JSON 结构的同时增加了二进制类型. 格式的选择取决于具体的使用情况和要求, 如schema兼容性, 数据大小和易用性.

优化 JSON 性能

JSON 虽然用途广泛, 在Web开发中被广泛采用, 但在速度方面也存在挑战. 这种格式的人类可读性会导致数据负载较大, 处理时间较慢. 因此, 问题出现了: 我们能够怎样优化JSON以使得它更快更高效? 在本文中, 我们将探讨可用于提高 JSON 性能的实用策略和优化方法, 以确保 JSON 在提供应用所需的速度和效率的同时, 仍然是现代 Web 开发中的重要工具.

以下是一些优化 JSON 性能的实用技巧以及代码示例和最佳实践:

1. 最小化数据大小:

• 使用简短, 描述性的键名: 选择简洁但有意义的键名, 以减小 JSON 对象的大小.

// Inefficient

{

  "customer_name_with_spaces": "John Doe"

}



// Efficient

{

  "customerName": "John Doe"

}

• 尽可能缩写:  在不影响清晰度的情况下, 考虑对键或值使用缩写.

// Inefficient

{

  "transaction_type": "purchase"

}

 

// Efficient

{

  "txnType": "purchase"

}

2. 明智地使用数组:

• 最小化嵌套: 避免深度嵌套数组, 因为它们会增加解析和遍历 JSON 的复杂性.

// Inefficient

{

  "order": {

    "items": {

      "item1": "Product A",

      "item2": "Product B"

    }

  }

}



// Efficient

{

  "orderItems": ["Product A", "Product B"]

}

3. 优化数字表示:

• 尽可能使用整数:  如果数值可以用整数表示, 请使用整数而不是浮点数.

// Inefficient

{

  "quantity": 1.0

}



// Efficient

{

  "quantity": 1

}

4. 消除冗余:

• 避免重复数据: 通过引用共享值来消除冗余数据.

// Inefficient

{

  "product1": {

    "name": "Product A",

    "price": 10

  },

  "product2": {

    "name": "Product A",

    "price": 10

  }

}



// Efficient

{

  "products": [

    {

      "name": "Product A",

      "price": 10

    },

    {

      "name": "Product B",

      "price": 15

    }

  ]

}

5. 使用压缩:

• 使用压缩算法:  如何可行的话, 使用压缩算法, 比如Gzip 或者Brotli, 以在传输过程中减少JSON负载大小.

// Node.js example using zlib for Gzip compression

const zlib = require('zlib');



const jsonData = {

  // Your JSON data here

};



zlib.gzip(JSON.stringify(jsonData), (err, compressedData) => {

  if (!err) {

    // Send compressedData over the network

  }

});

6. 采用服务器端缓存:

• 缓存 JSON 响应:  实施服务器端缓存, 以便高效地存储和提供 JSON 响应, 减少重复数据处理的需要.

7. 剖析与优化:

• 剖析性能:  使用剖析工具找出 JSON 处理代码中的瓶颈, 然后优化这些部分.

请记住, 你实施的具体优化措施应符合应用的要求和限制.

真实世界的优化: 在实践中加速

在这一部分, 我们将深入探讨现实世界中遇到 JSON 性能瓶颈并成功解决的应用和项目. 我们将探讨企业如何解决 JSON 的局限性, 以及这些优化为其应用带来的切实好处. 从 LinkedIn 和 Auth0 这样的知名平台到 Uber 这样的颠覆性科技巨头*, 这些示例为我们提供了宝贵的见解, 让我们了解在尽可能利用 JSON 的多功能性的同时提高速度和响应能力的策略.

1. LinkedIn集成Protocol Buffers:

挑战: LinkedIn 面临的挑战是 JSON 的冗长以及由此导致的网络带宽使用量增加, 从而导致延迟增加.
解决方案: 他们在微服务通信中采用了二进制序列化格式 Protocol Buffers 来取代 JSON.
影响: 这一优化将延迟降低了60%, 提高了 LinkedIn 服务的速度和响应能力.

2. Uber的H3地理索引:

• 挑战: Uber 使用 JSON 表示各种地理空间数据, 但解析大型数据集的 JSON 会降低其算法的速度.


• 解决方法 他们引入了H3地理索引, 这是一种用于地理空间数据的高效六边形网格系统, 可减少 JSON 解析开销.


• 影响: 这一优化大大加快了地理空间操作, 增强了 Uber 的叫车和地图服务.

3. Slack的消息格式优化:

• 挑战: Slack 需要在实时聊天中传输和呈现大量 JSON 格式的消息, 这导致了性能瓶颈.


• 解决方法 他们优化了 JSON 结构, 减少了不必要的数据, 只在每条信息中包含必要的信息.


• 影响: 这一优化提高了消息渲染速度, 改善了 Slack 用户的整体聊天性能.

4. Auth0的Protocal Buffers实现:

• 挑战: Auth0 是一个流行的身份和访问管理平台, 在处理身份验证和授权数据时面临着 JSON 的性能挑战.


• 解决方案: 他们采用Protocal Buffers来替代 JSON, 以编解码与身份验证相关的数据.


• 影响: 这一优化大大提高了数据序列化和反序列化的速度, 从而加快了身份验证流程, 并增强了 Auth0 服务的整体性能.

这些真实案例表明, 通过优化策略解决 JSON 的性能难题, 可对应用的速度, 响应和用户体验产生重大积极影响. 它们强调了在各种应用场景中考虑使用替代数据格式和高效数据结构来克服 JSON 相关缓慢的问题的重要性.

总结一下

在开发领域, JSON 是数据交换不可或缺的通用工具. 其人类可读格式和跨语言兼容性使其成为现代应用的基石. 然而, 正如我们在本文中所探讨的, JSON 的广泛应用并不能使其免于性能挑战.

我们在优化 JSON 性能的过程中获得的主要启示是显而易见的:

• 性能至关重要: 在当今的数字环境中, 速度和响应速度至关重要. 用户希望应用能够快如闪电, 即使是微小的延迟也会导致不满和机会的丧失.


• 尺寸至关重要: 数据有效载荷的大小会直接影响网络带宽的使用和响应时间. 减少数据大小通常是优化 JSON 性能的第一步.


• 替代格式: 当效率和速度至关重要时, 探索其他数据序列化格式, 如Protocal Buffers, MessagePack, BSON 或 Avro.


• 真实世界案例: 从企业成功解决 JSON 速度变慢问题的实际案例中学习. 这些案例表明, 优化工作可以大幅提高应用的性能.

在继续构建和增强Web应用时, 请记住要考虑 JSON 对性能的影响. 仔细设计数据结构, 选择有意义的键名, 并在必要时探索其他序列化格式. 这样, 你就能确保你的应用在速度和效率方面不仅能满足用户的期望, 而且还能超越用户的期望.

在不断变化的Web开发环境中, 优化 JSON 性能是一项宝贵的技能, 它能让你的项目与众不同, 并确保你的应用在即时数字体验时代茁壮成长.

今天想和大家分享的一个技术是 SSE 流式传输 。如标题所言，通过 SSE 流式传输的方式可以让我们不再通过轮询的方式获取服务端返回的结果，进而提升前端页面的性能。

对于需要轮询的业务场景来说，采用 SSE 确实是一个更好的技术方案。

接下来，我将从 SSE 的概念、与 Websocket 对比、SSE 应用场景多个方面介绍 SSE 流式传输，感兴趣的同学一起来了解下吧！

什么是 SSE 流式传输

SSE 全称为 Server-sent events , 是一种基于 HTTP 协议的通信技术，允许服务器主动向客户端（通常是Web浏览器）发送更新。

它是 HTML5 标准的一部分，设计初衷是用来建立一个单向的服务器到客户端连接，使得服务器可以实时地向客户端发送数据。

这种服务端实时向客户端发送数据的传输方式，其实就是流式传输。

我们在与 ChatGPT 交互时，可以发现 ChatGPT 的响应总是间断完成。细扒 ChatGPT 的网络传输模式，可以发现，用的也是流式传输。

SSE 流式传输的好处

在 SSE 技术出现之前，我们习惯把需要等待服务端返回的过程称为长轮询。

长轮询的实现其实也是借助 http 请求来完成，一个完整的长轮询过程如下图所示：

从图中可以发现，长轮询最大的弊端是当服务端响应请求之前，客户端发送的所有请求都不会被受理。并且服务端发送响应的前提是客户端发起请求。

前后端通信过程中，我们常采用 ajax 、axios 来异步获取结果，这个过程，其实也是长轮询的过程。

而同为采用 http 协议通信方式的 SSE 流式传输，相比于长轮询模式来说，优势在于可以在不需要客户端介入的情况下，多次向客户端发送响应，直至客户端关闭连接。

这对于需要服务端实时推送内容至客户端的场景可方便太多了！

SSE 技术原理

1. 参数设置

前文说到，SSE 本质是一个基于 http 协议的通信技术。

因此想要使用 SSE 技术构建需要服务器实时推送信息到客户端的连接，只需要将传统的 http 响应头的 contentType 设置为 text/event-stream 。

并且为了保证客户端展示的是最新数据，需要将 Cache-Control 设置为 no-cache 。

在此基础上，SSE 本质是一个 TCP 连接，因此为了保证 SSE 的持续开启，需要将 Connection 设置为 keep-alive 。

Content-Type: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

完成了上述响应头的设置后，我们可以编写一个基于 SSE 流式传输的简单 Demo 。

2. SSE Demo

服务端代码：

const express = require('express');

const app = express();

const PORT = 3000;



app.use(express.static('public'));



app.get('/events', function(req, res) {

    res.setHeader('Content-Type', 'text/event-stream');

    res.setHeader('Cache-Control', 'no-cache');

    res.setHeader('Connection', 'keep-alive');



    let startTime = Date.now();



    const sendEvent = () => {

        // 检查是否已经发送了10秒

        if (Date.now() - startTime >= 10000) {

            res.write('event: close\ndata: {}\n\n'); // 发送一个特殊事件通知客户端关闭

            res.end(); // 关闭连接

            return;

        }



        const data = { message: 'Hello World', timestamp: new Date() };

        res.write(`data: ${JSON.stringify(data)}\n\n`);



        // 每隔2秒发送一次消息

        setTimeout(sendEvent, 2000);

    };



    sendEvent();

});



app.listen(PORT, () => {

    console.log(`Server running on http://localhost:${PORT}`);

});

客户端代码：

<!DOCTYPE html>

<html lang="en">



<head>

    <meta charset="UTF-8">

    <title>SSE Example</title>

</head>



<body>

    <h1>Server-Sent Events Example</h1>

    <div id="messages"></div>



    <script>

        const evtSource = new EventSource('/events');

        const messages = document.getElementById('messages');



        evtSource.onmessage = function(event) {

            const newElement = document.createElement("p");

            const eventObject = JSON.parse(event.data);

            newElement.textContent = "Message: " + eventObject.message + " at " + eventObject.timestamp;

            messages.appendChild(newElement);

        };

    </script>

</body>

</html>

当我们在浏览器中访问运行在 localhost: 3000 端口的客户端页面时，页面将会以 流式模式 逐步渲染服务端返回的结果：

需要注意的是，为了保证使用 SSE 通信协议传输的数据能被客户端正确的接收，服务端和客户端在发送数据和接收数据应该遵循以下规范：

服务端基本响应格式

SSE 响应主要由一系列以两个换行符分隔的事件组成。每个事件可以包含以下字段：

data：事件的数据。如果数据跨越多行，每行都应该以data:开始。

id：事件的唯一标识符。客户端可以使用这个ID来恢复事件流。

event：自定义事件类型。客户端可以根据不同的事件类型来执行不同的操作。

retry：建议的重新连接时间（毫秒）。如果连接中断，客户端将等待这段时间后尝试重新连接。

字段之间用单个换行符分隔，而事件之间用两个换行符分隔。

客户端处理格式

客户端使用 EventSource 接口监听 SSE 消息：

const evtSource = new EventSource('path/to/sse');

evtSource.onmessage = function(event) {

    console.log(event.data); // 处理收到的数据

};

SSE 应用场景

SSE 作为基于 http 协议由服务端向客户端单向推送消息的通信技术，对于需要服务端主动推送消息的场景来说，是非常适合的：

SSE 兼容性

可以发现，除了 IE 和低版本的主流浏览器，目前市面上绝大多数浏览器都支持 SSE 通信。

SSE 与 WebSocket 对比

看完 SSE 的使用方式后，细心的同学应该发现了：

SSE 的通信方式和 WebSocket 很像啊，而且 WebSocket 还支持双向通信，为什么不直接使用 WebSocket ？

下表展示了两者之间的对比：

可以发现，SSE 与 WebSocket 各有优缺点，对于需要客户端与服务端高频交互的场景，WebSocket 确实更适合；但对于只需要服务端单向数据传输的场景，SSE 确实能耗更低，且不需要客户端感知。

参考文档

developer.mozilla.org/zh-CN/docs/…

早上刚来，就看到仓库那边不停发消息说，我们的某个功能用不了了。赶紧放下早餐加紧看。

原来是调的一个三方接口报错了：

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

	at sun.security.ssl.Alert.createSSLException(Alert.java:131)

	at sun.security.ssl.TransportContext.fatal(TransportContext.java:353)

	at sun.security.ssl.TransportContext.fatal(TransportContext.java:296)

	at sun.security.ssl.TransportContext.fatal(TransportContext.java:291)

	at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:652)

	at sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:471)

	at sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:367)

	at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:376)

	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)

	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)

	at sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)

	at sun.security.ssl.SSLTransport.decode(SSLTransport.java:154)

	at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1279)

	at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1188)

	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:401)

	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:373)

查看原因：

由于JVM默认信任证书不包含该目标网站的SSL证书，导致无法建立有效的信任链接。

奥...原来是他们把接口从http改为了https,导致我们获取数据报错了。再看看他们的证书，奥...新的。

好了，看看我们的逻辑，这其实是一个获取对方生成的PDF文件的接口

PdfReader pdfReader = new PdfReader(url);

url就是他们给的链接，是这行代码报的错。这时候，开始研究，在网上扒拉，找到了初版方案

尝试1

写一个程序专门获取安全证书，这代码有点长，全贴出来影响阅读。我给扔我hithub上了github.com/lukezhao6/I… 将这个文件贴到本地，执行javac InstallCert.java将其进行编译

编译完长这样：

然后再执行java InstallCert http://www.baidu.com （这里我们用百度举例子，实际填写的就是你想要获取证书的目标网站）

报错不用怕，因为它会去检查目标服务器的证书，如果出现了SSLException,表示证书可能存在问题，这时候会把异常信息打印出来。

在生成的时候需要输入一个1

这样，我们需要的证书文件就生成好了

这时候，将它放入我们本地的 jdk的lib\security文件夹内就行了

重启，这时候访问是没有问题了。阶段性胜利。

但是，但是。一顿操作下来，对于测试环境的docker，还有生产环境貌似不能这么操作。 放这个证书文件比较费事。

那就只能另辟蹊径了。

尝试2

搜到了，还有两种方案。

1.通过System.setProperty("javax.net.ssl.trustStore", "你的jssecacerts证书路径");

2.程序启动命令-Djavax.net.ssl.trustStore=你的jssecacerts证书路径 -Djavax.net.ssl.trustStorePassword=changeit

我尝试了第一种，System.setProperty可以成功，但是读不到文件，权限什么的都是ok的。
检查了蛮多地方

• 路径格式问题


• 文件是否存在


• 文件权限


• 信任库密码


• 系统属性优先级

貌似都是没问题的，但肯定又是有问题的，因为没起作用。但是想着这样的接口有4个，万一哪天其他三个也改了，我又得来一遍。所以就算研究出来了，还是不能稳坐钓鱼台。有没有一了百了的方法嘞。

尝试3

还真找到了：这个错是因为对方网站的证书不被java信任么，那咱不校验了，直接全部信任。这样就算其他接口改了，咱也不愁。而且这个就是获取pdf，貌似安全性没那么重。那就开搞。

代码贴在了下方，上边的大概都能看懂吧，下方的我加了注释。

URL console = new URL(url);

HttpURLConnection conn = (HttpURLConnection) console.openConnection();

if (conn instanceof HttpsURLConnection)  {

    SSLContext sc = SSLContext.getInstance("SSL");

    sc.init(null, new TrustManager[]{new TrustAnyTrustManager()}, new java.security.SecureRandom());

    ((HttpsURLConnection) conn).setSSLSocketFactory(sc.getSocketFactory());

    ((HttpsURLConnection) conn).setHostnameVerifier(new TrustAnyHostnameVerifier());

}

conn.connect();

InputStream inputStream = conn.getInputStream();

PdfReader pdfReader = new PdfReader(inputStream);

inputStream.close();

conn.disconnect();

private static class TrustAnyTrustManager implements X509TrustManager {

    //这个方法用于验证客户端的证书。在这里，方法体为空，表示不对客户端提供的证书进行任何验证。

    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {

    }

    //这个方法用于验证服务器的证书。同样，方法体为空，表示不对服务器提供的证书进行任何验证。

    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {

    }

    //这个方法返回一个信任的证书数组。在这里，返回空数组，表示不信任任何证书，也就是对所有证书都不做任何信任验证。

    public X509Certificate[] getAcceptedIssuers() {

        return new X509Certificate[]{};

    }

}

//这个方法用于验证主机名是否可信。在这里，无论传入的主机名是什么，方法始终返回 true，表示信任任何主机名。这就意味着对于 SSL 连接，不会对主机名进行真实的验证，而是始终接受所有主机名。

private static class TrustAnyHostnameVerifier implements HostnameVerifier {

    public boolean verify(String hostname, SSLSession session) {

        return true;

    }

}

解决了解决了，这样改算是个比较不错的方案了吧。

背景

目前笔者所在的小公司的前端项目还是推送到git仓库后由另一名后端拉取代码到他电脑上再build，然后再手动同步到服务器上，比较麻烦，而且出现一个bug就要立即修复，笔者一天要说100次“哥，代码更新了，打包上传下吧，球球了”，终于我实在受不了了（上传代码的这位哥也受不了了），于是想通过 Jenkins 实现简单的前端项目自动打包部署。

通过 docker 安装 Jenkins

通过 ssh 连接上局域网服务器 192.168.36.2，在 home 目录下新建了一个 Jenkins 文件夹，后续我们的配置文件就放在其中。

 cd

 # 将 Jenkins 相关的文件都放在这里

 mkdir jenkins

 cd jenkins

 

 # 创建 Jenkins 配置文件存放的地址，并赋予权限

 mkdir jenkins_home

 chmod -R 777 jenkins_home

 

 pwd

 # /root/jenkins

创建docker-compose.yml：

 touch docker-compose.yml

 vim docker-compose.yml

 version: '3'

 services:

   jenkins:

     image: jenkins/jenkins:latest

     container_name: 'jenkins'

     restart: always

     ports:

       - "8999:8080"

     volumes:

       - /root/jenkins/jenkins_home:/var/jenkins_home

Jenkins 启动后会挂在8080端口上，本文笔者将其映射到8999端口，读者可以自行更改。

关键在于将容器中的/var/jenkins_home目录映射到宿主机的/root/jenkins/jenkins_home目录，这一步相当于将 Jenkins 的所有配置都存放在宿主机而不是容器中，这样做的好处在于，后续容器升级、删除、崩溃等情况下，不需要再重新配置 Jenkins。

使用:wq保存后可以开始构建了：

 docker compose up -d

这一步会构建容器并启动，看到如下信息就说明成功了：

 [+] Running 1/1

  ✔ Container  Jenkins   Started           1.3s

查看一下容器是否在运行：

 docker ps

这个时候通过http://192.168.36.2:8999就可以访问 Jenkins 了。

Jenkins 初次配置向导

解锁

第一次打开会出现向导，需要填入管理员密码，获取密码有三种方式：

0. 通过宿主机

    cat /root/jenkins/jenkins_home/secrets/initialAdminPassword
   
    
   
    # 2bf4ca040f624716befd5ea137b70560
   
   

1. 通过 docker 进入容器

    docker exec -it jenkins /bin/bash
   
    
   
    #进入了docker
   
    jenkins@1c151dfc2482:/$ cat /var/jenkins_home/secrets/initialAdminPassword
   
    
   
    # 2bf4ca040f624716befd5ea137b70560
   
   

   与方法一类似，因为目录映射，这两个目录其实是同一个。

2. 通过查看 docker log

    docker logs jenkins
   
   

   会出现一大串，最后能找到密码：

   

填入密码，点击继续。

安装插件

选择安装推荐插件即可。

安装插件可能会非常慢，可以选择换源。

更换 Jenkins 插件源（可选）

有两种方法：

0. 直接输入地址：

   http://192.168.36.2:8999/manage/pluginManager/advanced，在Update Site中填入清华源地址：

    https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
   
   

   点击Submit提交保存，并重启容器。

1. 直接更改配置文件：

   宿主机中操作：

    cd /root/jenkins/jenkins_home
   
    vim hudson.model.UpdateCenter.xml
   
   

   替换其中的地址，然后重启容器即可。

   

创建用户

这一步建议用户名不为 admin ，不然会出现奇怪的问题，比如密码登录不上，需要用上一部的初始密码（2bf4ca040f624716befd5ea137b70560）才能登录。

我这里创建了一个 root 用户（只是名字叫 root，防止用户名太多记不住而已）。

点击保存并完成。

实例配置按需调整即可，直接下一步，Jenkins 就准备就绪了。

至此 Jenkins 安装就算完成了。

安装插件

笔者是一名前端，因此以前端项目为例。

前端项目的打包需要 node 环境，打包完成后通过 ssh 部署到服务器上，并且构建结果通过钉钉机器人推送到群里，因此需要三个插件。

0. NodeJS
1. Publish Over SSH
2. DingTalk（可选）

在 系统管理 -> 插件管理 -> Available plugins 中搜索并安装。

勾选安装后重启，让插件生效。

插件配置

我们安装了三个插件，分别进行配置。

NodeJS

这个插件可以在不同的项目中使用不同的 node 环境，例如 A项目 使用 node14，B项目 使用 node20 这样。

进入 系统管理 -> 全局工具配置 -> NodeJS 安装 （在最下面）

点击新增：

默认的这个使用的是 nodejs.org 的官方源，虽然现在 nodejs.org 的官方源国内访问也还可以，但为了保险起见，笔者还是换成阿里巴巴源。

点击红框里的 X 删除当前安装，在点击新增安装，选择 Install from nodejs.org mirror。

镜像地址填入https://mirrors.aliyun.com/nodejs-release/，版本按需选择，笔者这里选择的是 node20-lts，并且安装了包管理工具 pnpm，如果读者的项目需要别的全局安装的包，也可以写在 Global npm packages to install ，比如 yarn、cnpm 之类的。

记得起一个别名：

配置好后点击保存。

一般来说，在使用 npm 时，需要更改 npm 的源，同样在 Jenkins 中也是可以的。

安装完 NodeJS 插件后，系统设置中会多一项 Managed files

进入后选择左侧的Add a new Config，然后选择 Npm config file，然后点击 Next。

新增一个 NPM Registry，填入阿里巴巴镜像源：http://registry.npmmirror.com。

至此 NodeJS 相关的配置就完成了。

SSH Server

打包后需要通过 SSH 部署到服务器上，因此需要先配置好 SSH 服务器。

打开 系统管理 -> 系统配置 -> Publish over SSH （在最下面）:

然后根据实际情况进行填写：

字段	解释
Name	显示在 Jenkins 中的名称，可随意填写
Hostname	服务器地址，ip 或 域名
Username	SSH 登录的用户名
Remote Directory	SSH 登录后进入的目录，必须是服务器中已经存在的目录，设置好之后所有通过 SSH 上传的文件只能放在这个目录下

这里笔者使用用户名-密码的方式登录 SSH，如果要通过 SSH Key 的方式的话，需要在字段 Path to key 填入 key 文件的地址，或者直接将 key 的内容填入 Key 字段中:

设置好可以通过Test Configuration，测试 SSH 连通性：

出现 Success 代表 SSH 配置成功。

钉钉通知（可选）

如果不需要通过钉钉通知，可以不装 DingTalk 插件，并跳过本节内容。

钉钉部分设置

该功能需要一个钉钉群，并打开钉钉群机器人：

点击添加机器人，选择自定义：

这里笔者的安全设置选择了加签：

将签名保存下来备用。

点击完成后，出现了钉钉机器人的 Webhook 地址。

将地址保存下来备用。

至此钉钉部分的设置就结束了。

Jenkins 部分

打开 系统设置 -> 钉钉 （在最下面的未分类中）:

根据需要配置通知时机：

然后点击机器人-新增：

将刚刚的钉钉机器人的签名和 Webhook 地址填入对应的地方，并点击测试：

此时钉钉机器人也在群中发了消息：

至此钉钉机器人配置完毕。

创建任务（job）

本文中，笔者将以存储在 Git 仓库中的项目为例。

Github 项目

注意，如果想让 Github 项目全自动构建的话，需要你的 Jenkins 能被公网访问到，例如部署在云服务器上，像笔者这样部署在本地局域网中，是无法实现“提交代码 -> 自动构建 -> 自动部署”的，只能实现“提交代码 -> 手动点击开始构建 -> 自动部署”

如果在 Jenkins 新手向导里选择了 安装推荐插件，那么现在就不需要额外安装 Github 相关的插件了，否则的话需要手动安装 Github 相关的插件：

创建项目

选择 Dashboard -> 新建任务：

选择构建一个自由风格的软件项目，点击确定。

General

这部分可以添加钉钉机器人：

源码管理

这里选择 Git：

输入仓库地址：https://github.com/baIder/homepage.git

由于笔者这是一个私有仓库，因此会报错。

在下面的Credentials中，添加一个。

注意，这里的用户名是 Github 用户名，但是密码不是你的 Github 密码，而是你的 Github Access Token！！！

可以在这里创建 Token，需要勾选 admin:repo_hook 、repo 权限。

这里的报错是网络问题，连接 Github 懂得都懂。

分支可以根据实际情况选择。

构建触发器

勾选GitHub hook trigger for GITScm polling，这样在 Git 仓库产生提交时，就会触发构建，属于是真正的核心。

构建环境

勾选 Provide Node & npm bin/ folder to Path

Build Steps

到这里，可以理解为 Jenkins 已经将仓库克隆到本地，并且已经安装好了node、npm、pnpm，接下来就是执行命令：

我们需要执行命令：

 node -v

 pnpm -v

 

 rm -rf node_modules

 rm -rf dist

 

 pnpm install

 pnpm build

这里的pnpm build需要按情况更换为package.json中设定的命令。

构建后操作

经过所有的流程到这里，项目应该已经打包在dist目录下了。现在可以通过 SSH 将打包好的产物上传到服务器上了：

这里的 Source files 字段一定要写成dist/**/**，如果写成dist/*，则只会将第一层的文件上传。

Remove prefix 需要填写，否则会将dist这个目录也上传到服务器上。

Remote directory 是相对于配置 SSH Server 时的 Remote directory 的，本例中就是 /data/sites/homepage 。

Exec command 是文件上传后执行的命令，可以是任何命令，可以是让nginx有权限访问这些数据，重启nginx等等，根据服务器实际情况更改。

当然也可以在 Build Steps 中 build 完成后将 dist 目录打包，然后在通过 SSH 将压缩包上传到服务器，然后在 Exec command 中解压。

至此所有的配置已经完成，保存。

测试

点击左侧的 立即构建：

第一次构建会比较慢，因为需要下载node，安装依赖等等，可以从控制台看到，命令都如期执行了：

构建成功，钉钉机器人也提示了（因为 Github 访问失败的原因，多试了几次）：

笔者已经配置好了nginx，因此可以直接访问网页，查看效果：

通过 Git 提交触发构建

目前虽然构建成功了，但是需要手动点击构建，接下来实现如何将代码提交 Git 后自动触发构建。

打开仓库设置 -> Webhooks 添加一个：

这里的 Payload URL 就是 Jenkins 地址 + /github-webhook，例如笔者的就如图所示。

但是由于笔者的 Jenkins 部署在本地局域网，因此是不行的，Github 肯定是无法访问到笔者的局域网的，有公网地址的读者可以试试，在笔者的阿里云服务器上是没有问题的。所以目前如果是 Github 项目的话，笔者需要提交代码后手动点击 立即构建：

Gitlab 项目

实际上笔者所在公司是在局域网中部署了 Gitlab 的，因此针对 Gitlab 项目的自动化才是核心。

安装 Gitlab 插件：

安装完毕后重启 Jenkins。

获取 Gitlab token

与 Github 的流程类似，也需要在 Gitlab 中创建一个 token：

创建好之后保存 token 备用。

在 Jenkins 中配置 Gitlab

打开 Jenkins -> 系统管理 -> 系统配置 -> Gitlab

这里需要新建一个Credentials，点击下方的添加：

类型选择GitLab API token，将刚刚保存的 token 填入到 API token 字段中。

点击Test Connection：

出现Success说明配置成功。

创建项目

大多数过程与 Github 项目雷同。

General

会多出一个选项，选择刚刚添加的：

源码管理

Git 仓库地址填 Gitlab 仓库地址，同样会报错，添加一个Credentials便可解决：

用户名密码填登录 Gitlab 的用户名密码即可。

构建触发器

按需选择触发条件，这里笔者仅选择了提交代码：

这里红框中的 url 需要记下，后面要用。

其他配置

与 Github 项目相同。

测试构建

点击立即构建，查看是否能构建成功：

构建成功：

提交代码自动构建

进入 Gitlab 仓库 -> 设置 -> 集成：

这里的 url 填入刚刚 Jenkins 构建触发器 中红框内的 url 地址。

看情况是否开启 SSL verification。

点击 Add webhook：

测试一下：

可以看到 Jenkins 那边已经开始构建了：

构建成功：

测试 Git 提交触发构建

目前页面：

我们将v2.0-f改成v2.0-g：

提交代码，Jenkins 开始了自动构建：

构建成功，页面也发生了变化：

至此，Gitlab 提交代码后自动打包并部署至服务器的流水线就完成了。

后记

本文实现了从提交代码到部署上线的自动化工作流，适合小公司的小型项目或自己的演示项目，大公司一定会有更规范更细节的流程，笔者也是从实际需求出发，希望本文能帮助到各位，由于笔者也是第一次使用 Jenkins，如有不足或错误之处，请读者批评指正。

作者：bald3r
来源：juejin.cn/post/7354406980784504870

Redis Stream 是 Redis 5.0 版本中引入的一种新的数据结构，它用于实现简单但功能强大的消息传递模式。

这篇文章，我们聊聊 Redis Stream 基本用法 ，以及如何在 SpringBoot 项目中应用 Redis Stream 。

1 基础知识

Redis Stream 的结构如下图所示，它是一个消息链表，将所有加入的消息都串起来，每个消息都有一个唯一的 ID 和对应的内容。

每个 Redis Stream 都有唯一的名称 ，对应唯一的 Redis Key 。

同一个 Stream 可以挂载多个消费组 ConsumerGr0up , 消费组不能自动创建，需要使用 XGR0UP CREATE 命令创建。

每个消费组会有个游标 last_delivered_id，任意一个消费者读取了消息都会使游标 last_delivered_id 往前移动 ，标识当前消费组消费到哪条消息了。

消费组 ConsumerGr0up 同样可以挂载多个消费者 Consumer , 每个 Consumer 并行的读取消息，任意一个消费者读取了消息都会使游标 last_delivered_id 往前移动。

消费者内部有一个属性 pending_ids ， 记录了当前消费者读取但没有回复 ACK 的消息 ID 列表 。

2 核心命令

01 XADD 向 Stream 末尾添加消息

使用 XADD 向队列添加消息，如果指定的队列不存在，则创建一个队列。基础语法格式：

XADD key ID field value [field value ...]

• key ：队列名称，如果不存在就创建


• ID ：消息 id，我们使用 * 表示由 redis 生成，可以自定义，但是要自己保证递增性。


• field value ： 记录。

127.0.0.1:6379> XADD mystream * name1 value1 name2 value2

"1712473185388-0"

127.0.0.1:6379> XLEN mystream

(integer) 1

127.0.0.1:6379> XADD mystream * name2 value2 name3 value3

"1712473231761-0"

消息 ID 使用 * 表示由 redis 生成，同时也可以自定义，但是自定义时要保证递增性。

消息 ID 的格式： 毫秒级时间戳 + 序号 , 例如：1712473185388-5 , 它表示当前消息在毫秒时间戳 1712473185388 产生 ，并且该毫秒内产生到了第5条消息。

在添加队列消息时，也可以指定队列的长度。

127.0.0.1:6379> XADD mystream MAXLEN 100 * name value1 age 30

"1713082205042-0"

使用 XADD 命令向 mystream 的 stream 中添加了一条消息，并且指定了最大长度为 100。消息的 ID 由 Redis 自动生成，消息包含两个字段 name 和 age，分别对应的值是 value1 和 30。

02 XRANGE 获取消息列表

使用 XRANGE 获取消息列表，会自动过滤已经删除的消息。语法格式：

XRANGE key start end [COUNT count]

• key ：队列名


• start ：开始值， - 表示最小值


• end ：结束值， + 表示最大值


• count ：数量

127.0.0.1:6379> XRANGE mystream - + COUNT 2

1) 1) "1712473185388-0"

   2) 1) "name1"

      2) "value1"

      3) "name2"

      4) "value2"

2) 1) "1712473231761-0"

   2) 1) "name2"

      2) "value2"

      3) "name3"

      4) "value3"

我们得到两条消息，第一层是消息 ID ，第二层是消息内容 ，消息内容是 Hash 数据结构 。

03 XREAD 以阻塞/非阻塞方式获取消息列表

使用 XREAD 以阻塞或非阻塞方式获取消息列表 ，语法格式：

XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] id [id ...]

• count ：数量


• milliseconds ：可选，阻塞毫秒数，没有设置就是非阻塞模式


• key ：队列名


• id ：消息 ID

127.0.0.1:6379> XREAD streams mystream 0-0

1) 1) "mystream"

   2) 1) 1) "1712473185388-0"

         2) 1) "name1"

            2) "value1"

            3) "name2"

            4) "value2"

      2) 1) "1712473231761-0"

         2) 1) "name2"

            2) "value2"

            3) "name3"

            4) "value3"

XRED 读消息时分为阻塞和非阻塞模式，使用 BLOCK 选项可以表示阻塞模式，需要设置阻塞时长。非阻塞模式下，读取完毕（即使没有任何消息）立即返回，而在阻塞模式下，若读取不到内容，则阻塞等待。

127.0.0.1:6379> XREAD block 1000 streams mystream $

(nil)

(1.07s)

使用 Block 模式，配合 $ 作为 ID ，表示读取最新的消息，若没有消息，命令阻塞！等待过程中，其他客户端向队列追加消息，则会立即读取到。

因此，典型的队列就是 XADD 配合 XREAD Block 完成。XADD 负责生成消息，XREAD 负责消费消息。

04 XGR0UP CREATE 创建消费者组

使用 XGR0UP CREATE 创建消费者组，分两种情况：

• 从头开始消费:

XGR0UP CREATE mystream consumer-group-name 0-0  

• 从尾部开始消费:

XGR0UP CREATE mystream consumer-group-name $

执行效果如下：

127.0.0.1:6379> XGR0UP CREATE mystream mygroup 0-0

OK

05 XREADGR0UP GR0UP 读取消费组中的消息

使用 XREADGR0UP GR0UP 读取消费组中的消息，语法格式：

XREADGR0UP GR0UP group consumer [COUNT count] [BLOCK milliseconds] [NOACK] STREAMS key [key ...] ID [ID ...]

• group ：消费组名


• consumer ：消费者名。


• count ： 读取数量。


• milliseconds ： 阻塞毫秒数。


• key ： 队列名。


• ID ： 消息 ID。

示例：

127.0.0.1:6379>  XREADGR0UP group mygroup consumerA count 1 streams mystream >

1) 1) "mystream"

   2) 1) 1) "1712473185388-0"

         2) 1) "name1"

            2) "value1"

            3) "name2"

            4) "value2"

消费者组 mygroup 中的消费者 consumerA ，从 名为 mystream 的 Stream 中读取消息。

• COUNT 1 表示一次最多读取一条消息


• > 表示消息的起始位置是当前可用消息的 ID，即从当前未读取的最早消息开始读取。

06 XACK 消息消费确认

接收到消息之后，我们要手动确认一下（ack），语法格式：

xack key group-key ID [ID ...]

示例：

127.0.0.1:6379> XACK mystream mygroup 1713089061658-0

(integer) 1

消费确认增加了消息的可靠性，一般在业务处理完成之后，需要执行 ack 确认消息已经被消费完成，整个流程的执行如下图所示：

我们可以使用 xpending 命令查看消费者未确认的消息ID：

127.0.0.1:6379> xpending mystream mygroup

1) (integer) 1

2) "1713091227595-0"

3) "1713091227595-0"

4) 1) 1) "consumerA"

      2) "1"

07 XTRIM 限制 Stream 长度

我们使用 XTRIM 对流进行修剪，限制长度， 语法格式：

127.0.0.1:6379> XADD mystream * field1 A field2 B field3 C field4 D

"1712535017402-0"

127.0.0.1:6379> XTRIM mystream MAXLEN 2

(integer) 4

127.0.0.1:6379> XRANGE mystream - +

1) 1) "1712498239430-0"

   2) 1) "name"

      2) "zhangyogn"

2) 1) "1712535017402-0"

   2) 1) "field1"

      2) "A"

      3) "field2"

      4) "B"

      5) "field3"

      6) "C"

      7) "field4"

      8) "D"

3 SpringBoot Redis Stream 实战

1、添加 SpringBoot Redis 依赖

<dependency>

    <groupId>org.springframework.bootgroupId>

    <artifactId>spring-boot-starter-data-redisartifactId>

dependency>

2、yaml 文件配置

3、RedisTemplate 配置

4、定义stream监听器

5、定义streamcontainer 并启动

6、发送消息

执行完成之后，消费者就可以打印如下日志：

演示代码地址：

github.com/makemyownli…

4 Redis stream 用做消息队列完美吗

笔者认为 Redis stream 用于消息队列最大的进步在于：实现了发布订阅模型。

发布订阅模型具有如下特点：

• 消费独立
  
  

  相比队列模型的匿名消费方式，发布订阅模型中消费方都会具备的身份，一般叫做订阅组（订阅关系），不同订阅组之间相互独立不会相互影响。



• 一对多通信
  
  

  基于独立身份的设计，同一个主题内的消息可以被多个订阅组处理，每个订阅组都可以拿到全量消息。因此发布订阅模型可以实现一对多通信。

细品 Redis stream 的设计，我们发现它和 Kafka 非常相似，比如说消费者组，消费进度偏移量等。

我们曾经诟病 Redis List 数据结构用做队列时，因为消费时没有 Ack 机制，应用异常挂掉导致消息偶发丢失的情况，Redis Stream 已经完美的解决了。

因为消费者内部有一个属性 pending_ids ， 记录了当前消费者读取但没有回复 ACK 的消息 ID 列表 。当消费者重新上线，这些消息可以重新被消费。

但 Redis stream 用做消息队列完美吗 ？

这个真没有！ 。

1、Redis 本身定位是内存数据库，它的设计之初都是为缓存准备的，并不具备消息堆积的能力。而专业消息队列一个非常重要的功能是数据中转枢纽，Redis 的定位很难满足，所以使用起来要非常小心。

2、Redis 的高可用方案可能丢失消息（AOF 持久化 和 主从复制都是异步 ），而专业消息队列可以针对不同的场景选择不同的高可用策略。

所以，笔者认为 Redis 非常适合轻量级消息队列解决方案，轻量级意味着：数据量可控 + 业务模型简单 。

参考文章：

redis.io/docs/data-t…

http://www.runoob.com/redis/redis…

pdai.tech/md/db/nosql…

1、背景

1.2 业务重组与合并

随着需求不断迭代，转转消费分期整体出现了一些调整，并提出了新的产品方向，在此背景下，对于经历了久经沧桑的历史服务，已经逐渐不适合未来的产品规划。面对新的业务整合和重组，急需新的架构和思想来承载未来的业务。

1.2 解决技术债务

现阶段存在的主要问题：

1.3 影响开发效率

即使我们接手项目已经有一段时间，并对项目足够了解时，但排查问题起来依然费力费时，而且系统内部代码错综复杂，调用链路交错，难以正常维护，从长远的开发效率考虑，尽快提出新型方案来代替现有结构。

1.4 监控体系不够完善

线上异常机制不够敏感，缺少关键业务指标的告警看板，作为一个业务开发，应保持对核心指标数据的敏感性。

2、重构目标

3、设计

3.1 调研

开始重构之前，调研了互联网消金通用的架构解决方案：

由于是外部调研的通用架构设计，所以并非完全契合转转消费分期产品，但可以借鉴其分层架构设计的思想，在代码设计阶段，可以先对核心模块进行拆解和规划。

3.2 规划

前端页面与后端重构计划分两次迭代进行，分阶段进行，可以有效分摊并降低项目上线风险，第一次迭代围绕后端主要模块进行剥离重新设计并上线；第二次重构目的是解决产品需求，对接前端新页面。

3.3 修缮者模式

作为一个一线的业务开发，需要开展重构工作的同时还得保证产品需求的正常迭代，修缮者模式无疑是最佳选择。
第一次迭代历程，对于历史工程边缘逻辑保留并隔离，只对核心代码进行重构后转移到到新工程，新工程逐步接手老旧逻辑，并对老工程提供RPC接口，逐渐取代。此方案整体风险最低，同时能兼顾到正常的需求迭代。

第二次迭代历程，经历了第一次迭代后，新系统运行稳定，同时也具备接手新产品的能力，新工程开始与前端对接、联调，在此之后，V2版本也正式上线。

3.4 领域设计（横向拆分）

3.5 模块设计（纵向拆分）

基于以往项目存在的问题，再结合消费分期的特点，我们对分期购买到账单还款结清的整个流程进行拆解：用户主动填写申请信息，提交授信申请并获额，挑选商品分期下单，生成还款计划，提供绑卡、账单还款等功能。以上就是一个简单的分期购物流程，基于以上流程，我们把消费分期所包含的公共模块，如授信前获额、用信、账单还款，这些富有金融服务属性的功能进行剥离。消费分期作为转转的产品原型，在聚合层中各自维护，互不影响。

设计原则：在不改变原有代码逻辑的情况下，根据单一职责和依赖倒置原则的思想：对系统进行模块拆分与合并，以明确项目职责降低耦合度；对包进行重新规划，划分包与包之间的边界，进一步减少代码间的耦合。

3.6 代码设计

好的代码重构一定离不开设计模式，基于原有单一的策略模式，我们把合作方对接模块与基础服务模块进行了拆解，采用双层模板、策略、工厂模式的组合，分别对授信、用信、贷后几个模块单独设计接口，维护好对合作方通用标准API接口，同时具备灵活接入的特点，举个例子，以下为授信模块主要代码类图：

第一层作为基础服务的策略模式；

第二层作为合作方对接的策略模式。

主要类图设计：

在定义接口与实现类后，形成了对合作方对接层依赖，同时对订单、用信、授信等核心数据进行落地，对消费分期提供数据支撑，举个例子，以下为授信模块主要代码：

/**

 * 授信接口定义

 **/

public interface ICreditService {



    /**

     * appId，资方定义的一个唯一ID

     */

    String getAppId();



    /**

     * app名称

     *

     * @return zz or zlj

     */

    String getAppName();



     /**

     * 获取授信结果

     *

     * @return result

     */

    CreditResult creditResult(String logStr, Long uid);

}

2. 标准流程抽象