• 網名：撒加，先後在AdMaster、餓了麼擔任運維經理，現任天天拍車運維總監，主要負責天天拍車運維架構的管理、持續優化以及運維團隊的建設、培養。
• 9年以上運維及管理經驗。作為國內最早一批思科網路模擬器的推廣者、虛擬化先鋒論壇的創始人，一直致力於網路模擬器使用的推廣，為國內培養網路工程師盡一份力。

分享大綱：

• 架構改造的動力
• 運維架構詳解
• 未來的展望

一、架構改造的動力

大家好，我是天天拍車的運維總監李強，今天給大家分享一下天天拍車的運維架構的演進以及實踐。我們公司前身是51汽車，也就是說，天天拍車的架構是從51汽車的架構一步一步演進到現在的。我們為什麼要做架構的改造？是為了做什麼？為了滿足什麼樣的業務？今天的話題就分這三部分來講，第一部分是為什麼要改造，以及我們改造的動力。

1、網路層面

我入職51汽車面試時公司的技術VP和CPO告訴我機房的網路實在是太差了，希望找一個運維經理，對51汽車的機房網路進行改造，降低兩機房之間的延遲。

所以，我到了51汽車以後第一次去機房就讓我非常驚訝，為什麼驚訝呢？

• 盤絲洞

首先第一點，就是一個“盤絲洞”，大家可以想象一下“盤絲洞”是什麼樣的，估計做運維的兄弟們，下機房肯定能在裡面看到某些公司的伺服器交換的網路，到處飛線。這個問題在51汽車的時候非常嚴重。

• 網路質量

第二點就是網路質量，我們是放在無錫國際，有兩個機房。我去的時候兩個機房用光纖互聯的質量差到什麼程度呢？如果你用mtr做測試可以從零點幾毫秒變到三十、四十毫秒，外部訪問51汽車網站就會很慢，延遲100多毫秒到200多毫秒，最小的時候是在50多毫秒。

為什麼網路質量這麼差呢？當時在我之前他們選擇機房選了一家比較小的公司。可以這麼說，如果你訪問聯通的線路，可以讓你的路由經過美國再回來一趟。

• 交換機收斂比

第三點是交換機的收斂比，當時全部是做bond的且為mode 0模式。我們的接入層接到上聯的頻寬是1G，一臺交換機是48口的，每個機櫃裡面放12臺伺服器，每個伺服器兩個可做bond，總共用24個口。在理想的情況下交換機會產生24G的流量，但是上聯到核心的時候只有1G，這個時候交換機的收斂比是24:1。這種情況下想讓你的基礎架構承載住你的業務基本是不可能的。

• 網路部署架構

第四點就是網路部署架構。各位運維兄弟的公司裡面也是這樣的架構。電信或者是聯通的線路拉進來以後先接的防火牆，防火牆後面再做負載均衡，不管是硬體還是軟體。這種架構存在什麼問題呢？所有的問題最終會發生在防火牆上。如果你的機房裡面只用幾萬塊錢甚至十幾萬塊錢的防火牆，你就不要談多少併發，要多少使用者的訪問。這就是扯淡，為什麼呢？因為防火牆作為最前端的邊界裝置，如果你的請求進來會解包、封包再往後傳遞。

所以我們做網路架構時一般都是儘可能地在負載均衡前面少去接入一些硬體的防火牆，即使是用雲防火牆也不要用硬體防火牆。

2、伺服器硬體層面

我是2015年1月初入職51汽車的，在入職以後我收到了一個資訊：2014年的11月份公司採購了28臺伺服器花了200多萬。在去看伺服器時，一直到我入職有三個多月的時間，這批伺服器放在機房裡面空轉，為什麼呢？就是伺服器硬體搭配的嚴重不合理。

當時都是用的戴爾的伺服器，而且是在關鍵的資料庫上面，用的是戴爾預設的網絡卡。我看了非常震驚，戴爾的R820伺服器用來做資料庫的伺服器，上面記憶體只有32個G，是4CPU，3塊600G的SAS盤，就差到這種情況。

