在项目的开发中，我们经常会遇到需要创建复杂对象的场景，例如一个参数繁多的类的构造函数。这时如果我们不使用任何设计模式进行开发，项目将变得十分复杂，面对常常变动的需求，我们可能需要一个一个修改参数，并在任何引用该类的地方都做一次修改，最后只会变得乱成一团无法维护。那么该如何解决这个问题呢？

答案是使用工厂模式。在需要创建复杂对象，并频繁使用时，我们就可以选择工厂模式。

工厂模式的三种实现形式 #

工厂模式有三种实现形式

- 简单工厂（静态工厂）
- 工厂方法（本节核心）
- 抽象工厂

> 注：简单工厂并不算在GoF 23种设计模式中

本节，我们将深入理解工厂方法模式及其应用。

简单工厂（静态工厂） #

在介绍工厂方法模式之前，我先对简单工厂进行介绍。在简单工厂模式中，创建实例的方法通常为静态方法，因此简单工厂模式又被成为静态工厂方法。简单工厂只有一个具体的工厂类，专门用于生产特定专一的产品，在需要生产多种产品时，需要将多个产品定义到同一个工厂中进行生产。简单工厂名副其实，十分简单。这样的好处就是产品创建方便，客户直接提需求，工厂直接实现，不需要经过任何产品线。但问题也来了，在需要大量创建不同产品时，简单工厂就会变得“不堪重负”。回归到软件中，简单工厂会增加系统的复杂性，在多个产品的情况下，单个类职责过重，软件将变得难以维护。每增加一个产品就要增加一个工厂类，违背了“开闭原则”。

 简单工厂的示例 

我们有苹果树和梨树和一家工厂，这家工厂要负责将水果树上的所有水果都摘下来。

`java

package com.yeliheng.factory.simplefactory;

public class Main {
    public static void main(String[] args) {
        Apple apple = (Apple) SimpleFactory.make(0);
        Banana banana = (Banana) SimpleFactory.make(1);
        apple.show();
        banana.show();
    }

    //水果产品
    public interface Fruit {
        void show();
    }

    //具体产品
    static class Apple implements Fruit {
        public void show() {
            System.out.println("苹果树上长苹果...");
        }
    }

    //具体产品
    static class Banana implements Fruit {
        public void show() {
            System.out.println("香蕉树上长香蕉...");
        }
    }

    //工厂生产
    static class SimpleFactory {
        public static Fruit make(int kind) {
            switch (kind) {
                case 0:
                    return new Apple();
                case 1:
                    return new Banana();
            }
            return null;
        }
    }
}

`

通过代码示例我们可以看到每生产一种具体的水果，就要定义一个新的静态产品类让水果能被工厂生产。工厂类的代码将会随着产品的增加越来越复杂。

为了解决这个问题，工厂方法（Factory Method）模式出现了。

工厂方法 #

工厂方法模式在简单工厂模式的基础上进一步抽象，可以使系统拓展新的具体类时，原来的工厂代码不必修改，满足开闭原则。拓展新的需求，创建新产品，只需要在原来的基础上增加一个工厂类，这样就可以有多个工厂为我们服务。并且上层应用只需了解抽象的产品类，无需对其他类进行拓展。这也同时满足了迪米特法则、依赖倒置原则和里氏替换原则。但工厂方法模式同样存在缺点。它将会让工厂类数目繁多，降低系统代码的可读性。并且在抽象产品中，只能产出一种具体产品。（这个问题可以使用抽象工厂解决，下节介绍）。

工厂方法模式由以下结构组成：

- 抽象工厂（AbstractFactory）：提供了产品的抽象类或接口。
- 具体工厂（ConcreteFactory）：具体的创建类，实现具体生产产品的方法。
- 抽象产品（Product）：产品的抽象创建类。
- 具体产品（ConcreteProduct）：将抽象产品进行实现。

 实际应用场景 

- 日志工厂
- 文件存储
...

 示例 

我们来实现一个日志工厂，该日志工厂具有以下三个功能：
1. 打印日志到控制台
2. 打印日志到文件

我们按照上文所述的结构一一实现工厂方法：

1. 抽象产品

Logger.java

`java

package com.yeliheng.factory.factorymethod;

/
 * 日志产品的抽象
 */
public interface Logger {
    //日志级别
    void debug();

    void info();

    void warning();

    void error();

}

`

我们在抽象产品中定义了四个产品接口，可对应四种不同级别的日志。

2. 抽象工厂

LoggerFactory.java

`java

package com.yeliheng.factory.factorymethod;

public interface LoggerFactory {
    Logger getLogger();
}

`

在抽象工厂中，我们去使用Logger，定义一个getLogger()方法来便于待会具体工厂获取Logger实例。

3. 具体产品

我们实现两个具体产品类，一个是输出到控制台的产品类，一个是输出到文件的产品类。这里为了代码的简洁，就不详细地写出输出到文件的逻辑，仅使用输出进行简单举例。

ConsoleLogger.java

`java
package com.yeliheng.factory.factorymethod;

public class ConsoleLogger implements Logger{
    @Override
    public void debug() {

    }

    @Override
    public void info() {
        System.out.println("[INFO] 这条日志被输出到[控制台]");
    }

    @Override
    public void warning() {

    }

    @Override
    public void error() {

    }
}
`

FileLogger.java

`java
package com.yeliheng.factory.factorymethod;

public class FileLogger implements Logger{
    @Override
    public void debug() {

    }

    @Override
    public void info() {
        System.out.println("[INFO] 这条日志被输出到[文件]");
    }

    @Override
    public void warning() {

    }

    @Override
    public void error() {

    }
}

`

4. 实现具体的工厂

ConsoleLoggerFactory.java

`java
package com.yeliheng.factory.factorymethod;

/
 * 具体工厂
 */
public class ConsoleLoggerFactory implements LoggerFactory{
    @Override
    public Logger getLogger() {
        return new ConsoleLogger();
    }
}
`

我们重写了实现了抽象工厂：LoggerFactory，并重写了getLogger方法，让其返回一个ConsoleLogger实例。

FileLoggerFactory.java

`java

package com.yeliheng.factory.factorymethod;

public class FileLoggerFactory implements LoggerFactory{
    @Override
    public Logger getLogger() {
        return new FileLogger();
    }
}

`

原理相同。

5. 最后，我们可以开始使用我们通过工厂方法模式创建的日志工厂了。

Main.java

`java
package com.yeliheng.factory.factorymethod;

public class Main {
    public static void main(String[] args) {
        //输出到控制台
        LoggerFactory consoleLoggerFactory = new ConsoleLoggerFactory();
        Logger logger1 = consoleLoggerFactory.getLogger();
        logger1.info();
        //输出到文件
        LoggerFactory fileLoggerFactory = new FileLoggerFactory();
        Logger logger2 = fileLoggerFactory.getLogger();
        logger2.info();

    }
}

`
可以看到最终输出如下：

!output.png

细心的你可能会发现，这个写法与slf4j日志库的写法十分相似。没错，查看slf4j源码可以发现，其使用了大量工厂模式实现强大的日志框架。

小结 #

到此，我们使用工厂方法模式完成了一个简单的日志工厂，下节我们将使用抽象方法模式继续完善本节的例子。

源码参考：Github

在项目中，如何做到对象的创建与使用分离？本文将以Java为例，带你重温GoF设计模式之工厂方法模式，并深入理解工厂方法模式及其应用场景。

Java设计模式再相识 (三)——工厂方法(Factory Method)模式

当你的系统存在相同或者相似对象需要创建，你可能会想到使用new 对象名() 来创建。但如果你的系统存在大量相同对象需要创建时，这样做会显得效率低下，并且代码将杂乱无章，你需要在构造函数中使用大量类名来进行实例化。这时，我们可以采用原型模式来进行优化，提高执行效率。例如复印机只需要简单的配置就可以复印出大量材料，这就是典型的原型模式的体现。

原型模式介绍 #

