FinClip 后端服务采用 Golang 语言编写，系统架构采用微服务架构，每个服务经过编译之后会被打包成容器，我 们采用业界主流的容器管理平台进行服务编排, 因此，我们大部分运维能力，包括服务的故障转移、动态扩容、资源管理等能力都是依赖于容器平台实现。此外，FinClip 还依赖部分成熟的开源组件作为基础设施，以实现业务系统中的数据存储、缓存等。
运维架构图：
架构部分：
基础服务部分：
- 数据库：MySQL
- 数据缓存：Redis
- 对象存储：Minio (或者兼容 S3 的存储服务)
容器： Docker
容器编排平台： Kubernetes、Rancher(可选)
日志系统：
- 大规模： 采用 Vector + Kafka + ElasticSearch + Kibana
- 中小规模： Loki + Grafana
监控系统： Prometheus
FinClip 采用典型的三层架构设计，接入层 - 服务层 - 基础服务层。因此，我们的平台架构兼顾运维可维护性、可扩展性和安全性。
部署模式对比
提供多种部署模式，以满足不同业务场景和需求。
| 部署模式 | 适用环境 | 架构设计 | 优点 | 缺点 | 部署说明 |
|---|---|---|---|---|---|
| 单节点 | POC、测试环境 | compose 部署所有服务 | 部署快、成本低 | 性能一般，单点故障 | 服单台务器部署所有服务 |
| 小集群 | 生产、高可用场景 | 使用Kubernetes ，4台服务器 | 高可用、资源利用高 | 资源竞争 | 服务均匀分布在4台服务器 |
| 中大规模集群 | 对扩展性、灾备有要求 | Kubernetes 集群，多服务器，业务与基础服务分离 | 高可用、性能较好、无资源竞争 | 成本较高 | 类似小规模，更多服务器且服务分离 |
| 双机房冷备集群 | 对业务连续性要求高 | 主机房工作，冷备机房待命接管 | 更高的容灾能力、切换灵活 | 成本高、维护复杂 | 主从机房都部署 Kubernetes 集群，主机房部署数据服务集群，冷备机房做单节点同步 |
单节点部署模式
在单节点部署模式中，所有服务将部署在一台服务器中
操作系统与容器平台：
- Linux：作为基础操作系统，提供稳定的环境和资源管理。
- Docker：用于容器化各个服务，确保服务间的隔离性和易于管理。
- Docker Compose：用于定义和管理多容器应用，简化服务的启动和停止操作。
容器与系统组件：
- Gateway：负责 API 网关和请求路由。
- 前后端服务：前端和后端服务共同构成了应用的核心业务逻辑。
- 数据层：包括 MySQL、MinIO 和 Redis，用于数据存储和缓存管理。
服务器：
| 用途 | CPU | 内存 | 储存空间 | 部署内容 | 数量 | 参考 TPS |
|---|---|---|---|---|---|---|
| 最低配置 | 4 核 | 8 GB | 100 GB | 数据库、缓存和FinClip微服务 | 1 | 4000 |
| 推荐配置 | 8 核 | 16 GB | 200 GB | 数据库、缓存和FinClip微服务 | 1 | 6000 |
系统：
- 芯片架构: X86
- 操作系统: CentOS 7.9 或 Ubuntu 22.04 、 KylinOS V10 等
集群部署模式
1.小规模集群
小规模集群的部署架构提供最小规模的高可用，需要使用四台服务器，其中四台服务器只能宕机一台，适合绝大部分的、对高可用与故障隔离具有较小要求的客户。
小规模集群将采用 Kubernetes 的方式部署，所需的配置可以参考下表▼：
| 用途 | CPU | 内存 | 储存空间 | 数量 | 参考 TPS |
|---|---|---|---|---|---|
| 业务服务 | 8 核 | 16 GB | 500 GB | 4 台 | 2w |
| 运维管理(可选) | 8 核 | 16 GB | 500 GB | 1 台 | - |
角色分配可以参考下图▼：
系统:
- 芯片架构: X86
- 操作系统: CentOS 7.9 或 Ubuntu 22.04 、 KylinOS V10 等
部署说明： 所有服务将均匀部署在四台服务器中， 数据库和缓存系统使用docker compose部署在主机，业务服务使用Kubernetes进行部署，均匀分布在四台服务器。
2.中大规模集群
集群模式部署能够提供一定程度的、软件层面的故障转移能力。大规模集群的部署架构适合对可扩展性、灾备等指标有要求的客户使用。该架构的集群设计上主要关注在于故障隔离、故障恢复、可拓展性等方面。
大规模集群的服务器数量没有上限，支持多活、多机房部署，可根据业务规模、灾备要求自定义。相比小规模集群，大规模集群可以提供更高的QPS，更好的性能以及更好的扩展性。
大规模集群将采用 Kubernetes 的方式部署，所需的配置可以参考下表(磁盘建议使用SSD)▼：
| 用途 | CPU | 内存 | 储存空间 | 数量 | 参考 TPS |
|---|---|---|---|---|---|
| 业务服务 | 8 核 | 16 GB | 500 GB | 8 台 | 3w |
| 运维管理 | 8 核 | 16 GB | 500 GB | 1 台 | - |
角色分配可以参考下图▼：
系统:
- 芯片架构: X86
- 操作系统: CentOS 7.9 或 Ubuntu 22.04 、 KylinOS V10 等
部署说明： 与小规模部署类似，不过，大规模集群部署采用更多的服务器，业务服务与基础服务分离， 微服务采用更多的实例数部署，以承担更高的用户访问。
3.双机房冷备集群
双机房部署架构提供更高的容灾能力，适用于对业务连续性要求较高的客户。双机房架构通常包含一个主机房和一个冷备机房，平时仅主机房提供服务，冷备机房处于待命状态，只有在主机房出现故障时才会启用。
部署架构
主机房：主机房承担所有的业务负载，所有业务服务、数据库和缓存系统都运行在主机房。通常部署的组件和资源配置与小规模集群类似，保证业务的正常运转。
冷备机房：冷备机房不承担日常业务，但部署有与主机房相同的服务架构和数据同步机制。通过数据库备份或实时同步的方式，确保数据的一致性。一旦主机房故障，冷备机房能够迅速接管业务。
所需的配置可以参考下表(磁盘建议使用SSD)▼:
| 用途 | CPU | 内存 | 储存空间 | 数量 | 参考 TPS |
|---|---|---|---|---|---|
| 业务服务 | 8 核 | 16 GB | 500 GB | 12 台 | 3w |
| 运维管理 | 8 核 | 16 GB | 500 GB | 1 台 | - |
角色分配可以参考下图▼：
数据同步机制
数据库同步：通过主从复制和数据库同步工具保证主机房和冷备机房数据库的一致性。主机房负责写入，冷备机房保持数据同步。
缓存同步：Redis 等缓存服务可以通过持久化机制来同步缓存数据。冷备机房的缓存数据可以在主机房故障时恢复。
文件同步：通过对象存储的同步机制确保业务文件和数据的一致性。
部署说明
- 业务服务部署：主从机房所有应用服务均使用 Kubernetes 部署，分布在4台服务器上，冷备机房部署相同的架构。
- 数据库与缓存：主机房的数据库和缓存系统使用集群部署，冷备机房部署单节点服务，保持数据同步。正常情况下，冷备机房不会处理数据写入和业务请求。