IDC机房硬件设备选购方案

1.1 生产环境中选购依据

  • 价格
  • 性能
  • 冗余

1.1.1 生产环境负载均衡系统架构设备选购方案

负载均衡:
LVS1 DELL R610 1U CPU E52 8G * 2/4 硬盘 SAS 146 * 2 RAID1
LVS2 DELL R610 1U CPU E5
2 8G * 2/4 硬盘 SAS 146 * 2 RAID1

1.1.2 Web层硬件选择RAID

www主站1 业务2 DELL R730 2U CPU E5 * 2 8G(16G/32G) SAS 300G * 2 RAID0
www主站2 业务
2 DELL R730 2U CPU E5 * 2 8G(16G/32G) SAS 300G * 2 RAID0

1.1.3 数据库层硬件以及RAID

Mysql主库1-1 DELL R730 2U CPU E52 8/16/32 SAS 300G * 6 RAID10(兼顾冗余/速度)
Mysql主库1-2 DELL R730 2U CPU E5
2 8/16/32 SAS 300G * 6 RAID10(兼顾冗余/速度)
Mysql从库1-1 DELL R730 2U CPU E52 8/16/32 SAS 300G * 6 RAID0/5
Mysql从库1-2 DELL R730 2U CPU E5
2 8/16/32 SAS 300G * 6 RAID0/5
Mysql从库2-1 DELL R730 2U CPU E52 8/16/32 SAS 300G * 6 RAID0/5
Mysql从库2-2 DELL R730 2U CPU E5
2 8/16/32 SAS 300G * 6 RAID0/5

1.1.4 存储层硬件以及RAID

DELL R610 E5 * 2 16/32G SAS 10K 2T * 6 不做RAID交叉备份/ RAID5
DELL R730 E5 * 2 16/32G SAS 10K 2T * 6 RAID5折中方案

备份服务器一般考虑容量和冗余,对性能要求不高。

1.1.5 NFS硬件以及RAID

NFS1 DELL R730 E5 8G * 2 SAS 15K 600G * 6 RAID10/RAID5/RAID0
NFS2 DELL R730 E5 8G * 2 SAS 15K 600G * 6 RAID10/RAID5/RAID0

1.1.6 GFS、MFS分布式存储

NFS1 DELL R730 E5 8G * 2 SAS 15K 600G * 6 RAID10/RAID5/RAID0
NFS2 DELL R730 E5 8G * 2 SAS 15K 600G * 6 RAID10/RAID5/RAID0

1.1.7 监控管理/网关层硬件以及RAID

DELL R610/R430 E5*1 8/16G 146 SAS * 2 RAID1

1.1.8 网络设备

全千兆设备/网线
华为 H3C CISCO DLINK

都需要带有远程管理卡 4+1

Redis搭建

主机规划:

序号 主机名称 角色 数量 IP内网 IP外网 端口 软件 备注
1 Redis-Master-01 Node01 1 10.0.0.1 6379 Centos7.7
1 Redis-Master-02 Node02 1 10.0.0.2 6379 Centos7.7
1 Redis-Master-03 Node03 1 10.0.0.3 6379 Centos7.7
1 Redis-slave-01 slave01 1 10.0.0.4 6389 Centos7.7
1 Redis-slave-02 slave02 1 10.0.0.5 6389 Centos7.7
1 Redis-slave-03 slave03 1 10.0.0.6 6389 Centos7.7



1
2
3
4
5
6
7
bind 10.0.0.1
port 6379
pidfile /var/run/redis_7000.pid
cluster-enabled yes
daemonize yes
cluster-config-file nodes-63679.conf
appendonly yes

ES安装

cd /etc/yum.repos.d/
vim elasticsearcg.repo
yum makecache && yum install -y elasticsearch

创建软件应用程序时为了满足不断变化和发展的需求,一个成功的应用程序应该提供一种简单的方法来扩展它以满足不断变化的期望。

SOLID设计原则

单一职责原则

有且仅有一个原因引起类的变更。

问题:
Class IUser 负责两个不同的职责,职责1维护User的属性(id, name, age),职责2维护DB操作(save/update/delete/find).
当由于职责1需求发生改变要增加一个sex的时候,有可能会导致原本运行正常的职责2功能发生故障。

解决方法:
将IUser拆分为 UserInfo和UserDao。

优点:
降低类的复杂性,一个类只负责一项职责;
提高类的可读性,提高系统的可维护性;
降低变更引起的风险,当修改一个接口的功能时,可以降低对其他功能的影响。

开闭原则

一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
也就是说通过扩展来实现变化,而不是通过修改已有的代码来实现变化。

可以通过抽象约束、封装变化来实现开闭原则。
通过接口或者抽象类为软件实体定义一个相对稳定的抽象层,而将相同的可变因素封装在相同的具体实现类中。

里氏替换原则

派生类型必须完全可替代其基类型。在设计模块和类时,必须确保派生类型从行为的角度来看是可替代的。当派生类型被其父类替换时,其余代码就像它是自类型那样使用它。

  • 子类必须完全实现父类的方法
  • 子类可以有自己的个性
  • 覆盖或者实现父类的方法时,输入参数可以被放大
  • 腹泻或者实现父类的方法时,输出结果可以被缩小

接口隔离原则

客户端不应该依赖于它所不需要的接口。接口隔离原则减少了代码耦合,使软件更强壮,更易于维护和扩展。接口隔离原则要求接口的定义和设计尽量的细化。

  • 接口尽量小,但是要有限度。
    对接口进行细化可以提高程序设计的灵活性,但是如果过小,会造成接口数量过多,使设计复杂化。
  • 为依赖接口的类定制服务,只暴露给调用的类它需要的方法,不需要的方法隐藏起来,只有专注地为一个模块提供定制服务,才能建立最小依赖关系。
  • 提高内聚,减少对外交互。使接口用最少的方法完成最多的事情。

依赖倒置原则

高级模块不应该依赖低级模块,两者都应该依赖抽象。
抽象不应该依赖于细节,细节应该依赖于抽象。

  • 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,器依赖关系是通过接口或者抽象类产生。
  • 接口或者抽象类不依赖实现类
  • 实现类依赖接口或者抽象类

创建型模式(6/6)

行为型模式(12/12)

结构型模式(7/7)