原型(Prototype)：用一个已经创建的“原型对象”进行复制，得出与原型相同或者相似的新对象。原型模式和上节的单例模式同样属于创建型模式。它很少单独使用，经常与其他设计模式配合使用（例如：它可以与Command命令模式配合使用，便于复制Command模式中出现的命令）。但作为基础，我们也必须掌握原型模式。

应用场景 #

我相信你最关心什么时候需要用到原型模式，这里我列举出几种可以使用原型模式的场景供你参考：

- 相同或相似对象繁多，无法将他们整合到唯一一个类中。
- 一个类调用了另外一个类，两个类之间存在耦合，你想把他们解耦，在不修改另一个类的情况下改变职责。
- 难以根据类来生成实例时。

 举例 

下面我们来根据一个实际的例子实现原型模式。

例子：假设你有一台打印机，它可以为你打印大量的文件，并且支持各种纸张的样式。现在，你需要让它为你打印大量A4和A3版本的Hello,World。请使用原型模式实现它。

首先我们定义打印机原型：

Printer.java

`java
package com.yeliheng.prototype;

/
 * 打印机原型
 */
public class Printer implements Cloneable {

    private String paperType; //纸张类型

    private String content; //打印内容

    public Printer(String paperType, String content) {
        this.paperType = paperType;
        this.content = content;
        System.out.println("打印机准备就绪！");
    }

    public String getPaperType() {
        return paperType;
    }

    public void setPaperType(String paperType) {
        this.paperType = paperType;
    }

    public String getContent() {
        return content;
    }

    public void setContent(String content) {
        this.content = content;
    }

    public void display() {
        System.out.println(" 纸张类型: " + paperType + " \n 打印内容: " + content);
    }

    @Override
    public Printer clone() {
        try {
            return (Printer) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }
}
`

Printer原型的实现代码很简单，我们具体来关注对Cloneable接口的实现。在Printer类中，我们实现了java.lang包提供的Cloneable接口，并重写了clone()方法，在clone()方法内，我们试图捕获CloneNotSupportedException异常。这是因为我们必须保证被复制的对象必须实现java.lang.Clonable接口，否则对象将无法被克隆。细心的你可能会发现Cloneable接口中并没有clone()方法的相关定义。这是因为clone()方法被定义在java.lang.Object中，而Object类是所有Java类的父类。因此所有Java类都继承了clone()方法。像Cloneable接口很容易让人误认为Cloneable接口中声明了clone()方法，其实这是错误的。Clone接口中什么都没有，它只是起到告诉程序可以调用clone方法的作用。

写完了打印机原型，我们现在就开始让它工作，让它为我们复制出不同纸张类型的Hello,World。

Main.java

`java

package com.yeliheng.prototype;

/
 * 原型模式
 */
public class Main {
    public static void main(String[] args) {

        Printer obj1 = new Printer("A4","Hello,World");
        obj1.display();

        Printer obj2 = (Printer) obj1.clone(); //克隆！
        obj2.setPaperType("A3");
        obj2.display();
    }
}

`

我们先用传统的方式实例化了Printer类，让它打印一张A4的Hello,World。然后我们用克隆的方式：obj1.clone()，让它打印出一张A3的相同内容的纸。最后的输出结果如下：

!输出结果

这时，我们就实现了一个原型模式。本例中的克隆方式称为浅克隆。

>请注意：Cloneable接口破坏了单例模式，如果是单例类，又实现了Cloneable接口，那么该类就可以调用clone方法创建另外的实例，因此破坏了单例模式。

浅克隆 #

浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型，浅克隆只会将实例的引用复制。例如，当字段中保存的是数组时，如果使用clone()方法进行克隆，则只会将数组的引用复制，并不会复制数组内的元素。浅克隆默认使用super.clone()来实现。

深克隆 #

深克隆：创建一个新的对象，属性中引用的其他对象也将被克隆，不再指向原对象地址，即在内存中开辟新的空间。

如果你需要更复杂的功能，例如复制所有非基本类型的引用和值，则需要以下步骤：

1. 创建实例对象：通过clone()方法创建原型类的实例，这个步骤与浅克隆相同。
2. 克隆引用的成员：调用原型类对象成员的clone()方法，创建新的成员对象，将新的成员对象赋值给克隆出的原型模式的对象。（类似于递归调用）
3. 返回新对象：返回clone()创建的原型对象。

思考：你可以尝试着实现一个包含数组对象的深克隆。

总结 #

本文仅举一个简单的例子展现原型模式，在实际开发中，原型模式需要根据具体情况决定是否使用，例如上文描述的几种应用场景。熟练掌握原型模式，在后面需要与其他设计模式一起使用时，你就能够轻松驾驭。

源码参考：GitHub

当你的系统存在大量相同对象需要创建，使用原型模式能够为你高效地创建对象。本文将以Java为例，带你重温GoF设计模式之原型模式，并深入理解原型模式以及应用场景。

Java设计模式再相识 (二)——原型模式

> 当你想在一个庞大的工程中，确保整个程序只存在一个唯一的实例，并且保证在任何情况下，新的实例都不会被创建，这时候，单例模式将是你的不二之选。

我们在使用Windows操作系统时，是否曾注意到任务管理器，回收站等系统应用始终只能打开一个窗口，这就是单例模式的类比。接下来，我们将动手实现一个单例模式的程序。在开始之前，我们先来熟悉单例模式的基本概念。

基础篇 #

 介绍 

单例（Singleton）模式的定义：一个类只允许拥有一个实例。

单例模式通常有两种实现形式：饿汉式，懒汉式。在基础篇中，我将详细介绍饿汉式单例模式。

何为饿汉式？顾名思义，就是在类加载时就创建一个单例，这样能够保证在调用getInstance()方法之前这个单例就已经存在。

现在，就让我们来编写代码模拟实现一个Windows任务管理器，让它只能存在一个。

 示例-模拟任务管理器 

我们新建一个名为Singleton.java的文件，代码内容如下: 

Singleton.java

`java
package com.yeliheng.singleton;

public class Singleton {
    private static final Singleton singleton = new Singleton();

    private Singleton() {
        System.out.println("任务管理器已打开！");
    }

    public static Singleton getInstance() {
        return singleton;
    }
}

`

在Singleton类中，我们定义了static字段的成员变量singleton，并将其初始化为Singleton类的实例。然后我们定义了一个私有构造函数Singleton，打印提示。使用private修饰符可以防止从Singleton类以外的代码调用构造函数，从而单例模式将失去意义。

接着我们定义getInstance()方法，就可以让外部程序以只读的方式获取到Singleton类的唯一实例。(通常情况下，我们采用getInstance作为方法名。)

Main.java

`java

package com.yeliheng.singleton;

public class Main {

    public static void main(String[] args) {

        Singleton obj1 = Singleton.getInstance();

        Singleton obj2 = Singleton.getInstance();

        if(obj1.equals(obj2)) {
            System.out.println("obj1和obj2是同一个实例，任务管理器只能创建一个！");
        }
    }
}

`
在Main函数中，我们定义obj1和obj2两个变量，这两个变量都去创建两次Singleton实例。然后我们使用if语句来判断，这两个实例是否是同一个实例。代码十分简单，我们一起来看看运行结果。

运行结果如下：

!QQ20220210-214108@2x.png

显而易见，两个实例是同一个实例，我们的Singleton只被创建了一次。

饿汉式单例我们就介绍到这里，接下来，我们开始介绍懒汉式单例。

进阶篇 #

 懒汉式单例 

懒汉式单例在类加载时不会生成单例，只有当第一次调用getInstance()方法时才去创建这个单例。代码如下: 

`java
package com.yeliheng.singleton;

public class LazySingleton {
    
    private static LazySingleton lazySingleton = null; //创建一个空的懒汉式单例

    private LazySingleton() {

    }
    
    public static LazySingleton getInstance() {
        if (lazySingleton == null) {
            lazySingleton = new LazySingleton();
        }
        return lazySingleton;
    }
}

`

在这个例子中，代码与前面的大同小异，就是在初始化lazySingleton变量时，没有像饿汉式单例那样立即实例化，而是指定一个null，当需要获取Instance实例时，再进行实例化。这样做，可以在大型计算场景中，节省内存，按需加载。

