OA系统__集群架构

•  前言概述：

            以下的服务器集群架构是本人2016年在一家互联网软件开发公司工作时与开发团队沟通了解后的设计，

     在此之前公司主要是做 ERP管理软件的研发与实施，考虑到ERP客户的方便性，公司高层决定研发一款OA

     系统，并把ERP系统与OA系统的数据进行连通，之前只能在PC端操作查看的一些信息，现在APP也能进行

     操作，方便了外出人员与业务人员的使用，就这样新的目标开始了。

 

• 网络层

一）物理防火墙：

         华为：USG6330-AC      最大吞吐量 ：2G。测试会话最大并发数：150W。实际用户访问最大并发量：建议 600 以内。

             1、入侵防御   ：也叫ips防御，防御中包含了：漏洞攻击，WEB攻击，SQL注入攻击，跨站脚本攻击。防火墙会检查入

                                     网的数据包，对入网数据包与入侵库中的数据进行匹配，如果一致则给与禁止，其它的通过。

             2、病毒防护   ：防火墙会检查入网的数据包，对入网数据包与病毒库中的数据进行匹配，如果一致则给与禁止，其它的通过。

             3、链路负载   ：防火墙配置两条链路出入口，服务器配置两个出口的网关，正常情况下一条链路是处于备用状态，防

                                     火墙会对两条链路进行健康检查，当被使用的链路出现故障时会自动切换为另一条链路。                        

             4、DDos防御 ： 防火墙定义规则，禁止定义时间内访问多次的ip

【说明】 ：

            在第一次购买防火墙后，需要再购买 入侵防御库、病毒防护库（按年计费），因为库是例外收费的，防火墙只是支持这些功能，

 购买后会得到功能激活码，需要在防火墙管理页面进行功能激活 ，防火墙功能激活后会自动去华为库平台下载入侵库与病毒库到防火墙

 本地，在购买期内如果华为库平台有更新，防火墙也会自动去下载所更新的库。

            库到期后不再续费的话，防护墙将不能再与华为库平台进行下载更新，但前期下载到防火墙本地的库还是可以正常防御，只是

  没有了更新。       

                                                        

防火墙放在路由器放前放后的影响：

       1、路由器放在防火墙前面的话，如果受到攻击，路由器将承受所有的攻击，有可能崩溃。
       2、路由器放在防火墙后面的话，如果受到攻击，防火墙将过滤掉大部分的攻击，不会影响路由器。

 

二）路由器         ：局域网和广域网互连，实现不同网络互相通信、数据处理、网络管理。

三）交换机         ：又名交换式集线器，可以简单的理解为把多台电脑连接在一起组成一个局域网。     

四）CDN            ：第三方数据缓存，提高访问速度。

五）OpenVPN    ：SSL加密虚拟专用网络。

 

• 代理层

Haproxy :    

              工作在网络4层和7层，支持虚拟主机、支持多网段、支持Session的保持、支持Cookies的引导，支持url检测后端服务器

      的状态、以ACL的方式定义负载规则，配置相对简单。

Haproxy  :   对于大型的Web服务器的时候可以使用haproxy。

   Nginx   :   像对于大型的，需要进行高并发的网站或者对网络不太严格的时候，可以使用nginx。

       Lvs   :   对性能有严格要求的时候可以使用lvs，就单纯从负载均衡的角度来说，lvs也许会成为主流，更适合现在大型的互联网公司。

Keepalived ：

               Keepalived主要是通过虚拟路由冗余来实现高可用功能。

优点：部署和使用非常的简单，所有配置只需要一个配置文件即可以完成。

缺点：相对heartbeat，Keepalived主要用于集群倒换，基本没有管理功能。

 

 

• 应用层

