引入go-mir重构paopao-ce的接入层与业务逻辑层

[alimy]

主要功能特性

• 引入go-mir重构paopao-ce的接入层与业务逻辑层；
• 提供 单实例多服务运行的机制，也就是说可以在单个paopao-ce实例中在不同端口上运行多个服务，比如新的Web服务、旧的Deprecated:OldWeb服务、独立的前端服务Frontend:Web、后续将添加的服务于Android/iOS的Mobile服务等等都可以通过配置文件config.yaml配置成在不同的端口同时在一个paopao-ce实例中运行；
• 添加gRPC服务开发的基本代码基，并引入buf提供gRPC服务代码开发的全流程管理；
• 基于go-mir + gin实现了一个新的Web服务，同时保留旧的Deprecated:OldWeb服务；
• 添加独立的Web前端静态资源服务Frontend:Web，在配置文件config.yaml的Features中添加Frontend:Web就可以开启该服务；

本PR是作为 v0.2.0 版本的一部分

• add Friendship feature
• add Lightship feature
• add Sqlx feature
• add new Web service
• add Deprecated:OldWeb feature
• support run multiple service in single paopao-ce instance
• use go-mir optimize paopao-ce source code architecture

如何审核这个PR

由于这个PR是一个经过 长时间演进过来的代码，代码基特别大，基本上相当于一次代码重构，建议通过clone代码switch到feature/mir代码分支然后直接审核代码。

这个PR是如何形成的？

• 首先是为了更好、更便捷的添加子服务、功能模块；paopao-ce是一个非常好的项目，可以承载很多好的想法，这就需要一个更完善的方便添加功能模块与子服务的可扩展代码基，正好本人也一直在思考之前我开发的go-mir升级版本如何演进，有些编程思想的沉淀需要一个主体来承载，这就有了go-mir v3版本，而这正好也契合本人对paopao-ce代码优化的可扩展性需求，也就开始了一个漫长的代码演进过程，目前来看还算满意，远超预期。
• 本PR最初是有一个基本需求，就是让paopao-ce可以同时承载RESTful API服务与gRPC服务的代码开发，具体为什么需要gRPC服务，可以参考本PR中的docs文档；目前来说，已经添加基本的gRPC代码基，后期开发具体gRPC子服务的时候再继续优化；

本人希望这个PR先合并到dev分支，后期再持续优化。 PR可能还有一些不足之处，我会持续优化，这里先挂出来，大家都可以先试试、尝尝鲜，欢迎提供建议、优化。@rocboss 看看有没有时间，抽空帮忙审核一下，PR也不忙着合并，先至少挂个一星期吧。本人年前还有点闲余时间，可以持续跟踪反馈，年后要忙其他事就没那么多闲余时间了:)

[alimy]

审核、尝鲜、优化...

git clone https://github.com/rocboss/paopao-ce
cd paopao-ce
git checkout -f feature/mir
cp config.yaml.sample config.yaml
# edit config.yaml to custom paopao-ce runtime configure
# you can just add `Service` `Deprecated` sub-suites features to Features section to start all sub-service in a single paopao-ce instance
make run TAGS='embed go_json'
 ____   __    __  ____   __    __  
