构建微服务费用跟踪器的经验教训

Source: Dev.to

Introduction

你是否曾经把一个小想法故意弄得更复杂，并不是为了过度工程化，而是想了解真实系统是如何运作的？
这正是我在构建费用追踪器时所做的。与其使用单一的单体后端，我选择将其拆分为多个通过 API 相互通信的微服务。最初出于好奇的实验很快演变成一次关于系统设计、数据流、认证以及超越单个端点思考的实用教训。

这并不是在打造“可投产”的东西，而是学习在职责分离时后端系统的行为方式。

Why Microservices for a Small App?

大多数小型应用默认是单体结构。所有东西都放在一起，共享同一上下文，随着时间推移变得紧耦合。我刻意避免了这种做法。

我想了解：

• 服务之间如何相互通信
• 多个服务之间的认证是如何工作的
• 职责拆分如何改变你对后端设计的思考方式

微服务迫使我停止只考虑“路由”，而开始从系统的角度思考。即使在小规模下，这种转变也非常有价值。

How the System Is Structured

后端被拆分为四个独立的服务，每个服务都有明确的职责：

Auth

处理用户注册、登录以及 JWT 生成。该服务负责身份和信任。

Expense

管理所有与费用相关的操作，如创建、更新和获取费用记录。

Analytics

专注于使用费用数据生成汇总和洞察，例如消费趋势和类别分布。

Gateway

充当前端的唯一入口。每个请求都会先经过它，然后再路由到相应的服务。

前端从不直接与各服务通信。所有请求都通过 Gateway，JWT 被验证后才会转发。Analytics 只消费费用数据而不存储自己的副本，使系统保持简洁且模块化。

Lessons I Learned Along the Way

• 模块化改变思考方式 – 职责分离立刻带来了清晰度。每个服务都有自己的目的，减少了在开发功能或修复 bug 时的认知负担。
• 服务通信需要有意图 – 即使是简单的 REST 调用也需要规划。我必须考虑请求流、失败情况，以及一个服务如何在不紧耦合的前提下依赖另一个服务。
• 认证不仅是登录逻辑 – 跨服务的基于 JWT 的认证表明，认证是关于信任传播，而不仅仅是一次凭证验证。
• 系统思维很重要 – 我从只关注函数和端点转向考虑数据流、服务边界以及变更对整个系统的影响。
• 数据处理决定一切 – Analytics 完全依赖费用数据的结构。我学会了提前思考查询、聚合和性能——即使是小数据集也不例外。
• 跨服务调试是一项真实技能 – 在多个服务之间追踪请求教会我有条理地调试，并把系统视为一个相互连接的整体，而不是孤立的代码文件。

Final Thoughts

这个项目并不是要构建一个完美的应用，而是为了实验、学习和成长。

使用微服务让我看到模块化设计、安全通信和数据驱动功能如何共存——即使在一个简单的应用中也是如此。更重要的是，它帮助我在后端系统的推理上建立了信心，而不仅仅是写代码。

到最后，我不仅在追踪费用——我在追踪自己作为开发者的成长，并为将来处理更复杂的架构做好准备。