做虛擬化的伺服器CPU都是用的E5-2603、2609的處理器。反而做分佈系統的機器CPU是用的E5-2650的處理器。記憶體分配問題非常不均勻。

3、作業系統層面

作業系統層面就更慘不忍睹了，任何一臺伺服器上面的TCP/IP協議棧配置，幾乎清一色的預設。另外我們的系統限制，比如說最大檔案控制代碼數、程序數，還有我們的棧的大小全默認了。

System Limits很多同學會設定為65535，如果你們有這樣乾的話，真的是浪費了伺服器的效能。

第三點就是IRQ Balance，運維的同學應該不陌生。服務本身初衷是為了儘可能的讓CPU平衡地使用。但是在個別的情況下，不建議啟動，尤其是跟資料相關的開源元件是不建議啟動的。

第四點就是多餘服務，開放很多多餘埠。哪些埠是跟你的伺服器所提供服務相關，哪些是你開了以後從來沒有關注的。你服務的埠一定是開放的，而且是監聽全網。還有一些服務全是監聽在0.0.0.0上的。

根本原因就是開放多餘埠，而且是向公網開放的。如果在公網上你的伺服器用雲，隨便的NTP的反射攻擊你就掛了。

第五點是我們的軟體包冗餘，是根據不同的業務定製化，安裝需要的包。

第六點就是Linux網路配置不合理，你們伺服器上做bond的舉手，在做bond以後使用mode 0的舉手，mode 1的舉手,mode 4的舉手，沒有。Mode 0在你伺服器流量大的情況下會造成丟包以及TCP重傳，而且你的網絡卡會非常繁忙。

4、開源元件層面

再下面是開源元件的層面，軟體版本不統一。當時很多接手機器上去看了一下。Nginx版本從0.8的到1.26的版本全都有。而且安裝方式各不相同，有通過編譯安裝的，各種各樣都有。

還有糟糕的配置，因為51汽車的業務是使用JAVA的，當時用的Tomcat 6作為JAVA容器，配置均為預設配置，當時就震驚了。還有開源軟體亂用，大部分可以作為物件快取來使用，當時我進到51汽車時，memcached是在濫用的，很多東西都往裡面“丟”，導致記憶體的佔用並不到，但是應用訪問經常是超時的。

基於以上這些問題，我當時入職51汽車的時候，我們老大說給我兩個月的時間改造，把基礎網路架構改造了，把軟體不統一全部進行標準化。

最後我們花了不到兩個月的時間就把裡面大部分的問題都進行了解決。接下來詳細講一下天天拍車現在的架構。

二、架構詳解

這是我們當時做的架構圖，最上面的是我們的直接使用者通過電信、聯通的兩條線路直接到我們的Haproxy，Haproxy叢集目前還沒有構建，這是我們今年要去實踐的。再往下面是7層負載均衡，這塊為OpenResty，其次Proxmox是提供我們應用虛擬化的一套套件。

另一面是靜態資源，就是圖片、JS、CSS指令碼的服務提供。再下面是SOA叢集，相當於軟體通用的服務。到下面是資料層，資料層分了兩類，一類是資料服務，由於應用的關係，MongoDB後來我們直接取消了剔出掉了。圖片服務這一塊兒在目前為止仍然是兩種分散式系統同時提供服務。我們新的圖片全部是存在TFS叢集的，只有老的圖片會存在FastDFS。

天天拍車運維還沒有OPSDEV，全靠我們運維自己來做。

這是我們改造以後的網路架構，相當於是我們實際的部署。原來的架構裡面是防火牆，防火牆是放在這上面的。後來我們把防火牆放在這邊，就起一個VPN的作用，提供我們運維人員移動辦公的需要，以及VPN跟總部的VPN隧道打通，進行直接的互訪。

我們現在有9個機櫃，每一個機櫃裡面有個別的伺服器提供公網的訪問，其它伺服器的公網訪問全部都是通過內網核心進行資料互訪。

大家看到這邊的防火牆，我們現在可以做到什麼呢？只要通過防火牆連線到VPN，不光可以登入到內網核心交換機上管理內網所有的網路裝置，還可以從這邊連線公網交換機，對公網交換機進行管理。而且我們內部的監測系統是可以通過VPN設定，防火牆採集公網交換機的流量。

