mirror of
https://github.com/ZSCNetSupportDept/website.git
synced 2025-10-29 09:25:04 +08:00
准备新的开发组文档,初步手机端访问支持
原来的在docs/devdocs/_legacy目录下面
This commit is contained in:
28
docs/devdocs/_legacy/01-首页.md
Normal file
28
docs/devdocs/_legacy/01-首页.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# 开发组首页
|
||||
**欢迎来到中山学院网络维护科开发组!**\
|
||||
**开发组是一个相对独立的小组,负责维护网维日常所用的系统,**\
|
||||
**这里是开发组所维护系统的文档**
|
||||
## 项目清单
|
||||
我们手头上的项目
|
||||
### 网站
|
||||
zsxyww.com,网维的官网
|
||||
### 网维报修系统
|
||||
负责受理用户的故障保修,允许网维成员跟踪问题的解决情况,并管理工单\
|
||||
目前所使用的是上一届开发组成员所开发的系统,目前我们不熟悉其架构和细节,计划开发新的报修系统
|
||||
### 招新系统
|
||||
招新的系统
|
||||
### 基础设施
|
||||
开发组所持有的基础设施,包括云服务器,域名等
|
||||
## 你应该知道......
|
||||
### 项目托管
|
||||
我们的项目托管在github上,私聊组长来获得进入organization的权限
|
||||
### 文档编写
|
||||
为了项目的持续维护,对于我们的每一个项目都应该留有详尽的文档,文档以markdown格式编写,可以自动构建成静态网页,详见**网站/如何修改开发组网站内容**
|
||||
### 培训 资料
|
||||
这里是一些资料,帮助你了解加入开发组工作的必要知识
|
||||
- SSH教程:https://wangdoc.com/ssh/basic
|
||||
- git教程:
|
||||
- WEB基础:https://developer.mozilla.org/zh-CN/docs/Learn/Getting_started_with_the_web
|
||||
- linux命令:
|
||||
- markdown教程:
|
||||
|
||||
8
docs/devdocs/_legacy/02-网站/01-子站点.md
Normal file
8
docs/devdocs/_legacy/02-网站/01-子站点.md
Normal file
@@ -0,0 +1,8 @@
|
||||
# 子站点
|
||||
网站的子站点
|
||||
## www.zsxyww.com
|
||||
www.zsxyww.com是网维的官网
|
||||
## wiki.zsxyww.com
|
||||
wiki.zsxyww.com是网维的旧版wiki
|
||||
## developer.zsxyww.com
|
||||
developer.zsxyww.com是网维开发组的站点,托管了新版wiki和网维各种系统的文档
|
||||
22
docs/devdocs/_legacy/02-网站/02-开发组网站/02-开发组网站-概览.md
Normal file
22
docs/devdocs/_legacy/02-网站/02-开发组网站/02-开发组网站-概览.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# 开发组网站-概览
|
||||
## 技术
|
||||
网站基于Docusaurus开发,一个静态网页生成的框架,尤其对于生成技术文档来说,它提供了一个美观,现代的前端界面,这个项目本身是一个react.js应用,生成网页时只要输入:`npm run build`便可以在build目录里构建网站的所有资源,以进一步部署,关于详细的配置,可以去看官方的文档:[文档连接](https://www.docusaurus.cn/docs/category/guides)
|
||||
## 工作流程
|
||||
基本上,我们需要把markdown文件放在目录里面,系统就会根据目录的结构自动生成网页,但是我们必须写好配置文件,如果我们想自定义网站的外观的话,也需要好好研究一下配置文件,有关文档还在编写中 \
|
||||
开发组网站的开发流程基本如下:
|
||||
1. 将源代码仓库的最新版本拉取到本地,对仓库的内容进行修改,最终在本地的master分支上commit,
|
||||
2. 运行`npm start`在`https://localhost:3000`上运行基于改动构建的预览版本
|
||||
3. 测试改动,确保一切正常后push到github上
|
||||
4. demo网站会自动根据github上的msater分支构建网页,构成开发组网站的预览版本
|
||||
5. 积累几个改动后,在本地运行`npm run deploy`将网页构建好推送给github上的`build`分支,网站服务器自动获取并更新,构成开发组网站的正式版本
|
||||
## 目录
|
||||
所有的文档文件都储存在docs文件夹下\
|
||||
所有的公告文件都储存在blog文件夹下\
|
||||
所有的静态页面都储存在src/pages文件夹下\
|
||||
所有的媒体文件都储存在static文件夹下,供用户下载的资源也储存在这里\
|
||||
|
||||
docusaurus.config.js是项目的配置文件,配置格式请参照官方文档
|
||||
## 部署
|
||||
目前不确定
|
||||
## 注意事项
|
||||
最好还是看官方文档
|
||||
43
docs/devdocs/_legacy/02-网站/02-开发组网站/03-开发组网站-内容.md
Normal file
43
docs/devdocs/_legacy/02-网站/02-开发组网站/03-开发组网站-内容.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# 开发组网站-内容
|
||||
**本篇文章将教你进行内容发布,维护开发组网站内容的方法**
|
||||
## 如何修改
|
||||
### Edit This Page
|
||||
页面最下面有一个Edit This Page的超链接,点击就可以进入github里这个页面的源代码,可以提交PR,有权限的也可以直接修改
|
||||
### git clone
|
||||
(该方法仅限有权限的开发组成员)\
|
||||
如果你要进行比较多的修改的话,你也可以将仓库拉取到本地,然后修改,新建文件夹,打开终端
|
||||
- 输入`git clone https://github.com/ZSCNetSupportDept/website.git`
|
||||
- 输入`git checkout master`
|
||||
- 此时你应该可以看见项目的源代码,修改你需要改动的内容,然后输入`git add *`
|
||||
- 输入`git commit`,将你的改动提交到本地
|
||||
- 输入`git push`,提交内容到仓库
|
||||
## 仓库的内容
|
||||
你可以看见三个文件夹,分别是src,docs,blog,其中:
|
||||
- src文件夹存放了独立于文档和blog的静态页面
|
||||
- docs文件夹存放了所有的文档(目前有wiki和开发组文档两个docs)
|
||||
- blog文件夹存放了可以显示在“公告”板块的文章
|
||||
|
||||
所有的文档都以Markdown格式书写(其实也可以用MDX格式),
|
||||
### 前缀
|
||||
所有文件都有一个数字前缀,这是文章在成品网站中的顺序,文件请按照`order-filename.md`的格式命名
|
||||
|
||||
btw,docusaurus不会将以"_"开头的文件加入完成的网页中,所以可以在暂时不想要展现在最终网站的里的的文章前面加上一个下划线
|
||||
### 栏目的概况
|
||||
我们可以在一个子文件夹中加入`index.md`或者`README.md`或者`{$文件夹的名称}.md`,其中的内容会在成品网站中显示为这个栏目的概况(点击这个栏目本身出现的内容)
|
||||
### Markdown 文档
|
||||
Markdown 是一个标记文本格式的语言,轻便简单快捷,markdown最基本的语法如下:[markdown语法](https://commonmark.org/) ,我们用Markdown来编写文档,需要注意的是,文档只能有一个h1,系统用它来产生sidebar条目
|
||||
|
||||
另外docusaurus好像支持mdx格式的文档,可以把一些动态元素插入到文本中,
|
||||
### 媒体资源引用
|
||||
请将所有媒体资源放在static目录内,然后在文档中调用
|
||||
### 下载
|
||||
在`static`目录下面的内容会直接放到生成的网页里,我们在wiki和开发组文档里各设置了一个下载页面提供便捷访问的方式,在Markdown文本里链接这些文件,来提供下载的方式
|
||||
|
||||
### 公告
|
||||
docusaurus自带一个blog插件,需要按照`yyyy-mm-dd-filename.md`的格式发布
|
||||
|
||||
## 文档的维护
|
||||
如果发现了文档有错误的地方,请提交PR修改,或者告知开发组成员,
|
||||
|
||||
## 进阶
|
||||
更详细的内容,还是建议看docusaurus的官方文档:[文档连接](https://www.docusaurus.cn/docs/category/guides)
|
||||
15
docs/devdocs/_legacy/02-网站/02-开发组网站/03-开发组网站-部署.md
Normal file
15
docs/devdocs/_legacy/02-网站/02-开发组网站/03-开发组网站-部署.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# 开发组网站-部署
|
||||
本篇文章是开发组网站的部署流程备忘录
|
||||
## 开发部署流程
|
||||
网站假设在我们的云服务器上,服务器会自动从仓库的build分支拉取内容,所以,网站的开发部署流程是这样的:
|
||||
1. 将website仓库clone到本地/pull拉取最新版本
|
||||
2. 运行`npm start`在localhost:3000上运行网站的测试版本
|
||||
3. 确认网站的最新版本没有问题后,运行`npm run docusaurus deploy`,npm会自动构建网页文件,推送到origin/build分支上(记得配置好你的ssh,联系组长来获取仓库的权限)
|
||||
4. 服务器获取build分支的最新版本,pull到`/var/www/developer`目录下
|
||||
5. 服务器采用nginx,提供对developer.zsxyww.com的访问
|
||||
|
||||
## demo
|
||||
我在cloudflare pages上部署了一个网站的demo,这个网站会自动基于master分支构建,而不是获取构建好的build分支,可以在上面预览网站的效果,觉得没问题了再进行build,网址:https://zscdev-demo.pages.dev/
|
||||
|
||||
## 服务端
|
||||
目前,网站服务器拉取build构建的方式是通过定时执行(5分钟1次)一个特定的更新脚本,位置在`/opt/developer-build.sh`,写在crontab里了,
|
||||
9
docs/devdocs/_legacy/02-网站/02-开发组网站/04-开发组网站-外观.md
Normal file
9
docs/devdocs/_legacy/02-网站/02-开发组网站/04-开发组网站-外观.md
Normal file
@@ -0,0 +1,9 @@
|
||||
# 开发组网站-外观
|
||||
**本篇指南将教你如何修改开发组网站的外观**
|
||||
|
||||
|
||||
看官方文档
|
||||
|
||||
|
||||
|
||||
|
||||
249
docs/devdocs/_legacy/02-网站/02-开发组网站/快速上手.md
Normal file
249
docs/devdocs/_legacy/02-网站/02-开发组网站/快速上手.md
Normal file
@@ -0,0 +1,249 @@
|
||||
# 快速上手
|
||||
修网的知识需要在实践中不断积累,网维的wiki做为每一个网维成员经验的总结,自然也需要不断的更新,但是,wiki本身大部分时间都是由开发组的仅仅几个人来维护,难以时刻更新到最新情况,所以,我们想让网维的每个人都能加入wiki的维护,这篇文章就是写给希望为wiki添砖加瓦,却不太了解相关方法的小伙伴的,希望这篇文章能够快速让你上手wiki的维护工作。
|
||||
|
||||
在这篇文章里我们将教你:\
|
||||
将我们在github上的主仓库fork一份,然后将fork仓库clone到你的电脑;修改网站源代码;将你的修改传回fork仓库,提交pull request
|
||||
|
||||
:::info 信息
|
||||
|
||||
在正式开始编辑前,你可以看看我们的成品网站,每篇文章的下面会有一个`Edit This Page`的链接,是这篇文章的源代码,这里是网站的链接:[Click Me ](https://zscdev-demo.pages.dev/)
|
||||
|
||||
|
||||
:::
|
||||
|
||||
## 准备
|
||||
我们假设你所使用的是windows系统。
|
||||
|
||||
首先,我们需要安装必要的开发工具:git 和 Node.js。
|
||||
|
||||
访问如下链接:[git下载](https://git-scm.com/download/win) , [Node.js下载](https://nodejs.org/zh-cn/download/prebuilt-installer)。
|
||||
|
||||
:::info 信息
|
||||
|
||||
你也可以通过windows自带的WinGet包管理器下载,详见:[微软文档](https://learn.microsoft.com/zh-cn/windows/package-manager/winget/)。
|
||||
|
||||
:::
|
||||
|
||||
:::tip git是什么?
|
||||
|
||||
git是一个版本控制工具,他会记录一个项目从创建之初任何人对任何文件的任何改动,大大方便了多人协作工程的管理,wiki的源代码托管在基于git设计的github上。
|
||||
|
||||
:::
|
||||
|
||||
:::tip Node.js是什么?
|
||||
|
||||
Node.js是一个在后端运行javascript的运行时,我们使用基于这个平台设计的docusaurus框架来将wiki从一堆markdown文档变成一个网站。
|
||||
|
||||
:::
|
||||
|
||||
访问github,如果没有账号,就注册一个,然后,打开https://github.com/ZSCNetSupportDept/website。
|
||||
|
||||
点击上面的fork,创建仓库的一个分支,点击create fork。
|
||||
|
||||
进入你刚才fork的仓库,点击Code,选择HTTPS,复制下面的那一串内容。
|
||||
|
||||
然后,请打开你的终端,你可以在“开始”菜单栏里搜索"PowerShell"来打开。
|
||||
|
||||
如果你的系统没有安装PowerShell,你可以使用cmd,按`Win+R`,在弹出框里输入`cmd`打开。
|
||||
|
||||
输入`git clone 你复制的内容`,这将在你的当前目录下创建一个名为`website`的文件夹,并将开发组网站的全部内容复制到这个文件夹里面。
|
||||
|
||||
|
||||
:::tip 提示
|
||||
|
||||
你可能会需要科学上网的手段来访问github。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
然后,输入`cd website`。
|
||||
|
||||
切换到我们的项目目录下后,运行`npm install`来安装项目的所有依赖。
|
||||
|
||||
:::tip 提示
|
||||
|
||||
为了加速下载,你可能会需要配置npm镜像,可以输入`npm config set registry https://registry.npmmirror.com`。
|
||||
|
||||
:::
|
||||
|
||||
现在,输入`npm start`,程序就会在你的电脑上构建并部署网站。
|
||||
|
||||
然后在你的浏览器上输入`https://localhost:3000`
|
||||
|
||||
如果没有出错的话,你会看到我们开发组网站的主页。
|
||||
|
||||
:::tip 提示
|
||||
|
||||
每次启动测试版网站,都需要在这里再输入一次`npm start`
|
||||
|
||||
:::
|
||||
|
||||
## 编辑
|
||||
打开`website`下的`docs`文件夹,再打开`wiki`文件夹,这里就是我们的wiki内容仓库了。
|
||||
|
||||
仓库里的所有的文章都是以md结尾的markdown文件,你需要熟悉markdown的写法,才能对文章的内容修改和完善,markdown并不是特别复杂,你可以花一点时间去学会他。
|
||||
:::info 信息
|
||||
|
||||
这里是一些学习markdown的资源:https://markdown.com.cn/ \
|
||||
https://github.highlight.ink/mastering-markdown/intro \
|
||||
https://commonmark.org/ (英文)
|
||||
|
||||
:::
|
||||
|
||||
如果想要在文本中添加图片,视频,或者其他资源,请将这些素材放入static中,以方便管理。
|
||||
|
||||
对代码的修改将会自动同步到刚才打开的网页里,你可以在那里确认修改的结果满意与否,注意,你需要保存文件才会同步更改。
|
||||
|
||||
修改完毕后,输入`git add .`再输入`git commit`,并对你的修改做出一个简短的说明。
|
||||
|
||||
### 改什么?
|
||||
你可以校对已有的条目,增加一些内容,或者加入一些图片之类的。
|
||||
|
||||
你也可以添加新条目,撰写一些你觉得有价值的修网心得。
|
||||
|
||||
或是帮助我们改善网站本身,比如改一改主题,写一个首页等(如果有相关能力,需要react基础)
|
||||
|
||||
### 文件名
|
||||
你会发现,所有文件的名字前面都有一个数字,那就是文章在sidebar中出现的顺序,增添文件,请按照`order-filename.md`的格式修改名字。
|
||||
|
||||
在文件名前加一个下划线,系统就不会将文章加入成品网站中。
|
||||
|
||||
:::tip 提示
|
||||
|
||||
关于如何修改wiki的更多提示,可以去看docusaurus的官方文档:[链接](https://docusaurus.cn)
|
||||
|
||||
:::
|
||||
## 推送到仓库
|
||||
在修改完毕并且在本地检查完毕后,你需要将你的修改同步到你在github的远程fork仓库,然后再提交一个pull request请求主仓库合并你在fork仓库所做的修改。
|
||||
|
||||
首先,你需要验证你的身份,让github允许你的电脑向它提交push
|
||||
:::tip 提示
|
||||
|
||||
你可以使用github desktop或github cli来简化这个流程,不过我们想让你在这个过程中学习SSH的用法,如果你想方便一点,直接跳到“使用github-cli”。
|
||||
|
||||
:::
|
||||
### 选项1:使用SSH
|
||||
|
||||
首先,确保你安装了SSH,你可以看微软的这片文档:[链接](https://learn.microsoft.com/zh-cn/windows-server/administration/openssh/openssh_install_firstuse?tabs=gui)。
|
||||
|
||||
打开终端,输入
|
||||
|
||||
```PowerShell
|
||||
|
||||
ssh-keygen -t ed25519
|
||||
|
||||
```
|
||||
|
||||
然后在接下来的选项中检查密钥的存放路径,以及使用一个密码来加密这个密钥,我们建议你设置一个密码。
|
||||
|
||||
然后我们设置开机自动启动ssh-agent服务。
|
||||
|
||||
确保你使用了管理员权限运行了下面的PowerShell代码:
|
||||
|
||||
```PowerShell
|
||||
|
||||
Get-Service ssh-agent | Set-Service -StartupType Automatic
|
||||
|
||||
Start-Service ssh-agent
|
||||
|
||||
Get-Service ssh-agent
|
||||
|
||||
```
|
||||
|
||||
最后一个命令应该会返回`Running`状态。
|
||||
|
||||
然后,你就可以输入`ssh-add`来加载你的密钥。
|
||||
|
||||
```PowerShell
|
||||
|
||||
ssh-add 你的私钥位置
|
||||
|
||||
```
|
||||
:::tip 提示
|
||||
|
||||
每次重启电脑,你都要重新输入一遍`ssh-add`。
|
||||
|
||||
:::
|
||||
|
||||
:::info 信息
|
||||
|
||||
关于SSH的配置,参考了这片[微软文档](https://learn.microsoft.com/zh-cn/windows-server/administration/openssh/openssh_keymanagement)。
|
||||
|
||||
:::
|
||||
|
||||
接下来,我们配置github的SSH访问。
|
||||
|
||||
打开与私钥同目录下的公钥文件(以pub结尾),然后复制他,注意要全部复制,不要多出或减少任何内容。
|
||||
|
||||
点一下你的github头像,选择Settings,然后在侧边栏的Access板块找到SSH and GPG keys。
|
||||
|
||||
点击 `New SSH key`。
|
||||
|
||||
把密钥粘贴到下面,然后保存就行了。
|
||||
|
||||
在终端里输入
|
||||
|
||||
```PowerShell
|
||||
|
||||
ssh git@github.com
|
||||
|
||||
```
|
||||
|
||||
如果返回的文本里出现了你的用户名,配置就大概成功了。
|
||||
|
||||
现在就可以输入`git push`了
|
||||
|
||||
```PowerShell
|
||||
|
||||
git push
|
||||
|
||||
```
|
||||
|
||||
这个命令会向远端的仓库提交你在本地提交的commit,检查你的fork仓库,有没有更新到你本地的修改?
|
||||
|
||||
:::info 信息
|
||||
|
||||
参考了github的文档:[Click Me ](https://docs.github.com/zh/authentication/connecting-to-github-with-ssh/about-ssh)
|
||||
|
||||
:::
|
||||
|
||||
### 选项2:使用github-cli
|
||||
访问https://github.com/cli/cli/releases , 下载最新版本。
|
||||
|
||||
输入`gh`以检查安装的成功状况。
|
||||
|
||||
没问题的话,输入`gh auth login`,会弹出一个浏览器窗口,在弹出的窗口中完成登录。
|
||||
|
||||
然后,你应该就可以直接使用`git push`了,输入`git push`,然后查看你在github中的fork仓库,有没有更新到你本地的修改。
|
||||
:::info 信息
|
||||
|
||||
这里有更多关于github cli 的信息:[Click Me ](https://docs.github.com/zh/github-cli/github-cli/about-github-cli)
|
||||
|
||||
:::
|
||||
|
||||
### 提交pull request
|
||||
一个pull request 是一个请求,将修改建议发送给主仓库,并让主仓库合并这些修改。
|
||||
|
||||
打开主仓库,选择上面的Pull Requests,然后选择New Pull Request,如果没有出现你的fork仓库,点击compare accross forks。
|
||||
|
||||
然后就可以Create Pull Request了。
|
||||
|
||||
提交后,开发组成员会校对你的修改,将你的修改应用到主仓库中,这就是我们的开发流程了。
|
||||
|
||||
|
||||
:::info wiki的分层更新模型
|
||||
|
||||
按照我们的设计,wiki的内容从新到旧,一共分为三个版本:
|
||||
- 最新的版本是大家在自己的电脑上运行的测试版网站,这个版本包含了最新的想法和更改,等待完善后推送到主仓库。
|
||||
- 然后是我们的demo版本网站[zscdev-demo.pages.dev](zscdev-demo.pages.dev),这个版本立即反应了任何被合并进去主仓库master分支的更改,大家可以对这个网站上的内容随便提意见,任何修改都将很快被同步到网站里。
|
||||
- 当主仓库和demo网站的更新积累到一定程度的数量时,开发组成员会根据一个版本作为wiki的正式版,正式推送到我们的网站[developer.zsxyww.com](developer.zsxyww.com)里,这个版本通常要比demo要落后几次更新,但是那些在施工中的文章,和还在讨论的段落等不稳定的内容将不会被同步到这里,换句话说,这个版本是“稳定版”。
|
||||
|
||||
这样网站的测试和正式使用的版本就分开了,保证了网站内容的严谨
|
||||
|
||||
:::
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2
docs/devdocs/_legacy/02-网站/05-旧版wiki/05-旧版wiki-概览.md
Normal file
2
docs/devdocs/_legacy/02-网站/05-旧版wiki/05-旧版wiki-概览.md
Normal file
@@ -0,0 +1,2 @@
|
||||
# 旧版wiki
|
||||
使用wiki.js开发的wiki
|
||||
2
docs/devdocs/_legacy/02-网站/06-主页面/06-主页面-概览.md
Normal file
2
docs/devdocs/_legacy/02-网站/06-主页面/06-主页面-概览.md
Normal file
@@ -0,0 +1,2 @@
|
||||
# 主页面
|
||||
主页面就是www.zsxyww.com下的页面,这个页面好像很久没人维护了,文档正在编写。。。
|
||||
11
docs/devdocs/_legacy/02-网站/index.md
Normal file
11
docs/devdocs/_legacy/02-网站/index.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# 网站
|
||||
## 概述
|
||||
目前,网站有www.zsxyww.com(主站点),wiki.zsxyww.com(旧wiki),和developer.zsxyww.com(开发组网站),这些子域
|
||||
### www.zsxyww.com
|
||||
好像是前辈们留下来的项目,暂时不清楚情况
|
||||
### wiki.zsxyww.com
|
||||
旧版的wiki,使用wiki.js构建,上面存放了累积下来的许多文章,目前准备迁移
|
||||
### developer.zsxyww.com
|
||||
目前集中开发的新站点,把计划发布的新版wiki和开发组的文档都放在上面了,使用docusaurus构建
|
||||
## 部署
|
||||
网站部署在腾讯云的服务器上,dnspod进行解析,nginx反向代理,官网和旧wiki是封装在docker容器里的,监听8090端口和3000端口,
|
||||
1
docs/devdocs/_legacy/03-网维报修系统/index.md
Normal file
1
docs/devdocs/_legacy/03-网维报修系统/index.md
Normal file
@@ -0,0 +1 @@
|
||||
# 网维报修系统
|
||||
2
docs/devdocs/_legacy/03-网维报修系统/概览.md
Normal file
2
docs/devdocs/_legacy/03-网维报修系统/概览.md
Normal file
@@ -0,0 +1,2 @@
|
||||
# 网维报修系统
|
||||
目前所使用的系统在这里:[系统](https://github.com/ZSCNetSupportDept/WechatTicketSystem) 暂时不了解,难以维护,准备开发新的报修系统
|
||||
1
docs/devdocs/_legacy/04-招新系统/README.md
Normal file
1
docs/devdocs/_legacy/04-招新系统/README.md
Normal file
@@ -0,0 +1 @@
|
||||
# 招新系统
|
||||
2
docs/devdocs/_legacy/04-招新系统/概览.md
Normal file
2
docs/devdocs/_legacy/04-招新系统/概览.md
Normal file
@@ -0,0 +1,2 @@
|
||||
# 招新系统
|
||||
不了解
|
||||
6
docs/devdocs/_legacy/05-基础设施/README.md
Normal file
6
docs/devdocs/_legacy/05-基础设施/README.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# 基础设施
|
||||
## 服务器
|
||||
我们目前拥有负责报修系统和网站的两台服务器,位于tx云上,联系组长以获得访问权限
|
||||
## 域名
|
||||
我们拥有一个域名zsxyww.com
|
||||
|
||||
7
docs/devdocs/_legacy/05-基础设施/zsxyww.com域名.md
Normal file
7
docs/devdocs/_legacy/05-基础设施/zsxyww.com域名.md
Normal file
@@ -0,0 +1,7 @@
|
||||
# zsxyww.com
|
||||
这个域名目前托管在west.cn上,腾讯云dns,关于域名的交接事项,请联系组长
|
||||
:::tip 提示
|
||||
|
||||
记得续费域名
|
||||
|
||||
:::
|
||||
9
docs/devdocs/_legacy/05-基础设施/报修服务器.md
Normal file
9
docs/devdocs/_legacy/05-基础设施/报修服务器.md
Normal file
@@ -0,0 +1,9 @@
|
||||
# 报修服务器
|
||||
因信息安全,请移步我们的内部仓库访问相关信息
|
||||
:::tip 提示
|
||||
|
||||
记得续费网站
|
||||
|
||||
:::
|
||||
|
||||
|
||||
8
docs/devdocs/_legacy/05-基础设施/网站服务器.md
Normal file
8
docs/devdocs/_legacy/05-基础设施/网站服务器.md
Normal file
@@ -0,0 +1,8 @@
|
||||
# 网站服务器
|
||||
因信息安全,请移步我们的内部仓库访问相关信息
|
||||
:::tip 提示
|
||||
|
||||
记得续费网站
|
||||
|
||||
:::
|
||||
|
||||
9
docs/devdocs/_legacy/06-联系开发组.md
Normal file
9
docs/devdocs/_legacy/06-联系开发组.md
Normal file
@@ -0,0 +1,9 @@
|
||||
# 联系开发组
|
||||
开发组成员可以通过以下方式联系:
|
||||
## 联系方式
|
||||
QQ群:961797864
|
||||
QQ:2597760847(组长)
|
||||
|
||||
论坛:https://github.com/orgs/ZSCNetSupportDept/discussions (内部)\
|
||||
github主页: https://github.com/ZSCNetSupportDept
|
||||
|
||||
2
docs/devdocs/_legacy/07-下载.md
Normal file
2
docs/devdocs/_legacy/07-下载.md
Normal file
@@ -0,0 +1,2 @@
|
||||
# 下载
|
||||
可以把需要存放的文件链接放在这里以供下载
|
||||
44
docs/devdocs/_legacy/09-培训/01-git/01-概览.md
Normal file
44
docs/devdocs/_legacy/09-培训/01-git/01-概览.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# 概览Git
|
||||
这里是git的一个简短教程
|
||||
## 目录
|
||||
本教程的目录。。。
|
||||
|
||||
1. 介绍-做为版本控制系统的git
|
||||
|
||||
- 什么是版本控制系统(VCS)?
|
||||
- git是如何进行版本控制的?
|
||||
|
||||
2. git的基础概念
|
||||
|
||||
- 新建一个git仓库
|
||||
- 跟踪文件,暂存文件
|
||||
- 提交commit
|
||||
- 分支(branch)介绍
|
||||
- 合并-merge与rebase
|
||||
- cherry-pick
|
||||
- HEAD和相对引用
|
||||
|
||||
3. 远程仓库
|
||||
|
||||
- clone和origin
|
||||
- 远程分支是什么
|
||||
- fetch , pull & push !
|
||||
|
||||
4. 托管平台
|
||||
|
||||
- github
|
||||
- gitlab
|
||||
- gitea
|
||||
|
||||
5. 高级
|
||||
|
||||
- GUI
|
||||
- git-gui
|
||||
- vscode上的一些扩展
|
||||
- lazygit
|
||||
- 自建git服务
|
||||
- gitea
|
||||
- 参考
|
||||
- pro git
|
||||
- learngitbranching.js.org
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
# 什么是版本控制系统(VCS)?
|
||||
@@ -0,0 +1 @@
|
||||
# git是如何进行版本控制的?
|
||||
@@ -0,0 +1 @@
|
||||
# 新建一个git仓库
|
||||
@@ -0,0 +1 @@
|
||||
# 跟踪文件,暂存文件
|
||||
@@ -0,0 +1 @@
|
||||
# 提交commit
|
||||
@@ -0,0 +1 @@
|
||||
# 分支(branch)介绍
|
||||
@@ -0,0 +1 @@
|
||||
# HEAD和相对引用
|
||||
@@ -0,0 +1 @@
|
||||
# 合并-merge与rebase
|
||||
@@ -0,0 +1 @@
|
||||
# clone和origin
|
||||
@@ -0,0 +1 @@
|
||||
# 远程分支是什么
|
||||
@@ -0,0 +1 @@
|
||||
# fetch , pull & push !
|
||||
1
docs/devdocs/_legacy/09-培训/01-git/05-托管平台/01-github.md
Normal file
1
docs/devdocs/_legacy/09-培训/01-git/05-托管平台/01-github.md
Normal file
@@ -0,0 +1 @@
|
||||
# github
|
||||
1
docs/devdocs/_legacy/09-培训/01-git/05-托管平台/02-gitlab.md
Normal file
1
docs/devdocs/_legacy/09-培训/01-git/05-托管平台/02-gitlab.md
Normal file
@@ -0,0 +1 @@
|
||||
# gitlab
|
||||
1
docs/devdocs/_legacy/09-培训/01-git/05-托管平台/03-gitea.md
Normal file
1
docs/devdocs/_legacy/09-培训/01-git/05-托管平台/03-gitea.md
Normal file
@@ -0,0 +1 @@
|
||||
# gitea
|
||||
1
docs/devdocs/_legacy/09-培训/01-git/06-高级/01-gui.md
Normal file
1
docs/devdocs/_legacy/09-培训/01-git/06-高级/01-gui.md
Normal file
@@ -0,0 +1 @@
|
||||
# GUI
|
||||
1
docs/devdocs/_legacy/09-培训/01-git/06-高级/02-selfhosted.md
Normal file
1
docs/devdocs/_legacy/09-培训/01-git/06-高级/02-selfhosted.md
Normal file
@@ -0,0 +1 @@
|
||||
# 自建Git服务
|
||||
1
docs/devdocs/_legacy/09-培训/01-git/06-高级/03-references.md
Normal file
1
docs/devdocs/_legacy/09-培训/01-git/06-高级/03-references.md
Normal file
@@ -0,0 +1 @@
|
||||
# 参考
|
||||
213
docs/devdocs/_legacy/09-培训/02-Web后端/01-Web后端的简单介绍.md
Normal file
213
docs/devdocs/_legacy/09-培训/02-Web后端/01-Web后端的简单介绍.md
Normal file
@@ -0,0 +1,213 @@
|
||||
# Web后端的简单介绍
|
||||
这篇文章将带你学习构建一个Web后端的简单知识;作为一篇基础的教程,我们在教程里不会太多涉及诸如缓存,消息队列等高级内容,而是专注于基础的部分;我们也不会在一开始就涉及到具体的编程语言代码,而是将这篇文章作为一个理论性的介绍.你可能至少需要了解一些计算机的基础知识,比如html等,才可以了解文章中的一些概念.
|
||||
|
||||
## Web的历史
|
||||
进行Web后端开发,首先需要知道Web的一些概念,实际上,“后端”这个概念不是一开始就存在的,随着人们对互联网需求的不断复杂化,后端的概念才出现了,我们首先来了解Web的发展历史
|
||||
|
||||
### 静态网页
|
||||
互联网最开始只有静态网页,所谓“静态”,指的是网页中的内容是完全固定的,在服务器端存储了内容固定的html,css,或者是其他的什么文件,用户访问网页,就是通过互联网查看这些固定的文件。在这种情况下,你访问一个网站,从本质上更像是访问远端计算机上的某个文件夹
|
||||
|
||||
例如,如果要建立一个网站,那就在你的电脑上安装一个HTTP服务器(比如apache,nginx),在软件的设置里指定你电脑上的某个文件夹为网站的根文件夹,然后去买一个域名(网址的意思),把域名的DNS绑定到你电脑的IP地址上,那么其他人在浏览器上输入你的域名,就可以访问根文件夹下面的内容了。比如,在根文件夹下面放一个`index.html`,那访问域名时,浏览器就会默认显示这个文件的内容,可以在下面放一些图片,比如根文件夹下面有:
|
||||
`/foo.jpg`和`/subfolder/bar.jpg`,那么别人在浏览器上面输入`http://yourdomain.com/foo.jpg`和`http://yourdomain.com/subfolder/bar.jpg`就可以访问到对应的文件。
|
||||
|
||||
这种方法很原始,但是如果需求不是很大的话,你也可以使用这种静态网页,你现在正在看的文章,其实就是一个静态的网页
|
||||
|
||||
这些访问都是通过HTTP协议来进行的,在这里,我们需要详细介绍HTTP协议,以及HTTP协议的方法:
|
||||
|
||||
#### HTTP协议
|
||||
HTTP(HyperText Transfer Protocol,即超文本传输协议)是一个网络客户端(比如浏览器)和服务端(比如服务器,当然普通的电脑也可以)之间沟通的协议,让浏览器可以对服务器上的某个文件进行操作(最常见,也是大家最熟悉的用途就是获取这个文件,然后显示出来~),我们上面举的例子,包括我们日常浏览网站的本质,就是在获取服务器上面的内容(实际上HTTP协议可以做的不止这些,下面会讲到)
|
||||
|
||||
一个完整的HTTP通信包含了请求和回应,请求有客户端发起,回应是服务端返回给客户端
|
||||
|
||||
##### HTTP的请求
|
||||
严谨地说,一个HTTP请求包含请求头(HTTP Request Header)和请求体(Request Body),一个HTTP的请求头主要包含了:
|
||||
- 目标网站:资源存在的网站,例如`example.org`
|
||||
- URL,用于指定需要操作的是哪一个文件,例如`example.org/hahaha.txt`
|
||||
- 方法,用于指定操作,即对URL指定的资源进行什么操作,比如访问这个文件
|
||||
- 自定义参数:前面说的URL和方法都是通过键值对的形式存在于请求头上的,作为请求头的参数(键值对就是形如`a=b`的表达式)你也可以自定义一些键值对在请求头里,这表现为附加在URL之后的一系列键值对,通过?开头,&分割,例如`example.org/hello.html?locale=zh-CN&custom=wuwuwu`,这就告诉服务器:两个参数:`locale=zh-CN,custom=wuwuwu`,这些参数是可选的,自定义的参数可以用于被后端解析,现在不理解也没关系,关于URL参数的话题我们在之后谈
|
||||
- cookie:cookie是服务器放在浏览器里的一些临时缓存,可以干一些事情,当然需要有这个东西才会在请求头里带着,我们也以后再谈
|
||||
|
||||
对于某些方法,需要在请求时向服务器夹带一些东西,请求体就是装载这些东西的
|
||||
|
||||
|
||||
###### HTTP方法
|
||||
HTTP方法定义了这个请求具体要对指定的文件做什么,其中:
|
||||
- GET:获取指定的资源
|
||||
- POST:上传指定的资源
|
||||
- PUT:更新指定的资源,如果没有就创建一个
|
||||
- PATCH:修改指定的资源
|
||||
- DELETE:删除指指定的资源
|
||||
- HEAD:和GET差不多,但是只要求服务器返回回应头,可以用在试探文件的大小上,来判断文件的更新情况,从而决定下一步操作
|
||||
|
||||
我们日常使用浏览器,比如在地址栏中输入`baidu.com`,其实就是在对这个地址做GET请求,一般用户使用浏览器,自己是不能做出除了GET之外的请求的,但是其他请求在现代的网站中被经常使用,这其实是前端脚本在工作,以后会解释
|
||||
|
||||
如果使用某一些方法的话,需要上传一些东西,那么这些东西就需要放在请求体里面,比如POST等
|
||||
|
||||
##### HTTP的响应
|
||||
其实回应也分为回应头和回应体,回应头主要包含:
|
||||
- 状态码:针对请求的回应有对应的状态,比如,如果GET请求没有问题,成功返回的话就返回200 OK状态码,如果找不到请求里对应的文件就会返回`404 Not Found`
|
||||
- 内容格式:向浏览器说明回应体(若有)是什么格式的,文本文件的编码设置等,比如html文件?图片?这决定了浏览器如何对待这些文件
|
||||
- 内容的大小:返回所请求资源的大小(若有)
|
||||
|
||||
回应体就是包含了回应的主体内容了,如果是GET请求的话,那么就回应了所GET文件的内容,如果是其他请求的话,可能也会没有回应体,具体看使用的方法
|
||||
|
||||
##### 一个例子
|
||||
`GET`方法从服务器获得一个资源,我们在浏览器的地址栏输入一个地址时,就是在对这个URI做`GET`请求,前面的例子也是通过`GET`方法来进行的。
|
||||
|
||||
比如,发送`GET developer.zsxyww.com/test/test.txt`,那么就会把我们服务器上的test.txt这个文件发过来
|
||||
|
||||
`POST`方法向服务器上传一个资源,例如使用某个客户端发送`POST http://example.org/someprogram.exe`,在request body里面带上你的这个文件,那么`example.org`网站的根目录下就会多出一个叫做`someprogram.exe`的文件
|
||||
|
||||
除了上面介绍的这些方法,还有`DELETE`,`PATCH`等方法,分别对应了删除,修改一个资源,你可以在你的电脑上通过`curl`等程序,或者通过浏览器控制台来进行常规的`GET`之外的方法请求
|
||||
|
||||
:::tip 提示
|
||||
|
||||
httpbin.org 这个网站可以让你试验HTTP协议的方法
|
||||
|
||||
:::
|
||||
|
||||
不管使用的是什么方法,HTTP协议传输的对象都是一些固定静态的文件,这些文件的内容是什么就是什么,不会变化,这样的网页就叫做静态网页。
|
||||
|
||||
### 动态网页
|
||||
这样的网页是不能满足大家对互联网的需求的,举例子来说:淘宝上有数不清的商品在售卖,如果淘宝为每一个商品都在服务器目录下面创建一个html文件,好让大家通过访问`http://taobao.com/someproduct.html`来查看商品信息,那这个工作量就非常大了,还有一些更重要的问题:这样的网页,基本上没有交互的功能,我们希望用户可以点击按钮就能购买商品,商家填写表单就能上传商品
|
||||
|
||||
#### CGI
|
||||
这些都是静态互联网无法解决的问题,所以程序员们开发了一个叫CGI(Common Gateway Interface,通用网关接口)的技术,这种技术在用户请求网站的内容时,让一个脚本劫持用户的请求,返回给用户一个脚本动态生成的html文件,比如,如果用户想知道报名数据库里面目前所有的报名人员,发送`GET http://example.org/allVolunteer.html`,CGI程序发现给本机请求`allVolunteer.html`这个文件,并且程序的代码里写了:如果接受到对`/allVolunteer.html`的请求,那就去查找数据库里面的全部报名人员,并将返回结果插入到一个模板html文件中。程序返回这个文件,于是,用户就受到了CGI程序动态产生的html.
|
||||
|
||||
虽然CGI现在很少见了,但是将一个发送到服务器的地址请求劫持到脚本(函数)上是现代动态网站的常用思路。
|
||||
|
||||
#### JavaScript
|
||||
除了服务器,浏览器也在为适配动态网站而更新。在1995年,网景公司的员工发明了一种编程语言,叫做"JavaScript",这是对当时新兴的Java和Java Applet的回应,这种语言最大的特点就是它被设计在浏览器中运行,并且可以调用相关接口来操作页面html,css内容和进行HTTP请求,他们让自己家的网景浏览器率先支持了这种编程语言(这个浏览器就是火狐浏览器的前身),这极大的提高了浏览器对于动态网页的支持。
|
||||
|
||||
#### AJAX(Asynchronous JavaScript and XML)
|
||||
尽管是在浏览器里的语言,但是作为一个完整编程语言的JavaScript还是非常强大的,在有了操作DOM,发起HTTP请求的能力后,JavaScript,搭配一些后端的程序,可以做到CGI传统动态页面没有办法做到的功能:动态更新用户html页面上的内容。传统的后端CGI,可以动态生成html,但是这个html生成之后到用户的手里还是不会变化的,而JavaScript作为一个编程语言,通过运行在用户浏览器,可以操作html内容和发起HTTP请求,便可以自己异步地对服务器发送一些请求,依据这些内容便可以部分改变用户浏览器所显示的HTML,CSS,只需要浏览器重新渲染一遍就行了,这种技术就叫做AJAX,Asynchronous JavaScript and XML
|
||||
|
||||
AJAX与传统动态页面的不同点是:在获取新数据时,不是刷新全部的页面,而是让JavaScript操作页面的部分内容。同时,后端也不是返回html,而是返回一些可以被JavaScript理解的序列化数据(例如纯文本、XML,JSON等),前端的脚本根据这些数据,来操作用户的html
|
||||
|
||||
|
||||
##### 例子
|
||||
比如,在浏览我们的wiki网站时(虽然我们的wiki是静态网页),你会发现页面的大部分元素都是重叠的,比如页面最上面的导航栏,sidebar,页脚等,样式也是一样的,在切换不同的页面时,每次获取html都要重新获取这些重复的部分,这样就造成了一些浪费,如果使用AJAX技术,那么只需要第一次打开网站的时候加载这些框架性的元素,然后再加载一个JavaScript脚本,点击sidebar的时候,就将那个文章的内容本身拿过来,然后替换掉原有的页面内容,这样就更加节省,这种部分更新页面内容,而不重新加载整个页面的技术,就叫做AJAX
|
||||
|
||||
再举一个例子,比如我们的报名系统有一个查询功能,如果输入的用户在数据库存在的话,返回这个用户的全部信息,如果不存在,那么要给用户显示一条错误信息,这种信息如果要单独给用户发送一个新页面的话,是很麻烦的,用户端的体验也不好,我们希望在按下查询按钮之后直接在原来的页面旁边显示服务器返回的结果,如果没有AJAX技术,那么我们只能把用户的当前页面重新发过去,但是把查询结果也放里面,因为传统没有JavaScript的网页没有办法对数据进行一些简单的操作,只是被动的渲染html.css文件,而AJAX技术就允许我们直接把返回的数据本身发送到客户端,而且发送的数据也不止局限于HTML,CSS,而可以是一个XML,JSON,或是直接返回状态码,让客户端脚本负责解析这些数据,并将这些数据变成浏览器其他部分可以直接渲染的文件
|
||||
|
||||
当一个URL不是返回一个HTML数据,而是返回一些不是给用户本人准备的数据时,当这些路径不止于接受GET请求时,这些路径就和我们传统静态网站的URL,代表一个文件时所表现的路径有所不同了
|
||||
|
||||
这些后端路径不是给用户设计的,通过浏览器直接访问这些地方大概会返回一些用户难以读懂的代码,他们是给JavaScript,或者另一种程序设计的,这种路径就叫做web API,他们是两个程序通过HTTP交互的地方,而不是人机交互的界面,我们先举一个例子,再解释这个问题
|
||||
|
||||
:::tip 提示
|
||||
|
||||
AJAX技术在今天已经非常常用了,以至于很多人都意识不到他们在使用AJAX技术
|
||||
|
||||
:::
|
||||
|
||||
##### 一个AJAX报名系统的例子
|
||||
下面举一个例子,来详细说明AJAX的工作原理:用户需要通过一个网页进行某项活动的报名,填写个人信息,然后点击网页上的提交按钮,服务端会返回报名的结果,成功还是失败,与传统的方法不同,服务器返回信息时不是重新返回一个HTML,而是让浏览器直接在原有的界面上(比如提交按钮的下面)显示报名的状态
|
||||
|
||||
用户通过浏览器输入地址,使用`GET`方法发起对`http://example.org/submit.html`的请求,服务器获得请求后,在root目录下面找到submit.html文件,浏览器得到文件后开始解析渲染这个文件,发现这个html在头部又要求浏览器向服务器获取`submit.js`文件,于是浏览器不需要用户处理自己又发送了一条`GET`的HTTP Request,并且执行返回的脚本,这个脚本的内容是监听html文件中提交按钮的“点击”事件,当按钮被点击时,执行某个函数。
|
||||
|
||||
返回的html文件包括了提示框,要求用户输入姓名,手机,空闲时间等信息,在这些输入栏的最下面有一个提交按钮,当点击这个按钮时,脚本就会被激活,脚本执行的函数将读取用户从上面输入进来的内容,做一些简单的认证(比如说手机号的格式等),然后将这些信息组织成一个XML文件(当然,AJAX中的X就是XML咯,现在其实也可以用其他的方法序列化,比如JSON什么的),向服务器发送一个`POST`请求,地址是`http://example.org/api/submit/submit.php`,在请求体中包含刚才的XML文件。
|
||||
|
||||
服务器在接收这个请求后,就会将,这个请求的上下文全部转交给`submit.php`这个脚本,脚本再做一些工作,录入数据库,如果一切都成功了,就向客户端发送回应成功,反之则回应失败的消息,回应的内容可以是一个纯文本,或者直接是状态码,比如,就返回一个JSON:
|
||||
|
||||
```JSON
|
||||
|
||||
{
|
||||
"status":"success",
|
||||
"submit":{
|
||||
"name":"小明",
|
||||
"freeday":"2023-11-25",
|
||||
"phone":10000000000
|
||||
},
|
||||
"createdAt":"2023-10-25_9:23:22"
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
在JavaScript脚本接收到回应后,根据返回的内容,操作html文件的内容,在提交按钮的下面一行插入一个文本块:
|
||||
|
||||
```HTML
|
||||
|
||||
<div id="json_responses">
|
||||
<p id="json:status">提交成功!你提交了:</p>
|
||||
<p id="json:submit.name">姓名:小明</p>
|
||||
<p id="json:submit.freeday">空闲时间:2023-11-25</p>
|
||||
<p id="json:submit.phone">手机号:10000000000</p>
|
||||
<p id="json:createdAt">服务端提交创建时间:2023-10-25 9:23:22</p>
|
||||
</div>
|
||||
|
||||
```
|
||||
|
||||
或者其他的信息
|
||||
|
||||
#### URI在现代的意义
|
||||
从刚才的这个例子中,我们可以看到网站的URI,其实慢慢的不止可以指代一个文件了,他更多的是指代一个资源,或者一个业务,向`submit.php`提交一个`POST`请求,难道是在远端创建一个`submit.php`程序?其实在这里更多是指将客户端的数据上传到这个`/api/submit/submit.php`的业务窗口,我们的后端开发,也是建立在这种对虚拟的路径的请求下的。例如我们设计一个报名系统,我们可以设计一个API接口叫做`POST http://api.yourwebsite.io/newVolunteer`,接受浏览器js的报名信息提交,在服务器,根本就没有`/newVolunteer`这个文件,连文件夹都不一定会有,全靠路由在工作(见下篇文章)
|
||||
|
||||
### Web应用
|
||||
#### WebSocket
|
||||
HTTP的动态网站已经很好了,但是协议本身有一个缺点:一个HTTP连接分为请求和响应,只能由客户端发起请求,服务端返回响应,如果客户端没有先发一点什么给服务端的话,服务端是没办法先给客户端发信息的,这就给一些更加复杂的要求增添了障碍:比如通过浏览器和别人聊天,需要接受来自服务器发给你的其他人的聊天的信息;或者是在浏览器上玩游戏,需要和服务器交换数据。这可以通过轮询来解决,但是这样还是不方便。
|
||||
|
||||
WebSocket是一个全新的协议,支持客户端和服务器的全双工通信,即客户端和服务器都可以主动地发消息,而且可以同时进行,而且是采用较小的数据帧格式,降低了网络开销,提高了数据传输速度。WebSocket在建立连接后保持长时间有效,不需要为每次消息发送重新建立连接,因此效率更高。
|
||||
|
||||
为了兼容HTTP协议,WebSocket也是监听80和443端口(HTTPS),握手采用了HTTP协议,通过升级协议来建立连接,如果可以升级,服务器会返回101状态码,升级连接.
|
||||
|
||||
:::info 信息
|
||||
|
||||
对于WebSocket过于详细的介绍超出了本篇文章的内容,可以自行了解
|
||||
|
||||
:::
|
||||
|
||||
##### Server-Sent Events(SSE)
|
||||
WebSocket是一个全新的协议,兼容性可能不是那么好,如果要求比较低的话,可以看一看Server-Sent Events,这个协议基于HTTP,允许服务器主动给客户端发送信息,当然也请自行了解。
|
||||
|
||||
#### 在Web上运行应用
|
||||
传统观念里,一个应用程序是在计算机上直接运行的,但是在介绍了上面的技术之后,我们可以想到,在Web上也是可以运行应用程序的,通过现代的高性能JavaScript运行时,可以提供类似于原生的运行速度,通过WebSocket,可以快速的更新内容,现在的HTML和CSS也足够强大,用户的机器性能也越来越强了,而且,开发Web应用可以直接使用成熟的Web技术栈,在浏览器中运行也更安全,以至于现在很多本地的应用也开始使用Web技术了(electron)。
|
||||
|
||||
例如,我们所使用的腾讯文档,支持多人协作编辑,就使用了WebSocket技术来向你主动发送其他人对文档编辑的信息
|
||||
|
||||
#### 单页应用(SPA)
|
||||
一个现代的网站,或者说一个提供服务的Web应用,流行单页应用架构,顾名思义,服务器只会在用户打开网页时加载一段html文件,后面的全部内容都是通过js动态更新的,js和服务器的后端接口交互主要是采用AJAX,对于某些复杂的需求,可能会需要使用前面的技术,WebSocket或者SSE
|
||||
|
||||
`React.js`就是贯彻单页应用思想最彻底的前端框架,单页应用的坏处就是打破了为静态网页文件设计的“收藏”功能和前进后退,也不利于SEO和无障碍,因为用户在网站上只打开一个网页,网页的内容根据用户操作由浏览器脚本动态更新,而生成的html也大多没有做语义化优化,难以被理解和解析
|
||||
|
||||
SPA的例子就是邮箱应用(比如Gmail),通过浏览器访问你的邮箱,通过邮箱的主页面点某个邮件,你并没有进入一个新的页面,而是在原有的页面上,内容变成了邮件查看的界面,如果在主页面上点击发件的话,同样也没有一个发件页面,而是直接呈现发件的UI
|
||||
|
||||
有时候,通过AJAX调用API的HTTP交互没办法满足一些需求,比如说服务器主动推送信息,或者流式传输(比如直播平台,游戏等),这个时候就需要使用前面提到的技术,前面的腾讯文档就是一个例子,还有就是网络聊天室(matrix之类),需要向浏览器主动推送信息,还有直播平台,需要将源源不断的多媒体数据传递到用户那里,还有网络游戏需要快速在浏览器和服务器之间交换游戏数据,但是一般这些应用的基础框架都是建立在传统AJAX上的,只是业务部分采用其他协议实现,这些现代的应用慢慢地将计算量转移到了前端,而后端只负责存储和提供,查询数据,甚至后端都不用负责产生html,只需要提供API,来为前端提供数据就行
|
||||
|
||||
|
||||
##### WebAssembly
|
||||
WebAssembly是最近新出现的技术,他允许开发者将C/C++ , Rust等原本的一些编译型语言编译成浏览器可以执行的字节码,使得在浏览器中也可以执行这些程序,目前也有一些使用WebAssembly的应用,可以去看看,最大的好处就是不会JavaScript也能开发前端,也可以复用以前的代码(当然,这个其实是前端的内容)
|
||||
|
||||
## Web后端-是干什么的?
|
||||
前面用非常长的一段文字来介绍Web的发展历史,就是为了说明Web后端是干什么的,或者说,编写一个Web后端需要干什么?
|
||||
|
||||
如果你想写一个静态网站,那么简单的http服务器就可以满足你,不需要你手动写什么代码;如果你想写一个基于AJAX的服务(比如我们网维现在的报修系统),那么你需要设计好API,和前端沟通好序列化相关事项,或者是返回JSON信息什么的让前端处理,还是返回html让浏览器渲染;如果你想写一个WebSocket的Web应用那就要难一些了,可能需要掌握一些并发编程的知识才可以写出一个可以使用的服务
|
||||
|
||||
我们接下来的教程,将注重开发一个现代的AJAX后端服务,同时辅助提供一些静态文件托管的功能。
|
||||
|
||||
|
||||
### Web后端的组成
|
||||
一个Web后端主要由以下部分组成:
|
||||
- 路由(router)
|
||||
- 处理(handler)
|
||||
- 数据库/ORM
|
||||
- 鉴权
|
||||
- 模板(如果需要)
|
||||
|
||||
详细的信息,请阅读下一篇文章:[Click Me](./基于HTTP的Web后端的组成)
|
||||
|
||||
:::tip 提示
|
||||
|
||||
读完这篇文章之后,你可以回顾文章里的内容,问一问自己:
|
||||
|
||||
- Web经历了哪些发展阶段?
|
||||
- 前后端之间是如何使用HTTP协议交互的?
|
||||
- AJAX技术是什么?是如何支撑起现代的网页的?(单页应用)
|
||||
|
||||
推荐在看下一篇文章之前看看下面的参考文章
|
||||
|
||||
:::
|
||||
|
||||
## 参考
|
||||
在读完这篇文章后,你可以去详细阅读这篇文档:https://developer.mozilla.org/zh-CN/docs/Learn/Server-side/First_steps/Introduction (**强烈推荐!**)
|
||||
|
||||
这里是关于HTTP协议的详细介绍:https://developer.mozilla.org/zh-CN/docs/Web/HTTP
|
||||
156
docs/devdocs/_legacy/09-培训/02-Web后端/02-基于HTTP的Web后端的组成.md
Normal file
156
docs/devdocs/_legacy/09-培训/02-Web后端/02-基于HTTP的Web后端的组成.md
Normal file
@@ -0,0 +1,156 @@
|
||||
# 基于HTTP的Web后端的组成
|
||||
一个基于HTTP的Web后端通常有以下部分组成:
|
||||
|
||||
##### 路由系统(router)
|
||||
|
||||
路由系统负责处理用户访问网页时的请求路径/方法,并转交给对应的处理者
|
||||
|
||||
|
||||
##### 处理者(handler)
|
||||
|
||||
处理者负责处理用户的请求,读取用户在URI中的参数,和请求体中的内容(如果有)等,统称为上下文(Context),负责返回请求所对应的回应
|
||||
|
||||
有的系统还会继续细分,将业务层和接口层分开(这种情况下通常接口层是和路由功能合并的)
|
||||
|
||||
|
||||
_最低要求是这个,另外,通常一个后端系统还需要连接一个数据库:_
|
||||
|
||||
|
||||
##### 数据库
|
||||
|
||||
通常是兼容SQL协议的关系型数据库,负责存储后端所需要用到和产生的信息
|
||||
|
||||
_其实很多后端系统无非就是对数据库的增删改查(所谓的CRUD),可以说这些系统就是数据库的一层方便wrapper_
|
||||
|
||||
|
||||
##### 鉴权系统
|
||||
|
||||
通常,我们系统的内容不打算对互联网上的任何一个人开放,所以我们需要一些方法来验证访问者的身份
|
||||
|
||||
|
||||
|
||||
##### 模板系统(optional)
|
||||
|
||||
如果你打算通过后端渲染HTML返回到用户浏览器,那你需要一套模板来方便地将动态内容插入到模板里面返回给用户,如果是一个纯粹API的站点,还是想直接把工作甩给前端,你就可以不用配置模板
|
||||
|
||||
|
||||
此外,还有一些外围的工作:
|
||||
|
||||
##### 反向代理
|
||||
|
||||
通常我们的Web后端服务不是直接暴露对外访问的,而是经过一层代理的转发,这样更加的安全,配置也更加简单,服务只需要监听本地端口
|
||||
|
||||
##### 配置系统
|
||||
|
||||
你的系统需要读取配置,比如监听端口,数据库连接,还有其他服务的密钥等
|
||||
|
||||
##### CI/CD
|
||||
|
||||
自动化配置构建,部署,测试等工作,让你专注代码工作,而不用把心思过多地放在部署构建这些工作上面
|
||||
|
||||
## 路由
|
||||
假设你的一个报名服务架设在`service.io`上:
|
||||
|
||||
首先,用户访问这个网址时需要显示一段欢迎文字,然后将他们引导到报名的页面
|
||||
|
||||
那么,你应该在用户访问`/`时返回一个html文件,里面含有导向`/volunteer.html`的超链接
|
||||
|
||||
`/volunteer.html`里面的前端代码需要以AJAX的形式与后端API交互,比如:
|
||||
|
||||
`service.io/api/register`接受POST请求,前端上传报名人的信息,后端录入数据库,并返回录入的信息,全部以JSON序列化
|
||||
|
||||
`service.io/api/view`接受GET请求,让这个报名人查看自己的报名信息,返回JSON格式
|
||||
|
||||
`service.io/api/cancel`接受POST请求,取消某个报名人的信息,成功则返回相应状态码
|
||||
|
||||
`service.io/admin/viewAll`让管理员查看当前的所有报名,接受GET请求
|
||||
|
||||
`service.io/admin/cancel`让管理员取消任意的报名,接受的POST
|
||||
|
||||
在现代网站设计中,我们不是在根目录下面创建对应的文件(实际上,连根目录都不需要了),我们使用一些叫做“路由器(router)”的模块,当用户通过一定的方法请求一定的路径时,就把这些请求转交到相应的handler
|
||||
### URI参数
|
||||
参数在正常路径后面,以?开始,以&分割,以键值对的形式存在
|
||||
|
||||
例如:`service.io/api/register?name=小明&phone=10000000000&freeday=2024-9-25`
|
||||
|
||||
这样的参数可以被许多后端框架使用内置的解析器解析
|
||||
|
||||
### 参数化路径
|
||||
这种路径通常是配合REST风格的接口来设计的,比如:
|
||||
|
||||
`service.io/api/users/小明`
|
||||
|
||||
类似于这样的路径,许多后端框架可以使用`service.io/api/users/:user`这样的形式来匹配,在转交给的handler中可以读取`:user`参数,从而返回参数所指定的资源
|
||||
### API设计
|
||||
API的设计包括了路径的设计和接口格式的设计,一般小项目可以相对地随便一点,但是大项目还是需要认真一点的
|
||||
#### 传统
|
||||
我们刚才所举的例子就是一个传统的API设计,一个路径就对应了一个业务点,一般只会使用`GET`和`POST`来对应获取和上传,前后端的交互一般在文档里自行约定,或者采用内置的表单(如果数据比较简单的话)
|
||||
#### REST
|
||||
REST的意思是“表现层状态转换”(英语:Representational State Transfer,缩写:REST),这种风格的要点是一个URI表示一个资源,而不是一个业务,同时充分地利用HTTP方法
|
||||
|
||||
例如,我们在前面定义了`Register`,`View`和`Cancel`三个API,如果是要上传什么就用`POST`,获取`GET`,一个路径表示的是一个业务,而不是系统的某个资源,下面来看看REST怎么写:
|
||||
|
||||
`POST service.io/api/users/小明` 用户小明提交一个报名,具体的报名信息在请求体里,这将在数据库里面创建一个小明的报名记录
|
||||
|
||||
`GET service.io/api/users/小明` 用户小明查看自己的报名信息
|
||||
|
||||
`DELETE service.io/api/users/小明` 取消小明的报名
|
||||
|
||||
`PUT service.io/api/users/小明` 修改小明的报名信息,新信息放在请求体里面了
|
||||
|
||||
可以发现,REST风格的API可以看作是对传统静态网页互联网的回归,这种风格直观简洁,兼容性更好,更加利于缓存等
|
||||
|
||||
#### GraphQL
|
||||
GraphQL是一种用于API交互的查询语言,他意图解决接口格式定义和多次查询带来的复杂问题
|
||||
|
||||
首先,后端需要支持GraphQL,然后,前端需要在API请求中注明自己想后端用什么格式呈现什么想要的信息,这样就不需要前端多次请求不同的业务了
|
||||
|
||||
这对大型系统或许比较友好,但是如果只是一些小项目的话,这可能有些复杂,具体可以自己去了解
|
||||
## handler
|
||||
handler可以说是一个后端系统的核心了,因为他们是实际处理业务的地方
|
||||
### 面向对象与模型
|
||||
虽然可以使用其他的范式,但是最推荐的是依据OOP的原则,将需要处理的模型写成对象,将一系列操作写成对象的方法
|
||||
例如,报名系统本质上就是处理“报名人”这个对象的各种操作,我们可以定义:
|
||||
|
||||
```Go
|
||||
|
||||
type Volunteer struct{
|
||||
config.DB
|
||||
id int
|
||||
Name string
|
||||
Phone int
|
||||
FreeDay time.Time
|
||||
Note string
|
||||
}
|
||||
|
||||
func (v *volunteer)Add()error{
|
||||
if err:=db.addVolunteer(v.MainConnection) err!=nil{
|
||||
return err
|
||||
}
|
||||
return nil
|
||||
}
|
||||
|
||||
```
|
||||
要设计一个登记报名的handler,就只需要将前端发过来的信息反序列化到Volunteer对象里,然后调用Add方法即可,这种思路就叫做面向对象
|
||||
|
||||
所设计的Volunteer和他的一系列方法就叫做“模型”
|
||||
|
||||
## 数据库
|
||||
数据库为后端的业务数据提供了方便的存储和查询服务,这里指的是结构化数据,其他需求可以去看高级教程
|
||||
### SQLite
|
||||
这是个轻量级的数据库,一个数据库就是一个文件,通常用于业务量比较小的场景或者是本地开发的场景
|
||||
### PostgreSQL
|
||||
这个可以说是目前最厉害的开源数据库了,不仅提供了常规的结构化功能,而且对于一些简单的非结构化存储需求也可以胜任,但是本身的资源消耗是有点高的
|
||||
|
||||
### 选择数据库的各种考量
|
||||
- 业务量:如果业务量比较小的话,就使用SQLite吧
|
||||
- 兼容性:如果现有的环境和业务依赖于某个数据库,那么就继续用吧
|
||||
### ORM
|
||||
ORM是对数据库的一层抽象,让你专注于业务逻辑的开发,而不用担心具体的数据库问题,如果对于性能或者其他的方面没有很大的需求的话,建议在你的项目里使用ORM
|
||||
## 鉴权
|
||||
### Session
|
||||
### JWT
|
||||
### OAuth2.0
|
||||
|
||||
## 模板
|
||||
### Jinja2
|
||||
11
docs/devdocs/_legacy/09-培训/02-Web后端/03-高级教程.md
Normal file
11
docs/devdocs/_legacy/09-培训/02-Web后端/03-高级教程.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# 高级教程
|
||||
本篇是Web后端的进阶系列文章
|
||||
## 缓存
|
||||
### 为什么我们需要缓存?
|
||||
对于某些需要高频读写的数据,放在数据库中的速度会比较慢,所以我们需要一个缓存俩提供快速访问,这些缓存通常放在内存中,提供最快的访问速度
|
||||
### Redis 和 Memcached
|
||||
## 消息队列
|
||||
|
||||
## 日志与监控
|
||||
|
||||
## NoSQL与非结构化数据
|
||||
21
docs/devdocs/_legacy/_后端API服务_/01-概览.md
Normal file
21
docs/devdocs/_legacy/_后端API服务_/01-概览.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# 后端API服务
|
||||
## 介绍
|
||||
该项目作为网维的统一后端API接口而设计,连接网维的数据库,并提供一系列接口给前端以支持网维日常的业务逻辑,其他开发人员可以直接调用这些接口,从而专注与前端,以便于降低整个系统设计的复杂度
|
||||
|
||||
该项目采用Go语言编写,Web框架采用echo,ORM框架为gorm,
|
||||
## 项目地址
|
||||
https://github.com/ZSCNetSupportDept/zscnetworksupport-api
|
||||
## 构建
|
||||
要想构建该项目,你需要安装`Go`和`make`,在一台linux机器上构建
|
||||
|
||||
输入`make install`即可安装本项目的依赖,而不构建
|
||||
|
||||
输入`make build`即可构建该项目,项目放在`make`文件夹下
|
||||
## 部署
|
||||
只需要把可执行文件放在生产环境下运行即可,本项目可能会提供一些静态文件访问,需要将`static`放在与可执行文件相同的目录下
|
||||
## 配置
|
||||
程序接受,且只接受一个参数,为配置文件的路径,关于配置文件的格式,请参照“配置”一章
|
||||
## 运行
|
||||
运行后,程序会将日志和错误文件输出到stdout中,你可以配置系统服务来使程序开机自启动,将输出定向到日志或者stderr里
|
||||
|
||||
在运行程序之后,你还要配置一些反向代理的软件,来将流量导向程序所监听的端口,你还要定期续期https证书,以保证https访问
|
||||
13
docs/devdocs/_legacy/_后端API服务_/02-配置.md
Normal file
13
docs/devdocs/_legacy/_后端API服务_/02-配置.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# 配置
|
||||
# 介绍
|
||||
配置为一个`json`文件,其中,各个字段的定义如下:
|
||||
|
||||
`port`:一个数字,为程序所监听的端口
|
||||
|
||||
`database`:
|
||||
- `Type`:一个字符串,指定了所使用的数据库的类型,需要在`MySQL` `PostgreSQL` `SQLite`中选择一个
|
||||
- `Path`:对于SQLite填写数据库的位置,对于其他的数据库填写URL
|
||||
- `Port`:数据库所监听的端口,SQLite可以不用填,以下也是
|
||||
- `User`:数据库用户名
|
||||
- `name`:数据库名称,
|
||||
- `Password`:数据库密码
|
||||
22
docs/devdocs/_legacy/_后端API服务_/03-结构.md
Normal file
22
docs/devdocs/_legacy/_后端API服务_/03-结构.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# 结构
|
||||
仓库项目的结构如下:
|
||||
|
||||
`main.go`:项目程序的起点,从此处开始运行
|
||||
|
||||
`config`:存放了读取配置,提供配置变量相关的代码
|
||||
|
||||
`databases`:提供了连接数据库相关的代码,提供主数据库连接变量(Usingdb)
|
||||
|
||||
`handlers`:为handler的存放地点,一类业务为一个对象,handler作为其方法实现
|
||||
|
||||
`model`:业务所采用的模型,定义了一个业务对象的存储和相关方法
|
||||
|
||||
`use`:在这里注册所有需要提供的API和中间件,程序将使用这里的配置
|
||||
|
||||
`make`:存放了构建所产生的程序
|
||||
|
||||
`static`:存放了静态文件以进行路由
|
||||
|
||||
## 原理
|
||||
当程序运行时:
|
||||
main()将调用sysinit(),读取参数中的配置,将配置记录在全局变量`config.UseConfig`中
|
||||
Reference in New Issue
Block a user