告别单体架构，迎接分布式时代!

  随着互联网+、智能制造等大数据应用的发展，传统的企业信息化单体架构必定绕不过以下两个坎：

• 单机资源瓶劲造成系统响应慢，需要高成本升级硬件来解决；
• 单机故障造成系统不可用，需要较长的时间来恢复故障。

  所以将来的企业信息化基础架构必定是分布式的，AppBoxFuture设计之初就确立了必须满足简单、低成本的分布式架构原则，能够利用普通硬件构建具备横向扩展能力的集群。作者最近在设计与实现集群的运维管理功能，下面让我们来体验已实现的部分功能。

一、测试环境

二、创建集群

1. 启动集群：

在VM1上执行：

sudo ./appbox --init=10.211.55.3:9000 --peer=1.1.1 

在VM2及VM3分别执行：

sudo ./appbox --join=10.211.55.3:9000 --peer=1.1.2

sudo ./appbox --join=10.211.55.3:9000 --peer=1.1.3

执行完后，打开浏览器输入网址“http://任意节点:5000/ops”进入运维管理登录界面，用户名：Admin 密码：760wb，可以看到集群包含3个节点，其中第一个是元数据节点(MetaNode)。

运维管理系统由框架自身实现，可以自由修改相关模型进行自定义。

2. 提升副本因子：

依次点击“SetAsMeta”将其他两个节点设置为MetaNode, 点“刷新”按钮后可以看到另外两个节点也转化为MetaNode。然后点击“提升副本因子”按钮将系统自带的实体存储提升为副本因子3，即表的分区存在3份数据。稍候刷新可以看到如下图所示集群每个节点上都存在相同数量的分区，当然如果集群包含其他非MetaNode，系统会尽量将分区均匀分布在每个节点上。

三、测试高可用

1. 建立一个查询服务

代码如下图所示，保存并发布。

其中sys.Runtime.RuntimeContext.PeerId表示当前节点的标识

2. 建立Bash脚本定时调用服务

curl指向Nginx地址

3. 执行脚本并尝试关掉集群某一节点

执行脚本，控制台定时输出服务调用结果，可以看到Nginx均衡分配至3个节点上。此时如果关闭集群某一节点，Nginx将调用分配至其他两个节点，整个集群的可用性不受影响，存储层只要读写的目标分区有多数派存活，就可以保障可用性。

四、本篇小结

  本篇介绍了集群在多数派存活的情况下保障系统的高可用，GitHub上的运行时已更新可测试。作者还在努力争取到年底前达到基本可用的状态，请您多多点赞支持！