應用交付控制器（ADC）如何在架構方面更好地適應云計算？是公有云提供商還是用戶自身應該對云中ADC行使控制權？本文為你提供了中肯的建議。

應用交付控制器(ADC)對于數據中心的流暢運行十分關鍵，它提供了包括服務器負載平衡、監控服務器和應用健康、保護數據中心免遭分布式拒絕服務(DDOS)攻擊、執行SSL加解密等關鍵功能。通過管理連接、運行專用應用腳本和提升應用速度，應用交付控制器可提高服務器運行效率。ADC就如同粘合劑一樣，將數據中心網絡和應用層粘合在一起。

即便應用轉向公有云，它們仍然需要使用ADC所提供的所有服務。如果在轉向公有云時不使用關鍵的ADC功能，應用和服務將處于風險之中。以下敘述基于這樣的情況：在使用混合云解決方案時，應用的一部分位于云上，另一部分則位于企業數據中心上。

二層架構各有所長

在公有云上，ADC的最佳架構是雙層結構，ADC的功能大致被分為兩個層此。第一層由公有云提供商提供，負責處理服務器負載平衡(SLB)，將不同的客戶流量定向至運行應用的虛擬服務器群上。

這是一個基本的SLB功能，它并沒有根據服務器負載和延時等因素對定向流量進行進一步細化。云服務提供商的ADC僅是將流量轉向至支持應用的虛擬機群上。云提供商的ADC是抵御攻擊者的第一道防線，同時，這一層的ADC還負責執行SSL加解密功能。

除了提供認證服務外，ADC還能夠對流量進行壓縮或解壓縮，但是這需要與客戶進行協調。由于第一層的ADC保護云數據中心免遭攻擊，因此常常被稱之為"看門狗"ADC。同時由于它監視著整個云網絡，因此也被稱為網絡ADC。

硬件解決方案是第一層ADC的最佳方案，因為這層ADC需要最高的性能以處理大流量負載。SSL處理在專門的硬件中能夠被很好地執行，而只有硬件ADC才能勝任這一任務。在ADC發展初期，SSL處理是在軟件中進行的，但是業內很快就發現隨著流量的增加，軟件解決方案無法跟上發展步伐，同時延時程度也變得無法接受。此外，硬件解決方案具有足夠的實力，來擊退大型DDoS攻擊，并執行看門狗功能。

第一層ADC不執行其它的ADC的功能存在著多個原因。其中，性能是最主要的因素。看門狗ADC需要集中性能以定向流量、執行SSL，應對應用攻擊。運行單個客戶的腳本等額外功能，會導致ADC速度下降，并且會占用原本用于執行看門狗功能的性能。對不同客戶腳本間的相互作用的顧慮也是一個因素。運行客戶腳本將導致變化控制和問題處置復雜化。此外，將不同的客戶目標緩存在相同的ADC上將產生安全漏洞。出于這些原因，第一層ADC應當將性能集中在幾個關鍵應用上，將客戶的具體任務留至下一層進行處理。

第二層ADC也被稱為租戶ADC，它位于特定客戶的虛擬機和應用前端。所有客戶的應用既可以共有一個ADC，每個應用也可以單獨有一個ADC。第二層ADC主要負責執行具體的SLB功能，負責根據實時反應時間和負載等情況為單個虛擬機提供負載平衡，還向企業反饋服務器的健康信息。在執行諸如目標緩存和服務器卸載等應用加速功能的同時，第二層ADC還負責運行應用特定腳本。同時，它也是抵御攻擊的第二條防線。

一個ADC僅負責一個客戶或一個應用，在執行上述功能時具有一些優勢。其中最大的優勢在于可以讓客戶控制ADC。企業能夠控制腳本升級的時機，如果當中出現問題，企業能夠迅速進行補救。第二層ADC還可將客戶或應用相互隔離起來。在ADC失效的情況下(例如，當應用被遷移至其他的云提供商那里，所有的緩存信息消失時)，其可提供更高的安全性，。

