这是我参与「第三届青训营 -后端场」笔记创作活动的第1篇笔记。

一、项目说明与系列更新安排

虽然这个项目是个小组合作项目，但是由于小组里面大家的学习进度有所差别，因此我从开课的第一周就打算先一个人做着。做到后面再和小组其他小伙伴讨论一下遇到的困难以及优化方法。

这个项目大概做了3个多周，基本都是在教研室边划边做，其中弯路和技术转型也经历过好几次。理论上业务逻辑花了一个周完成，之后的时间都是在各种优化和不同部署技术的转换（具体就是全网查询解决方案，各种yaml文件的写和copy）。

github地址：github.com/incredibleg… （有些扫尾工作与build脚本没有写，所以仅供参考）

系列分P与技术难点

0. 项目起步的走过的一些弯路，以及找寻这些弯路的过程。最后确定了使用gRPC做主要的业务实现，Gin做一层http的代理（解析query）。
1. 业务逻辑的主要实现，以及介绍一下业务中生成封面图使用的ffmpeg库，在本地开另一个端口作为静态资源服务器；附带一些docker使用小知识。
2. 基于服务服务发现组件Nacos的SOA部署。介绍主要使用的Nacos作为配置中心以及微服务的服务发现组件，特别是在实现gRPC的负载均衡需要实现的resolver（解析器），这里是gRPC的重点，后面也会遇到。
3. 基于docker-compose部署的改造。在docker-compose部署中，放弃了对配置中心和服务发现中心，改造代码使用命令行或环境变量作为配置所需的变量。稍微讲一下docker镜像的制作与上传，包括为了缩小镜像大小的编译环境和运行环境分离，以及白嫖镜像仓库并上传步骤。
4. 基于kubernetes的部署方案。在上面把各种服务的镜像准备好了之后，就开始各种写（拷贝）yaml配置文件。些许体会到了yaml工程师的内涵，以及各种无效配置却找不到原因的难受（正是由于k8s这种声明式的部署才有的特色）。

二、项目起步的弯路

项目刚开始小组内部沟通了一下准备使用gRPC + grpc-gateway技术栈。在快速地完成了第一个注册接口后，使用postman完成了接口测试，然后在客户端demo上尝试了半天，发现根本没有任何反应。

这时候该干啥？———当然看接口文档呀！

本来也是去看了无数遍接口文档的。但是当你面对一个POST请求，而且这个请求带有两个参数的时候，大部分人的固有印象都是去request body里去取，即使当你看到下面这个接口的文档的时候，也不会去注意红框中的东西。 所以，我直接用了wireshark来抓app的流量，当我发现抓到的URI请求长得是下面这个样子的：

我当时的内心是这个样子的

首先，作为一个POST请求，在Restful的熏陶下，一般人的第一反应都会去Body里找这两个参数，而不是去uri里找query。

其次，将query参数做成prefix/?para1=?&para2=?格式的，就是有点为难使用有些技术栈不支持这样解析的小伙伴了。

我猜这可能是训练营老师为了让我们多去看看接口文档，顺便帮我们戒断这种Restful Prototype/doge.

三、技术选型

为了解决这样复杂query的解析以及之后部署的微服务需求，我就打算使用gRPC作为后端业务逻辑的操作单元，使用Gorm和数据库直接交互，使用Gin来做了一层HTTP 服务代理，主要也是帮助完成request的解析以及请求的过滤。

另一个很重要的原因就是使用Gin自带的log可以方便的看到request请求，可以方便看到是否存在一些比较妖的URI，以及方便把URI复制到postman中方便测试

第一个版本的简单架构如下：

其实分成了六个微服务是主动给自己加了点难度，因为到后面部署的时候微服务越多，之间的通信和调用也会更难。但这一环节中，稍微有点难度的其实还是gRPC的负载均衡和扩缩容的发现问题，当然这也是下一节的笔记了。

Bye