使用前言
背景
在现代软件开发中，微服务架构因其灵活性和可扩展性而受到广泛欢迎。然而，随着服务数量的增加，维护成本也随之急剧上升。
- 重复造轮子：每个新项目都需要重新搭建基础框架（日志、配置、数据库连接、RPC 等）。
- 标准不统一：不同的团队或开发者使用不同的目录结构、分层方式和编码规范，导致代码难以阅读和维护。
- 技术栈割裂：在多语言环境中，不同语言的服务之间往往缺乏统一的交互标准和治理手段。
Firefly 是什么？
Firefly 是一个旨在解决上述痛点的多语言微服务生态系统。它不仅仅是一套代码框架，更是一套经过验证的微服务最佳实践标准。
它提供了一系列开箱即用的项目模板（Layout）和工具链，帮助开发者快速构建高性能、低占用、易维护的微服务应用。
核心价值
- 统一规范：无论使用 Go, Rust 还是其他语言，Firefly 都致力于提供一致的架构分层和开发体验。
- 开箱即用：内置了微服务所需的通用基础设施（服务注册发现、配置管理、日志监控等），开发者只需关注业务逻辑。
- 协议驱动：坚持 Schema-First 的开发理念，通过 Protobuf 定义接口和数据结构，自动生成多语言代码，确保跨语言调用的可靠性。
- 极简主义：拒绝过度封装，保持代码的透明和可控，让开发者能够完全掌控自己的服务。
渐进式演进
Firefly 倡导“进可攻，退可守”的渐进式架构演进路线，帮助团队在不同发展阶段选择最适合的方案。
阶段一：快速验证（自研网关模式）
在项目初期，业务验证是首要目标。此时，Firefly 提供了极简的微服务架构：
- 轻量级依赖：相比传统微服务（如 Spring Cloud 全家桶），裸机 / IDC 阶段可以从
sidecar-agent + Consul起步，先获得注册、配置和本机接入能力。 - 开箱即用：利用
sidecar-agent、http-gateway和grpc-gateway，立刻获得负载均衡、鉴权、熔断和限流能力，无需复杂的运维配置。 - 资源友好：得益于 Go/Rust 的高性能，整套架构对系统资源的占用极低，非常适合成本敏感的初创团队。
阶段二：稳健发展（代码治理）
随着业务发展，代码质量成为关键。Firefly 坚持的整洁架构和协议驱动开始发挥威力：
- 业务纯净：业务逻辑与基础设施解耦，代码干净整齐，易于维护和测试。
- 低耦合：服务间通过 Proto 定义严格的边界，配合“单服务单仓库”模式，大大降低了系统耦合度。
- 多语言协作：不同语言的服务通过标准 gRPC 协议无缝协作。
阶段三：云原生规模化（K8s + Istio）
当业务规模达到一定量级，需要更强大的治理能力时，可以平滑升级到 Service Mesh 方案：
- 无缝迁移：由于 Firefly 的 Service 层本身不包含网关逻辑，因此迁移到 Istio 时，业务代码几乎无需修改。
- 能力下沉：将熔断、限流等关注点下沉到 Sidecar，让业务服务更加专注。
- 企业级治理：享受 K8s + Istio 带来的全链路可观测性、金丝雀发布、零信任安全等高级特性。
适用场景
- 初创项目：推荐使用自研网关模式。通过
sidecar-agent + Consul、http-gateway和grpc-gateway快速搭建具备注册配置、鉴权、熔断能力的微服务集群。 - 企业转型：推荐使用 K8s + Istio 模式。利用 Service Mesh 强大的流量治理能力，将 Firefly 服务无缝集成到云原生环境中。
- 多语言团队：需要统一管理 Go, Rust, Node.js 等多种语言服务的团队。
- 单服务单仓库：适合追求服务独立演进、职责分离的团队，避免大仓带来的构建和权限管理复杂度。