-
前言概述：
以下的服務器集群架構是本人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時間， 速度更快.
主從復制過程：
- 從節點執行 slaveof 命令。
- 從節點只是保存了 slaveof 命令中主節點的信息，並沒有立即發起復制。
- 從節點內部的定時任務發現有主節點的信息，開始使用 socket 連接主節點。
- 連接建立成功后，發送 ping 命令，希望得到 pong 命令響應，否則會進行重連。
- 如果主節點設置了權限，那么就需要進行權限驗證，如果驗證失敗，復制終止。
- 權限驗證通過后，進行數據同步，這是耗時最長的操作，主節點將把所有的數據全部發送給從節點。
- 當主節點把當前的數據同步給從節點后，便完成了復制的建立流程。接下來，主節點就會持續的把寫命令發送給從節點，保證主從數據一致性。
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圖形化展示。