不知道聪明的你有没有注意到这样做的问题。在上面这个代码中，存在线程安全问题。在多线程程序的条件下，会出现LazySingleton还未创建完成的情况下，另一个线程又去访问调用LazySignleton，造成实例被创建多次的情况，这样它就不再是一个单例模式了。我们现在对程序进行改进：

`java

package com.yeliheng.singleton;

public class LazySingleton {

    private static volatile LazySingleton lazySingleton = null; //创建一个空的懒汉式单例

    private LazySingleton() {

    }

    public static synchronized LazySingleton getInstance() {
        if (lazySingleton == null) {
            lazySingleton = new LazySingleton();
        }
        return lazySingleton;
    }
}

`
没错，只需要在变量出增加volatile关键字，并在静态成员方法处增加一个同步锁，就可以完美解决这个问题，保证线程安全。这样，全局程序将不可能出现多个实例。

 总结 

单例模式是设计模式中常用的模式之一。单例模式的形式常分为饿汉式和懒汉式。饿汉式的优点是创建起来简单，并且天然线程安全。缺点是在大量单例存在时，将造成资源浪费。懒汉式的优点是性能较好，按需加载对象，能够让内存空间被较佳利用。缺点是创建相对于饿汉式复杂，在多线程的场景下，对多线程不熟悉或稍不注意容易出现线程安全问题。

源码参考：GitHub

本文将以Java为例，带你重温GoF设计模式之单例模式，并深入理解单例模式的创建方法以及应用场景。

Java设计模式再相识 (一)——单例模式

引言

当你在开发一个后台管理系统时，突然遇到需要记录用户操作日志的需求，你会采取什么样的方法？解决此问题的方法有很多种，如：在每个地方都写一遍打印日志的逻辑（这显然是不明智的）、使用代理模式（AOP底层原理）...

本文将带领你使用较理想的解决方案处理这个需求——使用AspectJ提供的AOP库实现日志的记录，并配合Java的Annotation注解来实现在控制器上记录日志。

AOP介绍

在开始前，我将简单介绍AOP的一些概念，如果你对这些概念完全陌生，建议先上网了解相关概念，再继续阅读。

AOP，面向切面编程，即Aspect Oriented Programming。

- Aspect：切面，类似于Java中的类声明，是对系统中横跨多个类的关注点进行模块化封装

- Joinpoint：连接点，程序执行过程中的一个“点”，例如：方法的执行或异常的处理。在Spring AOP中，一个连接点总是代表一个方法的执行。

- Pointcut：切入点，即一组连接点的集合；

- Advice：通知，定义了将会织入到 Joinpoint 的具体逻辑，通过@Before、@After、@Around等注解来区别在JointPoint之前、之后等位置执行代码

- Weaving：织入，织入指的是将Advice连接到Pointcut指定的Joinpoint处的过程

- Interceptor：拦截器，是一种实现Advice（通知）的方式；

- Target：目标对象，即符合切入点所指定的条件被织入Advice的对象。

以上术语，你可能会感到些许困惑，不过没关系，我们开始进入到正式的Coding，一步一步实现功能后，再回来此部分看这些概念，就会豁然开朗。

Coding——开始实现日志模块

 引入依赖 

以SpringBoot为例，首先我们从Maven中央仓库引入AOP所需的依赖。在你的pom.xml中添加以下代码：

`xml
		
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-aop</artifactId>
		</dependency>
`

 定义注解 

定义注解目的在于：之后需要打印日志的地方，只需要@Log("模块名称","业务类型")即可。

---

我们使用IDEA右键->New->Java Class->Annotation，文件名为Log.java。代码片段如下：

`java

@Target({ ElementType.PARAMETER, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
public @interface Log {

    /
     * 模块名称
     */
    public String moduleName() default "";

    /
     * 业务类型
     */
    public int businessType() default BusinessType.OTHER; 
    //此处业务类型可以自己定义，完整代码可参考文末本仓库Github
}

`
在Log注解中，我们定义了注解能接收的两个参数：模块名称、业务类型。并将Target目标指定为METHOD方法，即方法注解。

@Retention(RetentionPolicy.RUNTIME)表明此注解不仅被保存到class文件中，在JVM加载class文件之后，此注解仍然存在。

 编写切面类 

日志切面的核心代码，这个类中的代码将动态地注入到注解所在方法的横截面中，并实现日志的记录。

`java

@Component
@Aspect
public class LogAspect {

    @Pointcut("@annotation(com.yeliheng.blogcommon.annotation.Log)")
    public void pointcut() {}

    @AfterReturning(pointcut = "pointcut()", returning = "jsonResponse")
    public void doReturningLogRecord(JoinPoint joinPoint, Object jsonResponse) {
        recordLog(joinPoint,null,jsonResponse);
    }

    @AfterThrowing(value = "pointcut()", throwing = "e")
    public void doThrowingLogRecord(JoinPoint joinPoint, ApiException e) {
        recordLog(joinPoint,e,null);
    }

    private void recordLog(JoinPoint joinPoint, ApiException e, Object jsonResponse) {
        Log log = getAnnotation(joinPoint);
        if(log == null) {
            return;
        }
        //TODO: 记录日志的具体逻辑 如：获取各种信息，写入数据库等操作...

    }

    /
     * 通过反射获取注解
     */
    private Log getAnnotation(JoinPoint joinPoint) {
        Signature signature = joinPoint.getSignature();
        MethodSignature methodSignature = (MethodSignature) signature;
        Method method = methodSignature.getMethod();
        if(method != null) {
            return method.getAnnotation(Log.class);
        }
        return null;
    }
   
}

`

要实现切面类，我们需要在类前加入两个注解：@Component,@Aspect，以供Spring IoC容器进行管理。Spring的IoC容器读取到Aspect注解时，会自动查找带有@Aspect的Bean，然后根据@AfterReturning、@AfterThrowing等拦截器注解把AOP注入到特定的Bean中。

拦截器注解说明：
- @AfterReturning: 当方法正常返回时会被此拦截器拦截。
- @AfterThrowing: 当方法运行过程中有异常抛出时，会被此拦截器拦截。

在doReturningLogRecord和doThrowingLogRecord，我们都传入一个joinPoint，并在recordLog方法中通过joinPoint获取我们定义的自定义注解——@Log，并可以通过反射从连接点获取到方法名称和类名。

弄清楚了拦截器方法的作用，我们就可以在recordLog方法中编写具体的记录日志的逻辑。如：记录操作时间，操作人，操作地点等，并把这些信息写入数据库中。

 开始使用 

编写完切面类后，不出意外的话你的自定义注解的日志已经可以正常使用并且记录用户日志了。但是我们要如何使用它呢？

`java

    @Log(moduleName = "新增用户",businessType = BusinessType.INSERT)
    @PostMapping
    public CommonResponse<Object> add(@Validated @RequestBody User user) {
        userService.insertUser(user);
        return CommonResponse.success();
    }

`

使用的方法非常简单，只需要在对应的控制器方法上，加上@Log("模块名称","业务类型")，JVM就会通过自身的动态代理功能将对应的代码编译成字节码并织入到对应的横截面中。这就是AOP面向切面编程的最佳实践。

总结 #

本文介绍如何使用Spring AOP实现对用户操作日志的记录，如需深入了解Spring AOP运行原理，请前往Spring官网，查阅Spring手册或通过源代码进行深入分析。

完整代码参见：Github

本文将使用AOP面向切面编程，基于SpringBoot下的AspectJ实现对用户操作日志的记录。

Spring AOP的最佳实践：在你的系统中记录用户的操作日志

> Yeliheng-Blog文档在GitHub、Yeliheng的技术小站上同步更新，开源仓库地址: https://github.com/yeliheng/yeliheng-blog
>
> 欢迎Star，Issue，Pull requests以及任何对本项目的贡献。开发不易，感谢支持！

系统介绍

