微服务架构设计原则

微服务的代价

微服务带来了独立部署和技术异构的灵活性，但同时引入了：分布式系统的复杂性、网络调用的额外延迟、跨服务事务的困难、运维和监控成本的显著增加。

在没有充分理由前，单体应用是更好的选择。

何时考虑微服务

• 团队规模超过 50 人，单体代码库成为协作瓶颈
• 不同模块有截然不同的扩展需求
• 需要技术异构（部分模块需要 Python ML，部分需要 Go 高性能）
• 组织上已经有明确的团队边界（Conway 定律）

服务拆分原则

遵循**领域驱动设计（DDD）**的限界上下文（Bounded Context）进行拆分：

用户域 → 用户服务（注册、登录、Profile）
内容域 → 内容服务（文章、评论、草稿）
通知域 → 通知服务（邮件、站内信、Push）

避免按技术层次拆分（"数据库服务"、"缓存服务"）——这会导致大量跨服务调用。

服务间通信

场景	推荐方案
同步请求响应	gRPC / REST
异步事件	Kafka / RabbitMQ
跨服务查询	GraphQL Federation / BFF

总结

微服务是组织复杂度的解决方案，不是技术问题的解决方案。在团队规模和产品复杂度达到临界点之前，保持单体或模块化单体，能让你以更低的成本快速迭代。