Wed Jan 5 16:49:42 CST 2022

Author: xulis

docs/ops/05-availability.md

@@ -4,16 +4,76 @@ title: 可用性
 author: xulishan@finogeeks.com
 ---
 
+ 在互联网业务系统中，高可用是非常重要的一环。为了向用户提供长期稳定的服务，FinClip 在架构设计上便要求所有组件均满足高可用扩展的要求。
 
+ 首先，对于基础服务，我们选择业界主流的开源解决方案。在生产环境采用多节点部署，所有基础服务包括Kafka、Mongo、Redis、Consul、ElasticSearch及其他基础服务均采用集群模式部署，以满足高可用要求，在实际运行中，这样的架构设计可以抵抗一定程度的服务器或网络故障。
 
- 通常，FinClip 应用服务运行在Kubernetes平台之上，借助Kubernetes的故障自动恢复能力，可以实现后端服
+ 对于 FinClip 服务端程序，我们采用无状态微服务架构。因此，FinClip服务端程序可以采用微服务的高可用最佳实践。通常，我们将 FinClip服务端以多副本的形式运行在容器平台之上，借助容器平台的运维能力，可以实现后端服务的自动故障切换、多副本部署、服务器节点管理等高可用场景需求。
 
-务的自动故障转移，以及多副本部署实现服务高可用。
 
- Kubernetes支持管理计算节点，当计算节点发生故障时，集群会自动进行节点排除故障节点，同时当新节点加入 时，可以实现平滑加入集群。
+### 数据存储（MongoDB）
 
- 对于基础服务，我们在生产环境采用多节点集群模式部署，所有基础服务包括Kafka、Mongo、Redis、 Consul、ElasticSearch等服务都是采用集群模式，因此可以抵抗一定程度的节点宕机情况。
+ FinClip 数据存储支持多种数据库。通常，我们采用 MongoDB 作为主要的存储方案，MongoDB 是一个基于分 布式文件存储的数据库，由 C++ 语言编写，旨在为 WEB 应用提供可扩展的高性能数据存储解决方案，且支持多机房部署。在实际部署中，我们使用 MongoDB 的副本集模式，以满足可扩展、高可用的运维需求。
 
- Rancher 平台默认情况下拥有出色的容灾能力，默认情况下最小规模集群为 4 节点部署，集群最小可运行状态为 (部署节点 - 失效节点)÷ 2 ≥ 1。基于此，应用服务也享有同样出色的自动迁移、容灾能力。
+ 在 MongoDB 副本集模式中，MongoDB以两个以上实例部署，其中一个是主节点，其余都是从节点。主节点负责处理客户端请求，从节点实时复制主节点上的数据。主节点记录在其上的所有操作，从节点轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。
 
- 所有基础服务均通过 Docker-Compose 进行部署，Docker-Compose 会为每一个基础服务容器分配守护进程， 当基础服务报错退出后会被严格按照约定数量重新拉起一个或多个基础服务，保证基础服务集群中的节点数量恒 定、保障基础服务集群稳定。
+![mongo-rs](/img/mongo-rs.png)
+
+ 当MongoDB副本集中的从节点发生故障时，不影响业务使用，当MongoDB副本集中的主节点发生故障时，集群将在从节点中进行投票选举出新的主节点，从而实现集群的高可用性和数据安全性。
+
+### 数据缓存（Redis）
+
+ FinClip采用 Redis 实现数据缓存。Redis 是一种开源(BSD 许可)、内存中数据结构存储的开源软件，通常 用作数据库、缓存和消息代理。 Redis 提供了诸如字符串、散列、列表、集合、带范围查询的排序集合、位图、 超级日志、地理空间索引和流等数据结构。
+
+ 通常，我们采用集群模式部署Redis，以确保系统实现高可用功能。在这种模式下，Redis存储空间会被分为多个区间，每个区间的数据将被存储在所属的主从实例中。例如：假设我们有 6 台服务器，我们可以部署一个由 3 主 3 从 组成的集群，Redis会将数据分成三个部分并存储其中。
+
+![redis-cluster](/img/redis-cluster.png)
+
+ 当Reids集群中出现Slave节点宕机时，Redis集群访问不受影响，当集群中出现Master节点宕机时，其对应的从节点将提升为主节点，为业务提供访问，由此实现了Redis集群的高可用性。
+
+### 消息队列（Kafka）
+
+ 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。在FinClip架构中，我们选择Apache Kafka作为我们的消息中间件。
+
+ Apache Kafka 是一个开源分布式事件流平台，被数千家 公司用于高性能数据管道、流分析、数据集成和关键任务应用程序。FinClip 采用 Kafka 作为消息队列中间件，基于 Kafka 的多分区设计，可以实现高吞吐量消息队列管理。
+
+![kafka-cluster](/img/kafka-cluster.png)
+
+ 在生产部署中，我们采用多节点部署Kafka集群。Kafka利用Zookeeper进行节点选举和管理。在服务内部，Kafka数据根据不同的Topic进行区分，Topic由多个partition组成，这些partition可以设置多个数据副本，这些数据副本保存在不同的机器节点上，当集群内有服务器发生故障时，集群访问将自动切换到相应的副本所在服务器上，从而实现集群服务的高可用性。
+
+### 行为数据存储（ElasticSearch）
+
+ FinClip 采用 ElasticSearch 进行存储、检索和分析用户行为数据。Elasticsearch 是一种分布式 RESTful 搜索和分析引擎，能够处理越来越多的用例。作为 Elastic Stack 的核心，它集中存储数据，以实现闪电般的快速搜索、微调相关性和可轻松扩展的强大分析。
+
+![es-cluster](/img/es-cluster.png)
+
+ ElasticSearch 的主旨是随时可用和按需扩容。 而扩容可以通过购买性能更强大（ 垂直扩容 ，或 纵向扩容 ） 或者数量更多的服务器（ 水平扩容 ，或 横向扩容 ）来实现。
+
+ 在生产环境中，我们采用多节点部署ElasticSearch集群，并设置相应的副本分片，使得数据可以同时存储在多个分散的服务器之上。当数据主分片所在的服务器发生故障时，副分片所在的服务器将继续提供集群服务，从而保证服务的可扩展性和可用性。
+
+### FinClip微服务
+
+ Finclip后端业务服务采用了微服务框架，每个服务是一个可以独立多实例部署的模块，通常对应于一个工程项目。有以下特性：
+
+  **服务发现与注册：** 微服务使用了consul组件进行注册与发现，通过consul，可以监控微服务活动状态。
+
+  **负载均衡：** 结合k8s和consul技术，微服务之间的访问是负载均衡的调用。
+
+  **可扩展：** 每个服务都是可以多实例部署。
+
+  **高并发：** 采用了集群模式的redis缓存机制和grpc调用机制，同时技术上使得同一个key分布在多个redis槽，提高redis访问命中率，提高并发程度。
+
+ finclip框架如下：
+
+![finclip-arch](/img/finclip-arch.png)
+
+ 系统总体架构上分为网关层、业务服务层、数据层、基础设施层。
+
+
+ **网关层：** 集成了流量控制、权限控制、负载均衡、网络隔离等功能。
+
+ **业务服务层：** 是业务、需求的实现层。
+
+ **数据层：** 业务或者非业务产生数据，需要落地到db(数据库)，同步到缓存(redis)，发送消息队列(kafka)，文件存储(对象存储)，数据搜索(es)等。
+
+ **基础设施层：** 底层支撑，包括虚拟机操作系统、网络物理层、硬盘等。