这个开源仓库是Yeliheng的技术小站的前后端实现。Yeliheng-Blog是一个基于SpringBoot + Vue3开发的前后端分离的完整博客系统。它并不仅仅是一个简单的博客系统，更是一个后台权限管理系统，通过模块化使其具有高拓展性，可拓展成任何您想要的管理系统，例如文章系统，OA办公系统，仓库管理系统等...

 特性

- 轻量化系统，无外部框架的重度依赖

- 良好的可拓展性

- 响应式前端网页，完全适配移动端以及不同分辨率设备

- 基于RBAC模型的权限管理系统

- 优质的用户体验

  ...

 在线地址

后台演示功能暂未完成，目前仅开放前台展示，后台系统可自行搭建体验。

前台演示地址: https://www.yeliheng.com

功能详解

 后台

 目前已有功能

- 文章管理：实现文章的增删改查，以及文章分类、标签，隐私性的设置。
- 用户管理：用户登录、注册以及管理员对用户的增删改查操作。
- 角色管理：对角色系统的增删改查以及为用户分配多个角色。
- 权限管理：可为不同角色分配所需的不同权限，支持菜单权限，资源权限，按钮权限。
- 菜单管理：为角色分配菜单权限，以及前端菜单的动态路由处理，支持放置外链。
- 字典管理：对前端需要进行切换的状态字典进行动态管理。
- 站点统计：目前仅实现对文章字数，阅读时长及字数的统计，后续将以模块化形式实现站点的完整统计功能。
- 数据库监控：基于Druid的数据库可视化监控。

 正在开发中的功能

- 评论管理模块

- 完整的站点统计模块

- 定时备份模块的开发

- API接口文档

---

 前台

 目前已有功能

- 基于Markdown和Github风格的文章查看器

- 按照分类索引文章

- 按照标签索引文章

- 基于Three.js实现的Header

- 站点信息的显示

- 关于页面

 正在开发的功能

- 评论模块

- 日夜间模式的切换

- 站点统计模块

---

工程结构

`
yeliheng-blog
├── blog-common    --  后端系统通用模块（封装各种工具类、公共常量、异常类等）
├── blog-framework --  后端系统框架层（封装框架相关工具，如权限工具，框架配置文件，安全相关类）
├── blog-system    --  博客系统核心业务层（服务，数据库访问）
├── blog-web       --  博客系统API控制器（controller）
└── blog-vue       --  博客系统前端模块（Vue3）
    ├── admin   --  博客系统前端后台模块
    └── blog    --  博客系统前端前台模块
`

!模块图

技术栈

| 技术                 | 说明                |
| -------------------- | ------------------- |
| SpringBoot           | 容器+框架           |
| SpringSecurity       | 认证/权限框架       |
| MyBatis              | ORM框架             |
| RabbitMQ             | 消息队列            |
| Redis                | 分布式缓存          |
| Nginx                | 静态资源服务器      |
| Docker               | 应用容器引擎        |
| Jenkins              | 自动化部署工具      |
| Druid                | 数据库连接池        |
| OSS                  | 对象存储            |
| JWT                  | JWT登录支持         |
| PageHelper           | MyBatis物理分页插件 |
| Swagger-UI           | 文档生成工具        |
| Hibernator-Validator | 验证框架            |
| Vue3                 | 渐进式js框架        |
| Sass                 | css扩展语言         |
| Element-UI           | 饿了么UI库          |
| Markdown-it          | markdown解析工具    |

搭建教程

 开发环境

在开始之前，请确认您的开发环境，尽量与此处保持一致，以免出现意料之外的问题。

 后端

| 开发环境 | 版本   |
| -------- | ------ |
| JDK      | 1.8  |
| JRE      | 1.8  |
| MySQL    | 5.7  |
| Redis    | 6.x  |

 前端

| 开发环境 | 版本     |
| -------- | -------- |
| Vue      |  3     |
| Node.js  | 14.x |
| npm      | 6.x  |

 快速开始

 后端

1、搭建如上表格所示的开发环境并确保所有环境处于正常运行状态。（具体过程此处不做赘述，可自行查阅相关资料）

2、克隆本项目

`
git clone https://github.com/yeliheng/yeliheng-blog.git
`

3、导入idea或其他IDE，等待Maven导入所有的包。（此过程可能需要一些时间，部分国外仓库加载较慢，建议使用国内镜像源，具体步骤可自行在搜索引擎上查看）

4、在blog-web包的resource目录下新建配置文件，文件名为：application-dev.yml，并将application-example.yml中的内容复制到刚刚创建的application-dev.yml中，并将datasource中的数据源修改为自己的数据库信息。

5、导入数据库

将项目sql文件夹中的所有.sql文件导入到数据库中。

6、准备完成，开始运行项目！

当您看到如下提示，代表项目已成功运行。

!成功

 前端

1、进入本项目中的blog-vue文件夹中，前端分为admin和blog两个模块，此处以admin模块为例进行说明。

2、我们首先进入admin文件夹，在admin文件夹中新建文件：.env.development（重要！），并将 .env.example 中的内容复制到刚刚创建的 .env.development中，并将VUE_APP_BASE_API地址修改为后端地址。若您没有改动后端地址则无需更改。

3、执行如下指令安装所需依赖：

`
npm install
`

4、等待上述指令执行完成后，执行以下指令：

`
npm run serve
`

5、项目成功运行，开始访问吧！

管理员账号：admin

管理员密码: admin123

blog模块的安装方法与上述过程完全相同

项目截图

!首页

!文章

!后台

!权限管理

Yeliheng-Blog已开源，欢迎二次开发！本篇文章将详细介绍本站系统以及搭建教程。

Yeliheng的技术小站正式开源！

介绍 #

这篇文章是我在遇到问题后查询git官方文档时看到的，对我帮助颇大，故整理分享出来。

原文地址：https://git-scm.com/book/zh/v2/Git-%E5%B7%A5%E5%85%B7-%E9%87%8D%E5%86%99%E5%8E%86%E5%8F%B2

许多时候，在使用 Git 时，你可能想要修订提交历史。
Git 很棒的一点是它允许你在最后时刻做决定。
你可以在将暂存区内容提交前决定哪些文件进入提交，可以通过 git stash 来决定不与某些内容工作，
也可以重写已经发生的提交就像它们以另一种方式发生的一样。
这可能涉及改变提交的顺序，改变提交中的信息或修改文件，将提交压缩或是拆分，
或完全地移除提交——在将你的工作成果与他人共享之前。

在本文中，你可以学到如何完成这些工作，这样在与他人分享你的工作成果时你的提交历史将如你所愿地展示出来。

在满意之前不要推送你的工作

Git 的基本原则之一是，由于克隆中有很多工作是本地的，因此你可以 在本地 随便重写历史记录。
然而一旦推送了你的工作，那就完全是另一回事了，除非你有充分的理由进行更改，否则应该将推送的工作视为最终结果。

> 简而言之，在对它感到满意并准备与他人分享之前，应当避免推送你的工作。

修改最后一次提交 #

修改你最近一次提交可能是所有修改历史提交的操作中最常见的一个。
对于你的最近一次提交，你往往想做两件事情：简单地修改提交信息，
或者通过添加、移除或修改文件来更改提交实际的内容。

如果，你只是想修改最近一次提交的提交信息，那么很简单：

$ git commit --amend

上面这条命令会将最后一次的提交信息载入到编辑器中供你修改。
当保存并关闭编辑器后，编辑器会将更新后的提交信息写入新提交中，它会成为新的最后一次提交。

另一方面，如果你想要修改最后一次提交的实际内容，那么流程很相似：首先作出你想要补上的修改，
暂存它们，然后用 git commit --amend 以新的改进后的提交来 替换 掉旧有的最后一次提交，

使用这个技巧的时候需要小心，因为修正会改变提交的 SHA-1 校验和。
它类似于一个小的变基——如果已经推送了最后一次提交就不要修正它。

> .修补后的提交可能需要修补提交信息

当你在修补一次提交时，可以同时修改提交信息和提交内容。
如果你修补了提交的内容，那么几乎肯定要更新提交消息以反映修改后的内容。

