安装node：

yum install -y nodejs

安装hexo脚手架：

npm install -g cnpm --registry=https://registry.npm.taobao.org

cnpm install -g hexo-cli

安装git（因为不安装会初始化很慢）：

yum install -y git

初始化一个博客：

hexo init blog

启动服务（可以提供http服务）

hexo server

下载工具：

wget https://dl.eff.org/certbot-auto

给予执行权限：

chmod u+x certbot-auto

生成证书：

./certbot-auto certonly -d “*.yubangweb.com” -m xxx@yubangweb.com –manual –preferred-challenges dns-01 –server https://acme-v02.api.letsencrypt.org/directory

注意：上面的域名换成自己的，邮箱换成自己的。然后根据提示，在自己的域名解析添加txt记录完成验证

证书更新：

certbot-auto renew

Abstract Factory模式，抽象工厂模式。首先这种模式跟Factory模式非常相近，但是抽象工厂模式是创建一系列产品，而工厂模式创建的是一种产品。

应用场景：

1. 生成一组对象很复杂的时候

优点：

1. 封装性好

缺点：

1. 扩展性低，每增加一个产品，所有工厂子类都要同步增加

UML：

builder模式，可以组装复杂的实例。

构建者模式，首先定义一个类，然后这个类定义好一系列函数来生成必要数据，再提供一个函数来调用这些函数。

应用场景：

1. 初始化一个类非常复杂
2. 产品类的调用顺序对结果有影响

优点：

1. 客户端不需要知道产品内部细节，解耦性强
2. 创建流程清晰，方便控制创建流程

缺点：

1. 客户端代码变得冗长

UML:

例子：

产品线只需要定义各部分的工艺，就可以一个流程生产出产品。

prototype模式，通过复制生成实例。

通过复制已有实例生成一个新的实例。

应用场景：

1. 创建对象需要非常复杂的数据准备

优点：

1. 简化创建对象

缺点：

1. 每个类都需要实现clone方法

UML：

例子：

就像制作菜式一样，当你成功实践出一道美食，以后只需要复制烹饪的食材和方法即可。

Singleton模式，单例模式。

一个类仅有一个实例，然后全局提供访问。

使用场景：

1. 需要频繁实例化然后销毁的对象
2. 创建资源耗时过多或者资源消耗过大
3. 一些需要共享的资源

优点：

1. 资源利用率高

缺点：

1. 不适合频繁变化的对象

UML：

例子：

同一时刻只允许一个程序读取文件，只允许一个程序连接打印机。

Factory Method模式，工厂方法模式。

我们初始化类可以通过 new A1()，new A2()的方法产生，但是呢，假如初始化类的时候有一些需要转换的参数或其他需求，我们可以定义一个类B，然后通过类B的一个函数返回我们需要的初始化的实例。

但是这种通过一个类的函数生成不同的类的实例叫做简单工厂模式，但是当我们需要这个类（工厂类）生成非常多不同类的实例的时候，这个类就会变得非常臃肿。另一种解决方案是，生成不同的类的实例的逻辑实现放到工厂类的子类来实现，每个工厂类的实例只对应生成一个类的实例。

应用场景：

1. 在生成对象很复杂的时候
2. 需要解耦的时候
3. 需要扩展性的时候

优点：

1. 多态性
2. 扩展性好
3. 解耦

缺点：

1. 当生成类种类很多的时候，要对应编写很多工厂类

UML：

例子：

例如手机工厂，每生产一种型号的手机（产品类子类）就多开一条产品线（工厂类子类）。

Template Method模式，模板方法模式。当多个需求都有相同的操作步骤，仅仅是某些步骤实现不同的时候，就可以定义一个父类，固定结构。然后定义子类，实现具体的细节算法。

应用场景：

1. 多个需求都有很多相同的结构，仅仅是部分实现不同

优点：

1. 提高了代码复用性
2. 实现了反向控制

缺点：

1. 由于每一个实现都引入一个子类，所以增加了系统实现复杂度

UML：

例子：

一批同型号的榨汁机卖给一条街的店铺，店铺A放置苹果进去，得到苹果汁。店铺B放置西瓜进去，得到西瓜汁。使用流程都一样，但是具体使用，放置材料这步修改了，就得到不同的产物，这就是模板方法模式。

Adapter模式，就是适配器模式。

假如已有一个类（A），但是这个类输出的数据并不能满足新的需求。那么我们可以定义一个接口（B）需要实现函数（C），然后新建一个类（D）继承类（A）实现接口（B）。然后类（D）在实现函数（C）的时候，调用类A的函数，然后处理输出新的需求需要的数据。

应用场景：

1. 已有实现的类，但是不符合现有接口规范
2. 使用第三方api或者库的时候转变成自己需要的接口

优点：

1. 系统后期修改和扩展都很容易

缺点：

1. 过多的适配器会让系统变得凌乱

UML：

例子：

例如家里的插座交流电都是220V，但是我们各种电器需要的电压却各不相同，所以就需要一个电源适配器把电流转换成电器适合的电压，这就是适配器模式。

itorator模式，又称迭代模式，本质是提供统一的接口，让外部可以顺序访问到内部的数据。

对外暴露两个接口：

1. hasNext，是否还有下一个元素
2. next，返回下一个元素

为什么需要这种模式？因为底层数据实现可能是数组，也可能是链表，前者可以通过下标遍历，后者通过指针遍历。但是这样子，在调用的时候，调用者还要分别处理。假如我们在它们上面包裹一层，提供hasNext和next函数，那么调用者就可以统一来遍历处理了。

uml图：

例子：

我们平常的各种调味品，例如糖，盐，味精，我们都可以放到一个一个相同的罐子存储，使用时候用勺子拿出一点点。统一的取出方法，能判断还能不能取出，这就是迭代模式。