IIS  :

         一开始的考虑是用Apache还是用IIS，IIS在实际使用中，经常会出现500错误，而且，有时候会出现假死的状态，造成

  系统无法正常使用，所以IIS要不定期的重新启动服务或回收程序池才能维持系统的正常运行，相对于IIS，Apache更加稳定

  些，只要完整配置好，可以支持系统长期运行正常，一般不会莫名其妙的出现的假死状态，当然Apache配置相对来说比较复

  杂点，所以很多人还是喜欢使用IIS，因为它配置简单方便。

 

         虽然在稳定性上Apache优于 IIS，但公司OA系统的研发是基于C# 编程语言的，C# 与 IIS又都是同属微软，考虑到后续

  兼容性的问题最后还是选择了IIS作为WEB服务。

         

 

• 数据层

SQL server  :

          选择 SQLserver 的原因主要有以下几点。

            1、因为系统是基于c#编程语言开发 , 而 .net和sql server都是微软的产品，自家兄弟兼容性较好。

            2、可视化管理界面：SQLserver 自带图形管理工具 sqlserver management studio，可同时连接多个数据库管理系统。

            3、扩展性：sql 数据库最多支持32台群集 24个节点服务器，而且添加节点的过程都是可视化的，非常的方便简单。

            4、安全性：因为数据会同步的多台服务器上，可以实现数据集的冗余，通过多份数据来保证安全性。

            5、用于决策支持的数据仓库功能、与许多其他服务器软件紧密关联的集成性、良好的性价比等。

 

   集群核心构造： 

        域控制器 ：

                   最大的优点是实现了集中式管理。以前在无数客户端要重复多次的设置，只要在域控制器上做一次设置就可以了，以

              及权限集中管理、文件集中管理等。

                   之所以安装域环境，是因为故障集群需要基于域的集中化管理节点。

 

        故障转移集群 ：

                  故障转移群集是Windows Server中的一个功能，可为服务器负载提供高可用性，是由一组独立的服务器组成, 并相互协作

          以提高服务和应用程序的可用性，群集中的某台计算机上发生故障时，资源会重定向到群集中的另一台计算机，工作量也会重

          新分发到群集中的另一台计算机。可以使用故障转移群集确保用户几乎一直具有访问基于服务器的重要资源的权限。故障转移

          群集是针对具有长期运行的内存中状态或具有大型的、频繁更新的数据状态的应用程序而设计。这些应用程序称为状态应用程

          序，并且它们包括数据库应用程序和消息应用程序。故障转移群集的典型使用包括文件服务器、打印服务器、数据库服务器和

          消息服务器。

 

       AlwaysOn高可用 ：

             可用性副本  ：把离散的数据库管理系统组合成一个组，让其共同实现故障转移，组中可以有一个或多个主与辅助。

          可用性数据库 ：把用户数据库添加到可用性数据库中后，辅助节点会与其进行数据同步，辅助节点只能用于读操作，无法写入。              

          可用性侦听器 ：定义一个虚拟的IP地址，在集群中侦听器专门用来监听客户端对VNN的访问请求，一旦侦听到了请求就将这个

                                 请求转接到AlwaysOn主站点，在发生故障转移后，侦听器始终会将请求转接给此刻的主站点。

 

      主辅副本间的数据同步：

                AlwaysOn必须要维护各副本间的数据一致性，当主副本上的数据发生变化，会同步到辅助副本上。

           步骤1 ：主副本记录发生变化的数据；
           步骤2 ：将记录传输到各个辅助副本；
           步骤3 :   把数据变化操作在辅助副本上执行一遍。

      具体实现如下：

                在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。对于一般的SQL Server服务器，即没有配

        置高可用性，会运行Log Writer的线程，当发生数据修改事务时，此线程负责将本次操对应的日志信息记录到日志缓冲区中，

        然后再写入到物理日志文件。但如果配置了AlwaysOny主副本的数据库，SQL Server会为它建立一个叫Log Scanner的线程，

        不间断的工作，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。因此可以保证发生的数据变化，

        不断送给各辅助副本。辅助副本上存在固化和重做两个线程完成数据更新操作，固化线程会将主副本Log Scanner所发过来的

        日志块写入辅助副本磁盘上的日志文件里，因此称为固化，然后重做线程负责从磁盘上读取日志块，将日志记录对应的操作重

        演一遍，此时主副本和辅助副本上的数据就一致了。重做线程每隔固定的时间点，会跟主副本通信，告知自己的工作进度。主

        副本由此知道两边数据的差距。Log Scanner负责传送日志块，不需要等待Log Writer完成日志固化；辅助副本完成日志固化

        以后就会发送消息到主副本，告知数据传输完成，而不需要等待重做完成，这样各自独立的设计，是尽可能减少 AlwaysOn所

        带来的操作对数据库性能的影响。

                      