另一方面，如果你的修补是琐碎的（如修改了一个笔误或添加了一个忘记暂存的文件），
那么之前的提交信息不必修改，你只需作出更改，暂存它们，然后通过以下命令避免不必要的编辑器环节即可：

$ git commit --amend --no-edit

修改多个提交信息 #

为了修改在提交历史中较远的提交，必须使用更复杂的工具。
Git 没有一个改变历史工具，但是可以使用变基工具来变基一系列提交，基于它们原来的 HEAD 而不是将其移动到另一个新的上面。
通过交互式变基工具，可以在任何想要修改的提交后停止，然后修改信息、添加文件或做任何想做的事情。
可以通过给 git rebase 增加 -i 选项来交互式地运行变基。
必须指定想要重写多久远的历史，这可以通过告诉命令将要变基到的提交来做到。

例如，如果想要修改最近三次提交信息，或者那组提交中的任意一个提交信息，
将想要修改的最近一次提交的父提交作为参数传递给 git rebase -i 命令，即  HEAD~2^ 或 HEAD~3。
记住 ~3 可能比较容易，因为你正尝试修改最后三次提交；但是注意实际上指定了以前的四次提交，即想要修改提交的父提交：

$ git rebase -i HEAD~3

再次记住这是一个变基命令——在 HEAD~3..HEAD 范围内的每一个修改了提交信息的提交及其 所有后裔 都会被重写。
不要涉及任何已经推送到中央服务器的提交——这样做会产生一次变更的两个版本，因而使他人困惑。

运行这个命令会在文本编辑器上给你一个提交的列表，看起来像下面这样：

`
pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

Rebase 710f0f8..a5f4a0d onto 710f0f8
Commands:
p, pick <commit> = use commit
r, reword <commit> = use commit, but edit the commit message
e, edit <commit> = use commit, but stop for amending
s, squash <commit> = use commit, but meld into previous commit
f, fixup <commit> = like "squash", but discard this commit's log message
x, exec <command> = run command (the rest of the line) using shell
b, break = stop here (continue rebase later with 'git rebase --continue')
d, drop <commit> = remove commit
l, label <label> = label current HEAD with a name
t, reset <label> = reset HEAD to a label
m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
.       create a merge commit using the original merge commit's
.       message (or the oneline, if no original merge commit was
.       specified). Use -c <commit> to reword the commit message.
These lines can be re-ordered; they are executed from top to bottom.
If you remove a line here THAT COMMIT WILL BE LOST.
However, if you remove everything, the rebase will be aborted.
Note that empty commits are commented out
`

需要重点注意的是相对于正常使用的 log 命令，这些提交显示的顺序是相反的。
运行一次 'log' 命令，会看到类似这样的东西：

`
$ git log --pretty=format:"%h %s" HEAD~3..HEAD
a5f4a0d added cat-file
310154e updated README formatting and added blame
f7f3f6d changed my name a bit
`

注意其中的反序显示。
交互式变基给你一个它将会运行的脚本。
它将会从你在命令行中指定的提交（HEAD~3）开始，从上到下的依次重演每一个提交引入的修改。
它将最旧的而不是最新的列在上面，因为那会是第一个将要重演的。

你需要修改脚本来让它停留在你想修改的变更上。
要达到这个目的，你只要将你想修改的每一次提交前面的 pick' 改为 edit'。
例如，只想修改第三次提交信息，可以像下面这样修改文件：

`
edit f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
`

当保存并退出编辑器时，Git 将你带回到列表中的最后一次提交，把你送回命令行并提示以下信息：

`
$ git rebase -i HEAD~3
Stopped at f7f3f6d... changed my name a bit
You can amend the commit now, with

       git commit --amend

Once you're satisfied with your changes, run

       git rebase --continue
`

这些指令准确地告诉你该做什么。
输入

$ git commit --amend

修改提交信息，然后退出编辑器。
然后，运行

$ git rebase --continue

这个命令将会自动地应用另外两个提交，然后就完成了。
如果需要将不止一处的 pick 改为 edit，需要在每一个修改为 edit 的提交上重复这些步骤。
每一次，Git 将会停止，让你修正提交，然后继续直到完成。

重新排序提交 #

也可以使用交互式变基来重新排序或完全移除提交。
如果想要移除 “added cat-file” 提交然后修改另外两个提交引入的顺序，可以将变基脚本从这样：

`
pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
`

改为这样：

`
pick 310154e updated README formatting and added blame
pick f7f3f6d changed my name a bit
`

当保存并退出编辑器时，Git 将你的分支带回这些提交的父提交，应用 310154e 然后应用 f7f3f6d，最后停止。
事实修改了那些提交的顺序并完全地移除了 “added cat-file” 提交。

压缩提交 #

通过交互式变基工具，也可以将一连串提交压缩成一个单独的提交。
在变基信息中脚本给出了有用的指令：

`
Commands:
p, pick <commit> = use commit
r, reword <commit> = use commit, but edit the commit message
e, edit <commit> = use commit, but stop for amending
s, squash <commit> = use commit, but meld into previous commit
f, fixup <commit> = like "squash", but discard this commit's log message
x, exec <command> = run command (the rest of the line) using shell
b, break = stop here (continue rebase later with 'git rebase --continue')
d, drop <commit> = remove commit
l, label <label> = label current HEAD with a name
t, reset <label> = reset HEAD to a label
m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
.       create a merge commit using the original merge commit's
.       message (or the oneline, if no original merge commit was
.       specified). Use -c <commit> to reword the commit message.
These lines can be re-ordered; they are executed from top to bottom.
If you remove a line here THAT COMMIT WILL BE LOST.
However, if you remove everything, the rebase will be aborted.
Note that empty commits are commented out
`

如果，指定 “squash” 而不是 “pick” 或 “edit”，Git 将应用两者的修改并合并提交信息在一起。
所以，如果想要这三次提交变为一个提交，可以这样修改脚本：

`
pick f7f3f6d changed my name a bit
squash 310154e updated README formatting and added blame
squash a5f4a0d added cat-file
`

当保存并退出编辑器时，Git 应用所有的三次修改然后将你放到编辑器中来合并三次提交信息：

`
This is a combination of 3 commits.
The first commit's message is:
changed my name a bit

This is the 2nd commit message:

updated README formatting and added blame

This is the 3rd commit message:

added cat-file
`

当你保存之后，你就拥有了一个包含前三次提交的全部变更的提交。

拆分提交 #

拆分一个提交会撤消这个提交，然后多次地部分地暂存与提交直到完成你所需次数的提交。
例如，假设想要拆分三次提交的中间那次提交。
想要将它拆分为两次提交：第一个 “updated README formatting”，第二个 “added blame” 来代替原来的 “updated README formatting and added blame”。
可以通过修改 rebase -i 的脚本来做到这点，将要拆分的提交的指令修改为 “edit”：

`
pick f7f3f6d changed my name a bit
edit 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
`

然后，当脚本带你进入到命令行时，重置那个提交，拿到被重置的修改，从中创建几次提交。
当保存并退出编辑器时，Git 带你到列表中第一个提交的父提交，应用第一个提交（f7f3f6d），
应用第二个提交（310154e），然后让你进入命令行。
那里，可以通过 git reset HEAD^ 做一次针对那个提交的混合重置，实际上将会撤消那次提交并将修改的文件取消暂存。
现在可以暂存并提交文件直到有几个提交，然后当完成时运行 git rebase --continue：

`
$ git reset HEAD^
$ git add README
$ git commit -m 'updated README formatting'
$ git add lib/simplegit.rb
$ git commit -m 'added blame'
$ git rebase --continue
`

Git 在脚本中应用最后一次提交（a5f4a0d），历史记录看起来像这样：

`
$ git log -4 --pretty=format:"%h %s"
1c002dd added cat-file
9b29157 added blame
35cfb2b updated README formatting
f3cc40e changed my name a bit
`

再次强调，这些改动了所有在列表中的提交的 SHA-1 校验和，所以要确保列表中的提交还没有推送到共享仓库中。