左邊是51汽車原來早期的前端應用叢集架構，後面是新的天天拍車應用叢集。

最開始做的時候在ISG上面配置了地址池，通過NAT對映的方式，請求轉發，當時還有一個高可用。LVS再把請求轉發到下面的虛擬機器上。邏輯架構是這樣的，但物理部署是怎麼部署呢？LVS這些東西全部是虛擬化的機器，除了資料庫，其它全是虛擬機器。再加上伺服器做了bond以後，我們的模式是mode 0，造成大量的資料包重傳。裡面的各種應用配置又沒有經過優化，大部分都是預設的。導致當時51汽車的網站經常掛。

後來重新做過以後把防火牆直接去掉了，用Haproxy來替換LVS，然後由OpenResty來實現負載均衡。Haproxy做4次的負載均衡，我們把VMware虛擬化，替換成KVM的虛擬化技術。

1、網路改造

• 移除防火牆

我們的網路改造做法是移除防火牆，把原來的防火牆全部下架。機櫃交換機原來是兩臺，因為裝置型號的更換現在是一臺。原來用的是H3C的企業網交換機，現在全是華為的資料中心交換機。這裡為什麼要由兩臺精減為一臺呢？當時我們發現早期人員在配置交換機時放兩臺是為了防止單點故障，必然要跟核心裝置之間全部建立連線。這個時候就是避免交換機的環路。兩個交換機之間要做互備，還要啟用VRRP協議。在很多時候我們設計網路架構下是避免生成資料協議的。

• 機櫃交換機由兩臺精簡為一臺

很多公司一般機櫃都不會很多，幾個、十來個已經挺不錯了。如果你的規模非常大，超過100臺交換機，這時如果你簽了協議，你的鏈路只要斷一條，整個網路就需要重新收斂，收斂的時間是以秒計。很多中大型的網際網路公司，如果生成樹協議引起了網路風暴，收斂時網路停止服務，幾秒鐘的時間肯定承受不了這樣的損失。

如果你們之前有去聽過京東的網路改造，他們當時也是遇上了這樣的情況。交換機是幾千臺、上萬臺，早期時就是使用生成樹協議，兩臺交換機做接入，一臺交換機的一個口出現故障，會導致業務中斷1、2個小時，其原因就是STP造成的。

• 調整交換機收斂比→6：5

我們調整了交換機的收斂比原來是24：1，後來調整為6：5。當時採購的交換機是24口的千兆交換機，每一個機櫃裡面放12臺伺服器，每臺伺服器有兩個網口跟交換機做聚合，理論上來說交換機伺服器產生的流量最大隻有24G。這樣我們的交換機收斂比就改了6：5，理論上是這樣說，我們的流量轉發是堵塞了，所以上線只有24G。只有我們設計時機櫃裡交換機收斂比小於等於1才可以進行流量的線速轉發。

• 接入：核心的兩層網路結構

我們希望架構的調整是使用接入核心的兩層網路和架構，把核心層和匯聚層結合在一起。

• 所有機櫃10G*2上聯到核心，起動態LACP

• 資料經過鏈路啟用巨型幀功能

每個機櫃的接入層使用這樣的網路結構：資料經過的全鏈路使用巨型幀，保證資料在傳輸時是正常的，如果你的交換機上沒有開啟巨型幀功能，你的伺服器沒有開啟PMTU探測的話就會造成伺服器訪問異常的。

2、伺服器硬體

• 按伺服器部署業務型別合理搭配硬體

硬體改造當時是28臺伺服器我都重新做了規劃，按照業務的不同做硬體的配置。比如說資料庫伺服器，用SAS加SSD的方案，使用Facebook Flashcache來做加速。現在公司裡面所有的資料庫叢集都是這樣放去做。

• 核心業務網絡卡由升級為intel i350

我們核心業務的網絡卡主要是為了負載均衡，還有所有跟資料有關的伺服器。全都升級為intelI350的網絡卡。

• 記憶體與CPU嚴格匹配

