毫無(wú)疑問(wèn)IT技術(shù)和基礎(chǔ)架構(gòu)在過(guò)年幾年當(dāng)中實(shí)現(xiàn)了快速發(fā)展。而網(wǎng)站系統(tǒng)也已經(jīng)從最初的“腳本和文件的簡(jiǎn)單組合”發(fā)展成為“由可重用代碼組件構(gòu)成的復(fù)雜模塊化應(yīng)用系統(tǒng)”——所有網(wǎng)站都在使用HTTP，其已經(jīng)成為互聯(lián)網(wǎng)通信的主要協(xié)議。各種各樣的Web應(yīng)用已經(jīng)完全融入到人們的生活當(dāng)中。用戶期望獲得響應(yīng)速度快、性能良好并且能夠在所有設(shè)備上流暢運(yùn)行的應(yīng)用程序。

盡管我知道很多工程師都認(rèn)為這是一件令人興奮的事情，但是同時(shí)我也知道很多技術(shù)經(jīng)理敏銳地意識(shí)到技術(shù)的快速發(fā)展以及用戶不斷提升的期望值所帶來(lái)的全新挑戰(zhàn)。而在所有這些挑戰(zhàn)當(dāng)中，管理權(quán)限是一個(gè)非常突出的問(wèn)題。我們?cè)趯鹘y(tǒng)基礎(chǔ)架構(gòu)遷移到更加流暢的web架構(gòu)方面已經(jīng)取得了很大進(jìn)步，但是仍然在使用傳統(tǒng)方式來(lái)分配控制權(quán)限。這就能夠解釋為什么現(xiàn)在很多公司當(dāng)中，網(wǎng)絡(luò)團(tuán)隊(duì)依然控制著應(yīng)用程序交付流程——而不是那些負(fù)責(zé)開(kāi)發(fā)應(yīng)用程序、并且加速其性能的DevOps工程師。顯而易見(jiàn)，這種權(quán)限分配方式并不合理。

下面的情況是否聽(tīng)起來(lái)十分熟悉？也許你也曾經(jīng)在自己的企業(yè)當(dāng)中遇到過(guò)類(lèi)似的問(wèn)題。如果真的是這樣，那么是時(shí)候思考應(yīng)該如何避免這些由控制和問(wèn)責(zé)機(jī)制失衡所導(dǎo)致的矛盾和沖突了。

也許你是一位開(kāi)發(fā)人員，現(xiàn)在想要為某個(gè)應(yīng)用程序添加或者修改訪問(wèn)控制列表（ACL）以提升系統(tǒng)安全性；或者想要臨時(shí)將流量重定向到另外一臺(tái)備份服務(wù)器。現(xiàn)在你需要做的不是思考應(yīng)該如何自己完成這項(xiàng)任務(wù)，而是認(rèn)真地準(zhǔn)備一份相關(guān)申請(qǐng)，之后提交給網(wǎng)絡(luò)運(yùn)維團(tuán)隊(duì)。（由于他們很有可能需要處理企業(yè)當(dāng)中的所有請(qǐng)求）因此你必須等待他們找到合適的時(shí)間來(lái)處理你的請(qǐng)求。

當(dāng)然，如果你總是向他們提交申請(qǐng)，那么最終他們可能會(huì)為你分配一些簡(jiǎn)單的控制權(quán)限，因?yàn)樗麄冃枰幚砥渌ㄍǔＪ歉又匾模┤蝿?wù)。但是如果在你操作過(guò)程當(dāng)中系統(tǒng)出現(xiàn)故障導(dǎo)致無(wú)法訪問(wèn)，那么無(wú)疑你將會(huì)成為那個(gè)被責(zé)備的對(duì)象。導(dǎo)致系統(tǒng)故障的原因很多，可能只是由于某個(gè)廠商設(shè)備的ACL具有默認(rèn)的“隱式拒絕”規(guī)則，而你忘記顯式放行特定流量，也或者你沒(méi)有搞清楚“反向掩碼”，還或者將ACL錯(cuò)誤地應(yīng)用到其他接口上了。因此，不論對(duì)于開(kāi)發(fā)人員還是網(wǎng)絡(luò)團(tuán)隊(duì)來(lái)說(shuō)，這種方式都不是一種好的解決方案。

