1.Element-Plus简介

Element-Plus:Element-plus是一套为构建基于Vue3的组件库而设计的UI组件库(UI Kit)。它为开发者提供了一套丰富的UI组件和扩展功能，例如表格、表单、按钮、导航、通知等，让开发者能够快速构建高质量的Web应用。

2.Vue3集成Element-Plus

2.1 安装依赖

安装依赖指令：

1

npm i element-plus -S

安装位置：

安装之后：

2.2 main.js导包

3.Button按钮

• 以Button按钮为例：

• Home.vue代码中：

4.Icon图标

4.1 安装依赖

安装依赖指令：

1

npm install @element-plus/icons-vue

安装位置：

4.2 main.js导包

4.3 具体使用

5.Element-Plus设置自定义主题色

5.1 安装依赖

安装依赖指令：

1
2
3
4

npm i sass@1.71.1 -D    【我的后面出现报错，更新到了1.86.3】--使用指令npm install sass@latest --save-dev
npm i unplugin-auto-import -D
npm i unplugin-element-plus -D
npm i unplugin-vue-components -D

安装位置：

安装之后：在总项目的package.json查看

5.2 创建index.scss文件

1
2
3
4
5
6
7

@forward "element-plus/theme-chalk/src/common/var.scss" with ($colors:(
  "primary": ("base": #0742b1),
  "success": ("base": #2b8f01),
  "warining": ("base": #ffad00),
  "danger": ("base": #d50707),
  "info": ("base": #74717f),
));

在src-assets文件下创建index.scss文件：

5.3 全局vite.config.js引入

修改三处位置：

具体代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

import { fileURLToPath, URL } from 'node:url'
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import vueDevTools from 'vite-plugin-vue-devtools'
//更改主题色-添加内容【引入index.scss内容】
import AutoImport from 'unplugin-auto-import/vite'
import Components from 'unplugin-vue-components/vite'
import { ElementPlusResolver} from 'unplugin-vue-components/resolvers'
import ElmentPlus from 'unplugin-element-plus/vite'

export default defineConfig({
  plugins: [
    vue(),
    vueDevTools(),
    //更改主题色-添加内容
    ElmentPlus({
      useSource: true,
    }),
    AutoImport({
      resolvers: [ElementPlusResolver({ importStyle: 'sass'})],
    }),
    Components({
      resolvers: [ElementPlusResolver({ importStyle: 'sass'})],
    }),
  ],

  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    },
  },
  //更改主题色-添加内容
  css: {
    preprocessorOptions: {
      scss: {
        additionalData: `
        @use "@/assets/index.scss" as *;   //注意是Esc按键下的``符号!!!
        `,
      }
    }
  },

})

5.4 查看对比

1.Vue简介

Vue (发音为 /vjuː/，类似 view) 是一款用于构建用户界面的 JavaScript 框架。它基于标准 HTML、CSS 和 JavaScript 构建，并提供了一套声明式的、组件化的编程模型，帮助你高效地开发用户界面。无论是简单还是复杂的界面，Vue 都可以胜任。

举例：

1
2
3
4
5
6
7
8
9

import { createApp, ref } from 'vue'

createApp({
  setup() {
    return {
      count: ref(0)
    }
  }
}).mount('#app')

1
2
3
4
5

<div id="app">
  <button @click="count++">
    Count is: {{ count }}
  </button>
</div>

结果展示：

• 声明式渲染：Vue 基于标准 HTML 拓展了一套模板语法，使得我们可以声明式地描述最终输出的 HTML 和 JavaScript 状态之间的关系。
• 响应性：Vue 会自动跟踪 JavaScript 状态并在其发生变化时响应式地更新 DOM。

1.1 渐进式框架

Vue是一个框架(生态)，能够覆盖大部分前端开发常见的需求。Vue 的设计非常注重灵活性和“可以被逐步集成”这个特点。根据你的需求场景，你可以用不同的方式使用 Vue：

• 无需构建步骤，渐进式增强静态的 HTML
• 在任何页面中作为 Web Components 嵌入
• 单页应用 (SPA)
• 全栈 / 服务端渲染 (SSR)
• Jamstack / 静态站点生成 (SSG)
• 开发桌面端、移动端、WebGL，甚至是命令行终端中的界面

1.2 单文件组件

在大多数启用了构建工具的 Vue 项目中，我们可以使用一种类似 HTML 格式的文件来书写 Vue 组件，它被称为单文件组件 (也被称为 *.vue 文件，英文 Single-File Components，缩写为 SFC)。顾名思义，Vue 的单文件组件会将一个组件的逻辑 (JavaScript)，模板 (HTML) 和样式 (CSS) 封装在同一个文件里。下面我们将用单文件组件的格式重写上面的计数器示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<script setup>
import { ref } from 'vue'
const count = ref(0)
</script>

<template>
  <button @click="count++">Count is: {{ count }}</button>
</template>

<style scoped>
button {
  font-weight: bold;
}
</style>

单文件组件是 Vue 的标志性功能。如果你的用例需要进行构建，我们推荐用它来编写 Vue 组件。

1.3 两种API风格

Vue 的组件可以按两种不同的风格书写：选项式 API 和组合式 API

1.3.1 选项式API(Options API)

• 用对象（包含多个选项）来描述组件的逻辑，例如 data、methods 和 mounted。选项所定义的属性都会暴露在函数内部的 this 上，它会指向当前的组件实例。

1.3.2 组合式API(Composition API)

• 用导入的 API 函数来描述组件的逻辑。在单文件组件中，组合式 API 通常会与

1.使用场景

我在做毕业设计和老师横向课题时，遇到我自己电脑写后端，其他人的前端调用我的场景：因此需要内网穿透【创建一个临时ip】，让其他人访问

2.cpolar介绍

2.1 下载并注册信息

• 进入官网之后注册登录一个账号，点击下载：
  

2.2 验证authtoken

• 点击左侧”验证”模块，保存authtoken：

2.3 启动http请求

• 打开本地cpolar下载位置打开cmd页面：输入cpolar.exe authtoken 2.2得到的authotoken

看到这样的提示语即证明成功！

• 在刚才的cmd页面：输入cpolar.exe http 8080(端口可变化)

2.4 访问

• 其他人就可以通过2.3得到的映射ip来访问：
  

3.整体流程

1.高并发定义

高并发：系统在单位时间内承受大量用户请求的能力【一般衡量高并发的指标就有QPS】

QPS:【Queries Per Second每秒查询次数】用来判断并发量的高低。

2.QPS范围

1.分支命名

不同公司中对Git的使用分支命名规范也略有差异，不过整体都会分为；上线、预发、开发、测试，这样几个分支。如图是一种比较简单使用的拉取分支方式。

• master/main 作为主分支，不可直接修改代码代码，只能从分支合并到主分支进行进行提交。同时，master 分支的合并需要进行审批，审批后才能合并。
• 开发前，先从 master 分支，拉一个开发分支。2024/10/11/xfg-xxx 使用带有斜线的分支命名会自动创建文件夹，对于多人开发的项目，可以直接归档。
• 后开发，也就是研发已经完成了本地的验证。进行测试时，可以把研发的开发分支合并到 test 分支，提交、部署、测试。遇到测试bug，需要回到可发分支修改代码，之后合并到 test 分支部署验证。
• pre/release 预发分支，用于测试完成后，把研发的开发分支合并到预发分支进行预发上线，上线后测试人员进行验证。最终完成验证后，把开发分支合并到 master 分支，并需要由架构师对合并代码审批通过。最后进行上线开量验证。
• 如果是修复bug的，可以添加一个 fix-用户名缩写-具体功能

2.提交规范

保持一个标准的统一的规范提交代码，在后续的评审、检查、合并，都会非常容易处理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 主要type
feat:     增加新功能
fix:      修复bug

# 特殊type
docs:     只改动了文档相关的内容
style:    不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert:   执行git revert打印的message

# 暂不使用type
test:     添加测试或者修改现有测试
perf:     提高性能的改动
ci:       与CI（持续集成服务）有关的改动
chore:    不修改src或者test的其余修改，例如构建过程或辅助工具的变动

3.合并分支

在公司中很多时候是大家一起在一个工程开发代码，那么这个时候就会涉及合并代码的。如果有多人共同开发一个接口方法，就会在合并的时候产生冲突。所以要特别注意。

1. 选择，你要从哪个分支合并到 test 分支。右键选择 Merge into test
2. 如果你合并到test分支的代码，有其他人也在同一行做了改变或者格式化了代码，就会弹出一个合并冲突。这个时候你需要点 Merge 进行合并。
3. 在点击 Merge 后，你会看到具体冲突的代码是什么，你可以有选择的从左右合并到中，最后点击 Apply。这个时候要注意不要把让别人的代码合并丢喽。
4. 合并完的代码，不要直接 push，你要先本地 install 看是否可以打包。以及如果可以运行的话，可以本地先跑一下。最后 push 提交合并代码即可。

4.回滚代码

如果出现了合并代码冲突后，丢失了代码，那么这个时候一般要进行回滚操作，重新合并。

虽然 Git 提供了回滚代码的功能，但一定要谨慎使用。怎么谨慎？第一个谨慎就是 push 的代码一定确保可以构建和运行，否则不要 push！第二个谨慎是要回滚代码，需要和团队中对应的伙伴打招呼，避免影响别人测试或者上线。

4.1 全量回滚

1. 先选择要在哪个分支的哪次提交上进行回滚。这里选择的是 test 分支上的提交进行回滚。
2. 这里选择 Hard 回滚。因为我们所有的都是合并到 test 分支，所以 test 分支丢失也没问题。可以重新合并。但要和同组伙伴提前说明。
3. 回滚后，你会看到代码只剩下从回滚往下的提交内容了。
4. 回滚后，你不能直接 push 提交了，这个之后会报错；fast-forward 因为此时本地分支落后于远程分支。
5. 所以要通过 git push origin HEAD --force 进行强制提交。或者你可以把 test 的远程分支删掉，之后在提交。

4.2 cherry-pick

只把我修改的部分合并上去，使用cheery pick

0.前提

在开发Web应用时，我们经常需要处理大量的数据展示，而分页功能几乎成了标配。它不仅提升了用户体验，还减轻了服务器的负担。今天，咱们就来聊聊一个在Java圈里非常流行的分页插件——PageHelper，看看它是如何在不动声色间帮我们搞定分页难题的。

1.定义

PageHelper是MyBatis的一个分页插件，它能够在不修改原有查询语句的基础上，自动实现分页功能。
简单来说，就是你在查询数据库时，告诉PageHelper你想看第几页、每页多少条数据，它就会帮你把结果集“裁剪”好。

2.分页原理

• 主要依赖于两个核心步骤：拦截器和分页SQL的生成

2.1 拦截器–Sql守门人

它首先会作为一个拦截器注册到MyBatis的执行流程中。这个拦截器就像是个守门人，会在SQL语句执行前和执行后进行一些“小动作”。

• 执行前：当你发起一个查询请求时，PageHelper会检查当前线程是否已经设置了分页参数（比如页码、每页数量）。如果设置了，它就会根据这些参数计算出需要跳过的记录数和要查询的记录数。
• 执行后：查询完成后，PageHelper还会对结果进行二次加工，比如封装成分页对象，包含总记录数、当前页的数据列表等信息。

2.2 分页SQL的生成

拦截到SQL语句后，PageHelper并不会直接修改你的原始SQL，而是通过动态生成一段分页SQL来实现分页功能。这个过程大致如下：

• 计算分页参数：根据你提供的页码和每页数量，计算出起始位置和结束位置。
• 拼接分页SQL：在原始SQL的基础上，添加LIMIT和OFFSET（或者数据库特定的分页语法，比如MySQL的LIMIT，Oracle的ROWNUM等），从而实现对结果集的裁剪。【如果要查询第20-30行数据。 limit 19,10 或者 limit 10 offset 19】
• 执行分页SQL：最终，这个经过“加工”的SQL会被提交给数据库执行，返回的就是你想要的那一页数据了。

3.使用操作

具体操作网页：如何使用分页插件

• 1.引入依赖：在你的项目中添加PageHelper的依赖，无论是Maven还是Gradle，都有现成的配置。

• 2.配置PageHelper：在MyBatis配置文件中简单配置一下PageHelper插件。

• 3.代码中分页：在需要分页的查询方法前，调用PageHelper.startPage(pageNum, pageSize)，其中pageNum是页码，pageSize是每页数量。

• 4.获取分页结果：执行查询后，你可以直接从返回的结果中获取分页信息，比如总记录数、当前页数据等。

后台分布式架构形形色色，特别是微服务和云原生的兴起，诞生了一批批经典的分布式架构，然而在公司内部，或者其他大型互联网企业，都是抛出自己的架构，从接入层Controller，逻辑层Service，数据层Mapper都各有特点，但这些系统设计中到底是出于何种考量，有没有一些参考的脉络呢，本文将从云原生和微服务，有状态服务，无状态服务以及分布式系统等维度探讨这些脉络。

1.分布式系统概论

• 定义：《Designing Data-Intensive Application》指出分布式系统：通过网络进行通信的多台机器的系统

• 好处：

  • 1.容错/高可用性：将应用程序部署在多台机器/网络/整个数据中心，保证任意宕机时仍可以继续工作。
  • 2.可扩容性：负载均衡到多台机器。
  • 3.低延迟：在全球各地设置服务器，保证每个用户都可以从最靠近他们地理位置的数据中心获取服务，避免用户等待网络包绕地球半圈响应请求。
  • 4.资源弹性：可以设置云部署根据需求来扩展/收缩，保证每个用户只需要为实际使用的资源付费。
  • 5.法律合规：有的数据符合的规则需要符合不同国家地区的政策，因此需要分布到多个位置的服务器上。

【DDIA这本书主要是基于有数据有状态来讨论分布式。】

但是，现实的实践中，分布式系统存在①有状态和②无状态：

• ①有状态：

• ②无状态：

2.实现分布式系统的模式

• AO：【微服务的顶层】封装应用程序的业务逻辑和处理流程；负责处理用户请求，调用相关的原子服务来完成特定任务；与其他对象进行交互，协调不同的功能模块。

• BO：【微服务中相关的原子服务】，负责业务原子化的服务[特定业务/数据打交道]；通常被各种AO服务调用

实现有状态的分布式系统，通常有以下三种：

2.1 单体应用

应用程序作为一个整体进行开发，测试和部署：

优点：

• 简单性：测试和部署更为简单。
• 性能较好：所有功能都在同一个进程中运行，有较好的性能和响应能力。
• 易于维护：所有代码和数据库都在同一个代码库和mysql库，很容易维护。

缺点：

• 系统复杂度高‌：随着功能的增加，代码库变得庞大和复杂，导致开发人员难以理解整个系统，进而影响代码的质量和维护性。
• 开发速度慢‌：由于需要编译、构建和测试整个项目，每次更改代码都会消耗大量时间，增加了开发成本。
• 难以扩展‌：单体应用难以根据不同模块的需求进行针对性的扩展，往往需要整体扩展，导致资源利用效率低下。
• ‌难以维护‌：模块之间的耦合度较高，修改一个模块的需求往往会带来连锁反应，影响其他模块的稳定性。
• 难以采用新技术‌：项目是一个庞大的整体，使得应用新技术的成本很高，因为必须对整个项目进行重构，这通常是不可能的。
• 开发速度慢‌：应用太大，每启动一次都需要很长时间，因此从编辑到构建、运行再到测试这个周期花费的时间越来越长。
• 部署困难‌：代码部署的周期很长，而且容易出问题。程序更改部署到生产环境的时间变得更长，代码库复杂，以至于一个更改可能引起的影响是未知的。
• 系统故障隔离差‌：应用程序缺乏故障隔离，因为所有模块都运行在同一个进程当中，任何部分的故障都可能影响整个系统的稳定性，导致宕机。

2.2 SOA架构–面向服务的架构

SOA架构关注于改变IT服务在企业范围内的工作方式，定义一种可通过服务接口复用软件组件并实现其互操作的方法。

优点：

• 可扩展性和灵活性：SOA 架构将系统拆分成独立的服务，可以按需组合和重组这些服务，从而实现系统的快速扩展和灵活部署。
• 提高系统的可重用性：每个服务都是独立的功能单元，可以在不同的系统中复用，提高了系统的开发效率和维护成本。
• 降低系统的耦合性：SOA 架构通过服务之间的松耦合关系，降低了服务之间的依赖性，有利于系统的模块化和维护。
• 提高系统的稳定性和可靠性：SOA 架构采用了服务注册与发现机制、负载均衡、故障恢复等机制，提高了系统的稳定性和可靠性。

缺点：

• 系统复杂度高：SOA 架构中涉及多个服务之间的协作和通信，系统的复杂度较高，开发、测试和维护成本相对较高。
• 性能问题：由于服务之间的通信需要通过网络进行，可能存在网络延迟和性能损失，对系统的性能造成影响。
• 安全性难以保障：SOA 架构中涉及多个服务之间的通信，需要对数据传输进行加密和安全控制，保障系统的安全性比较困难。
• 部署和运维难度大：SOA 架构中涉及多个服务的部署和管理，需要专门的运维团队进行管理，增加了系统的复杂性和运维成本。

2.3 微服务

【SOA架构的一种变体】微服务架构是一种云原生架构常用的实现方式—更强调基于云原生，独立部署，Devops，持续交付。

优点：

• 可扩展性和灵活性：SOA 架构将系统拆分成独立的服务，可以按需组合和重组这些服务，从而实现系统的快速扩展和灵活部署。

• 提高系统的可重用性：每个服务都是独立的功能单元，可以在不同的系统中复用，提高了系统的开发效率和维护成本。

• 降低系统的耦合性：SOA 架构通过服务之间的松耦合关系，降低了服务之间的依赖性，有利于系统的模块化和维护。

• 提高系统的稳定性和可靠性：SOA 架构采用了服务注册与发现机制、负载均衡、故障恢复等机制，提高了系统的稳定性和可靠性

  【基于SOA架构新增的优点】

• 独立性‌：每个服务可以独立部署和更新，提高了系统的灵活性和可靠性。

• ‌可扩展性‌：根据需求，可以独立扩展单个服务，而不是整个应用程序。

• ‌容错性‌：单个服务的故障不会影响其他服务，提高了系统的稳定性‌。

缺点：

【基于SOA架构，主要在运维和部署上增加了难度！！！】

需要处理的问题：

1. 必须有接入层：如上图，微服务化后，必然存在用户需要直接链接后端服务，那么这个时候就需要网关来解耦这块，也就是上面接入层讨论的好处。
2. 服务容错：多个微服务部署在云上，不同母机，会带来通讯的复杂性，网络问题会成为常态，那么如何容灾，容错，降级，也是需要考虑的。
3. 服务发现：当服务 A 发布或者扩缩容时，依赖服务 A 的服务 X 如何在保持运行的前提下自动感知到服务 A 的变化。这里需要引入第三方服务注册中心来实现服务的可发现性。比如北极星，stark，以及如何和容器，云原生结合。
4. 服务部署：服务变成微服务之后，部署是分散，部署是独立的，就需要有一个可靠快速的部署，扩缩容方案，也包括 ci/cd，全链路、实时和多维度的可观测性等，如 tke，智妍等，k8s 就是解决这种问题的。
5. 数据存储隔离：数据存储隔离(Data Storage Segregation, DSS) 原则，即数据是微服务的私有资产，必须通过当前微服务提供的 API 来访问数据，避免数据层产生耦合。对于有状态的微服务而言，通常使用计算与存储分类的方式，将数据下层到分布式存储方案中，从而一定程度上实现服务无状态化。
6. 服务间调用：服务 A 采用什么方式才可以调用服务 X，由于服务自治的约束 ，服务之间的调用需要采用开发语言无关的远程调用协议。现在业界大部分的微服务架构通常采用基于 IDL （Interactive Data Language， 交互式数据语言）的二进制协议进行交互，如 pb。

而整体解决微服务问题的思路：

1.出现原因

我直接关闭了我提交博客的git窗口，导致下次hexo d的时候提示：

2.解决方案

• 1.根据git命令行进入hexo博客所在目录：

• 2.根据git status命令查看当前仓库的状态：

• 3.根据git reset –hard命令重置仓库状态，但是有可能会丢失未提交的更改[谨慎使用]

• 4.重新hexo g和hexo d查看：

0.问题提出

关于创建xx数据库表，主键id的取值问题：如果自增可能会出现分库分表的麻烦，但是分库分表如果使用分布式id也有对应的缺点。因此，本文从①不分库分表②分库分表两个方面考虑

1.数据库自增ID

• 形式：使用数据库的id自增策略(Mysql的auto_increment)
• 优点：比较简单，天然有序
• 缺点：存在数量泄露，并发性能较差，数据库一旦故障就无法使用
• 解决方案：

1.1 数据库水平拆分

==每个数据库设置①不同的初始值和②相同的自增步长==

如图所示，这样可以保证DB123生成的ID是不冲突的，但是如果扩容，DB4数据库的话就没有初始值。

因此解决方案：

①根据扩容考虑决定步长，可以让多个数据库之间有空隙数字，可以扩容

②在其他未标记去扩容

1.2 批量缓存自增ID

==其实就是给数据库一批ID，不管多个DB之间的是否联系和连续，可能会出现多个数据库内连续，外不连续==

方案一步长的问题不好考虑，那我干脆一台机器分配，我分配的话肯定不会出现没法扩充，只是没办法保证多个数据库之间的ID是连续的。我DB4数据库来了，我可能忘了我就给他500-599的。

1.3 Redis生成ID

• 核心思路：Redis所有命令操作都是单线程的[本身提供像incr/increby这样的自增原子命令，能够保证Redis生成的ID唯一且有序]
• 优点：①不依赖数据库，灵活方便；②性能优于数据库；③数字天然有序
• 缺点：需要引入新的组件，增加系统复杂度；—》可以搭建redis集群提高吞吐量
• 适合场景：适合Redis生成每天从0开始的流水号。比如：订单号=日期+当前自增长号

2.UUID

• 形式：32个十六进制数字一共是128位【8-4-4-4-12】

• 优点：不是有序的，安全性更高

• 缺点：

  ①不是有序的，所以做主键的话innodb聚集索引内存消耗大，读写效率低；

  ②32个数字长度大，导致innodb叶子节点存储过大；

  ③因为无序，查找效率低下

3.雪花算法

• 形式：最多长度为19一共是64位【1个64bit字节的整数】

​ 第1个bit位：保留位，无实际作用

​ 第2-42的bit位：这41位表示时间戳，精确到毫秒级别

​ 第43-52的bit位：这10位表示专门负责生产ID的工作机器的id

​ 第53-64的bit位：这12位表示序列号，也就是1毫秒内可以生成2 12 2^{12}2

• 优点：

  ①整体上按照时间趋势增加，后续插入索引树的性能较好；

  ②整个分布式系统不会发生ID碰撞；

  ③本地生成，且不依赖数据库，没有网络消耗

• 缺点：

  ①强依赖时间容易发生时种回拨【Map存储<机器ID,max_id>服务器出故障就从max_id重新生成】