記憶體與CPU嚴格匹配，當時我們有一些伺服器，記憶體頻率是比較高的，但是與之對應的CPU並不支援那麼高，你雖然插上去可以用，但是系統一直提示報錯。為了防止以後不應該出現的奇葩問題，所以我們是把記憶體跟CPU進行了試配。

3、作業系統

作業系統這一塊兒我們做的是非常多，我們做了訂製化，而且深度訂製化。

• Kernel統一使用精簡過且重新生成的rpm包

第一就是我們kernel，我們把核心使用了2.6.32-431.29.2的核心，對核心重新做了調整。把一些伺服器上用不到的驅動模組全都進行剔除，比如說WIFI、紅外、藍芽、用不著的網絡卡驅動全都剔除，做一個精減，精減完了以後重新做成核心的安裝包。

• KickStart高度定製（網路部分）

因為要實現自動化安裝，所以必然要做KickStart，這塊我們也做高度訂製化。我們已實現了自動去配網絡卡，如果你看過紅帽官方的文件，KickStart裡面的章節是31章節，你就可以知道網絡卡直接可以配置成bond模式。

我們還在Kickstart裡面對SSH配置，還有DNS的配置，還有對於網絡卡硬體的配置。我們可以修改網絡卡的引數，傳送和接收都是可以更改的，我們也是在KickStart裡面做指令碼自動修改。

• 優化TCP/IP協議棧（TW、sysctl.conf）

優化TCP/IP的協議棧主要是視窗還有大小,調整TCP各種連線的超時時間。如果沒有經過核心的訂製，一般做架構或者你的應用訪問時伺服器上會產生TW連線，一般核心裡面預設是60秒的時間才會進行釋放。如果你的網站是高併發訪問量非常大的話，那你的連線基本上是釋放不乾淨的。所以我們做了一套直接修改核心的定義。從60秒修改成5秒。這樣可以讓自身的伺服器對外始終只有少量的TW連線。

• 預設關閉不必要的服務，關閉無關埠

把不必要的服務全部關掉，因為關閉了不必要的服務大部分埠也就被你關閉掉了。

• 剔除不需要的rpm包，保留效能分析工具、編譯工具

再接下來是刪除不需要的rpm。如果你們有仔細訂製過的話，就會發現有時候也挺坑的，會給你安裝很多用不到的軟體在系統裡，而且還給你開放一些埠。

• 所有開源元件定製化，動態連結庫不依賴作業系統（綠色版）

• 軟體安裝目錄、配置檔案目錄、日誌目錄、PID目錄標準化

再下面是所有的開源元件進行訂製化，我們的安裝目錄、配置目錄、PID檔案目錄、啟動指令碼都是做了定製的。需要你把軟體安裝到下面，方便管理。自己有源伺服器，會在上面把原始碼進行定製化的翻譯，再做成綠色軟體。不依賴於作業系統，我的軟體包如果是rpm包，只要是以rpm包管理的系統上隨便安裝，不依賴於動態軟體庫。

4、開源元件

這邊是開源元件做的升級還有引用的其他東西，我們每一個開源元件的變更都是有原因的。

• 4層負載均衡：LVS–àHaproxy

其中第一個負載均衡把LVS換成了Haproxy，大家去網上查的話應該有很多人寫過差別。當時換LVS是為什麼呢？第一，LVS雖然是非常高效能的轉發，網上人家說可以轉發100萬、200萬，這都是扯淡的。因為這些人在寫的時候並沒有告訴你他的網絡卡的頻寬，他測試時後端真實響應的資料多大。LVS在部署時它的機器的IP地址必須是同一網段的。如果你的公司業務非常大的話，你就要消耗非常非常多的公網IP，唯品會就是這樣做的。

LVS除了剛才說的原因，還有一個原因是不能靈活地進行配置，配置我們的虛擬主機，不能把CPU按照不同的業務運營的負載高低進行分配。LVS不能做什麼事情呢？不能動態地對配置進行修改，如果你要新增新的叢集的話你得修改配置檔案。再往大了說，如果用LVS跟OSPF配合使用的話，RealServer上就需要維護指令碼，進入51汽車時運維經常在配置指令碼時忘記執行，所以鑑於這些原因，當然還有一些其它的原因，使用起來並不符合我們的要求。

