# Dbdoctor体验报告

![image.png](/static/img/bd5c5dbc39752f2f888522478cce3f5a.image.webp)


# 一、关于我
> 1.姓名或昵称：Kevin
> 
> 2.公司或行业：地产相关行业
> 
> 3.职业或职位：dba
> 
> 4.从业年限或介绍：10+
> 
> 5.了解DBdoctor的详细途径：互联网
> 
> 6.重点关注的数据库工具及功能：SQL审核，巡检报告，锁透视，根因诊断等




# 二、DBdoctor部署体验

- 1.下载时长：< 3分钟
- 2.部署环境描述：`CentOS Linux release 7.9(Core) 8核16G`
- 3.部署过程中遇到的问题(图文并茂更佳，也可以附上录屏)：

    总体部署安装还是比较顺利，只遇到了一个小问题如下：
    ### 问题一：Dbdoctor部署agent报错
    
```bash

[root@wtj1vpfrmysql01 agent]# ./agent --install -h 172.17.44.40 -k 172.17.44.70:9092 -s 172.17.44.70:13000
2024-06-14 11:58:22.582296439 [ERROR] [agent check_time:65]: time check failed,time check failed,time out of sync

问题原因，agent上的时间和server端的时间不一致。

解决办法：调整系统时间和server端时间保持一致即可。
# timedatectl set-ntp yes
[root@wtj1vpfrmysql01 agent]# timedatectl status 
      Local time: Fri 2024-06-14 12:04:12 CST
  Universal time: Fri 2024-06-14 04:04:12 UTC
        RTC time: Fri 2024-06-14 04:04:12
       Time zone: Asia/Shanghai (CST, +0800)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a
```

   ### 问题二：运行一段时间后，有一天登录Dbdoctor，提示无法登录
   
   #### 问题原因：磁盘空间占满
   #### 解决办法：清理空间后，重启，检查状态

