今天我们进入第三周周一课程正式从单服务转向微服务架构。今天的核心不是写代码而是学会如何把单体应用拆成微服务并定义清晰的服务边界和接口契约。这是微服务开发中最重要、也最容易出错的一步。今日目标掌握 DDD领域驱动设计核心概念特别是限界上下文用于指导服务拆分。将前两周的文章系统拆分为用户服务和文章服务明确各自职责和数据归属。使用Protobuf和JSON Schema定义两个服务之间的 RPC 调用契约。编写一份专业的服务拆分设计文档包含服务边界、接口列表、数据模型、依赖关系。为明天的 JSON-RPC 实战做好准备工作。一、环境与工具准备约 20 分钟今天我们不需要启动服务但需要准备文档和契约文件的编写环境。建议工具绘图工具draw.io、ProcessOn 或纸笔用于绘制服务拓扑图。Protobuf 编译器可选如果你希望验证.proto文件语法可以在容器内安装protoc但今天只需编写文件。安装protoc可选# 进入容器后执行apt-getupdateapt-getinstall-yprotobuf-compiler工作目录在项目根目录下新建docs/和protos/文件夹mkdir-p/var/www/hyperf-app/docs /var/www/hyperf-app/protos二、知识核心微服务拆分与契约设计约 2 小时1. 单体架构的痛点与微服务优势我们目前的文章系统是单体应用用户管理、文章 CRUD、评论、点赞全部在一个代码库里共用一个数据库。优势是开发快但问题明显部署耦合改一行评论代码整个应用都要重新部署。扩展困难无法单独对文章查询或用户服务进行扩容。数据压力集中所有表在同一个数据库无法针对不同场景优化如文章需要大量读用户需要高安全。团队协作瓶颈多人同时修改同一个代码库容易冲突。微服务通过按业务能力拆分每个服务独立开发、部署、扩展服务间通过轻量级协议RPC/HTTP通信。2. DDD 与限界上下文Bounded Context领域驱动设计的核心概念是限界上下文一个业务领域内特定模型有明确的含义和边界。比如“用户”这个词在身份认证上下文中用户关注的是登录凭证、密码、权限。在社交上下文中用户关注的是昵称、头像、粉丝数。在文章上下文中用户只是一个作者标识ID 和名称。如果把它们混在一个“用户模型”里会导致模型臃肿、变更影响范围大。微服务的拆分通常就是以限界上下文为边界。3. 如何拆分我们的系统分析现有功能可以划分出两个主要上下文上下文职责可能包含的实体用户服务user-service注册、登录、用户信息管理、Token 签发与验证User (id, username, email, password, avatar, created_at)文章服务article-service文章 CRUD、分类、标签、评论、点赞、阅读量统计Article, Category, Tag, Comment, Like拆分原则数据独立每个服务有自己的数据库不能直接访问对方的数据库表。接口通信文章服务需要用户信息时通过 RPC 调用用户服务获取。最小数据暴露用户服务只返回必要字段如 id, username, avatar绝不暴露密码。无状态认证认证可以通过 JWT 或网关统一处理服务间传递用户 ID 即可。今天我们先规划基础接口。4. 接口契约的定义方式服务间通信需要先定义契约再开发这就是“契约优先”原则。常用两种格式Protocol Buffers (Protobuf)二进制、高性能、强类型适合高性能 RPC 调用。需要在.proto文件中定义消息和服务。JSON Schema / OpenAPI纯文本、可读性好、调试方便适合 HTTP API 或对性能不极致的场景。可以用 JSON Schema 约束请求/响应。我们两个都会写Protobuf 作为正式的 RPC 契约为明天 JSON-RPC 做准备JSON Schema 作为补充文档。三、实战拆分设计文档与契约编写约 3 小时1. 服务拓扑图画出服务间依赖关系可用文字描述[客户端] -- [API 网关] -- [文章服务] | -- [用户服务]文章服务依赖用户服务用户服务独立。2. 用户服务接口规划方法接口名称描述请求参数响应参数1GetUserById根据 ID 获取用户信息user_id (int)User { id, username, email, avatar, created_at }2GetUserByUsername根据用户名获取用户登录用username (string)User { id, username, email, avatar, created_at }3VerifyToken验证 JWT Token 并返回用户信息token (string)User { id, username } 或 null4Register用户注册username, email, passwordUser { id, username, email }5Login登录username, passwordtoken, User { id, username }注意用户服务的数据库独立存储在user_service_db中包含users表。3. 文章服务接口规划文章服务原有功能保留但用户相关的数据不再存储在本地的users表而是通过调用用户服务获取。文章表里的author_id就是用户 ID。评论里的user_id同理。文章服务接口列表内部对外暴露的 RESTful 接口基本不变只是在内部实现时当需要用户信息时调用用户服务。方法接口名称描述请求参数响应参数1GetArticle文章详情含作者信息article_id (int)Article { …, author: User }2ListArticles文章列表page, category_id, tag_idPage(每篇文章携带作者基本信息)