核武器级选项：filter-branch #

有另一个历史改写的选项，如果想要通过脚本的方式改写大量提交的话可以使用它——例如，全局修改你的邮箱地址或从每一个提交中移除一个文件。
这个命令是 filter-branch，它可以改写历史中大量的提交，除非你的项目还没有公开并且其他人没有基于要改写的工作的提交做的工作，否则你不应当使用它。
然而，它可以很有用。
你将会学习到几个常用的用途，这样就得到了它适合使用地方的想法。

git filter-branch 有很多陷阱，不再推荐使用它来重写历史。
请考虑使用 git-filter-repo，它是一个 Python 脚本，相比大多数使用 filter-branch
的应用来说，它做得要更好。它的文档和源码可访问 https://github.com/newren/git-filter-repo 获取。

从每一个提交中移除一个文件 #

这经常发生。
有人粗心地通过 git add . 提交了一个巨大的二进制文件，你想要从所有地方删除。
可能偶然地提交了一个包括一个密码的文件，然而你想要开源项目。
filter-branch 是一个可能会用来擦洗整个提交历史的工具。
为了从整个提交历史中移除一个叫做 passwords.txt 的文件，可以使用 --tree-filter 选项给 filter-branch：

`
$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
Ref 'refs/heads/master' was rewritten
`

--tree-filter 选项在检出项目的每一个提交后运行指定的命令然后重新提交结果。
在本例中，你从每一个快照中移除了一个叫作 passwords.txt 的文件，无论它是否存在。
如果想要移除所有偶然提交的编辑器备份文件，可以运行类似 git filter-branch --tree-filter 'rm -f *~' HEAD 的命令。

最后将可以看到 Git 重写树与提交然后移动分支指针。
通常一个好的想法是在一个测试分支中做这件事，然后当你决定最终结果是真正想要的，可以硬重置 master 分支。
为了让 filter-branch 在所有分支上运行，可以给命令传递 --all 选项。

使一个子目录做为新的根目录 #

假设已经从另一个源代码控制系统中导入，并且有几个没意义的子目录（trunk、tags 等等）。
如果想要让 trunk 子目录作为每一个提交的新的项目根目录，filter-branch 也可以帮助你那么做：

`
$ git filter-branch --subdirectory-filter trunk HEAD
Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
Ref 'refs/heads/master' was rewritten
`

现在新项目根目录是 trunk 子目录了。
Git 会自动移除所有不影响子目录的提交。

全局修改邮箱地址 #

另一个常见的情形是在你开始工作时忘记运行 git config 来设置你的名字与邮箱地址，
或者你想要开源一个项目并且修改所有你的工作邮箱地址为你的个人邮箱地址。
任何情形下，你也可以通过 filter-branch 来一次性修改多个提交中的邮箱地址。
需要小心的是只修改你自己的邮箱地址，所以你使用 --commit-filter：

`
$ git filter-branch --commit-filter '
        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
        then
                GIT_AUTHOR_NAME="Scott Chacon";
                GIT_AUTHOR_EMAIL="schacon@example.com";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD
`

这会遍历并重写每一个提交来包含你的新邮箱地址。
因为提交包含了它们父提交的 SHA-1 校验和，这个命令会修改你的历史中的每一个提交的 SHA-1 校验和，
而不仅仅只是那些匹配邮箱地址的提交。

Git工具-重写历史：如何在提交后修改Commit的内容?

oculus-base-setup

 仓库地址 

0X01 这个仓库有什么用？ #

通过这个仓库你可以在unity快速配置Oculus的开发环境。并且这个仓库中包含了Oculus quest/quest2的基本交互。如：控制器按钮交互、手部模型交互、贝塞尔曲线指针、传送。并且可在原来的基础上简单地进行攀爬，抓取等动作拓展。

0X02 参数说明 #

1. 运行环境：Unity 2019.x

2. 测试设备：Oculus Quest/Quest2、Oculus Rift（上述设备已通过测试，其他型号的设备请自行测试）

3. 依赖说明：本项目用到以下包(Packages)，按照从属关系列出：

   > Malimbe
   >
   > >Zinnia
   > >
   > >> VRTK

   以及最基本的Oculus Integration(在Unity的Asset Store下载)

   下文会给出Packages的下载地址。

0X03 开始使用 #

1. 克隆本仓库

   git clone https://github.com/yeliheng/oculus-base-setup.git

2. 用Unity打开本项目

3. 添加依赖。

   3.1.在Unity Asset Store下载Oculus Integration库，按照提示Upgrade和Restart。

   3.2.按照0X02的依赖说明依次导入所需的Package。顺序依次是：Malimbe->Zinnia->VRTK

   （导入包在Unity的操作：点击Window->Package Manager->+->Add package from disk->选择package.json文件即可）

   依赖包下载地址：

   链接：https://pan.baidu.com/s/11QO8DMKYVvK2jJB8IS2tlA 
   提取码：lw1i 

4. 进入play mode 体验。Enjoy yourself!

0X04 项目截图

!手模

!传送和指针

0X05 Yeliheng的技术小站

帮助你快速实现指针曲线、传送、手部模型甚至攀爬等交互

[开源项目]快速构建Oculus开发环境和基本交互

Springboot下通过Jpa连接MySQL数据库实现ORM对象关系映射 #

 1.1 依赖的搭建 

要在Springboot中使用Jpa首先要引入项目依赖，这里以Maven为例: 

`xml
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>6.0.6</version>
</dependency>
`

  1.2 配置数据源 

等到Maven Sync完成后，我们需要在application.properties文件中配置数据源。

`properties
注释: 在jdbc的url中，需要注意: 
编码设置为utf-8
时区需要手动指定，否则在使用系统自动管理的Timestamp时会出现时间与北京时间相差11小时左右
spring.datasource.url=jdbc:mysql://数据库IP:端口/数据库名称?charset=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai
spring.datasource.username=你的用户名
spring.datasource.password=你的密码
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
在Springboot版本>=2.0,请根据需要将数据库引擎切换为InnoDB
spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect
是否在控制台输出sql语句
spring.jpa.show-sql=true
自动生成ddl语句
这里需要解释一下常用参数: 
create: 每次加载Hibernate时删除数据库中所有的数据和表，再重新创建新的(慎用!)
update: 当表不存在时自动创建数据表，当表存在时自动根据model更新表的结构，表中的数据保持不变。(常用)
(注意:当model中的字段被删除时，update模式是不会删除字段的)
validate: 每次加载Hibernate时比对表的结构，根据model自动做出修改,!但是新的表不会被创建!
spring.jpa.hibernate.ddl-auto=update
`

 1.3 开始使用 

 1.3.1 数据实体类的创建 

首先，需要创建数据实体类。这里以User表的实体类为例:  (UsersDO.java)

`java
package com.yeliheng.test.domain;

import org.hibernate.annotations.CreationTimestamp;
import org.hibernate.annotations.UpdateTimestamp;

import javax.persistence.*;
import java.time.LocalDateTime;

@Entity
@Table(name = "users")
public class UsersDO {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    @Column
    private String nickname;
    @Column
    private String phone;
    @Column
    private String password;
    @CreationTimestamp
    private LocalDateTime createDateTime;
    @UpdateTimestamp
    private LocalDateTime updateDateTime;

    public String getNickname() {
        return nickname;
    }

    public void setNickname(String nickname) {
        this.nickname = nickname;
    }

    public String getPhone() {
        return phone;
    }

    public void setPhone(String phone) {
        this.phone = phone;
    }

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }

    public LocalDateTime getCreateDateTime() {
        return createDateTime;
    }

    public void setCreateDateTime(LocalDateTime createDateTime) {
        this.createDateTime = createDateTime;
    }

    public LocalDateTime getUpdateDateTime() {
        return updateDateTime;
    }

    public void setUpdateDateTime(LocalDateTime updateDateTime) {
        this.updateDateTime = updateDateTime;
    }

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }
}

`

这里对以上代码的关键点进行解释：

@Entity 注解：用于数据库的实体类均需要加上Entity注解

