diff --git a/ROADMAP.md b/ROADMAP.md index a1a28465..fc0e6681 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -6,6 +6,7 @@ paopao-ce roadmap. * [ ] add `Lightship` feature * [ ] add `Sqlx` feature * [x] add new `Web` service +* [x] add `Frontend:Web` feature * [x] add `Deprecated:OldWeb` feature * [x] support run multiple service in single paopao-ce instance * [x] use [go-mir](https://github.com/alimy/mir) optimize paopao-ce source code architecture diff --git a/docs/proposal/001-关于paopao-ce的设计定位.md b/docs/proposal/001-关于paopao-ce的设计定位.md index a1d084cb..8d11911f 100644 --- a/docs/proposal/001-关于paopao-ce的设计定位.md +++ b/docs/proposal/001-关于paopao-ce的设计定位.md @@ -24,7 +24,7 @@ paopao-ce使用对象存储服务存储 图片/视频/附件 等推文资源。 * 本地(Native) - 部署OBS(Object Blob Storage System) 目前开发环境可以使用`localoss`功能提供简单的OBS服务, 也可以自行部署[MinIO](https://github.com/minio/minio)来提供对象存储服务。 -* 云对象存储服务 +* 云对象存储服务 阿里云、腾讯云、华为云都提供云对象存储服务，如何开启服务请参考相应文档进行部署。 #### 搜索引擎 @@ -40,7 +40,7 @@ paopao-ce在代码实现上采用 **单体架构模式、分层设计、功能 ## 从人文角度思考 现在的互联网世界已经非常精彩，各种社交媒体平台琳琅满目，使用体验也非常友好。每个社交平台都有自己的运营方式，都有自己的核心用户群体，也有自己的产品灵魂，都在不断的进行生态演进。比如Twitter、微博都已经从最初的推文分享服务演进到一个成熟的传媒平台，注册用户非常庞大，日均访问PV也是一个惊人的数字，这就注定了平台的运营思维是多维度考量均衡的结果，只能做到让用户群体的大多数人用户体验友好，并不能满足所有人的需求。大平台有大平台的运营模式，小站点有小站点的维系空间。对于类似Twitter这样的推文分享服务，paopao-ce提供一种小站点部署模式，采用类似WordPress的运维模式，让 **个人/小组织** 能快速、便捷的拥有一个提供推文分享服务的小站点，以填补那些在大平台下难以享受到的用户体验，享受小圈子内的自由空间。 -就像许巍唱的「曾经的你」这首歌中所说:"曾梦想仗剑走天涯～ 看一看世界的繁华～ 年少的心总有些轻狂～ 如今你四海为家～ ......" 曾经的你我也在 疯狂刷朋友圈、狂奔微博空间、畅游Twitter世界，但是随着环境的改变、岁月的洗礼、心路的淬炼后，你我可能已经不复当年的热情，逐渐淡出朋友圈、沦为微博的稀客，或许Twitter世界还有点吸引力，但是总感觉表达的欲望不复从前了。是什么原因变成这样的呢，原因可能很多，也各自有自己的不同情形所至于此。但是总归一条，那就是 **自由**; 如果有那么一个有限空间内，可以自由的 *谈天说地、品头论足、唠唠叨叨亦或自言自语*，你我是否又能燃起表达的激情呢？！从这个角度来说，paopao-ce就很契合这种需求，曾经你我想拥有一个自己的博客小站点而使用WordPress，那么今天想拥有一个自己的类似Twitter的推文分享服务小站点，部署paopao-ce或许也是一个不错的选择。 +就像许巍唱的「曾经的你」这首歌中所说:*"曾梦想仗剑走天涯～ 看一看世界的繁华～ 年少的心总有些轻狂～ 如今你四海为家～ ......"* 曾经的你我也在 疯狂刷朋友圈、狂奔微博空间、畅游Twitter世界，但是随着环境的改变、岁月的洗礼、心路的淬炼后，你我可能已经不复当年的热情，逐渐淡出朋友圈、沦为微博的稀客，或许Twitter世界还有点吸引力，但是总感觉表达的欲望不复从前了。是什么原因变成这样的呢，原因可能很多，也各自有自己的不同情形所至于此。但是总归一条，那就是 **自由**; 如果有那么一个有限空间内，可以自由的 **谈天说地、品头论足、唠唠叨叨亦或自言自语**，你我是否又能燃起表达的激情呢？！从这个角度来说，paopao-ce就很契合这种需求，曾经你我想拥有一个自己的博客小站点而使用WordPress，那么今天想拥有一个自己的类似Twitter的推文分享服务小站点，部署paopao-ce或许也是一个不错的选择。 一个产品应该有一个**属于自己的灵魂**，可以说 paopao-ce的宗旨就是 **打造一个清新文艺的微社区**。 @@ -54,7 +54,7 @@ paopao-ce在代码实现上采用 **单体架构模式、分层设计、功能 1. paopao-ce在代码实现上为什么采用单体架构模式？ 一个项目的架构设计是多方面考量均衡的结果，最终的目的是满足项目的需求与长远发展。 * 从架构模式的角度来说，单体架构模式可以满足paopao-ce对自身服务定位的需求，完全有能力承载预期的用户流量QPS，所以采用单体模式架构设计是没有问题的； - * 从运营者的角度来说，在能保障服务质量的前提下，最看重的还是运营成本的考量。提供一项保质保量的服务，可持续性是评价一项服务的重要指标。单体架构模式的项目部署简单，成本相对于分布式架构模式的项目也更低，假设门槛也没有那么高。黑猫白猫，能抓老鼠就是好猫， 在什么阶段就用什么技术，根据部署运营场景选择适合的技术来支撑服务，才是运营者明智的选择。 + * 从运营者的角度来说，在能保障服务质量的前提下，最看重的还是运营成本的考量。提供一项保质保量的服务，可持续性是评价一项服务的重要指标。单体架构模式的项目部署简单，成本相对于分布式架构模式的项目也更低，架设门槛也没有那么高。*黑猫白猫，能抓老鼠就是好猫*， 在什么阶段就用什么技术，根据部署运营场景选择适合的技术来支撑服务，才是运营者明智的选择。 * 现在不管是单体架构模式亦或是云原生的分布式架构模式，相应的技术栈生态都已经非常成熟，技术本身没有优劣之分，需要根据具体环境来适配合适的技术，这样才能在你保证服务质量的同时保证服务的可持续性与经济性。说白了就是paopao-ce目前采用单体架构模式的设计，满足优质服务的同时性价比最高。 1. 如果一个paopao-ce部署站点运营一段时间后QPS逐渐提高到一定程度，目前架构的paopao-ce无法满足进一步的用户流量冲击，是否会采用分布式技术栈进行优化？ 不会。paopao-ce将保守的采用目前的单体架构模式提供极致的QPS用户体验，如果确实需要超高QPS需求的实例部署，将另起炉灶开发另一款相应的产品，或许会采用云原生的分布式技术栈生态进行架构设计，这将是另一个paopao产品的故事序章了(前提是paopao能火出圈)。 diff --git a/docs/proposal/006-关于paopao-ce的结构设计.md b/docs/proposal/006-关于paopao-ce的结构设计.md index 5ae669ff..3f3c8ed8 100644 --- a/docs/proposal/006-关于paopao-ce的结构设计.md +++ b/docs/proposal/006-关于paopao-ce的结构设计.md @@ -56,7 +56,7 @@ tree -L 2 ### 疑问 1. 为什么要引入[go-mir](https://github.com/alimy/mir)? -工欲善其事，必先利其器。为了RESTFul API的后端开发体验可以媲美gRPC，本人特意打造[go-mir](https://github.com/alimy/mir) v3版本来满足需求。[go-mir](https://github.com/alimy/mir)是一套使用golang自身语言生态实现的RESTFul API从接口定义到代码自动生成的脚手架辅助工具集，便捷的实现快速后端开发体验，颇有“程咬金的三板斧，简单抡着就完事”的韵味。而从[go-mir](https://github.com/alimy/mir)的官方文档参考也可以看出，其生成的代码也确实就将一个HTTP的请求/响应简单分成 `请求绑定`->`业务逻辑`->`结果渲染`三个步骤去完成，生成的代码结构简单清晰，与gRPC的生成代码有点类似。 +**工欲善其事，必先利其器**。为了RESTFul API的后端开发体验可以媲美gRPC，本人特意打造[go-mir](https://github.com/alimy/mir) v3版本来满足需求。[go-mir](https://github.com/alimy/mir)是一套使用golang自身语言生态实现的RESTFul API从接口定义到代码自动生成的脚手架辅助工具集，便捷的实现快速后端开发体验，颇有 *“程咬金的三板斧，简单抡着就完事”* 的韵味。而从[go-mir](https://github.com/alimy/mir)的官方文档参考也可以看出，其生成的代码也确实就将一个HTTP的请求/响应简单分成 `请求绑定`->`业务逻辑`->`结果渲染`三个步骤去完成，生成的代码结构简单清晰，与gRPC的生成代码有点类似。 1. 为什么要兼容RESTful服务与gRPC服务？ RESTful服务与gRPC服务各自有擅长的场景，在合适的场景使用最适合的技术去做相应的适配，这是paopao-ce秉持的代码开发原则之一。 diff --git a/mirc/README.md b/mirc/README.md index 81c88517..7e7aa864 100644 --- a/mirc/README.md +++ b/mirc/README.md @@ -1,10 +1,10 @@ ### RESTful API for paopao-ce 本目录包含所有RESTful API相关定义文件 -|目录|系列API|备注| -| ----- | ----- | ----- | -|web|/|Web v1版本RESTful API相关定义文件| -|admin|m|Admin后台运维系列相关RESTful API相关定义文件| -|space|x|SpaceX系列相关RESTful API相关定义文件| -|localoss|s| LocalOSS OBS系列RESTful API相关定义文件| -|bot|r| Bot系列相关RESTful API相关定义文件| +|服务|目录|系列API| url前缀|备注| +| ----- | ----- | ----- | ----- | ----- | +|Web|web|/|/|Web系列RESTful API相关定义文件| +|Admin|admin|m|/m/|Admin后台运维系列相关RESTful API相关定义文件| +|SpaceX|space|x|/x/|SpaceX系列相关RESTful API相关定义文件| +|NativeOBS|localoss|s|/s/| NativeOBS系列RESTful API相关定义文件| +|Bot|bot|r| /r/|Bot系列相关RESTful API相关定义文件|