1. 要项目拉取权限
   这一点虽然很废话，但是你刚来就敢主动找 mt 要项目不？
2. 有没有开发规范和接口文档？
   问 mt 要一个看，如果没有那也没事，有的话会更方便你后续开发
3. 寻找 main

• main 是运行代码的入口，只有找到了它，你才能开始后续的操作
• 一般来说 main 中会包含：
  • 配置初始化
  • 定时任务启动（当然，一般一个已经稳定的项目，它的定时任务是分离出去的）
  • 创建 web 服务器

4. 快速熟悉项目代码风格

• 先寻找 router ，在 router 中寻找一个你认为分离得比较成功的路由小模块
• 看路由写法
• 随机找一个接口进去看
• 如果你有开发规范文档，那么就可以结合着文档了解他们的接口名、函数名、变量名、结构体名这些命名规范
• 看它是怎么使用 log 、 db 和 cache 的
• 如何处理错误，错误应该如何构建
• 常量是放在哪里的？
• 好了，现在回过头来看一下，你一路追下来的文件的文件夹层是怎么个分布法（恭喜，你已经会写一个符合团队风格的接口了）
• 寻找 config ，你只有一个任务，它是怎么读配置的

5. 同步业务信息

• 直接看 git 提交记录，等同于爬楼看聊天记录一样，如果前者的 commit 写得正常点，你就能快速看懂它在干嘛

1. 开启交易会话
   1. 使用平台提供的私钥，向平台的创建交易会话的接口发起请求，生成一个交易链接，需要提供价格ID、商品数量、成功支付重定向链接、取消支付重定向链接等自定义参数
   2. 价格ID：价格在stripe中是一个概念实体，比如你有一个VIP服务商品，可以一次性开通一个月，也可以连续包月，那这个商品就有两个价格了，每个价格的单价与结算方式是不一样的，同时每个价格都有唯一的ID，即价格ID
2. 事件监听
   【背景】用户的支付是在第三方平台完成的，对于我们服务端来说是无感知的，即你无法直接得知用户是否付完钱、哪个用户付了哪一笔钱。所以你需要向第三方平台订阅这个消息，这个订阅也叫做事件监听
   1. 创建服务端事件回调接口：当第三方平台想要向服务端发送消息时，就会把消息发送到事件回调接口，事件回调接口接收消息并正确处理消息（包括：将订单状态转为成功支付）
   2. 注册第三方事件监听：在第三方注册自己的回调接口以及需要触发回调的事件类型
   3. 事件成功监听：第三方与服务端会约定一个规则来确认是否服务端成功接收并处理事件，例如服务端成功接收并处理事件就返回200状态码
   4. 事件重发行为：由于网络环境复杂，不能确保发一次消息就能成功，所以一般第三方会有不断重发的行为逻辑，知道得到服务端的确认（例如：200状态码）
   5. 事件监听的不可信：不论是网络问题还是第三方平台服务崩溃问题，都有可能导致消息发送失败，并且支付可能有延迟完成的情况（比如银行走流程确认转帐什么的），所以第三方支付一般不保证事件实时发送给服务端
   6. 事件鉴权：与第三方约定好一个鉴权机制，确保请求事件监听回调接口的是第三方
3. 最终方案
   1. 发起交易会话的同时，生成一个订单ID，与会话ID结合加密生成一个新ID
   2. 支付成功重定向的网址拿会话ID请求事件回调接口，事件回调接口发现无法通过strip的鉴权，认为是重定向的请求，此时向strip发起请求确认交易会话状态
   3. 为了防止支付成功并重定向那一刻服务端崩溃，以事件监听作为兜底机制
   4. strip请求事件回调接口，通过strip的鉴权，可以信任strip发来的事件状态，也可以不信任，重新向strip发起请求确认交易会话状态
   5. 总体采用状态机模式
   6. 确认订单状态，完成订单

联合文件系统

联合文件系统（Union File System）UnionFS是docker制作镜像和容器文件的主要技术。通过联合文件系统，可以将多个路径挂载到同一个挂载点上，实现多个path的合并操作（上层同名文件会将下层文件覆盖），最后通过挂载点想上层应用/用户呈现一个合并之后的视图，联合文件系统有多种实现，ubuntu采用AUFS实现，centos采用overlay/overlay2来实现。

• 随着技术和业务不断迭代，镜像层不断叠加，会出现非常大的镜像，以默认的docker配置拉取的话，网络一旦波动就会前功尽弃，这其实是非常灾难性的情况
• docker可以通过在配置文件中添加👇的配置内容，重启docker后就可以支持断点续传

1
2
3

 "features": {
 "containerd-snapshotter": true
}

• 断点续传配置生效后，docker原有的镜像将无法识别，也就是假性清空，可以把断点续传配置取消，镜像就又能识别了

原理

• docker断点续传本质是不断对拉取的镜像层打“快照”，如果你有一次突然中断了拉取，再次进行拉取时，docker会取出快照，接着原来的进度继续拉取，所以断点续传会产生较多的冗余数据，占空间

最近发现一种很奇葩的情况：

A机push镜像a（版本：0.0.0，hash值：a）到harbor

A机修改了a的容器并commit了镜像b（版本：0.0.0，hash值：b）

A机push镜像b上harbor

A机 save镜像a成tar包并通过USB直接传给B机

B机load tar包得到镜像a（版本号：0.0.0，hash值：a）

B机pull harbor上版本号为0.0.0的镜像

发现B机全部层重拉

B机pull harbor上hash为a的镜像，不用重拉

但是，dockerHub完全没有以上问题，区别就在于，dockerHub和harbor的存储结构不一样，harbor有一个镜像层标识，docker save会抹除这个标识，导致无法识别

1. githubflow有什么用

githubflow是指github的工作流（详细可看github的Action选项）

githubflow常用于：

• merge时，自动检测是否有错误
• merge时，自动打包镜像并部署（这个最厉害，自动化cicd）

1.语法

使用的是yaml语法

示例

• 2.1

1
2
3

on:
  push: //当进行push时
    branches:[ "master" ] //push到分支master时

• 2.2

1
2
3
4
5
6
7
8
9

jobs:
  build: //构建阶段
    runs-on: ubuntu-latest //使用ubuntu-latest镜像
    
    steps: //后续步骤
    - uses: action/checkout@v3 //使用该action库，actions/checkout 是一个官方提供的 GitHub Action，用于检查出代码。@v3 指定了动作的版本，这里使用的是版本 3
    - name: (该过程的名称，自定义)
      run: |  //|用于表示准备多行字符串
      （这里写一下自己的构建镜像的shell命令）