大部分情況下，網(wǎng)絡(luò)團(tuán)隊(duì)掌握應(yīng)用程序交付控制權(quán)是因?yàn)楫?dāng)前環(huán)境使用了基于硬件的應(yīng)用程序交付控制器。但是這些集中式應(yīng)用程序交付解決方案由于潛在的單點(diǎn)故障問(wèn)題而變得非常脆弱。除了脆弱性之外，還需要思考被分配過(guò)多任務(wù)的網(wǎng)絡(luò)團(tuán)隊(duì)如何快速構(gòu)建和部署應(yīng)用程序，這無(wú)疑是一種并不穩(wěn)妥的做法。

企業(yè)當(dāng)中的開(kāi)發(fā)人員數(shù)量通常大大超過(guò)網(wǎng)絡(luò)工程師的數(shù)量。我們經(jīng)常能夠聽(tīng)到一家擁有數(shù)百個(gè)虛擬化服務(wù)器實(shí)例、數(shù)十種應(yīng)用程序的企業(yè)擁有100個(gè)人的DevOps團(tuán)隊(duì)——但是同時(shí)也許只有兩個(gè)網(wǎng)絡(luò)工程師在管理多個(gè)部署在私有云當(dāng)中的應(yīng)用程序交付控制器。顯而易見(jiàn)，網(wǎng)絡(luò)團(tuán)隊(duì)很難同時(shí)處理多項(xiàng)web加速任務(wù)，而且他們同樣擔(dān)心將過(guò)多的應(yīng)用程序邏輯引入到網(wǎng)絡(luò)環(huán)境當(dāng)中。

此外需要記住的是，高速網(wǎng)絡(luò)并不一定總是意味著應(yīng)用程序的良好表現(xiàn)。配置命令當(dāng)中的潛在沖突或者網(wǎng)絡(luò)設(shè)備當(dāng)中的錯(cuò)誤腳本都有可能導(dǎo)致問(wèn)題的發(fā)生。事實(shí)上，向網(wǎng)絡(luò)團(tuán)隊(duì)不停發(fā)送配置變更請(qǐng)求所能夠得到的唯一結(jié)果就是抱怨的逐漸加深。

另外一種不和諧因素的來(lái)源是應(yīng)用程序系統(tǒng)工程師使用的現(xiàn)代敏捷開(kāi)發(fā)過(guò)程。使用這種方式之后，開(kāi)發(fā)人員不能在開(kāi)發(fā)完一款產(chǎn)品之后將其交付給其他人進(jìn)行部署和維護(hù)；敏捷開(kāi)發(fā)過(guò)程需要?jiǎng)?chuàng)建迭代，之后部署，一直重復(fù)這個(gè)循環(huán)。而這個(gè)循環(huán)要求開(kāi)發(fā)人員擁有全部、端到端的控制權(quán)限，這樣才能夠避免大量http傳輸可能產(chǎn)生的系統(tǒng)性能和可擴(kuò)展性問(wèn)題。然而協(xié)商各個(gè)部門(mén)任務(wù)分工的過(guò)程無(wú)疑會(huì)延緩開(kāi)發(fā)人員的工作進(jìn)度，并且開(kāi)發(fā)人員難以更改系統(tǒng)配置以提升系統(tǒng)性能。

那么DevOps工程師應(yīng)該如何解決這些問(wèn)題呢？其應(yīng)該想辦法獲得web加速和應(yīng)用程序性能方面關(guān)鍵功能的管理權(quán)限，同時(shí)仍然滿足企業(yè)對(duì)于性能和安全方面的需求。

而壞消息是，你不能使用任何10或15年之前推出的工具，這些工具針對(duì)大型、古老的獨(dú)立應(yīng)用程序（同時(shí)對(duì)于消費(fèi)者和企業(yè)來(lái)說(shuō)）而開(kāi)發(fā)，因此并不適用于現(xiàn)代的分布式、松耦合以及組件化的應(yīng)用程序。而網(wǎng)絡(luò)工程師也不能幫助開(kāi)發(fā)人員解決HTTP的復(fù)雜性問(wèn)題，他們的注意力仍然在網(wǎng)絡(luò)設(shè)備硬件方面，主要關(guān)注數(shù)據(jù)包，而不是應(yīng)用程序。