Mongodb :

             MongoDB可以直接写入数据，不需要提前创建表，由于存 储的数据与金融等行业比起来并不是那么重要，而且对事务

   也没什么要求，所以在这种场景下，MongoDB要比关系型 . 数据库更适合，因为传统的关系型数据库的每次操作都会有ACK，

   而MongoDB的设计去掉了这个步骤，大大提高了存储 的性能，而且MongoDB的设计考虑了设备故障经常出现的场景，所以

   在设计时就做了容灾和故障转移方面方案。

            一般存储：业务性不是很强的，但是数据量又很大的一些功能信息.如：OA系统中的各种应用模块，分享，日志，消息记录等。

  集群核心构造：

       mongos：

              数据库集群请求的入口，所有的请求都通过mongos进行协调，不需要在应用程序添加一个路由选择器，mongos 自己就是

一个请求分发中心，它负责把对应的数据请求请求转发到对应的shard服务器上。在生产环境通常有多mongos 作为请求的入口，防

止其中一个挂掉所有的mongodb请求都没有办法操作。

      config server：

              顾名思义为配置服务器，存储所有数据库元信息（路由、分片）的配置。mongos本身没有物理存储分片服务器 和数据路由

信息，只是缓存在内存里，配置服务器则实际存储这些数据。mongos第一次启动或者关掉重启就会从config server 加载配置信息，

以后如果配置服务器信息变化会通知到所有的 mongos 更新自己的状态，这样 mongos 就能继续 准确路由。在生产环境通常有多个

config server 配置服务器，因为它存储了分片路由的元数据，这个可不能丢失！就 算挂掉其中一台，只要还有存货， mongodb集群

就不会挂掉。

       shard：

             这就是传说中的分片了。上面提到一个机器就算能力再大也有天花板，就像军队打仗一样，一个人再厉害喝血瓶 也拼不过对

方的一个师。俗话说三个臭皮匠顶个诸葛亮，这个时候团队的力量就凸显出来了。在互联网也是这样，一台普 通的机器做不了的多台

机器来做，

 

Fastdfs+Nginx :

           FastDFS 是用 c 语言编写的一款开源的分布式文件系统FastDFS 为互联网量身定制，充分考虑了冗余备份、负载均衡、