@Table 注解：顾名思义，这是一个表注解，可在name属性中赋值需要的表名。默认表名与类名相同

@Id : 表示主键ID，如果想让id自增则需要再加上@GeneratedValue(strategy = GenerationType.IDENTITY)注解

@Column 注解：表示这是一个字段

这里，我们希望将数据的创建时间与更新时间交给框架来管理，则我们需要加上@CreationTimestamp和@UpdateTimestamp注解。并将数据类型定义为LocalDateTime。

这样有什么好处？首先，我们无需在数据更新时自行去实现时间更新的逻辑，用户的注册时间以及更改时间完全交付给系统管理，提供很大的便利。其次，我们无需自行格式化时间戳，因为Jpa的时间戳与MySQL的时间戳有格式上的不同，在格式化的过程中，极其容易踩坑。

 1.3.2 开始与数据库进行交互(Dao层的创建) 

首先解释一下什么叫DAO层

DAO即Data Access Object，能够实现对数据持久化的访问。不止是数据库，持久化的数据例如文件的操作，都可在DAO层进行。也算是一种规范。简单地说，DAO层用于隔离业务逻辑代码和数据访问代码，隔离不同数据的实现。

Jpa已经帮忙封装完Dao层的相关代码，所以，我们实现增删改查十分容易。只需要定义一个接口，这个接口继承自org.springframework.data.repository.Repository<T, ID> 接口，一句话即可完成初始化。T表示数据的实体类，例如我们的UsersDO类，ID表示实体类的主键类型。最后，别忘了加上@Respository这个注解，这个注解用于表示存储层Bean。代码如下:

`java
package com.yeliheng.test.dao;

import com.yeliheng.test.domain.UsersDO;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

@Repository
public interface UsersDao extends JpaRepository<UsersDO,Long> {
    Boolean existsByPhone(String phone);
    UsersDO findByPhone(String phone);
}

`

我们在定义完接口后，在接口中实现了两个方法：顾名思义，一个是通过手机号判断用户是否存在，一个是通过手机号查找用户。

就这么简单，Jpa就可以实现查询功能。

稍微提一下方法名称: 

findByXXX：XXX表示你要查什么字段。你甚至可以findByXXXAndXXXAndXXXAndXXX......多少字段都没问题，中间用And进行连接。超级方便。

exists同理。

这里仅仅列举了两种操作，Jpa的接口功能十分强大， 可自行定制使用其他功能，例如排序、分页、多表联查等等等等...用户自行查表获取。

 1.3.3 在service里调用 

 增 

通俗易懂，直接上代码。

`java
@Autowired
private UsersDao usersDao;
public void addUser(){
  UsersDO usersDO = new UsersDO();
  usersDO.setPhone("11111111111");
  usersDO.setPassword("h3khj1￥sdjs%
  usersDao.save(usersDO);
}
`

 删 

`java
@Autowired
private UsersDao usersDao;
public void deleteUser(){
  UsersDO usersDO = usersDao.findByPhone("1111111111");
  usersDao.delete(usersDO);
}
`

 改 

与增的方法相同，就是多一步查找出UsersDO的实例，再调用set方法进行设置，最后save即可。

`java
@Autowired
private UsersDao usersDao;
public void updateUser(){
  UUsersDO usersDO = usersDao.findByPhone("1111111111");
  usersDO.setPhone("12222222222");
  usersDao.save(usersDO);
}
`

 查 

`java
@Autowired
private UsersDao usersDao;
public void queryUser(){
  UsersDO usersDO = usersDao.findByPhone("1111111111");
}
`

Springboot下通过Jpa连接MySQL数据库实现ORM对象关系映射

下载地址 #

点击下载 版本: v1.2.0

注: 项目作为学习用途，源代码仍可通过GitHub查看，亦可自行编译运行

正文 #

这次的疫情对人类来说是一次灾难，渺小的我不知该如何是好。我希望能够通过写程序来为社会贡献一份自己微薄的力量。经过几天的思考，我决定使用Unity3D疫情和C
![](/uploads/kodo/1405923_672f85b3_7664_3494%402217x1506.png.m.jpg)
这个疫情可视化的地球可以直观地看出各个地区的疫情分布情况，中国精确到省份，外国精确到全国(以首都为国家位置)。使用Unity 粒子系统来进行数据的渲染，白色最轻，接着是黄色，严重是红色。粒子的密度和颜色的深浅可以反映出一个地区的严重程度。地球是可以用鼠标拖动的，滚轮可缩放。

![](/uploads/kodo/1405923_672f85b3_7664_3494%402217x1506.png.m.jpg)

![](/uploads/kodo/1405923_0d2c3a9e_7664_35%403840x2160.jpeg.m.jpg)

接下来说说项目的开发流程。其实在开发的过程中，遇到很多大大小小的坑，也不是那么容易。
首先是地球场景的构建。我直接采用一个球体，调整到合适的大小，并贴上世界地图的贴图。(贴图的资源来源于互联网，不用于任何商业用途，侵删！)。
接着就是最关键的环节: 数据的获取与数据的渲染。
数据接口是来自腾讯新闻的疫情大数据，可以获取到全球的所有疫情数据。疫情的数据已经拿到， 但是拿到的数据只有地区和确诊人数，要如何将它们渲染到球体上呢？

![](/uploads/kodo/1405923_bbb5fc12_7664_3502%403645x1632.png.m.jpg)

这个问题困扰了我一段时间。因为我的球体采用简单的建模方式，并没有数据在上面，手动一个地区一个地区放置是绝对不可能完成的。所以后面我采用了一种方法：先获取各个地区的经纬度信息，再将经纬度转换成球体坐标，将数据以粒子的形式进行渲染。

![](/uploads/kodo/1405923_1ae914b7_7664_3504%403776x1707.png.m.jpg)

经纬度的数据来源于Google地图云服务，由于Google有日请求量限制，所以我做了缓存，仅在有改动时才会进行请求。
在拿到经纬度数据后，我尝试将它转换为unity中对应的球体坐标。这个环节我卡了好久，因为我进行了好多计算，都没办法精确地将数据渲染到具体位置。经过我的不懈努力，和查阅了大量关于球体坐标的资料后，我终于成功了哈哈哈(我太难了~)

![](/uploads/kodo/1405923_067c404b_7664_3506%403425x1115.png.m.jpg)

数据可以精确地渲染到全球的各个地区，并且如果有新的确诊案例，地图上会自动渲染数据。
本项目已开源，希望能尽自己的一分微薄之力，与大家一同共渡难关。

![](/uploads/kodo/1405923_47e8e8fe_7664_3508%402364x1388.png.m.jpg)

开源仓库地址: https://github.com/yeliheng/NcovEarth

真希望这场疫情快点过去。感谢医学工作者在前线默默地奉献着自己的生命，向你们致敬！辛苦了！！！
武汉加油！中国加油！世界加油！大家齐心协力，定能共渡难关！待到春暖花开时，我们再一起共赏祖国的大好河山！！！

[公益项目]用unity引擎呈现疫情大数据

前言 #

上周，我们团队组织前往北京进行为期一周的区块链培训，写一篇来总结这次培训，白嫖许多知识/滑稽，也算不虚此行。

这里感谢布比区块链公司对我们团队提供的支持！

---

区块链总结 #

 概念 

首先从区块链的概念开始，什么是区块链。简单笼统地说，一种多方共同维护同一份“账本”的技术就是区块链。当然，此处不止局限于账本，账本仅作为举例。

 特点 

区块链的特点: 不可伪造、全程留痕、可以追溯、公开透明、集体维护等

区块链之所以具有这些特点，具体就要追溯到数学算法和密码学上。

 共识算法 

区块链拥有多种共识算法，用于验证该笔交易是否有效。

>注:这里的交易不止是金融上交易的概念，在区块链中，每次的上链统称交易(transaction)

共识算法有很多种，各有优劣。了解共识算法之前需要先了解拜占庭将军问题。
这里采用百度百科的概念简单介绍:

 拜占庭将军问题 