企業可能希望第二層ADC能夠與他們數據中心的ADC匹配。其實，第一層的ADC的品牌是否和企業自己使用的ADC品牌相同并不重要。原因在于，第一層ADC對于企業來說是透明的，并且僅僅執行一些通用功能。第二層ADC則不同，其品牌最好與企業使用的ADC品牌相同，因為這樣可以簡化整合和運行工作，同時腳本能夠從企業數據中心的ADC無縫地流向云。盡管企業使用的ADC品牌與第二層ADC品牌是否相同并不是必須的，但是保持品牌的一致性還是一個值得考慮的問題。

第二層ADC的控制權之爭

云提供商已經開始在他們的服務列表中將第二層ADC作為一種額外的服務選項。客戶可選擇包括：在單獨的服務器或者虛擬分區的服務器上運行軟件ADC，專門的硬件ADC，或是在硬件上ADC隔離出來的分區。目前，專門的硬件ADC僅有為數不多的幾個廠商可提供，因為準備不同品牌的ADC將使得云提供商的運營復雜化，同時費用也非常昂貴。

目前日益普及的選擇是使用在服務器上運行的軟件ADC。這一選擇允許云提供商在性能和廠商品牌方面提供更多的可能。目前提供這一虛擬化選項的主要ADC廠商包括A10、Array、思杰、Coyote Point、F5、Kemp、Radware，以及通過收購Zeus 加入這一市場的Riverbed。博科也計劃在2012年上半年推出其軟件ADC產品。

目前在第二層ADC上使用軟件ADC并不存在重大缺陷。因為在第二層ADC所負責的任務并不涉及重大性能問題。所有的ADC廠商都聲稱性能不是問題，同時所有的證據也表示這似乎是可信的。

目前還不清楚云提供商是否將提供豐富的ADC解決方案品牌。他們很可能僅提供一些受市場青睞的廠商的解決方案。此外，目前也不清楚他們將允許在第二層ADC上向企業提供多大程度的定制，以及他們將向企業轉交多少ADC控制權。

對選項和控制權進行限制的問題將催生出另一個選項--"帶來你自己的"(Bring Your Own) ADC選項。企業將他們在自己數據中心上使用的軟件版ADC作為一個應用遷移到公有云的虛擬機上。這一選項可讓企業徹底地控制第二層ADC，同時允許企業讓云ADC適應由眾多ADC廠商提供的全球負載平衡功能，以及部署他們已有的定制服務。目前的主要問題是企業如何讓自己的ADC適應公有云提供商的基礎設施。

盡管云提供商可能更喜歡客戶選擇他們服務列表中的選項，但是他們也會通過克服技術配置問題允許客戶"帶來自己的"ADC。在簽署協議前，應當確認云提供商允許客戶帶來多少"自己的ADC"。

在選擇第二層ADC時應當參考以下幾個標準。首先，在為你的數據中心選擇一個ADC時應當全面考慮這些標準。不要想當然地以為軟件ADC與硬件ADC有著相同的功能。盡管確實許多軟件ADC與硬件ADC不相上下，但是這一點并無法保證。此外，ADC的性能應當容易擴展。許多軟件ADC在性能上低于它們的硬件版本，在使用云時應當考慮到吞吐量的影響。如果不清楚所需要的吞吐量，那么應當尋找能夠很容易擴展為更大吞吐量的解決方案，并了解成本與吞吐量間的關系。

云中ADC "公""私"皆宜

選擇公有云提供商的一個標準是，應當清楚他們部署ADC架構的情況，以及能否很容易地與企業自身的ADC需求整合在一起。ADC并不是"可有可無"的，而是支持企業應用的關鍵因素。

針對公有云的ADC架構基礎知識同樣適用于私有云，尤其是大型數據中心。雙層解決方案為數據中心擴展提供了更高的靈活性。將每個應用腳本隔離在專用的ADC中，可以讓確定問題根源所在和升級變得更加容易。對于公有云和私有云來說，雙層解決方案代表著ADC架構的未來發展趨勢。