线性扩容等机制，并注重高可用、高性能等指标，使用 FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载
等服务。其中Client客就是官方提供的C、Java和PHP的调用API。

 

  集群核心构造：

      Tracker Servre（追踪服务器）
           主要做调度工作，在访问中起负载均衡的作用。在内存中记录集群中group和storage server的状态信息，是连接Client和
  Storage的枢纽。因为相关信息全部在内存中，Tracker server的性能非常高，一个比较大的集群(比如上百个group)中有三台就
   足够了

      Storage Server（存储服务器）
             是采用分组的方式，同一个组内的服务器的文件是完全相同的(利用同步线程进行同步)，组和组之间是不通信的。而存储
   服务器会主动定期向追踪服务器报告目前的状态，追踪服务器可以有多个，多个之间是对等的，不存在主从。文件和文件属性
   (meta data)都保存在存储服务器上。

       Client (客户端)
             是不需要有关存储服务器的任何信息的。一般客户端通过API接口，与Tracker发生通信，而不是直接请求存储服务器
    例如：一个客户端需要上传文件，此时追踪服务器就会从存储服务器中找出一个组分配给客户端，供其上传文件，此时
              客户端拿到组的信息后，开始直接和存储服务器的这个组进行交互，无需再通过追踪服务器进行中转。

    

    Fastdfs 为什么要与nginx结合使用:

            我们在使用 FastDFS 部署一个分布式文件系统的时候，通过FastDFS的客户端API来进行文件的上传、下载、删除等操作。
      同时通过FastDFS的HTTP服务器来提供HTTP服务。但是FastDFS的HTTP服务较为简单，无法提供负载均衡等高性能的服务，

      所以FastDFS 的开发者——淘宝的架构师余庆同学，为我们提供了Nginx上使用的FastDFS模块（也可以叫FastDFS的Nginx模块）。

 

Redis+哨兵 :

           非关系型数据库  适合不需要复杂结构数据的场景（数据量大 但是结构不复杂） 不存在行 列 表 ，以及没有各种关联 读取速度

极快 所有数据都存储在内存中  更加缩短读取IO时间， 速度更快.

   主从复制过程：

1. 从节点执行 slaveof 命令。      
2. 从节点只是保存了 slaveof 命令中主节点的信息，并没有立即发起复制。      
3. 从节点内部的定时任务发现有主节点的信息，开始使用 socket 连接主节点。    
4. 连接建立成功后，发送 ping 命令，希望得到 pong 命令响应，否则会进行重连。      
5. 如果主节点设置了权限，那么就需要进行权限验证，如果验证失败，复制终止。        
6. 权限验证通过后，进行数据同步，这是耗时最长的操作，主节点将把所有的数据全部发送给从节点。    
7. 当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

   redis哨兵机制：

                            Redis哨兵系统用于管理多个 Redis 服务器,该系统执行以下三个任务 : ·

    监控(Monitoring) :     

              哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

    提醒(Notification) :

             当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

    自动故障迁移(Automatic failover) :

             当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为

    新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新

    Master的地址,使得集群可以使用Master代替失效Master。

 

              每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间

    (可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).若“哨兵群”中的多数sentinel,都报告

    某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,

    从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。

 

 

• 监控层

   Zabbix 监控

             1、具有可视化WEB图形界面

             2、添加监控主机时比较简单，基本性能监控可图形化操作。

             3、自带监控模块比较多，特殊监控项需自定义脚本。

               4、扩展性强，Zabbix最多监控5000台Agent,后面就需要 加 Node 或者 Proxy。

               5、支持、邮件、短信、微信报警机制。  

   Cacti  ：优点：主要用途还是用来收集历史数据和画图, 所以界面比 Nagios 漂亮很多。

                缺点：默认不支持告警。

Nagios ： 优点：监控很多协议，邮件和短信通知，服务抖动检测 。

                缺点：只能在终端配置，基于文件的配置方式，不方便扩展，易读性差，管理耗时。

 

 Zabbix  :  优点： 图表显示、数据库存储、分布式等功能已经整合，页面配置主动发现主机，内置插件比较全面，监控模块化，

                              邮件短信报 警，功能全面，图表显示比较细腻。

                缺点： 安装稍微复杂，WEB操作方便，没有服务抖动检测，配置较复杂

 

ELK日志收集

  Filebeat ：

               负责收集客户端的日志文件，传递给Logstash。

  Logstash：

               把所有Filebeat传输过来的日志进行分类与过滤，然后输出给Elasticsearch。

  Elasticsearch：

               接受logstash传输过来的日志，并进行存储。

  Kibana：

               读取Elasticsearch的日志数据，进行web图形化展示。

 

转载于:https://www.cnblogs.com/hnchenqiang/p/11234972.html