換成了Haproxy以後，可以根據業務的壓力不同，將CPU分配給壓力大的業務，有的人可能會用Haproxy，但是它就一個問題，不能將我們使用者真實的IP傳到後端。很多人會使用Haproxy的透明代理模式Tproxy模式，把使用者的真實IP上傳到後端，這跟LVS的機制幾乎是類似的。但是我們更換到Haproxy的1.5版本以後這上面預設之了proxy協議，我不再使用透明代理上傳客戶端的真實IP，使用varnish寫在日誌裡面做分析。

• 頁面快取：Varnish 3.0 —à  Varnish 4.1

頁面快取原來用的是varnish3.0的版本，後來升級到varnish4.1。因為它在做資料連線時很容易產生CLOSE-WAIT連線，它連線的釋放是有問題，你的記憶體有多大就一直消耗。大家知道做TCP連線的記憶體是不可交換的記憶體，不能使用交換分割槽。

• 反向代理：Nginx–àTengine–àOpenResty

早期反向代理用的很多版本後來我們使用Tengine，為了統一技術體系就使用了它。但是在去年下半年時我們發現Tengine的很多公司已經跟不上Nginx了，很多技術Tengine雖然支援但是有很多問題。後來用下來，包括日誌的過濾，相信大家有很多這種需求，比如說你的網站，你主要的運維下面可能會加一些JS、CSS，如果你不開始過濾的話會希望把訪問日誌全部寫到日誌裡面，不方便你去進行日誌的分析。如果我只去過濾我主要的請求，那我就需要使用日誌過濾，而那個時候Tengine2.1.2裡面根本沒有，只能使用第三方的模組。第三方的模組功能我要去用時，我發現Nginx早就實現了，可以做一些變數的對映，應用到我們的指令裡面就可以進行過濾，非常方便。我們更換了Opneresty，更換它的原因還有什麼呢？因為微博開發了一個模組是Opneresty，可以進行增加和產出，而Tengine不支援模組，所以沒有辦法，我們只能更換Opneresty。而且Opneresty又支援別的模組所以我們就直接更換了。

• 虛擬化技術：VMWare —à Proxmox(kvm)

虛擬化技術把vmware更換為KVM，直接使用了開源的Proxmox，目前小的網際網路公司也在用。做虛擬化非常簡單，運維開發時可以進行系統研發。

• 物件快取：Memcached–àRedis

物件快取，我們把Memcached替換成Redis。現在的快取也不是什麼資料都往Redis裡面放，Redis裡面只做資料對應關係的快取。不像以前Memcached裡面，不光存快取，還有很多亂七八糟全都存。後來Memcached經常出現失敗，原因就是因為快取的非常大，超過1M。Memcached預設是1M這是1.4.21版本之前。

• 圖片儲存：NFS–àFastDFS–àTFS

圖片儲存對51汽車來說是最頭疼的事情。最早是用NFS來搭建的，而且是兩臺。我去的時候NFS 6T空間用的不到500G，訪問一些圖片時非常非常慢，慢到什麼程度呢？假如說你在一個圖片庫下要執行的話會卡住，大家知道某一個目錄下面存在了上千萬張圖片時，怎麼才能最快速度地把圖片給列出來？這個是非常小的技巧，就是用LS命令在執行的時候把色彩引數給去掉，或者直接dir命令。

NFS用得非常頭大，所以我們使用了FastDFS，因為它非常的輕量。可後來我們為什麼又替換了FastDFS呢？因為擴容時必須以group單位進行擴容，如果單位超過16個單位怎麼辦？當你的FastDFS上的硬碟是獨立的模式，如果一臺戴爾的730XD可以插14塊硬碟，當硬碟再多時你會發現掛載時你在Nginx做配置，這個零零你們猜是10進位制還是16進位制，這個資訊FastDFS的作者從來沒有說過，作者說這個地方只能是16進位制的，M00到MFF，就踩了這麼一個坑，後來發現它在擴容時真的不方便，因為我以前用過TFS，所以建議我們老大換TFS。