![image.png](/static/img/3237f3db98589a678f1205eb86a2987d.image.webp)

  ### 问题三：接入纳管阿里云RDS后，点开某个实例时，经常会出现：服务端内部错误提示。
  
  ![image.png](/static/img/5e08282f2fd8e8c81e0cee6a4899e583.image.webp)
  ![](https://vlogs.iftballs.com/static/img/6fdb5dd3c67dee520b3f4ebc4da023ed.image.webp)
   #### 问题原因：不明
   #### 解决办法：暂无


- 4.关于产品文档有哪些建议：

   `产品文档非常详细，用户可以按照文档很快的部署搭建完成。阿里云RDS接入纳管到Dbdoctor后，会出现一些报错问题`
   


- 5.下载和部署部分给我们的建议：

    `下载和部署对新上手用户来说，也是非常的简单方便`
    

# 三、SQL审核功能试用体验

## 1.体验过程:
 
   ### 提交某个Sql进行审核后，会给出审核结果及优化建议：
   
![image.png](/static/img/5abd63e7d98d8f19623c1669600ccced.image.webp)


![image.png](/static/img/5505ec8bb3a0a93f4f6d90070d310449.image.webp)


![image.png](/static/img/f302fcc7789ebed4cb5b278c9124e773.image.webp)


![image.png](/static/img/befe95e3091f5e31bd1e7bb8c3b48442.image.webp)


## 2.体验SQL性能审核时，遇到的问题及对产品有些建议：

   ### 稍复杂的多表关联查询，进行SQL审核时，审核时间会比较慢，一直转圈，如下图：

![image.png](/static/img/0dd8cbbe68d2afaa55fc3971a42f2823.image.webp)

## 3.体验SQL规范审核时，您是否遇到问题，有哪些建议，能否满足您公司研发SQL规范要求：
 ### 在进行SQL审核时，只能选中到schema级别，不能象阿里云可以展示到table级别
 
 阿里云：
![image.png](/static/img/0a51d064aeee62209920302755cda0cc.image.webp)
 
 - Dbdoctor给出的优化建议：(优于阿里云)
 
![image.png](/static/img/8669b956d089418852118ee96fea5cb9.image.webp)

- 阿里云给出的优化建议：(暂无建议) 
![image.png](/static/img/dc7837d47ec6e2ee1317cf5562b97910.image.webp)

- 公司自用的第三方审核平台，给出优化建议：(优于阿里云) 
![image.png](/static/img/65f1f31a918b395f228bfd8c4967ed84.image.webp)

## 4.SQL审核功能中，我最需要我们的产品提供哪些SQL场景识别：

- 识别潜在的SQL注入漏洞，确保查询使用参数化查询或ORM来避免此类风险。
- 识别和建议删除冗余的索引，以减少不必要的维护开销。
- 识别长期未被使用的索引，并建议删除或优化。
- 识别可能会返回错误或无效数据的查询，并提供修复建议。
- 识别频繁使用临时表或中间结果集的查询，并提供替代方案以提高性能。
- 识别未使用外键约束的表关系，并建议添加以确保数据一致性。
- 识别和建议修复表和索引碎片，以提高数据库性能。

## 5.您公司属于什么行业？SQL审核如果要在您公司的生产环境部署，有哪些限制或需满足哪些条件：

  - 我司属于地产相关行业。
  - SQL审核如果要在您公司的生产环境部署，会有需要与CI/CD流程集成进行SQL代码审核和跟踪。目前，是单独部署进行的测试，纳管起来很不方便。


# 四、随意发挥

## 1、 除体验SQL审核功能外，您还深度试用DBdoctor的锁透视和根因诊断。这两个功能点，也是非常强大。


![image.png](/static/img/3cedfc5027593f9d3417921478f8490a.image.webp)
### 通过上图，用户可以很直观的看到，最近5分钟，1小时，5小时，24小时，2天，1周等根因SQL，以及长事务，IO异常，CPU异常或流量突增等问题

![image.png](/static/img/384278e576f20559f089dc47400cd3ba.image.webp)

### 通过根因推导过程，以关系图的关系，展示出来问题SQL的根因，帮助用户能够快速定位问题SQL。

## 2、希望能上线对tidb实例的纳管功能。

## 3、专业版License可在公众号自助申请，您觉得申请过程是否简单，对于License申请您有哪些建议：
   
   ### 用户可以通过公众号自助申请，申请过程很简单方便快捷，License的周期可以再适当的增长，比如说，可以允许用户体验1-3个月。因为，有些功能在短短一个月内，可能无法完全深入体验或发现其中的问题。
   
## 4、针对DBdoctor当前有三个产品版本，如果是企业版本的话，建议可以象国外的一些类似产品采用订阅制，季度，年度，以及单独买断制。取消按照实例个数的收费等。

Dbdoctor体验报告

# Wiki.js 通过 Generic OAuth2 进行身份验证]

## `Wiki.js`介绍

`Wiki.js` 是一个开源的`百科全书`系统，可以用来搭建自己的知识库、文档库等。
[官网](https://js.wiki/) | [GitHub](https://github.com/Requarks/wiki)

后续内容中的`Wiki.js`会用`Wiki`代替。
本文环境：`Wiki 2.5.303`。

`Wiki`的基本环境搭建和使用，网上一大堆，本文就不在累赘。
使用过程中，需要用到身份验证时，发现出错后页面提示信息不是很友好，最后也是通过调试源码后配置成功，所以还是很有必要记录一下配置方式。



基本的配置包含2个部分，分别是**授权配置**、**注册配置**。

## 1. 授权配置

![Authorization.png](https://s2.loli.net/2022/11/17/UHQWONMYTbxcngC.png)
个人认为这部分是最不友好的地方，卡壳也是卡在这里。

### 1.1 Client ID

获取 `Token` 时会作为参数传递给接口。

### 1.2 Client Secret

获取 `Token` 时会作为参数传递给接口。

### 1.3 Authorization Endpoint URL

授权页面的地址。
当进入 `Wiki` 的登录页后，选择 `Generic OAuth2` 授权登录时跳转的地址。
如果同意授权，则需要跳转到 `Wiki` 指定的回调页面（跳转时可以加入自定义参数）。
每个项目的回调地址都不相同，最简单的办法就是在页面的最下面找到配置参考。
`http://xxx:3000/login/bf4439-a770-fedee4be57df/callback?MyValue=test`
如果回调地址配置的不对，可能会出现`Invalid authentication provider.`错误页。
![demo.png](https://s2.loli.net/2022/11/17/Wgya85PDKhRm7fQ.png)

### 1.4 Token Endpoint URL

获取`Token`的接口地址。

在调用该地址时，`Wiki`会自动附带下面这些参数：

1. `grant_type=authorization_code`
2. `client_id=1.1中配置的值`
3. `client_secret=1.2中配置的值`
4. `自定义参数（1.3中配置的值）`

服务端验证逻辑完成后，接口必须返回包含以下字段的返回值（**注意区分大小写**）

```
{    "access_token":"xxx"}
```

如果返回值不合法，会出现错误页`Failed to obtain access token`。

### 1.5 User Info Endpoint URL

成功拿到`Token`后，获取用户信息的接口地址。

> 可以设置 `Wiki` 获取用户信息时 `Token` 的传递方式：`Query string` 或 `Authorization header`
> ![SetToken.png](https://s2.loli.net/2022/11/17/qRtYNFA4ODhfeLU.png)

服务器根据 `Token` 获取用户信息，最终返回包含以下字段的返回值（**注意区分大小写**）

```
{    "UserId":10086,    "Name":"张三",    "Email":"zs@test.com"}
```

如果返回值不合法，会出现错误页`Missing or invalid email address from profile.`

> **`Wiki` 系统中是通过 `Email` 来标识唯一用户，因此不同用户的 `Email` 不能重复。**

### 1.6 ID Claim

用户信息接口中返回的`用户 ID` 字段名。

### 1.7 Display Name Claim

用户信息接口中返回的`用户名称`字段名。

### 1.8 Email Claim

用户信息接口中返回的`邮箱`字段名，该字段值必须保证唯一。

![UserInfo.png](https://s2.loli.net/2022/11/17/tuaSXR1TUZmA5Js.png)

## 2. 注册配置

![Config.png](https://s2.loli.net/2022/11/17/t2c6waEJz4hnGiU.png)

### 2.1 启用开放注册

授权登录完成后，当用户信息在 `Wiki` 中不存在时，则会新建用户信息并完成登录。

### 2.1 禁用开放注册

授权用户的 `Email` 必须已经在 `Wiki` 中注册，否则无法登录，出现错误页`You are not authorized to login.`

Wiki.js 通过 Generic OAuth2 进行身份验证

为什么美国一直维持高息，而中国必须减息？

# docker常用操作命令
![image.png](/static/img/20f8bd022862a6cf3cb1727a7c870e19.image.webp)


## 1.停止所有的container，这样才能够删除其中的images：

```bash
docker stop $(docker ps -a -q)
```


### 如果想要删除所有container的话再加一个指令：

```bash
docker rm $(docker ps -a -q)
```

## 2.查看当前有些什么images

```bash
docker images
```
## 3.删除images，通过image的id来指定删除谁

```bash
docker rmi <image id>

想要删除untagged images，也就是那些id为<None>的image的话可以用
docker rmi $(docker images | grep "<none>" | awk "{print $3}")

要删除全部image的话
docker rmi $(docker images -q)
```

## 4.关闭服务及删除镜象

```bash
docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
docker images
docker rmi $(docker images -q)
```

docker常用操作命令

# Apache ShardingSphere数据脱敏全解决方案详解(下)【转载】

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/5/22/1723a47eb3a6afa2~tplv-t2oaga2asx-jj-mark:3024:0:0:0:q75.awebp)



## 作者介绍

潘娟，京东数科高级DBA，主要负责京东数科数据库中间件开发、数据库运维自动化平台开发、生产数据库运维工作。多次参与京东6.18、11.11等大促活动的护航工作。曾负责京东数科数据库自动化平台设计与开发项目，现专注于Apache ShardingSphere分布式数据库中间件开发。乐于在数据库、自动化、分布式、中间件等相关领域进行学习和探索。

## 一、前言

[《ApacheShardingSphere数据脱敏全解决方案详解(上)》](https://link.juejin.cn/?target=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzUzNjgwODk2Mw%3D%3D%26mid%3D2247484022%26idx%3D1%26sn%3Dede687dedaf7117b53e4828794dfa67f%26scene%3D21%23wechat_redirect)主要介绍了ShardingSphere内部脱敏功能的具体实现。本次分享承接上篇，将具体实现与实际的场景结合，提供针对已上线业务脱敏改造和新上线业务脱敏使用的详细介绍。

## 二、解决方案详解

在了解了ShardingSphere脱敏处理流程后，即可将脱敏配置、脱敏处理流程与实际场景进行结合。所有的设计开发都是为了解决业务场景遇到的痛点。那么面对之前提到的业务场景需求，又应该如何使用ShardingSphere这把利器来满足业务需求呢？

### 新上线业务

**业务场景分析**：新上线业务由于一切从零开始，不存在历史数据清洗问题，所以相对简单。

**解决方案说明**：选择合适的加密器，如AES后，只需配置逻辑列（面向用户编写SQL）和密文列（数据表存密文数据）即可，**逻辑列和密文列可以相同也可以不同**。建议配置如下（Yaml格式展示）：

encryptRule:
encryptors:
aes_encryptor:
type: aes
props:
aes.key.value: 123456abc
tables:
t_user:
columns:
pwd:
cipherColumn: pwd
encryptor: aes_encryptor

使用这套配置，Encrypt-JDBC只需将logicColumn和cipherColumn进行转换，底层数据表不存储明文，只存储了密文，这也是安全审计部分的要求所在。如果用户希望将明文、密文一同存储到数据库，只需添加plainColumn配置即可。整体处理流程如下图所示：

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/5/22/1723a48eaa123e56~tplv-t2oaga2asx-jj-mark:3024:0:0:0:q75.awebp)

### 已上线业务改造

**业务场景分析**：由于业务已经在线上运行，数据库里必然存有大量明文历史数据。现在的问题是如何让历史数据得以加密清洗、如何让增量数据得以加密处理、如何让业务在新旧两套数据系统之间进行无缝、透明化迁移。

**解决方案说明**：在提供解决方案之前，我们先来头脑风暴一下：首先，既然是旧业务需要进行脱敏改造，那一定存储了非常重要且敏感的信息。这些信息含金量高且业务相对基础重要。如果搞错了，整个团队KPI就再见了。所以不可能一上来就停业务，禁止新数据写入，再找个加密器把历史数据全部加密清洗，再把之前重构的代码部署上线，使其能把存量和增量数据进行在线加密解密。如此简单粗暴的方式，按照历史经验来谈，一定凉凉。

那么另一种相对安全的做法是：重新搭建一套和生产环境一模一样的预发环境，然后通过相关迁移洗数工具把生产环境的存量原文数据加密后存储到预发环境，而新增数据则通过例如MySQL主从复制及业务方自行开发的工具加密后存储到预发环境的数据库里，再把重构后可以进行加解密的代码部署到预发环境。这样生产环境是一套**以明文为核心的查询修改**的环境；预发环境是一套**以密文为核心加解密查询修改**的环境。在对比一段时间无误后，可以夜间操作将生产流量切到预发环境中。此方案相对安全可靠，只是时间、人力、资金、成本较高，主要包括：预发环境搭建、生产代码整改、相关辅助工具开发等。除非无路可走，否则业务开发人员一般是从入门到放弃。

业务开发人员最希望的做法是：**减少资金费用的承担、最好不要修改业务代码、能够安全平滑迁移系统**。于是，ShardingSphere的脱敏功能模块便应用而生。可分为三步进行：

### 系统迁移前

假设系统需要对t_user的pwd字段进行脱敏处理，业务方使用Encrypt-JDBC来代替标准化的JDBC接口，此举基本不需要额外改造（我们还提供了SpringBoot，SpringNameSpace，Yaml等接入方式，满足不同业务方需求）。另外，提供一套脱敏配置规则，如下所示：

encryptRule:
encryptors:
aes_encryptor:
type: aes
props:
aes.key.value: 123456abc
tables:
t_user:
columns:
pwd:
plainColumn: pwd
cipherColumn: pwd_cipher
encryptor: aes_encryptor
props:
query.with.cipher.column: false

依据上述脱敏规则可知，首先需要在数据库表t_user里新增一个字段叫做pwd_cipher，即cipherColumn，用于存放密文数据，同时我们把plainColumn设置为pwd，用于存放明文数据，而把logicColumn也设置为pwd。由于之前的代码SQL就是使用pwd进行编写，即面向逻辑列进行SQL编写，所以业务代码无需改动。通过Encrypt-JDBC，针对新增的数据，会把明文写到pwd列，并同时把明文进行加密存储到pwd_cipher列。此时，由于query.with.cipher.column设置为false，对业务应用来说，依旧使用pwd这一明文列进行查询存储，却在底层数据库表pwd_cipher上额外存储了新增数据的密文数据，其处理流程如下图所示：

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/5/22/1723a48eaa2d2e53~tplv-t2oaga2asx-jj-mark:3024:0:0:0:q75.awebp)

新增数据在插入时，就通过Encrypt-JDBC加密为密文数据，并被存储到了cipherColumn。而现在就需要处理历史明文存量数据。**由于Apache ShardingSphere目前并未提供相关迁移洗数工具，此时需要业务方自行将pwd中的明文数据进行加密处理存储到pwd_cipher。**

### 系统迁移中

新增的数据已被Encrypt-JDBC将密文存储到密文列，明文存储到明文列；历史数据被业务方自行加密清洗后，将密文也存储到密文列。也就是说现在的数据库里即存放着明文也存放着密文，只是由于配置项中的query.with.cipher.column=false，所以密文一直没有被使用过。现在我们为了让系统能切到密文数据进行查询，需要将脱敏配置中的**query.with.cipher.column设置为true**。在重启系统后，我们发现系统业务一切正常，但是Encrypt-JDBC已经开始从数据库里取出密文列的数据，解密后返回给用户；而对于用户的增删改需求，则依旧会把原文数据存储到明文列，加密后密文数据存储到密文列。

虽然现在业务系统通过将密文列的数据取出，解密后返回；但是，在存储的时候仍旧会存一份原文数据到明文列，这是为什么呢？答案是：为了能够进行系统回滚。**因为只要密文和明文永远同时存在，我们就可以通过开关项配置自由将业务查询切换到cipherColumn或plainColumn。**也就是说，如果将系统切到密文列进行查询时，发现系统报错，需要回滚。那么只需将query.with.cipher.column=false，Encrypt-JDBC将会还原，即又重新开始使用plainColumn进行查询。处理流程如下图所示：

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/5/22/1723a48eaa2d6100~tplv-t2oaga2asx-jj-mark:3024:0:0:0:q75.awebp)

### 系统迁移后

由于安全审计部门要求，业务系统一般不可能让数据库的明文列和密文列永久同步保留，我们需要在系统稳定后将明文列数据删除。即我们需要在系统迁移后将plainColumn，即pwd进行删除。那问题来了，现在业务代码都是面向pwd进行编写SQL的，把底层数据表中的存放明文的pwd删除了，换用pwd_cipher进行解密得到原文数据，那岂不是意味着业务方需要整改所有SQL，从而不使用即将要被删除的pwd列？还记得我们Encrypt-JDBC的核心意义所在吗？

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/5/22/1723a47eb399c65a~tplv-t2oaga2asx-jj-mark:3024:0:0:0:q75.awebp)

**这也正是Encrypt-JDBC核心意义所在，即依据用户提供的脱敏规则，将用户SQL与底层数据库表结构割裂开来，使得用户的SQL编写不再依赖于真实的数据库表结构。而用户与底层数据库之间的衔接、映射、转换交由ShardingSphere进行处理。**

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/5/22/1723a47eb3aca2a4~tplv-t2oaga2asx-jj-mark:3024:0:0:0:q75.awebp)

是的，因为有logicColumn存在，用户的编写SQL都面向这个虚拟列，Encrypt-JDBC就可以把这个逻辑列和底层数据表中的密文列进行映射转换。于是迁移后的脱敏配置即为：

encryptRule:
encryptors:
aes_encryptor:
type: aes
props:
aes.key.value: 123456abc
tables:
t_user:
columns:
pwd: # pwd与pwd_cipher的转换映射
cipherColumn: pwd_cipher
encryptor: aes_encryptor
props:
query.with.cipher.column: true

其处理流程如下

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/6/3/172794d6d5255335~tplv-t2oaga2asx-jj-mark:3024:0:0:0:q75.awebp)

至此，已在线业务脱敏整改解决方案全部叙述完毕。我们提供了Java、Yaml、SpringBoot、SpringNameSpace多种方式供用户选择接入，力求满足业务不同的接入需求。该解决方案目前已在京东数科不断落地上线，提供对内基础服务支撑。

## 三、中间件脱敏服务优势

1. 自动化&透明化数据脱敏过程，用户无需关注脱敏中间实现细节。

2. 提供多种内置、第三方(AKS)的脱敏策略，用户仅需简单配置即可使用。

3. 提供脱敏策略API接口，用户可实现接口，从而使用自定义脱敏策略进行数据脱敏。

4. 支持切换不同的脱敏策略。

5. 针对已上线业务，可实现明文数据与密文数据同步存储，并通过配置决定使用明文列还是密文列进行查询。可实现在不改变业务查询SQL前提下，已上线系统对加密前后数据进行安全、透明化迁移。

## 四、适用场景说明

1. 用户项目使用Java语言进行编程。

2. 后端数据库为MySQL、Oracle、PostgreSQL、SQLServer。

3. 用户需要对数据库表中某个或多个列进行脱敏(数据加密&解密)。

4. 兼容所有常用SQL；

Coding...

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/5/22/1723a48eae135b78~tplv-t2oaga2asx-jj-mark:3024:0:0:0:q75.awebp)

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2020/5/22/1723a48eae900810~tplv-t2oaga2asx-jj-mark:3024:0:0:0:q75.awebp)