等一下，也許你會(huì)想使用NFV（Network Function Virtualization）來(lái)解決這個(gè)問(wèn)題怎么樣？這是一種可行——但是只適用于部分情況——的解決方案。首先，其主要提供2層、有時(shí)是3/4層的功能，而和第7層相關(guān)的功能還沒(méi)有被完全開(kāi)發(fā)。NFV和SDN的另外一個(gè)問(wèn)題是，目前為止，其只解決了商業(yè)網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的問(wèn)題，而無(wú)法應(yīng)對(duì)如何在DevOps環(huán)境當(dāng)中如何管理完整第7層環(huán)境的挑戰(zhàn)。企業(yè)需要尋找一種解決方案，合理地對(duì)層級(jí)權(quán)限進(jìn)行管理。網(wǎng)絡(luò)團(tuán)隊(duì)需要控制3和4層，而DevOps工程師需要第7層的控制權(quán)。

最后同樣重要的是，大多數(shù)應(yīng)用程序框架都沒(méi)有提供良好的方式來(lái)快速和輕松解決HTTP的固有復(fù)雜性問(wèn)題——比如并發(fā)處理、安全、訪問(wèn)控制等——以及應(yīng)用層流量管理。

那么究竟應(yīng)該如何解決這種問(wèn)題呢？網(wǎng)絡(luò)或者應(yīng)用程序框架都不能在端到端web加速方面起到真正的幫助作用，是否存在相關(guān)軟件能夠解決這種矛盾關(guān)系，完全滿足DevOps的全部需求？

幸運(yùn)的是，答案是肯定的。現(xiàn)在有很多非常有用的工具，能夠提供HAProxy、負(fù)載均衡或 SSL termination等功能，而另外一些產(chǎn)品（比如我們自己的NGINX Plus）能夠提供所有主要功能，比如應(yīng)用層負(fù)載均衡、請(qǐng)求路由、應(yīng)用程序內(nèi)容交付、web緩存、SSL termination、即時(shí)壓縮、協(xié)議優(yōu)化等。

這些DevOps工具的配置方式遵循“應(yīng)用程序風(fēng)格”，能夠很好地兼容Puppet或Docker等其他工具所提供的自動(dòng)化功能。此外，其還能夠被輕松部署到云環(huán)境當(dāng)中，在虛擬化環(huán)境當(dāng)中高效運(yùn)行，并且和應(yīng)用程序協(xié)同工作，最終成為應(yīng)用程序的一部分。同時(shí)，這些產(chǎn)品擁有和網(wǎng)絡(luò)硬件設(shè)備相同、甚至更好的性能表現(xiàn)，在低成本投入的情況下?lián)碛袩o(wú)限制的吞吐量。

最后，也許是最重要的一點(diǎn)，其還能夠?yàn)镈evOps團(tuán)隊(duì)提供期望已久的針對(duì)HTTP性能和可擴(kuò)展性的端到端控制權(quán)限。

決定使用DevOps工具之后，下一步就是思考如何使用其滿足當(dāng)前需求了。DevOps和網(wǎng)絡(luò)基礎(chǔ)架構(gòu)團(tuán)隊(duì)可以融洽相處，并且更加高效地合作，如果應(yīng)用層功能由基于軟件的可擴(kuò)展層實(shí)現(xiàn)——完全由DevOps團(tuán)隊(duì)進(jìn)行創(chuàng)建和管理——而像數(shù)據(jù)包傳輸、QoS以及其他傳統(tǒng)網(wǎng)絡(luò)功能仍然交給網(wǎng)絡(luò)基礎(chǔ)架構(gòu)團(tuán)隊(duì)進(jìn)行管理。

誰(shuí)能夠從中受益？所有人。開(kāi)發(fā)團(tuán)隊(duì)可以從順利運(yùn)營(yíng)、快速配置和部署以及更加簡(jiǎn)化的應(yīng)用程序開(kāi)發(fā)流程當(dāng)中受益。而網(wǎng)絡(luò)團(tuán)隊(duì)的負(fù)擔(dān)減少，能夠更好地控制其所需要管理的領(lǐng)域，同時(shí)將集中精力于自身工作。用戶受益于更好的應(yīng)用程序使用體驗(yàn)。最終，公司也能夠從高效交付高性能應(yīng)用程序以及滿足市場(chǎng)預(yù)期等方面獲益。

我們推薦用戶嘗試使用這種基于軟件的解決方案，查看應(yīng)用程序速度和效率的提升情況以及團(tuán)隊(duì)成員是否對(duì)其感到滿意。企業(yè)現(xiàn)在可以免費(fèi)試用NGINX Plus以替換現(xiàn)有的基于硬件的應(yīng)用程序交付控制器，或者聯(lián)系我們，更好地了解NGINX如何幫助企業(yè)以一種DevOps友好的方式交付高性能、安全、可靠和可擴(kuò)展的應(yīng)用程序。