目錄
第9章 第八階段：服務拆分-用戶和爬蟲流量分離-ELK 日誌收集
第一章 初入公司
1.1 架構拓撲圖
1.2 存在的問題彙總
- 1.物理服務器電源單電，機房電力切割時需要關閉所有服務器，導致服務中斷 4-6 小時
- 2.物理服務器配置不當，有的服務器系統盤用 SSD，數據盤反而用機械盤
- 3.服務器虛擬化 ESXi 上的虛擬機經常無故變成系統只讀導致服務不可用
- 4.操作系統不統一，有 debian，有 FreeBSD
- 5.數據庫單點，且沒有備份以及恢復計劃
- 6.keepalived 配置錯誤導致 HA 高可用沒有生效
- 7.重要的 NFS 服務器 5T 的數據沒有備份，且操作系統爲 FreeBSD
- 8.zabbix 監控項過多，報警內容太多，關鍵報警被淹沒
- 9.軟件部署方式不統一，有編譯/腳本/tar 包/deb 包多種安裝方式
- 10.腳本不統一，腳本隨處存放，命名混亂，很多不知道有沒有用
- 11.沒有批量操作工具，依靠純手工或腳本操作
第2章 第一階段：解決物理服務器單電問題
2.1 問題現象
1.物理服務器電源單模塊，如果機房進行電力切割，必須關閉所有服務器，等機房電力切割結束再把所有服務器開機
2.2 導致後果
1.電力切割期間所有的業務完全中斷，用戶在此期間無法訪問
2.服務沒有做開機自啓動，重新開機之後需要手動起服務
3.因爲服務器老舊，關機之後可能起不來
4.因爲關機時暴力 kill 了服務，導致服務器重啓後數據損壞
2.3 解決方案
1.因爲服務器型號老舊，廠商已經停產，買不到新電源
2.退而求次，淘寶聯繫賣二手服務器的賣家，購買服務器相同型號的電源
3.服務器電源屬於熱插拔，可以直接插上測試
4.驗收方法爲：
- 兩個電源模塊都插上電，然後拔掉第一個電源模塊，查看服務器有沒有重啓。
- 如果服務器沒有重啓，再全部插上電源，然後再拔掉另一個電源，查看有沒有重啓
- 如果都沒有重啓，就證明服務器雙電模塊運行正常
2.4 價值體現
1.由原來業務需要中斷 4-6 小時縮短爲 0 中斷
2.給公司減少了由於業務中斷導致的經濟損失
3.運維再也不用在機房通宵熬夜等待電力切割了
第3章 第二階段：解決服務器虛擬化問題
3.1 問題現象
1.服務器虛擬化採用的是 VMware ESXi 虛擬化平臺，運行的虛擬機經常無故的系統變成只讀，導致服務中斷
3.2 導致後果
1.虛擬機運行的服務不可用，導致業務中斷，影響用戶體驗
3.3 解決方案
1.找臺新服務器安裝部署新版本的 ESXi,安裝 VCenter 管理中心
2.遷移舊服務到新服務器
3.持續觀察檢驗
3.4 價值體現
1.新版本虛擬機運行穩定，業務不會中斷
2.服務器虛擬化充分利用了硬件資源，爲公司節省了購買 3 臺物理服務器的價格
第4章 第三階段：數據庫備份
4.1 問題現象
1.mysql 數據庫只有一臺主從，沒有備份
2.redis 和 mongo 單點，且沒有備份
3.數據庫服務器數據盤均爲單塊 SSD 固態硬盤，一旦損壞沒有修復的希望
4.2 導致後果
1.如果數據庫服務器硬件或者硬盤損壞，沒有數據可以提供恢復，後果不堪設想
4.3 解決方案
1.這個階段重點是先備份數據
2.新增加一個 mysql 從庫，使用 xtrabackup 在從庫上每天定時備份數據
3.新增加一個 redis 從庫，每天物理備份 redis 持久化的 RDB 文件
4.新增加一個 mongo 從庫，每天使用 mongodump 導出數據
4.4 價值體現
1.在服務器有限和時間有限的情況下，按照緊急度優先解決數據庫備份
2.降低了因爲物理服務器損壞或者人爲操作失誤導致的數據災難性丟失情況
3.爲下一步數據庫服務集羣化提供了基礎保障
4.5 拓撲圖
第5章 第四階段：解決數據庫單點
5.1 問題現象
1.數據庫故障到完全修復過程中，業務會中斷，用戶不能訪問
5.2 導致後果
1.雖然已經做了數據庫備份，但是一旦數據庫損壞，恢復起來依然需要很多時間
2.由於業務代碼寫死了 IP 地址，一旦數據庫損壞，在其他機器上恢復了，業務代碼也需要變更 IP 地
址，重新發布，耗時太長
5.3 解決方案
1.對目前單點數據庫升級到集羣架構
2.新增加 mysql 從庫。
3.redis 由單節點升級爲 redis cluster 集羣
4.mongo 由主從複製升級爲 3 節點副本集
5.新部署 elasticsearch 服務集羣
5.4 實施難點
1.對於運維來說，安裝部署不復雜，但是難題在於由於數據庫架構升級，從而導致業務代碼連接方
式發生改變
2.因爲現在的業務代碼都是採用框架開發，所以很多數據庫插件需要升級，比如 redis 和 mongo 都需
要升級插件才能支持集羣化連接
3.需要提前在開發環境搭建部署好。然後開發測試沒有問題之後，再採用輪訓升級的方式逐步升級
升級數據庫以及代碼框架
5.5 價值體現
1.對數據庫的穩定性以及安全性有了質的改變
2.由於數據庫集羣化，性能得到了大大的提升，用戶打開網站訪問速度更好，體驗更好
3.由於數據庫集羣化，提供了冗餘，所以即使服務器損壞或者維護也不會影響架構改變，用戶訪問
也不會中斷
4.減少了因爲數據庫宕機或恢復導致的經濟損失
5.6 拓撲圖
第6章 第五階段：完善監控項
6.1 問題現象
1.監控項報警內容太多，有時候幾分鐘上百條
6.2 導致後果
1.關鍵的報警信息被不重要的報警淹沒，以至於不能第一時間發現關鍵問題
2.由於報警監控項配置不當，導致連鎖反應，牽動很多不需要的警告
3.由於短時間大量的報警產生，對 zabbix 服務器造成很大壓力，甚至導致 zabbix 服務宕機
4.如果配置了短信報警，那麼大量的非關鍵報警導致消耗很多短信條目，很花錢！
6.3 解決方案
1.優化報警內容，只監控必須要監控的，模版自帶的一些不需要的監控項停掉
2.報警分級，將報警信息按緊急度拆分，所有報警都發郵件，緊急的報警追加發送到微信
3.取消短信報警，改爲郵件和微信報警
4.報警內容優化，儘量看標題就能知道報警內容是什麼
6.4 價值體現
1.接受的報警量大大減少，運維的注意力可以更集中在關鍵的問題處理上
2.通過不同的發送介質第一時間瞭解問題的緊急度，比如發送到微信上的都是需要立刻處理的
3.取消短信報警爲公司節省開銷
第7章 第六階段：統一服務的安裝方式
7.1 問題現象
1.服務安裝混亂，有腳本安裝，有 tar 包安裝，有 deb 包安裝，有編譯安裝
2.軟件存放目錄不統一，數據存放目錄不統一，腳本存放目錄不統一
3.防火牆規則不統一，有一些不用的規則沒有清理
7.2 導致後果
1.一些操作無法進行批量執行
2.安裝服務基本需要手動操作
3.文檔缺失，不知道以前怎麼裝的，不知道以前配了什麼參數
4.防火牆規則混亂，有一些已經不用的服務，但是規則沒有刪除，看起來很亂
7.3 解決方案
1.引入 ansible 批量管理工具，統一服務安裝方式，新服務統一使用 playbook 安裝
2.統一服務安裝目錄，數據目錄，日誌目錄
3.清理防火牆不用的規則，只保留必須的規則
4.編寫運維文檔，制定運維規範
7.4 價值體現
1.新服務安裝部署由原來的按小時縮短爲分鐘級別，提高了運維效率
2.避免了因爲手動操作敲錯命令導致的不可預料後果，實現了一次編寫重複運行
3.編寫運維文檔，爲部門同事和公司留下可持續的價值輸出
第8章 第七階段：關鍵服務 NFS 遷移備份
8.1 問題現象
1.公司成立以來所有的圖片數據都保存在一臺安裝 FreeBSD 操作系統的老舊服務器上且沒有備份
8.2 導致後果
1.NFS 服務器的數據高達 5T，且沒有備份，一旦服務器或硬盤損壞，後果不堪設想
2.由於 FreeBSD 操作系統的原因，沒有辦法使用 sersync 來進行實時同步備份
3.一旦服務器發生損壞，所有業務網站的圖片服務都將失效，短時間沒有替代方案
8.3 解決方案
1.雖然 FreeBSD 系統不能使用 sersync，但是可以使用 rsync
2.找一臺性能足夠服務器，使用四塊 6T 磁盤製作 RAID10，安裝部署 rsync 服務端和 NFS 服務端
3.分目錄進行同步，總目錄數據量太大，同步起來時間按天算，拆分成一個個小目錄分批進行同步
4.統計記錄每次同步的時間，最高在半夜業務低峯期進行同步
5.和開發溝通切換方案，開發修改代碼，用戶上傳數據同時往 2 臺服務器上寫入，保證數據一致性
6.業務低峯期進行切換，在前端代理輪流更新 WEB 服務器的卸載舊 NFS，然後重新掛載新 NFS
7.修改個別權限不對的目錄。測試所有上傳業務是否可以正常的寫入
8.爲了防止意料不到的意外情況，舊服務器數據繼續保留 1 個月。確定一切正常之後重做舊服務器
9.然後使用 sersync 同步數據到新服務器，持續觀察，保證同步正常工作
8.4 價值體現
1.在業務不中斷，數據不丟失的情況下爲公司的寶貴資產提供了可靠的備份方案
2.燙手的山芋在運維手裏得到了解決，榮譽感，成就感大增
3.在公司領導和同事心中留下了可靠可信賴的印象
8.5 拓撲圖
第9章 第八階段：服務拆分-用戶和爬蟲流量分離-ELK 日誌收集
9.1 問題現象
1.因爲公司有論壇，需要爬蟲來爬取
2.但是爬蟲的流量和用戶的流量混合在了一起，且沒有統一的日誌管理平臺查看過濾
9.2 導致後果
1.由於流量沒有分離，導致當有大量的爬蟲訪問的時候，對服務器和數據庫造成非常大的壓力
2.當爬蟲訪問頻次過高時，會導致數據庫連接數變多，系統負載變高，影響用戶正常服務
3.同樣，由於爬蟲流量和用戶流量混在了一起，沒有很好的辦法分析壓力高的原因
4.開發或者運營想看一些日誌數據只能找運維解決，每次分析都要花很久，分析腳本沒有辦法複用
9.3 解決方案
1.新增加一臺 WEB 服務器專門給爬蟲使用，頁面做靜態化，優化爬蟲抓去效率
2.數據庫讀寫分離，爬蟲抓取如果需要查詢數據庫，把流量指向沒有業務訪問的從庫
3.前端代理根據訪問的請求報文裏的 user-agent 來分離爬蟲和用戶的訪問流量，如果是爬蟲就把流量引到給爬蟲抓取的 WEB 服務器上，用戶正常的流量還是正常訪問 WEB 集羣。
4.搭建部署 ELK 日誌收集平臺，集中收集所有 Nginx 訪問日誌，使用 kibana 作爲過濾搜索和展示，
製作好用戶展示數據的圖表，培訓部門同事 ELK 的使用和查詢方法
9.4 價值體現
1.將用戶和爬蟲流量分離，當爬蟲大量訪問時候正常用戶訪問也不會受到影響，用戶體驗大大提升
2.搭建部署了 ELK 日誌分析平臺，方便部門同事查詢數據，定位故障時間大大地縮減，大大提高了工作效率
9.5 拓撲圖
第10章 第九階段：增加第二機房-大數據服務
10.1 項目需求
1.業務發展，需要部署 Hadoop 平臺和 kafka+zookeeper 服務
2.由於 IDC 機房只有一個機架，所以需要在第二機房部署
10.2 價值體現
1.測試環境測試沒問題後使用 ansible 批量部署到新的大數據服務器，節省了部署時間
2.大數據服務可以更好的分析用戶訪問行爲，根據分析結果可以更精確的給用戶推送推薦內容
10.3 拓撲圖
完整架構圖
整體結構演變