TFS可以做什麼呢？動態進行了擴容，我們現在是5臺TFS DS，當容量不夠的時候只需要往裡面增加機器就可以了，每增加一臺機器，原來5臺的機器資料就可以做負載，增加到新的機器上，這個擴容是非常容易的，比起FastDFS的擴容簡單的多，FastDFS的擴容每次絕對是兩個伺服器。

• 資料庫：MySQL–à Percona

伺服器我們用的是MySQL，後來我們全部統一替換成Percona。原因是它裡面的功能做了增強，對於一些空閒的事物做了控制，庫裡面的資料可以拿出來，在下次資料啟動時可以進行熱載入。

• 資料庫讀寫分離：程式碼實現–à OneProxy

唯品會也用過，但他們做了修改。13.0使用的一種方式，但是大部分的公司肯定不會投入這麼大的精力。很多人只能說兩臺放在那裡做高可用，結果到只要你的資料庫連線庫超過800就開“死”。發現它已經發布的版本跟下一個版本的文字表述是有差異的，會讓我們踩到坑。程式碼裡面並沒有寫名，這個配置1.4的版本是這樣的，在1.5的版本是那樣的，但是並沒有寫名，原始碼的註釋裡面寫的，一路坑。後來沒有辦法我們又上了Oneproxy，自從用上了這個，我再也沒有關心過資料庫的問題，基本上資料庫沒出現過問題，使用這個根本不用在資料庫伺服器上查詢，通過Onepoxy我們可以直接看到業務過來的時候哪些執行時間非常高，哪些執行時間非常長，現在都不需要上伺服器。包括我們的研發，現在都很主動、自覺地等到Oneproxy。

• 引入RabbitMQ並且實現叢集化

原來我們寫入資料庫時，當你訪問量大時資料庫寫壓會比較大，我們引用了RabbitMQ，RabbitMQ很多公司也要用。做叢集必須要注意一點，就是連線。節點之間必須配置長連線，如果沒有長連線的話你的應用裡面經常會報錯，這個我們原來是碰上了。做除錯實現了超連線。當然是TCP的而不是HTTP。

• 引入業務內網DNS系統：PowerDNS

再下面是引入了業務內網DNS系統，我們之前用的東西是非常低效，我剛去時程式碼連線的資料庫存全是用的IP，只要用一遍，應用就要修改、重啟，很麻煩。我並沒有用棒的東西，雖然現在有外掛，但是還是需要修改的方式，我當時覺得這個東西肯定不是高效的。我使用了的話沒有辦法進國內網的DNS系統進行匹配。

現在如果有新的機器要開或者有運維的變化，會通過我們的運維訪問工具直接上資料庫裡面去寫資料就可以了，不是很忙的時候可以通過PowerDNS的資料包進行修改。我們會通過格式匯出來，匯出來的檔案會下發到所有的機器上面，讓面還部署了PowerDNS的解析器，每一臺訪問的是賓機的PowerDNS的解析器。不管我們PowerDNS的認證器掛不掛，我都可以保證在解析方面不會出現任何錯誤的。

• 構建資料備份叢集：LizardFS(MFS)

資料庫的備份叢集使用了分散式檔案系統，MFS大家應該比較熟悉了，比較常見了。就是MooseFS。我們並沒有使用官方的，而是使用了這個，MooseFS的衍生版，它能做什麼呢？它實現了MooseFS的影子版，備份資料庫的資料。這個指令可以在被動服務商上使用，通過其它叢集的Moos，方便我做資料的任意節點的恢復。

• 引入Rundeck作為程式碼釋出任務的平臺

再下面發程式碼，我們使用了Rundeck，很多公司是可以自己做程式碼釋出平臺，就是通常所說的自動化運營平臺。我們因為沒有，所以使用這種Rundeck方式，這個可以建議大家使用一下，非常方便。

• 引入Kong作為API Gateway

最後是API閘道器，我們引入了開源的Kong作為API訪問閘道器，這個主要是做手機APP用的，為什麼使用它呢？原因是在於Kong的底層使用的就是Opneresty。這是我們2015年到2016年整個的改造，實現了釋出程式碼的分秒級。資料庫再也沒有操過心，虛擬化也沒有操心，我現在基本上不做原來以前一線的運維，現在主要做架構。

