在建立分布式生产环境的过程中，相对于传统的生产环境，我们会面临更多的挑战：
分布式集群维护困难：搭建、集群节点间配置同步、日常维护（节点启停、服务启停、状态查看）
升级风险大：升级过程中、升级过程后、数据量大、持续时间长、影响范围大、业务影响大
故障定位复杂：大量服务状态需要检查、日志信息四散分布
故障恢复代价高：重新搭建故障节点或模块、重新恢复、同步（数据、配置）
为了应对这些挑战，我们需要使我们的分布式系统具备以下特点：
稳定：集群内不存在单点、数据保持完全同步（数据、配置、程序等）
高效：自动化部署、升级、恢复，快速故障定位（状态查看、日志定位）
安全：避免各个节点人工修改风险，验证后再发布到集群其他节点（灰度发布）
简单：不依赖于过多的外部资源，使用成熟工具避免引入外部故障
灵活：适用于多种分布式、非分布式软件，易于扩展，易于与其他产品结合
Elasticsearch Stack中提供的各种beats可以用于采集各种类型的数据，在非linux的环境下使用flume采集数据，也可以使用SDC或者自行开发的app进行数据采集。采集到的数据写入到传输层kafka集群。
特点：以最小的代价快速地将数据传递出来，通常不进行复杂的数据处理，避免对宿主机造成影响。
该层我们选用通用消息中间件kafka集群充当，负责缓存数据，提供多次的数据消费能力，屏蔽数据生产端和消费端的差异。
特点：通用的消息中间件，将数据缓存于该层，避免数据峰涌，避免由于前后端数据处理的速度差异而导致数据丢失。在高可用环境中提供对同一数据的多次消费能力。
该层我们选用SDC集群充当（streamsets data collector），负责将数据从kafka集群读取出来，进行必要的解析、加工、处理，最终存储到Elasticsearch集群。
特点：完全图形化处理，通过拖拽即可完成开发工作，数据处理流程一目了然；对系统资源消耗低，处理速度快；具备back pressure能力，避免短时间大量数据从源端涌入，致使后端数据处理超载；直观查看各个数据处理环节的处理性能及数据处理异常情况。
该层我们选用nginx集群充当，每个物理节点都部署一个独立的nginx节点，负责在对Elasticsearch集群写入时进行安全控制，避免非授权访问。
该层由Elasticsearch集群充当，负责存储海量数据，提供高效数据查询能力。
特点：提供业界领先的海量数据存储、准实时的数据查询、分析能力。在日志分析、全文检索、实时推荐、安全预警、业务分析、机器学习、图计算等方面都能提供强大的处理能力。
该层我们选用nginx集群充当，每个物理节点都部署一个独立的nginx节点，负责在对Elasticsearch集群读取时进行安全控制，避免非授权访问。
在该层我们可以对数据进行图形化展示、实时告警、供应用系统进一步加工处理等。
特定：在基于对Elasticsearch所提供的各种数据查询能力上，我们可以非常方便地进行各种二次开发，满足业务需要。
通过这套数据处理架构，形成了大数据处理从采集-》传输-》处理-》存储-》展现的完整生态。上述数据处理的流程是自上而下，单向流动，这是为搭建高可用集群打下基础。最终可以形成集群多活的高可用环境。
整个集群中各个节点的内容都是相同的，关系是对等的，采用的是去中心化的架构设计。
对于Elasticsearch集群来说，少数任意节点出现故障不会导致集群服务异常（故障的master节点数低于master节点总数的一半），这是由Elasticsearch的集群设计所保障的；对于SDC集群来说，由于采用的是无状态节点的部署方式，因此只要集群中还有一个节点存活，则集群就不会停止服务；对于elastalert、curator集群来说，采用的是动态节点选举的方式，因此也能够做到只要集群中还有一个节点存活，则集群就不会停止服务。
可以在任意时刻通过集群中的任意剩余节点恢复故障节点，执行简单的复制操作就可以使集群快速恢复功能。
在最内层是服务级别的管理，针对的是各个独立的服务模块，每个模块都能够进行启停、状态查看等操作，模块间独立。
在外面一层是节点级别的管理，通过supervisor将各个独立的服务模块有机地组合起来，实现全部服务或个别服务的管理（启动、停止、状态查看），在服务出现异常退出时自动拉起异常服务。
在最外面一层为集群级别的管理，通过pssh进行远程命令控制，最终实现在集群中的任何一个节点都可以对整个集群的运行状态进行控制（启动、停止、状态查看）。
本地服务拆分（程序、配置、日志、运行数据等），避免升级导致的覆盖，同时规范数据存储位置易于信息查找；
本地服务管理（启动、停止、状态），脚本进行封装；
节点服务管理（启动、停止、状态）调用本地服务管理，脚本进行封装，supervisor；
集群服务管理（启动、停止、状态）远程调用本地服务管理，脚本进行封装，pssh；
数据同步（rsync），所有节点数据一致，节点间关系都是对等的，在服务启动时再确定正确的运行环境（广义上的一种docker）。
命令（bin）：存放在整个集群环境运行所需的各种命令脚本
配置(conf)：各服务、组件的配置文件；按服务、组件分子目录存放，事先准备好；该目录下的*.list文件定义了哪些节点启动哪些服务以及运行角色
数据(data)：各服务、组件的中间运行态数据；按服务、组件分子目录存放
日志(log)：各服务、组件的运行日志信息；按服务、组件分子目录存放
安装(install)：各服务、组件的标准安装包，从各产品的官方网站下载
程序(software)：各服务、组件的运行程序，由各安装包安装后产生；按服务、组件分子目录存放
initnode.sh：初始安装或升级安装一个节点上所有服务、组件。
各服务脚本：服务层面控制，负责自身服务的启停、状态监控，依据*.list来设置合理的运行环境、动态修改配置文件等
supervisor.sh：节点层面的服务控制，对节点范围内对服务进行启停、状态监控，节点服务退出自动拉起。
cluster.sh：集群层面的服务控制，在整个集群范围内对服务进行启停、状态监控。
sync.sh：将当前节点的数据完全同步到集群中的其他节点，保证节点间信息完全同步。用于扩容、升级、信息同步等场景。
Ø 部署场景：执行initnode.sh对该节点进行安装；
Ø 升级场景：执行initnode.sh对该节点进行升级；
Ø 变更场景：不执行initnode.sh，仅更改配置；
Ø 扩容场景：不执行initnode.sh。
基于前面的部署架构可以很容易地扩展为多集群的高可用架构。
SDC集群在对kafka集群里面的同一数据进行多次消费后，使用不同的pipeline但进行相同的处理，然后将相同的处理后数据存储进多个ES集群，保证ES集群间的数据最终一致性。
ES集群间相互没有关系，存储的数据最终一致，在一个集群出现停止服务后，可以快速地将其上的业务迁移到可用的ES集群上。
在一定时间范围内故障的ES集群恢复功能后，由于SDC在kafka上记录的offset没有改变，因此可以从故障点的数据重新开始追加处理，实现数据的自动恢复。
升级过程中：在需要对某一个ES集群进行升级时，可以将其上的业务迁移到其他ES集群，然后对没有业务运行的ES集群进行升级，减少升级对业务的影响，降低升级压力；
升级过程后：在某个ES集群完成升级，运行一段时间的业务后，发现存在不可解决的问题，这时如果整个集群中还有ES集群运行在老版本上未完成升级，这时可以快速地将业务切换到老版本集群上，实现版本回退。
按照官方的升级路径，某些低版本由于结构差异太大，是不能直接升级到新版本的，而需要经历一些过度版本，完成内部数据结构的转换，这会增加升级的风险和影响。本方案可解决这一问题，各集群间仅仅是存储的数据相同，相互之间没有关联，因此无需进行任何数据结构的转换，可以一次性实现跨多个版本的升级工作。
相关代码及详细演示过程参见开源项目：https://github.com/zhan-yl/es_cluster。
詹玉林，中国民生银行信息科技部大数据团队运维工程师。曾经担任过银行核心系统开发工程师，IBM informix数据库L2支持工程师，民生银行数据库DBA等角色。目前主要负责与elasticsearch相关的大数据方面的工作。
本文转载自公众号：民生运维，点击查看原文
相关阅读：
万字长文：ELK（V7）部署与架构分析
民生银行：OpenStack 安全加固探索与实践
民生银行：基于 F5 技术实现 Kubernetes 生产环境最佳实践
民生银行：桌面云自动化交付实践
民生银行：OpenStack Ironic实现X86裸机自动化装机实践与优化
2019 Q1中国公有云市场份额：阿里云、腾讯云、中国电信、AWS、金山云、华为云、百度云
2018年全球公有云 TOP10：阿里云 第三、腾讯云 第六、中国电信 第七、金山云 第十
RightScale 2019年云状况调查报告：35% 的云支出被浪费「附50页PDF下载」
更多文章请关注
文章好看点这里[在看]👇
