從臨危授命到扭轉乾坤，天天拍車運維架構演進及實踐

李強 2017-04-24 11:52:24

本文根據李強老師在〖4月8日DBAplus社群上海數據庫技術沙龍〗現場演講內容整理而成。點擊文末鏈接還能下載PPT哦~

 

講師介紹  

李強

天天拍車運維總監

 

• 網名：撒加，先後在AdMaster、餓了麼擔任運維經理，現任天天拍車運維總監，主要負責天天拍車運維架構的管理、持續優化以及運維團隊的建設、培養。

• 9年以上運維及管理經驗。作為國內最早一批思科網絡模擬器的推廣者、虛擬化先鋒論壇的創始人，一直致力於網絡模擬器使用的推廣，為國內培養網絡工程師盡一份力。

 

分享大綱：

1. 架構改造的動力

2. 運維架構詳解

3. 未來的展望

 

一、架構改造的動力

 

大家好，我是天天拍車的運維總監李強，今天給大家分享一下天天拍車的運維架構的演進以及實踐。我們公司前身是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

 

數據庫原來是在DevOps應用裏麵使用代碼實現的，我增加服務器的話，所有應用的配置文件必須做，否則沒法用，後來我們使用了Oneproxy，在使用這個之前我們首選還是開源。我們在側環境用的時候一點問題都沒有，一上線早上9點鍾線到10點鍾全網全掛了，查問題最終查到什麼呢？我們的應用連不上數據庫，但是登上去看的時候數據庫是連上後來跟用戶交流的時候，發現它的數據特別容易造成假死。

 

 

唯品會也用過，但他們做了修改。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都是關閉的，不開放。

原文發布時間為：2017-04-24

本文來自雲棲社區合作夥伴DBAplus