這個圖是我們剛才說的DNS系統的。這是是MQ叢集的結構，兩個記憶體節點加一個磁碟節點。這個是TFS的叢集，如何向我們的應用提供服務。

三、未來的展望

1、網路架構

今年我們準備即將要做的事情，第一個就是網路。網路這一快寫準備把介入層裝置華為的CE交換機並升級為2臺，使用華為的網路裝置虛擬化技術，Stack技術，把兩臺裝置虛成一臺裝置。可以提供給冗餘。

主要是為我們的技術網路做鋪墊，我們現在已經準備部署了，但是網路端並沒有使用Vxlan，因為這是非常重要的事情，使用Vxlan坑太多。

2、構建日誌採集分析平臺

第二個是構建日誌採集分析平臺，我們的分析平臺跟網上人家講的ELK完全是不一樣的，我們不使用ELK，而是使用了V8，V8版本是可以做模板定製，收集日誌是GRaylog，非常方便。

3、非核心業務Docker化

這是我們即將馬上實施的Docker方案。

4、Web業務前段技術驗證

第四個是技術認證，通過ECMP+HAproxy可以實現百萬併發，如果你們去買過京東技術解祕，京東目前就是用了這樣的方式。

5、運維其他方面

再接下來是其它的輔助。首先是運營平臺的建設、資產管理、VPN。然後，實時效能的分析大家都瞭解過，我們準備使用開源。

第三就是Zabbix+OneProxy的分庫分表設計，資料庫的效能單採用的效能是撐不住的，需要做分表，這一塊兒我們是非常熟悉的。而且新浪微博也使用Zabbix做資料庫。

第四是GlusterFS深入研究和叢集化。我們現在使用的換並沒有做叢集，我們做叢集化實踐考慮是跟這個有關，GlusterFS。

第五是OVS-DPDK，如果你們公司採用Docker的話這塊東西是必然跑不掉的。我們為什麼要去研究？主要是因為DPDK環境下可以實現單機網絡卡效能的最大化。

Q&A

Q1：我是一個做網站的，將來想做大型的網站，但我不是網管，你說的都是網管的事情，跟我們不相關。

A1：絕對不是網管做的，公司必須要有專門的運維團隊。

（接上問）

Q2：絕對不是做網站的程式設計師管的事情嗎？

A2：很多公司都是由寫程式碼的人區別做的，當你的網站有一定規模時必須要有專門的運維團隊。

Q3：我問一個比較low的問題，我對防火牆的理解不是特別深，我也是搞開發的。看到你們把防火牆拿掉了，會不會有安全性的問題？

A3：如果你的伺服器能把大部分的關口給關閉了，你的伺服器不得不開放公網時，你在啟動時必須加上監聽IP，要監聽在內網IP上，不要監聽在0.0.0.0上。你只要把不需要的服務給關閉掉，基本上可以解決80%的安全問題。

防火牆真的能防護你嗎？防不住，傳統的放火牆並不能幫你處理一些基層的處理，你要做策略是做不了的。傳統的防火牆做不了這件事的，只有應用服務牆是專門做的。但凡設計到硬體有一個最大的問題，不易擴充套件。

如果你今天買一個30萬的防火牆在那裡，你怕它出問題得買兩臺，60萬，你的網站如果流量非常大到像餓了麼那種流量爆發式的增長，那你得加裝置你買新的裝置，你一買就得是2的倍數，而且最快也要一週，你的網站連續掛一週能接受嗎？不能接受。

（接上問）

Q4：別人用拼的放或者搞肉雞搞你的網站呢？

A4：這個時候雲防火牆有非常大的用處，基本上使用雲防火牆做處理。拼不了你還有一種方式是說在小流量的攻擊下面，一般讓想到是用IPT，建議不要用這種。使用推動路由，你可以把攻擊者的IP路由指向了LO環回介面這就是簡單的黑洞物流。如果你做防火牆規則的話還得消耗資源。所以我們公司的所有伺服器上IPT都是關閉的，不開放。

文章來自微信公眾號：DBAplus社群