最后一次更新时间：2021年05月09日 17:00

一、服务架构的一些基础概念

1. 单机(Standalone)、集群（Cluster）和分布式（Distributed）

见示意图，画了一晚上，麻烦点个赞

单机结构.png
集群.png
分布式.png
分布式与集群示意2.png

下面三段介绍引用自知乎：

分布式与集群的区别是什么？

https://www.zhihu.com/question/20004877

1. 单机结构

大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。

2. 集群结构

单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。

但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。

集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用分布式结构了（微服务就是典型的分布式）。

3. 分布式结构

分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。

举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。

二、Elastic search中的一些基础概念

文档和索引，偏向于【开发人员视角】，是一种【逻辑】上的概念；

节点和分片，更偏向于【运维人员视角】，是一种【物理硬件】上的概念

1. 文档（document）

文档：【索引集】内存储的JSON化数据

• 文档 JSON 对象中的每个字段都有对应的字段类型（字符串 / 数值 / 布尔 / 日期 / 二进制 / 范围类型）

• 每一篇文档都有一些【元数据】，用于标注文档的相关信息

文档的元数据.png

2. 索引（indexing）、索引集（indices）

索引（动词）：把一个文档存储到【索引集】的过程。以便后续它可以被检索或查询。即【锁引】过程

索引集（名词）：存储一类相似文档的地方。类似于【目录库】的概念。在ES中也简称索引。

• 每个索引集都有一些【元配置】来指定该索引集下文档【字段的类型】（通过Mapping），以及规定数据应该往哪几个【分片】上分发存储（通过Setting）
• 分片是一个物理上的概念，是存储【索引集】内文档数据的地方，可以用【分开片区存放】来理解。不同的分片一般都分布在不同的机器上

3. 节点（node）

节点：本质就是一个 JAVA 进程，指代一个ES实例。有时一台机器就是一个节点

• 生产环境一般一台机器只运行一个 ES 实例。在上述前提下，【1台机器 = 1个节点】，但 【1个节点 != 一台机器】，因为1台机器也可以运行【多个】ES实例
• 每个节点在启动之后，会分配一个UID，保存在 data 目录下
• 每个节点都有自己的名字，可以通过2种方式指定节点名
  • 配置文件配置
  • 启动时 通过追加启动参数-E node.name=节点名字 指定
• 每个节点都有自己的特定类型，用于区分各自的功能定位：比如设置一个节点为机器学习节点，承担异常监控的工作；或者设置为 仅协作节点，只负责分发请求等等。【开发环境】中一个节点可以承担多种角色，【生产环境】中，一个节点则应该设置为单一角色

节点类型的划分

3.1 按照主次划分：主节点（Master Node） 与 候选主节点（Master-eligible nodes）

• 每个节点启动后，默认就是一个【候选主节点】。每个候选主节点都可以参选主节点的投票选举，都有机会成为主节点。当第一个节点启动的时候，它会将自己选举成【主节点】
  • 可以通过设置 node.master:false来禁止节点成为候选主节点
• 主节点与候选主节点上都保存了集群的【状态】，但只有【主节点】才能【修改】集群状态信息。因为如果任意节点都能修改信息会导致数据的不一致性。
  • 集群状态（Cluster State）：维护了一个集群中必要的信息，包含：
    • 所有节点信息
    • 所有索引和其相关的Mapping与Setting信息
    • 分片的路由信息

3.2 按照功能划分：数据节点（Data Node） 与 协同节点（Coordinating Node）

数据节点：负责保存分片数据

协同节点：负责接收客户端请求，将请求分发到合适的节点，最终把结果汇集到一起，返回给调用的客户端。实际运行时，每个节点默认都是【协同节点】

3.3 按照其他特性划分：

• 热/暖节点（Hot & Warm Node）：硬件【配置较高】的节点设置成 Hot节点，处理较新的或活跃的数据，Warm节点则处理旧数据，相对机器配置也比较低。
• 机器学习节点（Machine Learning Node）：用于做异常检测监控
• ......

4. 分片（shard）

引用【分布式结构】的一段介绍来理解：

分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。

于是我们得到【分片】定义

分片：将一份完整的数据，拆分存储到一个个独立的【存储片区】中，以达到数据水平扩展的目的。

分片示意.png 分片示意2.png

• 主分片：用以解决【数据水平扩展】的问题。通过主分片，可以将数据分布到集群内的所有节点上
  • 一个分片就是一个运行的【Lucene】实例，兼具【存储数据】和【检索数据】的功能
  • 主分片数在索引创建时指定，后续不允许修改，除非Reindex
• 副本分片：用以解决数据高可用的问题，即【容灾】。是主分片的拷贝
  • 副本分片数，可以通过配置项来动态调整副本分片数，一般来说一份副本分片即可。
  • 增加副本数，还可以在一定程度上提高服务的可用性（读取的吞吐）
• 分片数需要提前做好容量规划
  • 分片数设置太小，后续无法水平扩展（2个鸡蛋放不到3个篮子里，篮子多也用不上），或者扩展时数据重分配耗时严重
  • 分片数设置过大，空间资源浪费（总共就那么几条数据，却来个20多个分片，70%空间浪费了）

5. 分段（segment）

• 每个分片的Lucene索引可以再被分割成更小的单元，就是分段
• 分段越多搜索越慢
• 索引新的文档会创建新的分段
• 分段会持续地被合并（小水滴变成大水滴）
• 删除文档的时候不会真的删除（只是标记）