(  _ \ / _\  /  \(  _ \ / _\  /  \ 
 ) __//    \(  O )) __//    \(  O )
(__)  \_/\_/ \__/(__)  \_/\_/ \__/ 
paopao v0.1.2 (build:5aa3074 2023-01-01 16:28:06)
starting run service...

[email protected]       [start] - listen on http://0.0.0.0:8014
[email protected]         [start] - listen on http://0.0.0.0:8010
[email protected]      [start] - listen on http://0.0.0.0:8020
[email protected]        [start] - listen on http://0.0.0.0:8011
[email protected]      [start] - listen on http://0.0.0.0:8012
[email protected]      [start] - listen on http://0.0.0.0:8008
[email protected] [start] - listen on http://0.0.0.0:8006
[email protected]         [start] - listen on http://0.0.0.0:8016
[email protected]    [start] - listen on http://0.0.0.0:8018
``

[rocboss]

整体看了下结构，没啥问题，设计思路挺好的，开发和迭代频率也很高👍🏻。
后续features迭代完成后，可以合入主干以2.0系列发布。

有两个建议可以参考下：

1. 目前整合的各类服务较多，配置项有些繁杂，建议拆分为多个配置文件，大部分配置提供默认项即可，方便一些小白用户快速配置上手。
2. 多服务按照端口进行了拆分，目前占用了8个端口，有个场景可能需要考虑下，比如：有些宿主机混部多种其他服务实例，整体只对外开放部分端口如8000-9000，单实例限制最多分配3个端口，考虑端口也是比较紧俏的资源，建议可以按照 http api、rpc 切分端口，同类型的服务按path区分。

[alimy]

1. 目前整合的各类服务较多，配置项有些繁杂，建议拆分为多个配置文件，大部分配置提供默认项即可，方便一些小白用户快速配置上手。

这个是有考虑的，其实目前已经提供了按需添加配置的机制，paopao-ce在internal/conf/config.yaml中内嵌了一份完整的默认配置，内嵌的默认配置与自定义配置config.yaml在paopao-ce启动时自动进行了配置项合并，自定义的配置(./config.yaml或者./custom/config.yaml)中只需要自定义 运行时 声明Features 的相应配置即可。比如只运行Web 子服务，config.yaml可以只包含如下配置(其他配置使用默认值):

# file: config.yaml

Features:
  Default: ["Sqlite3", "Zinc", "LocalOSS",  "BigCacheIndex", "Web"]
WebServer: # Web服务
  HttpIp: 0.0.0.0
  HttpPort: 8010
  ReadTimeout: 60
  WriteTimeout: 60
LocalOSS: # 本地文件OSS存储配置
  SavePath: data/paopao-ce/oss
  Secure: True
  Bucket: paopao
  Domain: api.paopao.info
Zinc: # Zinc搜索配置
  Host: 127.0.0.1:4080
  Index: paopao-data
  User: admin
  Password: admin
  Secure: False

部署paopao-ce实例时，可以按需自定义配置运行时所需的配置项， 多个实例部署可以使用不同配置项组合，运行不同的子服务，再通过一个统一的 Proxy(Nginx或云端proxy) 将请求桥接到具体的paopao-ce部署实例。

[alimy]

2. 多服务按照端口进行了拆分，目前占用了8个端口，有个场景可能需要考虑下，比如：有些宿主机混部多种其他服务实例，整体只对外开放部分端口如8000-9000，单实例限制最多分配3个端口，考虑端口也是比较紧俏的资源，建议可以按照 http api、rpc 切分端口，同类型的服务按path区分。

这个也有考虑， 目前提供的机制是各个子服务(gRPC/RESTful API服务)可以在一个独立端口提供业务服务，也可以多个同类型的子服务（RESTful API服务 或者 gRPC 服务）共享同一个端口提供服务，比如 Web/Admin/Bot 三个子服务在8010端口提供服务, 只需要配置三个子服务的HttpIp/HttpPort为相同值即可:

# file: config.yaml

Features:
  Default: ["Sqlite3", "Zinc", "LocalOSS",  "BigCacheIndex", "Web", "Admin", "Bot"]
WebServer: # Web服务
  HttpIp: 0.0.0.0
  HttpPort: 8010
  ReadTimeout: 60
  WriteTimeout: 60
AdminServer: # Admin后台运维服务
  HttpIp: 0.0.0.0
  HttpPort: 8010
  ReadTimeout: 60
  WriteTimeout: 60
BotServer: # Bot服务
  HttpIp: 0.0.0.0
  HttpPort: 8010
  ReadTimeout: 60
  WriteTimeout: 60

...

Tips: 多服务同端口运行 这个功能 目前可以运行，但是还有一个bug尚没解决: 使用这种机制时退出paopao-ce会被卡住，应该是哪里死锁了，后续会优化解决这个bug。

各个子服务在设计时，也考虑了多服务同端口同时运行的场景，URL在设计时进行了分组管理，比如 Web/Admin/Bot/SpaceX 服务都分为了不同系列的RESTful API， 都有各自独立的URL前缀，可以注册到同一个gin.Engine中：

服务	目录	系列API	url前缀	备注
Web	web	/	/	Web v1版本RESTful API相关定义文件
Admin	admin	m	/m/	Admin后台运维系列相关RESTful API相关定义文件
SpaceX	space	x	/x/	SpaceX系列相关RESTful API相关定义文件
Localoss	localoss	s	/s/	LocalOSS OBS系列RESTful API相关定义文件
Bot	bot	r	/r/	Bot系列相关RESTful API相关定义文件

参考 mirc目录中的RESTful API定义文件。

[alimy]

目前文档没怎么完善，有些内部设计细节只体现在代码中，还没有导出到文档中进行说明，后续会持续完善开发文档的编写。

[rocboss]

👍🏻不错，挺好的！

[alimy]

Tips: 多服务同端口运行 这个功能 目前可以运行，但是还有一个bug尚没解决: 使用这种机制时退出paopao-ce会被卡住，应该是哪里死锁了，后续会优化解决这个bug。

这个问题已经解决了，多服务同端口运行 可以正常工作了。