使用 Encore 将单体Monolith拆分为微服务完整实战指南【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encore本指南基于 Encore Go 应用模型讲解如何在不重写代码的前提下把一个单体后端中的某个功能拆分成独立服务service。你将学会如何通过新建 Go 包 移动 API 端点完成服务拆分、拆分后 Service Catalog 与 Flow 架构图如何自动更新、以及拆分时数据库共享策略该如何取舍。读完即可在自己的 Encore 应用中安全地逐步演进架构。为什么要拆分单体随着业务增长把单体后端中的特定功能拆分为独立服务是很常见的诉求。驱动拆分的典型原因包括独立扩缩容某个功能如通知、报表的流量峰值与其他模块差异巨大希望单独部署、单独扩容代码库结构优化把不同业务域切成更小的代码单元让团队边界与模块边界对齐故障隔离让部分功能在依赖异常时仍能独立存活可配合独立数据库实现更优雅的部分降级。Encore 的核心设计目标之一就是让系统架构可以随业务自然演进应用模型Application Model由代码声明式地推导而来部署方式可以随环境变化而改变却不需要改动业务代码。这意味着拆分服务主要是一个移动代码的动作剩下的编排工作由 Encore 编译器自动完成。如何从单体中拆出一个服务以文档中的示例为例假设我们有一个单体应用hello包含两个公共 API 端点H1和H2package hello import ( context ) //encore:api public path/hello/:name func H1(ctx context.Context, name string) (*Response, error) { msg : Hello, name ! return Response{Message: msg}, nil } //encore:api public path/yo/:name func H2(ctx context.Context, name string) (*Response, error) { msg : Yo, name ! return Response{Message: msg}, nil } type Response struct { Message string }现在要把H2拆到独立的yo服务中。在 Encore 中拆分的全部操作就是新建一个 Go 包package并把H2端点移进去。新建yo/yo.gopackage yo import ( context ) //encore:api public path/yo/:name func H2(ctx context.Context, name string) (*Response, error) { msg : Yo, name ! return Response{Message: msg}, nil } type Response struct { Message string }磁盘上的目录结构变为/my-app ├── encore.app // ... and other top-level project files │ ├── hello // hello service (a Go package) │ └── hello.go // hello service code │ └── yo // yo service (a Go package) └── yo.go // yo service code为什么新建包就等价于新建服务这背后是 Encore 对服务service的定义方式在 Encore Go 中服务就是一个包含 API 定义的普通 Go 包包名即服务名。这一点在 定义服务 文档中有明确说明只要在一个普通 Go 包内通过//encore:api注解定义了至少一个 APIEncore 就会把这个包识别为一个服务。也就是说hello与yo从一个包里的两个函数变成两个各自包含 API 的包的那一刻Encore 的应用模型就已经把它们视为两个独立服务了——不需要任何注册表、配置文件或额外声明。从源码结构看v2/app/service.go 等解析层逻辑正是围绕包 服务这一模型来组织服务发现与资源归属的。端点路由注意点拆分后H2的路径/yo/:name保持不变这得益于 Encore 使用声明式的路径参数:name语法路由与具体的包位置解耦。因此在拆分过程中对外 API 路径无需修改客户端调用不感知服务间调用则从同包函数调用变为跨服务 API 调用需要把原来的直接调用改为通过 Encore 生成的客户端进行调用可参考 定义类型安全 API 中关于 public/private 访问控制的说明跨服务调用通常应使用//encore:api private。架构可视化自动更新Service Catalog 与 Flow拆分完成后Encore 会自动感知架构变化无需手动维护任何图表或文档Service Catalog服务目录Encore 基于应用模型自动生成服务目录与全部 API 文档且永远与代码保持同步。运行你的应用本地开发或云端部署后在本地开发控制台即可看到hello与yo两个服务分别列出各自的端点文档也已就绪。详见 Service Catalog。Flow 架构图Flow 是实时更新的交互式架构可视化工具服务以方框表示、箭头表示依赖关系。本地开发时它会随代码变更实时刷新云端环境则随每次部署自动更新。拆分后你可以在 Flow 中立刻看到hello与yo两个独立服务节点。详见 Flow 架构图。借助这两个工具拆分服务的风险可以被即时可视化地确认依赖关系是否正确、是否引入了意外的循环依赖、每个服务的资源数据库、Pub/Sub 主题等归属是否如预期。拆分时的数据库策略共享还是独立服务拆分后紧接着要面对的核心问题是数据库如何处理。Encore 对两者都支持选择取决于你的具体场景详见 在服务间共享数据库。默认行为每服务独立数据库默认情况下Encore 中每个服务拥有自己的数据库其收益包括数据库的归属与连接方式对其他服务完全抽象服务间不耦合数据层数据库变更范围更小、更安全schema 演进只在单一服务内生效服务独立性更强整体可靠性更高——即使某个数据库暂时过载或离线其他服务仍能更优雅地处理部分故障。何时选择共享数据库有些情况下共享数据库反而更简单可靠例如报表类服务需要直接读取业务库的数据。Encore 的共享方式非常轻量每个数据库归属于定义它的服务服务名即数据库名其他服务通过sqldb.Named(dbname)建立数据库引用即可。以文档中的todo/report示例为例report服务直接访问todo服务的数据库todo/migrations/1_create_table.up.sqlCREATE TABLE todo_item ( id BIGSERIAL PRIMARY KEY, title TEXT NOT NULL, done BOOLEAN NOT NULL DEFAULT FALSE );report/report.gopackage report import ( context encore.dev/storage/sqldb ) // todoDB connects to the todo services database. var todoDB sqldb.Named(todo) type ReportResponse struct { Total int } // CountCompletedTodos generates a report with the number of completed todo items. //encore:api methodGET path/report/todo func CountCompletedTodos(ctx context.Context) (*ReportResponse, error) { var report ReportResponse err : todoDB.QueryRow(ctx, SELECT COUNT(*) FROM todo_item WHERE completed TRUE ).Scan(report.Total) return report, err }一旦这样声明Encore 就理解report服务依赖todo服务的数据库并自动编排好所需连接——本地开发与云端运行行为完全一致。拆分实践中的数据库决策建议拆分初期如果拆分出的服务只是消费同一份业务数据做只读计算如报表、聚合、导出共享数据库可以显著降低迁移成本需要独立演化时如果被拆出的服务将来会独立演进 schema 或独立部署扩缩容尽早迁移为独立数据库收益更大边界清晰无论选择哪种方式都应让数据库归属关系与服务的业务边界一致避免出现多个服务交叉读写同一张表、schema 归属混乱的情况。从单体到微服务的渐进式路线图结合本文的拆分方法与 Encore 的应用结构能力详见 应用结构推荐的分步演进路线是保持单体初期所有代码放在一个包里快速验证业务按需拆分服务当某个功能需要独立扩缩容、独立故障域或独立团队维护时按本文步骤拆出新包数据库策略同步决策拆分时一并决定是共享还是独立数据库用可视化验证每次拆分后通过 Service Catalog 与 Flow 检查依赖关系是否符合预期部署形态灵活调整Encore 允许在云环境AWS/GCP中按需配置多个服务是合并到同一进程还是分开部署这一决策可以在不改代码的情况下于环境配置层面完成见 应用结构 中关于进程分配的说明。这套路线图的核心价值在于架构演进是代码目录结构的演进而不是基础设施重构。你可以在需要时才拆分也可以随时调整部署形态而业务代码始终保持稳定。总结Encore 把拆分单体为微服务从一项重工程化简为一次轻量重构服务即包新建 Go 包并移入 API 端点Encore 即自动识别为独立服务零配置架构图Service Catalog 与 Flow 自动跟随代码更新随时确认依赖关系数据库策略可权衡默认每服务独立数据库也支持通过sqldb.Named()轻量共享部署解耦服务合并或分拆部署可在环境层配置无需改动代码。相关深入阅读定义服务、定义类型安全 API、应用结构、在服务间共享数据库、Service Catalog、Flow 架构图。【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
使用 Encore 将单体Monolith拆分为微服务完整实战指南【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encore本指南基于 Encore Go 应用模型讲解如何在不重写代码的前提下把一个单体后端中的某个功能拆分成独立服务service。你将学会如何通过新建 Go 包 移动 API 端点完成服务拆分、拆分后 Service Catalog 与 Flow 架构图如何自动更新、以及拆分时数据库共享策略该如何取舍。读完即可在自己的 Encore 应用中安全地逐步演进架构。为什么要拆分单体随着业务增长把单体后端中的特定功能拆分为独立服务是很常见的诉求。驱动拆分的典型原因包括独立扩缩容某个功能如通知、报表的流量峰值与其他模块差异巨大希望单独部署、单独扩容代码库结构优化把不同业务域切成更小的代码单元让团队边界与模块边界对齐故障隔离让部分功能在依赖异常时仍能独立存活可配合独立数据库实现更优雅的部分降级。Encore 的核心设计目标之一就是让系统架构可以随业务自然演进应用模型Application Model由代码声明式地推导而来部署方式可以随环境变化而改变却不需要改动业务代码。这意味着拆分服务主要是一个移动代码的动作剩下的编排工作由 Encore 编译器自动完成。如何从单体中拆出一个服务以文档中的示例为例假设我们有一个单体应用hello包含两个公共 API 端点H1和H2package hello import ( context ) //encore:api public path/hello/:name func H1(ctx context.Context, name string) (*Response, error) { msg : Hello, name ! return Response{Message: msg}, nil } //encore:api public path/yo/:name func H2(ctx context.Context, name string) (*Response, error) { msg : Yo, name ! return Response{Message: msg}, nil } type Response struct { Message string }现在要把H2拆到独立的yo服务中。在 Encore 中拆分的全部操作就是新建一个 Go 包package并把H2端点移进去。新建yo/yo.gopackage yo import ( context ) //encore:api public path/yo/:name func H2(ctx context.Context, name string) (*Response, error) { msg : Yo, name ! return Response{Message: msg}, nil } type Response struct { Message string }磁盘上的目录结构变为/my-app ├── encore.app // ... and other top-level project files │ ├── hello // hello service (a Go package) │ └── hello.go // hello service code │ └── yo // yo service (a Go package) └── yo.go // yo service code为什么新建包就等价于新建服务这背后是 Encore 对服务service的定义方式在 Encore Go 中服务就是一个包含 API 定义的普通 Go 包包名即服务名。这一点在 定义服务 文档中有明确说明只要在一个普通 Go 包内通过//encore:api注解定义了至少一个 APIEncore 就会把这个包识别为一个服务。也就是说hello与yo从一个包里的两个函数变成两个各自包含 API 的包的那一刻Encore 的应用模型就已经把它们视为两个独立服务了——不需要任何注册表、配置文件或额外声明。从源码结构看v2/app/service.go 等解析层逻辑正是围绕包 服务这一模型来组织服务发现与资源归属的。端点路由注意点拆分后H2的路径/yo/:name保持不变这得益于 Encore 使用声明式的路径参数:name语法路由与具体的包位置解耦。因此在拆分过程中对外 API 路径无需修改客户端调用不感知服务间调用则从同包函数调用变为跨服务 API 调用需要把原来的直接调用改为通过 Encore 生成的客户端进行调用可参考 定义类型安全 API 中关于 public/private 访问控制的说明跨服务调用通常应使用//encore:api private。架构可视化自动更新Service Catalog 与 Flow拆分完成后Encore 会自动感知架构变化无需手动维护任何图表或文档Service Catalog服务目录Encore 基于应用模型自动生成服务目录与全部 API 文档且永远与代码保持同步。运行你的应用本地开发或云端部署后在本地开发控制台即可看到hello与yo两个服务分别列出各自的端点文档也已就绪。详见 Service Catalog。Flow 架构图Flow 是实时更新的交互式架构可视化工具服务以方框表示、箭头表示依赖关系。本地开发时它会随代码变更实时刷新云端环境则随每次部署自动更新。拆分后你可以在 Flow 中立刻看到hello与yo两个独立服务节点。详见 Flow 架构图。借助这两个工具拆分服务的风险可以被即时可视化地确认依赖关系是否正确、是否引入了意外的循环依赖、每个服务的资源数据库、Pub/Sub 主题等归属是否如预期。拆分时的数据库策略共享还是独立服务拆分后紧接着要面对的核心问题是数据库如何处理。Encore 对两者都支持选择取决于你的具体场景详见 在服务间共享数据库。默认行为每服务独立数据库默认情况下Encore 中每个服务拥有自己的数据库其收益包括数据库的归属与连接方式对其他服务完全抽象服务间不耦合数据层数据库变更范围更小、更安全schema 演进只在单一服务内生效服务独立性更强整体可靠性更高——即使某个数据库暂时过载或离线其他服务仍能更优雅地处理部分故障。何时选择共享数据库有些情况下共享数据库反而更简单可靠例如报表类服务需要直接读取业务库的数据。Encore 的共享方式非常轻量每个数据库归属于定义它的服务服务名即数据库名其他服务通过sqldb.Named(dbname)建立数据库引用即可。以文档中的todo/report示例为例report服务直接访问todo服务的数据库todo/migrations/1_create_table.up.sqlCREATE TABLE todo_item ( id BIGSERIAL PRIMARY KEY, title TEXT NOT NULL, done BOOLEAN NOT NULL DEFAULT FALSE );report/report.gopackage report import ( context encore.dev/storage/sqldb ) // todoDB connects to the todo services database. var todoDB sqldb.Named(todo) type ReportResponse struct { Total int } // CountCompletedTodos generates a report with the number of completed todo items. //encore:api methodGET path/report/todo func CountCompletedTodos(ctx context.Context) (*ReportResponse, error) { var report ReportResponse err : todoDB.QueryRow(ctx, SELECT COUNT(*) FROM todo_item WHERE completed TRUE ).Scan(report.Total) return report, err }一旦这样声明Encore 就理解report服务依赖todo服务的数据库并自动编排好所需连接——本地开发与云端运行行为完全一致。拆分实践中的数据库决策建议拆分初期如果拆分出的服务只是消费同一份业务数据做只读计算如报表、聚合、导出共享数据库可以显著降低迁移成本需要独立演化时如果被拆出的服务将来会独立演进 schema 或独立部署扩缩容尽早迁移为独立数据库收益更大边界清晰无论选择哪种方式都应让数据库归属关系与服务的业务边界一致避免出现多个服务交叉读写同一张表、schema 归属混乱的情况。从单体到微服务的渐进式路线图结合本文的拆分方法与 Encore 的应用结构能力详见 应用结构推荐的分步演进路线是保持单体初期所有代码放在一个包里快速验证业务按需拆分服务当某个功能需要独立扩缩容、独立故障域或独立团队维护时按本文步骤拆出新包数据库策略同步决策拆分时一并决定是共享还是独立数据库用可视化验证每次拆分后通过 Service Catalog 与 Flow 检查依赖关系是否符合预期部署形态灵活调整Encore 允许在云环境AWS/GCP中按需配置多个服务是合并到同一进程还是分开部署这一决策可以在不改代码的情况下于环境配置层面完成见 应用结构 中关于进程分配的说明。这套路线图的核心价值在于架构演进是代码目录结构的演进而不是基础设施重构。你可以在需要时才拆分也可以随时调整部署形态而业务代码始终保持稳定。总结Encore 把拆分单体为微服务从一项重工程化简为一次轻量重构服务即包新建 Go 包并移入 API 端点Encore 即自动识别为独立服务零配置架构图Service Catalog 与 Flow 自动跟随代码更新随时确认依赖关系数据库策略可权衡默认每服务独立数据库也支持通过sqldb.Named()轻量共享部署解耦服务合并或分拆部署可在环境层配置无需改动代码。相关深入阅读定义服务、定义类型安全 API、应用结构、在服务间共享数据库、Service Catalog、Flow 架构图。【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