拜占庭位于如今的土耳其的伊斯坦布尔，是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔，为了达到防御目的，每个军队都分隔很远，将军与将军之间只能靠信差传消息。 在战争的时候，拜占庭军队内所有将军和副官必须达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，在军队内有可能存有叛徒和敌军的间谍，左右将军们的决定又扰乱整体军队的秩序。在进行共识时，结果并不代表大多数人的意见。这时候，在已知有成员谋反的情况下，其余忠诚的将军在不受叛徒的影响下如何达成一致的协议，拜占庭问题就此形成。

拜占庭将军问题是一个协议问题，拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开来的，并且将军中存在叛徒。叛徒可以任意行动以达到以下目标：欺骗某些将军采取进攻行动；促成一个不是所有将军都同意的决定，如当将军们不希望进攻时促成进攻行动；或者迷惑某些将军，使他们无法做出决定。如果叛徒达到了这些目的之一，则任何攻击行动的结果都是注定要失败的，只有完全达成一致的努力才能获得胜利。

  实用拜占庭容错算法(PBFT)  

在实际开发中，我们采用的是实用拜占庭容错算法，改进型实用拜占庭容错的共识机制是少数服从多数，根据信息在分布式网络中节点间互相交换后各节点列出所有得到的信息，一个节点代表一票，选择大多数的结果作为解决办法。PBET将容错量控制在全部节点数的1/3，即如只要有超过2/3的正常节点，整个系统便可正常运作。

---

包括PBFT在内，还有许多种共识算法，这里通过一张图介绍，概括优劣。

![](/uploads/kodo/WX20200211-215737%402x.png)

其中，POW工作量证明就是我们常说的“挖矿”。

 加密方式 

简单介绍完几种常见的共识算法，接下来关注密码学上常见的两种加密方式。如图所示:

![](/uploads/kodo/WX20200211-220213%402x.png)

流程清晰明了。

 交易流程 

区块链中的交易主要分为以下两种模型: UTXO模型的账本、Account模型的账本。

 UTXO模型的账本 

UTXO即未花费交易输出，通俗的讲，相当于你把100元存入某个地方，呃，就叫银行吧，然后银行在存储这笔钱时，将其分为10元、20元、20元、50元进行存储，也可以理解为现实中的找零。。较为抽象

优点：

计算是在链外的，交易本身既是结果也是证明。节点只做验证即可，不需要对交易进行额外的计算，也没有额外的状态存储。交易本身的输出 UTXO 的计算是在钱包完成的，这样交易的计算负担完全由钱包来承担，一定程度上减少了链的负担。

交易的 Input 始终是链接在某个 UTXO 后面。交易无法被重放，并且交易的先后顺序和依赖关系容易被验证，交易是否被消费也容易被举证。

UTXO 模型是无状态的，更容易并发处理。

安全性比Account高

缺点：

无法实现一些比较复杂的逻辑，可编程性差。对于复杂逻辑，或者需要状态保存的合约，实现难度大，且状态空间利用率比较低。

当 Input 较多时，见证脚本也会增多。而签名本身是比较消耗 CPU 和存储空间的。

![](/uploads/kodo/WX20200211-221743%402x.png)

 Account模型的账本 

顾名思义,Account模型即账户模型，也就是每笔交易都有对应的账户，围绕账户进行。Account模型保存了交易的事件状态，交易只是事件本身，不包含结果，交易的共识和状态的共识本质上可以隔离的。

优点：

合约以代码形式保存在 Account 中，并且 Account 拥有自身状态。这种模型具有更好的可编程性，容易使开发人员理解，场景更广泛。

批量交易的成本较低。

缺点：

Account 模型交易之间没有依赖性，需要解决重放问题。

对于实现闪电网络/雷电网络，Plasma 等，用户举证需要更复杂的 Proof 证明机制，子链向主链进行状态迁移需要更复杂的协议。

工作原理如图所示

![](/uploads/kodo/WX20200211-222040%402x.png)

---

 上链流程 

上链是交易的关键一步，直接关系到此次交易是否成功，流程如下图所示。

![](/uploads/kodo/WX20200211-222231%402x.png)

最后，我以以太坊为平台，成功发布了自己的智能合约(YlhCoin)，具体发布流程请自行查阅手册。

代码如下:

ylhCoin.sol

`js
pragma solidity ^0.5.14;
contract MyCoin{
	address public god;
	uint256 public total;
	mapping(address => uint256) public balances;
	
	constructor() public{
		god = msg.sender;
		total = 10000000;
		balances[god] = total;
	}
	//获取余额
	function getBal(address owner) public view returns(uint256){
		return balances[owner];
	}
	//转账
	function transaction(address payee,uint256 amount) public returns(bool){
		address owner = msg.sender;
		require(amount > 0);
		require(balances[owner] >= amount);
		balances[owner] -= amount;
		balances[payee] += amount;
		return true;
	}
}

`

ylhCoin_OpenSource.js

`javascript

let fs = require('fs');
let Web3 = require('web3');
let privateKey = Buffer.from("你的私钥","hex");
let Tx = require('ethereumjs-tx').Transaction;
//打开服务器
let provider = new Web3.providers.HttpProvider("https://ropsten.infura.io/v3/8a4622e55aa842d99e232dafdece2605");
let web3 = new Web3(provider);
//console.log(web3);

//读取ABI和BIN
ylhCoinABIObj = fs.readFileSync('ylhCoin_sol_MyCoin.abi');
ylhCoinABIJson = JSON.parse(ylhCoinABIObj.toString());
//console.log("ABI:" + ylhCoinABIObj.toString());
console.log("-------------------------");
ylhCoinBinObj = fs.readFileSync('ylhCoin_sol_MyCoin.bin');
ylhCoinByte = ylhCoinBinObj.toString();
//console.log("BIN:" + ylhCoinByte);
console.log("-------------------------");

//部署合约
account = {
address: "钱包地址",
privateKey: "你的私钥"
}
//console.log("当前账户: " + account);
contract = new web3.eth.Contract(ylhCoinABIJson);
//contract = new web3.eth.Contract(ylhCoinABIJson);//合约核心文件(ylhCoinABIJson)
//console.log(contract);

(async()=>{
let nowNonce = await web3.eth.getTransactionCount(account.address);
console.log("Nonce: " + nowNonce);
//构建交易(合约数据)
txData = {
	nonce: nowNonce,
	data:  "0x" + ylhCoinByte,
	from: account.address,
	gasPrice: '0x01',
	gasLimit: '0xfffff',
	value: web3.utils.toHex(web3.utils.toWei("1","ether")),
	to: '收款人的钱包地址'
}
//签发交易(使用私钥)
let tx = new Tx(txData,{
	chain: "ropsten",
	//hardfork: "petersburg"
});
tx.sign(Buffer.from(privateKey,"hex"));
let serializedTx = tx.serialize();
//sendSignedTransaction
//签发!
web3.eth.sendSignedTransaction('0x' + serializedTx.toString('hex')).on('receipt',console.log);
})();

`

最终运行效果如图:

![](/uploads/kodo/46405AD0-E478-42EE-9C4B-AB45F016FBB1_1_105_c.jpeg)

代码地址:Yeliheng-Github

完结撒花

12月北京区块链培训总结

# 👋 Hey，我是 Yeliheng

Java 后端工程师，专注构建高并发、高可用系统，关注架构的鲁棒性和可扩展性。

追求代码的表达力与演进能力，热衷以工程化手段提升系统韧性与开发效率。

## 💻 专攻领域

- Java / JUC / 并发控制 / 函数式编程
- Spring 全家桶及底层：Spring / Spring Boot / Spring Cloud
- 消息系统：RabbitMQ，熟悉队列设计与消息幂等
- 数据存储：MySQL / MongoDB / Redis，熟悉分片、事务与调优
- 分布式基础设施：Docker / Kubernetes / Jenkins / GitOps
- 数据监控：Prometheus / Grafana / ELK / Alertmanager

## 📫 联系方式

- GitHub: [🔗 Yeliheng](https://github.com/yeliheng)
- Email: yeliheng00@gmail.com
