HAOVP 的技术选型和服务拆分

第一版功能范围确定之后，HAOVP 接下来需要回答两个问题：采用什么技术栈，以及业务应该怎样划分边界。

技术越多并不代表系统越合理。个人项目更容易出现“为了使用组件而使用组件”的情况，所以每一项选型都需要对应具体问题；服务拆分也不能只按功能名称切开，还要考虑数据归属、调用关系和独立变化的可能性。

目前先确定技术选型和服务边界，接下来再通过编码、启动、联调和部署逐项验证这些选择是否合适。

为什么考虑微服务

如果只追求尽快做出页面，单体应用会更直接。但 HAOVP 的目标不仅是完成基础视频业务，也希望练习服务治理、独立部署、故障隔离和多模块协作。

视频平台中的业务资源差异较大：

• 登录认证关注身份和安全；
• 视频上传与处理消耗文件、CPU 和存储资源；
• 评论互动更偏向高频写入；
• 推荐与行为数据需要独立演进；
• 管理端关注审核、权限和运营管理。

这些模块未来可能以不同节奏变化，因此我计划采用微服务方式拆分。但微服务会增加配置、调用、数据一致性、部署和排障成本，这些成本也要进入项目范围。

后端基础技术

后端计划使用 Java 17 和 Spring Boot 3，主要原因是：

• Java 是我已有工作经验的主要语言；
• Spring Boot 适合快速建立统一的 Web、配置和数据访问基础；
• Java 17 是长期支持版本，可以使用较新的生态；
• 后续接入 Spring Cloud 时版本关系相对清晰。

微服务治理计划围绕 Spring Cloud 和 Spring Cloud Alibaba 展开，重点考虑：

• Gateway 作为统一入口；
• Nacos 提供服务注册发现和配置管理；
• OpenFeign 简化服务间 HTTP 调用；
• Sentinel 用于限流、熔断和降级方向的验证。

这些目前是选型和设计目标。组件加入依赖不等于能力已经生效，后续还需要通过配置、部署和故障场景验证。

用户端和管理端

前端计划使用 Vue 3 与 TypeScript，分别建设用户端和管理端。

用户端更关注：

• 内容浏览和播放；
• 上传与互动；
• 个人资料和使用状态；
• 移动端适配。

管理端更关注：

• 用户和内容管理；
• 审核与状态处理；
• 分类、标签和评论治理；
• 权限与运营信息。

两个前端可以共享后端能力和接口规范，但页面组件、交互方式和权限入口不同。现阶段先确定分端方向，再按核心流程逐步推进页面和管理功能。

数据与基础设施

不同数据适合不同的存储方式：

这些技术需要分别落到具体链路中。特别是消息、缓存和多节点存储，我会把“已配置”“已实现”和“已验证”作为不同状态记录。

服务边界的初步方案

当前计划将后端分成统一入口和若干业务服务：

统一网关
    -> 认证服务
    -> 用户服务
    -> 内容服务
    -> 评论服务
    -> 推荐服务
    -> 管理服务

初步职责如下：

• 认证服务：注册登录、身份凭证和认证状态；
• 用户服务：用户资料、关系和个人设置；
• 内容服务：视频、分类、标签、上传和播放相关数据；
• 评论服务：评论、回复和互动状态；
• 推荐服务：热门、相似和兴趣方向的推荐能力；
• 管理服务：管理员、权限以及用户和内容治理入口；
• 网关：统一路由、基础认证检查和跨域等入口能力。

这套边界先作为开发起点。开发过程中如果发现调用过多、数据归属不清或职责重叠，就需要继续调整。

为什么不按数据库表拆服务

一个服务应该围绕业务能力，而不是一张表。按表拆分容易产生大量细粒度远程调用，也会让一个完整业务流程分散在多个服务里。

我会优先考虑：

• 哪些数据由同一业务规则管理；
• 哪些功能经常一起变化；
• 哪些模块需要独立扩展或隔离；
• 服务之间是否只能通过明确接口交互；
• 一个请求是否需要跨越过多服务。

如果拆分之后每个操作都需要多个服务相互调用，说明边界可能过细。

数据边界与一致性

服务拆分后，数据一致性会比单体更复杂。当前不准备为所有业务强行使用同一种分布式事务方案，而是先区分场景：

强一致要求高
    -> 尽量在单一服务和本地事务内完成
允许短暂延迟
    -> 考虑事件或异步补偿
跨服务查询
    -> 通过接口或适当的数据冗余处理

具体方案必须结合业务失败后果决定。不能因为技术栈中存在消息队列，就把所有跨服务操作都改成异步。

统一入口和认证边界

所有外部请求计划通过网关进入。网关适合做统一路由、基础认证信息检查、跨域和入口限流，但具体业务权限仍然需要由对应服务确认。

客户端
    -> 网关识别请求与身份
    -> 路由到业务服务
    -> 服务校验具体权限与状态
    -> 返回统一响应

认证服务负责身份凭证，用户服务负责用户业务资料，两者需要明确边界，避免认证数据和业务数据相互混杂。

选型需要有退出方案

某个组件如果明显增加复杂度，却没有解决当前问题，就应该允许暂缓或替换。

例如：

• 第一版消息量很小时，异步链路先保持简单；
• 推荐服务先使用可解释的基础策略，等行为数据和基础链路稳定后再继续扩展；
• 多节点部署未验证前，先保证单机环境可启动和复现；
• 限流、熔断和降级必须经过测试，不能只看配置文件存在。

个人项目的目标是理解和验证技术，而不是把组件名称堆进 README。

当前设计结论

截至 2025 年 12 月 20 日，HAOVP 计划采用 Java 17、Spring Boot 3、Spring Cloud、Vue 3 等作为主要技术基础，并以网关、认证、用户、内容、评论、推荐和管理等能力划分服务边界。

下一步需要把设计继续落到模块结构、接口契约、数据归属和可运行的开发环境中，再通过编译、联调和部署检查这些选择是否真正合适。