diff --git a/docs/devdocs/09-培训/02-Web后端/01-Web后端的简单介绍.md b/docs/devdocs/09-培训/02-Web后端/01-Web后端的简单介绍.md index 96273de..1e9389f 100644 --- a/docs/devdocs/09-培训/02-Web后端/01-Web后端的简单介绍.md +++ b/docs/devdocs/09-培训/02-Web后端/01-Web后端的简单介绍.md @@ -27,7 +27,7 @@ httpbin.org 这个网站可以让你试验HTTP协议的方法 这样的网页是不能满足大家对互联网的需求的，举例子来说：淘宝上有数不清的商品在售卖，如果淘宝为每一个商品都在服务器目录下面创建一个html文件，好让大家通过访问`http://taobao.com/someproduct.html`来查看商品信息，那这个工作量就非常大了，还有一些更重要的问题：作为服务器的管理员，你如何从商家那里获取他们要卖什么？如何通过网页来让顾客点击按钮就可以下单？ #### CGI -这些都是静态互联网无法解决的问题，所以程序员们开发了一个叫CGI(Common Gateway Interface,通用网关接口)的技术，这种技术在用户请求网站的内容时，让一个脚本劫持用户的请求，返回给用户一个脚本动态生成的html文件，比如，如果用户想知道这台计算机目前的内存和硬盘占用情况，发送`GET http://example.org/status.html`，CGI程序发现给本机请求status.html这个文件，并且代码里写了如果是这个文件的话，就执行系统的相关操作，并将返回结果插入到一个模板html文件中，返回这个文件，于是，用户就受到了CGI程序动态产生的html. +这些都是静态互联网无法解决的问题，所以程序员们开发了一个叫CGI(Common Gateway Interface,通用网关接口)的技术，这种技术在用户请求网站的内容时，让一个脚本劫持用户的请求，返回给用户一个脚本动态生成的html文件，比如，如果用户想知道这台计算机目前的内存和硬盘占用情况，发送`GET http://example.org/status.html`，CGI程序发现给本机请求status.html这个文件，并且程序的代码里写了：如果是这个文件的话，就执行系统的相关操作，并将返回结果插入到一个模板html文件中。程序返回这个文件，于是，用户就受到了CGI程序动态产生的html. 虽然CGI现在很少见了，但是将一个发送到服务器的地址请求劫持到脚本（函数）上是现代动态网站的常用思路。 @@ -69,7 +69,11 @@ WebSocket是一个全新的协议，支持客户端和服务器的全双工通 WebSocket是一个全新的协议，兼容性可能不是那么好，如果要求比较低的话，可以看一看Server-Sent Events,这个协议基于HTTP,允许服务器主动给客户端发送信息，当然也请自行了解。 #### 在Web上运行应用 -传统观念里，一个应用程序是在计算机上直接运行的，但是在介绍了上面的技术之后，我们可以想到，在Web上也是可以运行应用程序的，技术的难关已经扫除了，通过现代的高性能JavaScript运行时，可以提供类似于原生的运行速度，通过WebSocket,可以快速的更新内容，现在的HTML和CSS也足够强大，用户的机器性能也越来越强了，而且，开发Web应用可以直接使用成熟的Web技术栈，在浏览器中运行也更安全，以至于现在很多本地的应用也开始使用Web技术了(electron) +传统观念里，一个应用程序是在计算机上直接运行的，但是在介绍了上面的技术之后，我们可以想到，在Web上也是可以运行应用程序的，通过现代的高性能JavaScript运行时，可以提供类似于原生的运行速度，通过WebSocket,可以快速的更新内容，现在的HTML和CSS也足够强大，用户的机器性能也越来越强了，而且，开发Web应用可以直接使用成熟的Web技术栈，在浏览器中运行也更安全，以至于现在很多本地的应用也开始使用Web技术了(electron)。现在流行的单页应用(Single Page Application)，后端基本上不参与渲染UI,只是为前端提供API接口，这些应用大多数都使用一些前端框架，例如`React.js`或者`Vue.js`，`Next.js`等，许多复杂的功能大多数使用前端完成，也减轻后端的压力，符合“边缘计算”的原则 + +例如，我们所使用的腾讯文档，支持多人协作编辑，就使用了WebSocket技术来向你主动发送其他人对文档编辑的信息 + + ##### WebAssembly WebAssembly是最近新出现的技术，他允许开发者将C/C++ , Rust等原本的一些编译型语言编译成浏览器可以执行的字节码，使得在浏览器中也可以执行这些程序，目前也有一些使用WebAssembly的应用，可以去看看 diff --git a/docs/devdocs/09-培训/02-Web后端/02-基于HTTP的Web后端的组成.md b/docs/devdocs/09-培训/02-Web后端/02-基于HTTP的Web后端的组成.md index 6df0b88..0f612d2 100644 --- a/docs/devdocs/09-培训/02-Web后端/02-基于HTTP的Web后端的组成.md +++ b/docs/devdocs/09-培训/02-Web后端/02-基于HTTP的Web后端的组成.md @@ -1,72 +1,148 @@ # 基于HTTP的Web后端的组成 一个基于HTTP的Web后端通常有以下部分组成: ---- -- 路由系统(router) +##### 路由系统(router) 路由系统负责处理用户访问网页时的请求路径/方法，并转交给对应的处理者 ---- -- 处理者(handler) +##### 处理者(handler) 处理者负责处理用户的请求，读取用户在URI中的参数，和请求体中的内容（如果有）等，统称为上下文(Context),负责返回请求所对应的回应 有的系统还会继续细分，将业务层和接口层分开(这种情况下通常接口层是和路由功能合并的) ---- _最低要求是这个，另外，通常一个后端系统还需要连接一个数据库:_ ---- -- 数据库 +##### 数据库 通常是兼容SQL协议的关系型数据库，负责存储后端所需要用到和产生的信息 _其实很多后端系统无非就是对数据库的增删改查(所谓的CRUD),可以说这些系统就是数据库的一层方便wrapper_ ---- -- 鉴权系统 +##### 鉴权系统 通常，我们系统的内容不打算对互联网上的任何一个人开放，所以我们需要一些方法来验证访问者的身份 ---- -- 模板系统（optional） + +##### 模板系统（optional） 如果你打算通过后端渲染HTML返回到用户浏览器，那你需要一套模板来方便地将动态内容插入到模板里面返回给用户，如果是一个纯粹API的站点，还是想直接把工作甩给前端，你就可以不用配置模板 ---- 此外，还有一些外围的工作： -- 反向代理 +##### 反向代理 通常我们的Web后端服务不是直接暴露对外访问的，而是经过一层代理的转发，这样更加的安全，配置也更加简单，服务只需要监听本地端口 -- 配置系统 +##### 配置系统 你的系统需要读取配置，比如监听端口，数据库连接，还有其他服务的密钥等 -- CI/CD +##### CI/CD 自动化配置构建，部署，测试等工作，让你专注代码工作，而不用把心思过多地放在部署构建这些工作上面 ## 路由 -### API设计 -#### 传统 -#### REST -#### GraphQL +假设你的一个报名服务架设在`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 +这是个轻量级的数据库，一个数据库就是一个文件，通常用于业务量比较小的场景或者是本地开发的场景 ### Postgre + ### 选择数据库的各种考量 +### ORM ## 鉴权 ### Session diff --git a/docs/devdocs/09-培训/02-Web后端/03-高级教程.md b/docs/devdocs/09-培训/02-Web后端/03-高级教程.md new file mode 100644 index 0000000..c4bdd7a --- /dev/null +++ b/docs/devdocs/09-培训/02-Web后端/03-高级教程.md @@ -0,0 +1,9 @@ +# 高级教程 +本篇是Web后端的进阶系列文章 +## 缓存 + +## 消息队列 + +## 日志与监控 + +## NoSQL与非结构化数据