尧图网页设计 
EcommerceAPI的Product服务深度解析基于Elasticsearch的商品存储与全文搜索【免费下载链接】EcommerceAPIModular e-commerce backend with a GraphQL gateway and gRPC microservices for accounts, products, orders, payments, and recommendations.项目地址: https://gitcode.com/gh_mirrors/ecom/EcommerceAPIEcommerceAPI 是一个模块化的电商微服务后端它用 GraphQL 网关统一对外入口背后则由账号、商品、订单、支付、推荐等多个 gRPC 微服务协同工作。其中Product 服务商品服务是一个非常有意思的模块——它没有使用传统的 MySQL/PostgreSQL 存商品而是直接把Elasticsearch当作商品存储数据库并借助它强大的倒排索引实现了开箱即用的商品全文搜索。这篇文章将带你逐步拆解 Product 服务的设计思路、目录结构、CRUD 与搜索实现以及它如何通过 Kafka 与推荐服务联动非常适合想了解 Elasticsearch 微服务落地实践的开发者阅读。EcommerceAPI 与 Product 服务在架构中的位置从上图可以看出EcommerceAPI 采用典型的微服务架构GraphQL API Gateway唯一对外入口负责鉴权、聚合与转发Product / Order / Account / Payment / Recommender五个职责单一的后端微服务Elasticsearch / PostgreSQL / Kafka分别承担商品搜索、业务数据与事件流。Product 服务处于「网关 → 商品客户端 → 商品服务 → Elasticsearch」这条链路的中间层。它对外提供 gRPC 接口对内把商品文档写入 Elasticsearch 的catalog索引同时把商品创建、更新、删除事件发送到 Kafka供推荐服务消费。Product 服务的目录结构与分层设计先看 Product 服务的完整目录代码分层非常清晰很适合新手学习product/ ├── client/ # gRPC 客户端封装供 GraphQL 网关调用 ├── cmd/product/ # 服务启动入口 ├── config/ # 环境变量配置 ├── internal/ # 核心业务repository service server ├── models/ # 数据模型定义 ├── proto/ # protobuf 定义与生成代码 └── tests/ # 单元测试对应的三个关键分层文件是repository.go数据访问层直接与 Elasticsearch 交互service.go业务逻辑层负责校验、事件发送server.gogRPC 传输层负责协议转换。为什么选择 Elasticsearch 作为商品存储数据库电商平台的商品数据有一个显著特点读多写少、查询条件多样、对搜索体验要求高。相比传统关系型数据库Elasticsearch 有以下优势全文搜索基于倒排索引对名称、描述这类文本字段做模糊匹配非常快高吞吐读取商品浏览、列表、搜索场景都能获得毫秒级响应天然的文档模型一个商品就是一个 JSON 文档结构简单直观无需额外维护搜索组件存储即索引写入即可被检索。在 docker-compose.yaml 中可以看到Product 服务的数据库就是elasticsearch-oss:6.2.4环境变量DATABASE_URL: http://product_db:9200直接指向 Elasticsearch 的 HTTP 端口说明它没有独立的关系型数据库所有商品数据都以文档形式保存在 ES 中。商品数据模型与 Elasticsearch 索引设计商品模型定义在 models/product.go分为两个结构Product对外返回的完整商品对象包含ID、Name、Description、Price、AccountIDProductDocument写入 Elasticsearch 的文档结构不含 IDID 由 ES 自动生成。写入时仓库层会把商品索引到名为catalog的索引、类型为product例如PutProduct的实现见 repository.gores, err : r.client.Index(). Index(catalog). Type(product). BodyJson(models.ProductDocument{...}). Do(ctx) p.ID res.Id // ES 返回的文档 ID 就是商品 ID这里有个非常优雅的设计Elasticsearch 生成的文档 ID 直接作为商品 ID 使用省去了主键生成与映射的麻烦。商品 CRUD写入、读取、更新与删除的完整实现Product 服务的增删改查全部由elasticRepository完成我们逐一来看写入商品PutProduct将商品文档索引到catalog成功后把 ES 返回的res.Id赋给商品对象作为它的唯一标识。按 ID 读取商品GetProductById使用client.Get()按文档 ID 精确获取并判断res.Found是否命中未命中则返回ErrNotFound见 repository.go。批量读取ListProducts / ListProductsWithIDs列表场景使用MatchAllQuery配合From/Size实现分页拉取购物车场景使用MultiGet一次性按多个 ID 批量取回商品避免循环请求。更新与删除UpdateProduct / DeleteProduct更新使用client.Update()整体覆盖文档字段删除使用client.Delete()按 ID 移除。值得一提的是更新和删除在 Service 层会先校验AccountID是否匹配防止越权操作见 service.go。商品全文搜索是如何实现的MultiMatch 查询解析全文搜索是 Product 服务的亮点核心代码只有寥寥几行见 repository.gores, err : r.client.Search(). Index(catalog). Type(product). Query(elastic.NewMultiMatchQuery(query, name, description)). From(int(skip)). Size(int(take)). Do(ctx)这里的要点是elastic.NewMultiMatchQuery(query, name, description)对商品名称和商品描述两个字段同时做多字段匹配用户输入任意关键词ES 都会在两个字段中查找相关文档并按相关度打分排序命中结果自动按相关度score从高到低返回这正是电商搜索「越相关越靠前」的体验基础。整个搜索调用链是GraphQL 网关 → gRPC →SearchProducts→ ESMultiMatch查询。搜索分页机制skip/take 与 GraphQL 分页封装Product 服务的所有列表与搜索接口都支持skip/take分页参数skip跳过的记录数对应 ES 的Fromtake返回的记录数对应 ES 的Size。在 GraphQL 网关层分页参数由 pagination.go 统一封装前端通过pagination: { skip: 0, take: 10 }即可完成翻页。搜索请求在 query.go 中被识别只要传入query参数网关就调用GetProducts(ctx, skip, take, nil, q)走全文搜索分支。事件驱动商品变更如何通过 Kafka 驱动推荐服务商品不止要被搜索到还要驱动个性化推荐。Product 服务在业务层做了一件巧妙的事在商品创建、更新、删除、被查看时异步发送事件到 Kafka。以创建商品为例见 service.go服务通过go func()异步调用kafka.SendMessageToRecommender把product_created事件连同商品数据发往product_events主题查看商品时则发送product_retrieved事件到interaction_events主题。这些事件最终被 Python 编写的 Recommender 服务消费用于构建「看了又看」「猜你喜欢」等推荐结果再通过 GraphQL 的viewedProductsIds参数回传给前端。商品服务因此成了一个数据生产者与推荐系统形成完整的闭环。如何快速启动 Product 服务体验全文搜索想本地跑起来推荐使用 Docker Compose 一键启动仓库地址https://gitcode.com/gh_mirrors/ecom/EcommerceAPIgit clone https://gitcode.com/gh_mirrors/ecom/EcommerceAPI docker compose build base docker compose up -d --build启动完成后打开http://localhost:8080/playgroundGraphQL Playground先用createProduct突变创建几个商品如 Camera、Wireless Mouse再用带query参数的商品查询测试全文搜索例如搜索 camera 即可看到相关商品按相关度返回。 小提示Product 服务通过DATABASE_URL环境变量连接 Elasticsearch如果自行部署只需把它指向任意 ES 地址如http://localhost:9200即可。总结EcommerceAPI 的 Product 服务是一个很值得借鉴的 Elasticsearch 微服务范例它把「存储 搜索」合二为一用一份代码同时解决了商品持久化与全文检索两个问题。通过本文你应该已经掌握了Product 服务的分层结构与模块职责商品如何以文档形式写入 Elasticsearch 的catalog索引MultiMatch 多字段全文搜索与 skip/take 分页的实现方式商品事件如何经 Kafka 流转到推荐服务形成业务闭环。如果你正在设计自己的电商搜索系统不妨从 repository.go 和 service.go 这两个文件读起相信会有不少收获【免费下载链接】EcommerceAPIModular e-commerce backend with a GraphQL gateway and gRPC microservices for accounts, products, orders, payments, and recommendations.项目地址: https://gitcode.com/gh_mirrors/ecom/EcommerceAPI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EcommerceAPI的Product服务深度解析：基于Elasticsearch的商品存储与全文搜索
EcommerceAPI的Product服务深度解析基于Elasticsearch的商品存储与全文搜索【免费下载链接】EcommerceAPIModular e-commerce backend with a GraphQL gateway and gRPC microservices for accounts, products, orders, payments, and recommendations.项目地址: https://gitcode.com/gh_mirrors/ecom/EcommerceAPIEcommerceAPI 是一个模块化的电商微服务后端它用 GraphQL 网关统一对外入口背后则由账号、商品、订单、支付、推荐等多个 gRPC 微服务协同工作。其中Product 服务商品服务是一个非常有意思的模块——它没有使用传统的 MySQL/PostgreSQL 存商品而是直接把Elasticsearch当作商品存储数据库并借助它强大的倒排索引实现了开箱即用的商品全文搜索。这篇文章将带你逐步拆解 Product 服务的设计思路、目录结构、CRUD 与搜索实现以及它如何通过 Kafka 与推荐服务联动非常适合想了解 Elasticsearch 微服务落地实践的开发者阅读。EcommerceAPI 与 Product 服务在架构中的位置从上图可以看出EcommerceAPI 采用典型的微服务架构GraphQL API Gateway唯一对外入口负责鉴权、聚合与转发Product / Order / Account / Payment / Recommender五个职责单一的后端微服务Elasticsearch / PostgreSQL / Kafka分别承担商品搜索、业务数据与事件流。Product 服务处于「网关 → 商品客户端 → 商品服务 → Elasticsearch」这条链路的中间层。它对外提供 gRPC 接口对内把商品文档写入 Elasticsearch 的catalog索引同时把商品创建、更新、删除事件发送到 Kafka供推荐服务消费。Product 服务的目录结构与分层设计先看 Product 服务的完整目录代码分层非常清晰很适合新手学习product/ ├── client/ # gRPC 客户端封装供 GraphQL 网关调用 ├── cmd/product/ # 服务启动入口 ├── config/ # 环境变量配置 ├── internal/ # 核心业务repository service server ├── models/ # 数据模型定义 ├── proto/ # protobuf 定义与生成代码 └── tests/ # 单元测试对应的三个关键分层文件是repository.go数据访问层直接与 Elasticsearch 交互service.go业务逻辑层负责校验、事件发送server.gogRPC 传输层负责协议转换。为什么选择 Elasticsearch 作为商品存储数据库电商平台的商品数据有一个显著特点读多写少、查询条件多样、对搜索体验要求高。相比传统关系型数据库Elasticsearch 有以下优势全文搜索基于倒排索引对名称、描述这类文本字段做模糊匹配非常快高吞吐读取商品浏览、列表、搜索场景都能获得毫秒级响应天然的文档模型一个商品就是一个 JSON 文档结构简单直观无需额外维护搜索组件存储即索引写入即可被检索。在 docker-compose.yaml 中可以看到Product 服务的数据库就是elasticsearch-oss:6.2.4环境变量DATABASE_URL: http://product_db:9200直接指向 Elasticsearch 的 HTTP 端口说明它没有独立的关系型数据库所有商品数据都以文档形式保存在 ES 中。商品数据模型与 Elasticsearch 索引设计商品模型定义在 models/product.go分为两个结构Product对外返回的完整商品对象包含ID、Name、Description、Price、AccountIDProductDocument写入 Elasticsearch 的文档结构不含 IDID 由 ES 自动生成。写入时仓库层会把商品索引到名为catalog的索引、类型为product例如PutProduct的实现见 repository.gores, err : r.client.Index(). Index(catalog). Type(product). BodyJson(models.ProductDocument{...}). Do(ctx) p.ID res.Id // ES 返回的文档 ID 就是商品 ID这里有个非常优雅的设计Elasticsearch 生成的文档 ID 直接作为商品 ID 使用省去了主键生成与映射的麻烦。商品 CRUD写入、读取、更新与删除的完整实现Product 服务的增删改查全部由elasticRepository完成我们逐一来看写入商品PutProduct将商品文档索引到catalog成功后把 ES 返回的res.Id赋给商品对象作为它的唯一标识。按 ID 读取商品GetProductById使用client.Get()按文档 ID 精确获取并判断res.Found是否命中未命中则返回ErrNotFound见 repository.go。批量读取ListProducts / ListProductsWithIDs列表场景使用MatchAllQuery配合From/Size实现分页拉取购物车场景使用MultiGet一次性按多个 ID 批量取回商品避免循环请求。更新与删除UpdateProduct / DeleteProduct更新使用client.Update()整体覆盖文档字段删除使用client.Delete()按 ID 移除。值得一提的是更新和删除在 Service 层会先校验AccountID是否匹配防止越权操作见 service.go。商品全文搜索是如何实现的MultiMatch 查询解析全文搜索是 Product 服务的亮点核心代码只有寥寥几行见 repository.gores, err : r.client.Search(). Index(catalog). Type(product). Query(elastic.NewMultiMatchQuery(query, name, description)). From(int(skip)). Size(int(take)). Do(ctx)这里的要点是elastic.NewMultiMatchQuery(query, name, description)对商品名称和商品描述两个字段同时做多字段匹配用户输入任意关键词ES 都会在两个字段中查找相关文档并按相关度打分排序命中结果自动按相关度score从高到低返回这正是电商搜索「越相关越靠前」的体验基础。整个搜索调用链是GraphQL 网关 → gRPC →SearchProducts→ ESMultiMatch查询。搜索分页机制skip/take 与 GraphQL 分页封装Product 服务的所有列表与搜索接口都支持skip/take分页参数skip跳过的记录数对应 ES 的Fromtake返回的记录数对应 ES 的Size。在 GraphQL 网关层分页参数由 pagination.go 统一封装前端通过pagination: { skip: 0, take: 10 }即可完成翻页。搜索请求在 query.go 中被识别只要传入query参数网关就调用GetProducts(ctx, skip, take, nil, q)走全文搜索分支。事件驱动商品变更如何通过 Kafka 驱动推荐服务商品不止要被搜索到还要驱动个性化推荐。Product 服务在业务层做了一件巧妙的事在商品创建、更新、删除、被查看时异步发送事件到 Kafka。以创建商品为例见 service.go服务通过go func()异步调用kafka.SendMessageToRecommender把product_created事件连同商品数据发往product_events主题查看商品时则发送product_retrieved事件到interaction_events主题。这些事件最终被 Python 编写的 Recommender 服务消费用于构建「看了又看」「猜你喜欢」等推荐结果再通过 GraphQL 的viewedProductsIds参数回传给前端。商品服务因此成了一个数据生产者与推荐系统形成完整的闭环。如何快速启动 Product 服务体验全文搜索想本地跑起来推荐使用 Docker Compose 一键启动仓库地址https://gitcode.com/gh_mirrors/ecom/EcommerceAPIgit clone https://gitcode.com/gh_mirrors/ecom/EcommerceAPI docker compose build base docker compose up -d --build启动完成后打开http://localhost:8080/playgroundGraphQL Playground先用createProduct突变创建几个商品如 Camera、Wireless Mouse再用带query参数的商品查询测试全文搜索例如搜索 camera 即可看到相关商品按相关度返回。 小提示Product 服务通过DATABASE_URL环境变量连接 Elasticsearch如果自行部署只需把它指向任意 ES 地址如http://localhost:9200即可。总结EcommerceAPI 的 Product 服务是一个很值得借鉴的 Elasticsearch 微服务范例它把「存储 搜索」合二为一用一份代码同时解决了商品持久化与全文检索两个问题。通过本文你应该已经掌握了Product 服务的分层结构与模块职责商品如何以文档形式写入 Elasticsearch 的catalog索引MultiMatch 多字段全文搜索与 skip/take 分页的实现方式商品事件如何经 Kafka 流转到推荐服务形成业务闭环。如果你正在设计自己的电商搜索系统不妨从 repository.go 和 service.go 这两个文件读起相信会有不少收获【免费下载链接】EcommerceAPIModular e-commerce backend with a GraphQL gateway and gRPC microservices for accounts, products, orders, payments, and recommendations.项目地址: https://gitcode.com/gh_mirrors/ecom/EcommerceAPI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考