## 五、限制条件

1. 用户需要自行处理数据库中原始的存量数据、洗数。

2. 使用脱敏功能+分库分表功能，部分特殊SQL不支持，请参考SQL使用规范。

3. 脱敏字段无法支持比较操作，如：大于小于、ORDER BY、BETWEEN、LIKE等

4. 脱敏字段无法支持计算操作，如：AVG、SUM以及计算表达式

## 六、后续

本篇文章介绍了如何使用ShardingSphere产品之一的Encrypt-JDBC进行接入，接入形式还可以选择使用SpringBoot、SpringNameSpace等，这种形态的接入端主要面向JAVA同构，并与业务代码共同部署在生产环境中。面向异构语言，ShardingSphere还提供Encrypt-Proxy客户端。**Encrypt-Proxy是一款实现MySQL、PostgreSQL的二进制协议的服务器端产品**，用户可独立部署Encrypt-Proxy服务，并且像使用普通MySQL、PostgreSQL数据库一样，使用例如Navicat第三方数据库管理工具、JAVA连接池、命令行的方式访问这台具有脱敏功能的虚拟数据库服务器。

脱敏功能属于Apache ShardingSphere分布式治理的功能范畴。**事实上，Apache ShardingSphere这个生态还拥有其他更强大的能力，例如数据分片、读写分离、分布式事务、监控治理等。您甚至可以选择任意多种功能模块进行叠加使用**，例如同时使用数据脱敏+数据分片，或是数据分片+读写分离，再或者是监控治理+数据分片等。除了在功能层面的叠加选择，ShardingSphere还提供了各种接入端形式，例如Sharding-JDBC或Sharding-Proxy等以满足大家不同场景需求

## 七、写在最后

ShardingSphere从最初的仅支持分库分表功能，到现在已形成包括数据分片、分布式治理、分布式事务等核心功能为主的生态圈。这也标识着它不仅仅是一款分布式数据库中间件，不仅仅拥有分库分表的能力，更是形成以数据分片、分布式治理、分布式事务为核心的全方位解决方案生态体系

Dbdoctor体验报告

Wiki.js 通过 Generic OAuth2 进行身份验证]

Wiki.js介绍

为什么美国一直维持高息，而中国必须减息？【转载：作者/西风的罗盘】

docker常用操作命令

Apache ShardingSphere数据脱敏全解决方案详解(下)【转载】

`Wiki.js`介绍