溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
原文地址：https://martinfowler.com/articles/serverless.html
作者：Martin Fowler, Mike Roberts
??到目前為止，我們一直試圖只定義和解釋無(wú)服務(wù)器架構(gòu)的含義?，F(xiàn)在我將討論這種設(shè)計(jì)和部署應(yīng)用程序方法的一些優(yōu)點(diǎn)和缺點(diǎn)。你絕對(duì)不應(yīng)該在沒有充分考慮并權(quán)衡利弊的情況下使用無(wú)服務(wù)器架構(gòu)。
??讓我們從彩虹和獨(dú)角獸的國(guó)度開始，看看無(wú)服務(wù)器架構(gòu)的好處。
??在最簡(jiǎn)單的情況下，無(wú)服務(wù)器架構(gòu)是一個(gè)外包解決方案。它允許你花錢請(qǐng)人來(lái)管理服務(wù)器、數(shù)據(jù)庫(kù)，甚至你自己管理的應(yīng)用程序邏輯。由于你使用了許多其他人也將使用的預(yù)定義服務(wù)，因此我們看到了規(guī)模效應(yīng)的經(jīng)濟(jì)性:因?yàn)橐粋€(gè)供應(yīng)商正在運(yùn)行數(shù)千個(gè)非常類似的數(shù)據(jù)庫(kù)，所以你為托管數(shù)據(jù)庫(kù)支付的費(fèi)用較低，。
??降低的成本給你帶來(lái)的收益來(lái)自兩個(gè)方面：第一個(gè)是基礎(chǔ)設(shè)施成本收益，它純粹來(lái)自于與他人共享基礎(chǔ)設(shè)施(如硬件、網(wǎng)絡(luò))；第二個(gè)是人工成本收益，你可以花更少的時(shí)間在外包的無(wú)服務(wù)器系統(tǒng)上，而不是花在自己開發(fā)和托管的同等系統(tǒng)上。
??但是，這種好處與你從基礎(chǔ)設(shè)施服務(wù)(IaaS)或平臺(tái)服務(wù)(PaaS)中獲得的好處并沒有太大的不同。但是可以通過無(wú)服務(wù)器架構(gòu)的BaaS和FaaS來(lái)擴(kuò)展這一優(yōu)勢(shì)。
??IaaS和PaaS的前提是服務(wù)器和操作系統(tǒng)管理可以商品化，而BaaS則是整個(gè)應(yīng)用程序組件商品化的結(jié)果。
??身份驗(yàn)證就是一個(gè)很好的例子。許多應(yīng)用程序編寫自己的身份驗(yàn)證功能，這些功能通常包括注冊(cè)、登錄、密碼管理和與其他身份驗(yàn)證提供者的集成等功能?？偟膩?lái)說(shuō)，這種邏輯在大多數(shù)應(yīng)用程序中都非常相似，像Auth0這樣的服務(wù)已經(jīng)被創(chuàng)建，它允許我們將已經(jīng)構(gòu)建好的身份驗(yàn)證功能集成到應(yīng)用程序中，而無(wú)需我們自己開發(fā)它。
??BaaS數(shù)據(jù)庫(kù)也是同樣道理，比如Firebase的數(shù)據(jù)庫(kù)服務(wù)。一些移動(dòng)應(yīng)用程序團(tuán)隊(duì)發(fā)現(xiàn)，讓客戶端直接與服務(wù)器端數(shù)據(jù)庫(kù)通信是有意義的。BaaS數(shù)據(jù)庫(kù)刪除了大量的數(shù)據(jù)庫(kù)管理開銷，并且提供了對(duì)不同類型的用戶執(zhí)行適當(dāng)授權(quán)的機(jī)制，這與無(wú)服務(wù)器應(yīng)用程序的模式相同。
??根據(jù)你的實(shí)際情況，這些想法可能會(huì)讓你感到不安(我們將在缺陷一節(jié)中討論)，但不可否認(rèn)的是，許多成功的公司幾乎不用自己的服務(wù)器端代碼就能生產(chǎn)出令人信服的產(chǎn)品。
??無(wú)服務(wù)器FaaS的樂趣之一是——正如我在本文前面提到的——“水平縮放是完全自動(dòng)的、有彈性的，并且由服務(wù)商管理?！弊畲蟮暮锰幨?，只需要為你需要的計(jì)算付錢。如在AWS Lambda中，取決于應(yīng)用形態(tài)，可能只需要支付100毫秒的邊，界對(duì)你而言這很劃算。
??假設(shè)你正在運(yùn)行一個(gè)服務(wù)器應(yīng)用程序，該應(yīng)用程序每分鐘只處理一個(gè)請(qǐng)求，處理每個(gè)請(qǐng)求需要50毫秒，則你在一個(gè)小時(shí)內(nèi)的平均CPU使用率是0.1%。如果這個(gè)應(yīng)用程序部署到自己的專用主機(jī)上，那么這是非常低效的。上千個(gè)類似的應(yīng)用程序都可以共享一臺(tái)機(jī)器。
??無(wú)服務(wù)器FaaS解決了這種低效率，以更低的成本為你提供好處。在上面的示例應(yīng)用程序中，你只需要為每分鐘所花費(fèi)的100毫秒計(jì)算時(shí)間付錢，這是總時(shí)間的0.15%。
??這帶來(lái)了下面的連鎖效應(yīng)：
??讓我們看另一個(gè)例子。假設(shè)你的流量配置文件非常繁忙——可能你的基本流量是每秒20個(gè)請(qǐng)求，但是每5分鐘你就會(huì)在10秒鐘內(nèi)接收到每秒200個(gè)請(qǐng)求(是通常數(shù)量的10倍)。如果你不想希望在流量峰值階段減少響應(yīng)時(shí)間，怎么解決這個(gè)問題？
??在傳統(tǒng)環(huán)境中，你可能需要將硬件總數(shù)增加10倍，以處理峰值，即使峰值的總持續(xù)時(shí)間占總機(jī)器正常運(yùn)行時(shí)間的不到4%。在這里，自動(dòng)縮放可能不是一個(gè)好的選擇，因?yàn)樵谛聦?shí)例啟動(dòng)時(shí)，服務(wù)器的新實(shí)例需要較長(zhǎng)的啟動(dòng)時(shí)間。
??然而對(duì)于無(wú)服務(wù)器FaaS，這就不是一個(gè)問題。如果你的流量分布是均勻的，那么你就不會(huì)有什么不同，你僅需要支付高峰期產(chǎn)生的額外計(jì)算能力。
??顯然，我在這里特意選擇了幾個(gè)例子，其中無(wú)服務(wù)器FaaS可以節(jié)省大量的成本。但重點(diǎn)是想說(shuō)明，從縮放的角度來(lái)看，除非你有一個(gè)非常穩(wěn)定的流量形態(tài)，并且始終充分利用你的服務(wù)器主機(jī)的全部能力，否則使用FaaS可以節(jié)省成本。
??關(guān)于FaaS成本還有一個(gè)更有趣的方面:對(duì)代碼進(jìn)行性能優(yōu)化不僅會(huì)提高應(yīng)用程序的速度，而且還會(huì)直接降低運(yùn)營(yíng)成本，具體降低多少取決于供應(yīng)商的收費(fèi)的粒度。例如，假設(shè)一個(gè)應(yīng)用程序最初需要一秒鐘來(lái)處理一個(gè)事件。如果通過代碼優(yōu)化，這將減少到200ms，它(在AWS Lambda上)將立即看到在不更改任何基礎(chǔ)設(shè)施的情況下，計(jì)算成本節(jié)省了80%。
??在無(wú)服務(wù)器BaaS方面，很容易理解為什么操作管理比其他體系結(jié)構(gòu)更簡(jiǎn)單:支持更少的組件就等于更少的工作。
??盡管上一節(jié)中我們對(duì)縮放記憶猶新，但值得注意的是，F(xiàn)aaS的縮放功能不僅降低了計(jì)算成本，還減少了操作管理，因?yàn)榭s放是自動(dòng)的。
??如果你的縮放過程是手動(dòng)的(例如，需要人為地向服務(wù)器數(shù)組添加和刪除實(shí)例)，那么使用FaaS你可以很高興地忽略這一點(diǎn)，并讓FaaS供應(yīng)商為你擴(kuò)展應(yīng)用程序。
??即使你已經(jīng)達(dá)到在非FaaS體系結(jié)構(gòu)中使用自動(dòng)縮放的程度，仍然需要安裝和維護(hù)。而FaaS不再需要這項(xiàng)工作。
??與部署整個(gè)服務(wù)器相比，打包和部署FaaS功能很簡(jiǎn)單。你所做的就是將所有代碼打包成一個(gè)zip文件，然后上載它。沒有Puppet/Chef，沒有啟動(dòng)/停止shell腳本，沒有是否在機(jī)器上部署一個(gè)或多個(gè)容器的決定。如果你剛剛起步，那么你甚至不需要打包任何東西——甚至可以在服務(wù)提供者的控制臺(tái)上編寫代碼(顯然，這并不推薦!)。
??這個(gè)過程不需要很長(zhǎng)時(shí)間來(lái)描述，但是對(duì)于一些團(tuán)隊(duì)來(lái)說(shuō)，這個(gè)好處可能是絕對(duì)巨大的:一個(gè)完全無(wú)服務(wù)器的解決方案需要零系統(tǒng)管理。
??PaaS解決方案具有類似的部署優(yōu)勢(shì)，但正如我們前面看到的，在比較PaaS和FaaS時(shí)，F(xiàn)aaS在伸縮性方面具有優(yōu)勢(shì)。
??更簡(jiǎn)單的運(yùn)營(yíng)管理是我們工程師所理解的好處，但這對(duì)我們的業(yè)務(wù)意味著什么呢?
??顯而易見的是成本:花費(fèi)在操作上的時(shí)間越少，操作所需的人員就越少，正如已經(jīng)描述的那樣。但在我看來(lái)，更重要的是上線時(shí)間。隨著我們的團(tuán)隊(duì)和產(chǎn)品越來(lái)越傾向于精益和敏捷流程，我們希望不斷嘗試新事物并快速更新現(xiàn)有系統(tǒng)。雖然在持續(xù)交付的環(huán)境中進(jìn)行簡(jiǎn)單的重新部署可以快速迭代穩(wěn)定的項(xiàng)目，但是擁有“快速部署”的能力允許我們嘗試平滑和低成本的新實(shí)驗(yàn)。
??雖然成本效益是無(wú)服務(wù)器架構(gòu)最容易顯現(xiàn)的改進(jìn)，但上線時(shí)間的提前讓我最興奮。它可以使產(chǎn)品開發(fā)的思維模式持續(xù)不斷地試驗(yàn)，這才是對(duì)軟件交付的真正革命。
??在過去的幾十年里，世界上數(shù)據(jù)中心的數(shù)量和規(guī)模都有了巨大的增長(zhǎng)。使用物理資源來(lái)構(gòu)建這些中心,相關(guān)的能源需求是如此之大，這會(huì)造成巨大的環(huán)境影響。
??一方面，云基礎(chǔ)設(shè)施可能已經(jīng)幫助減少了這種影響，因?yàn)楣局荒茉诮^對(duì)需要的時(shí)候“購(gòu)買”更多的服務(wù)器，而不是提前很長(zhǎng)時(shí)間提供所有可能需要的服務(wù)器。不過，也有人可能會(huì)說(shuō)，如果很多服務(wù)器沒有進(jìn)行足夠的容量管理，那么供應(yīng)服務(wù)器的便捷性可能會(huì)讓情況變得更糟。
??無(wú)論我們使用的是自托管服務(wù)器、IaaS、還是PaaS基礎(chǔ)架構(gòu)解決方案，我們?nèi)匀恍枰止Q策應(yīng)用程序的容量，這些決策通常要持續(xù)數(shù)月或數(shù)年。通常，我們對(duì)管理能力持謹(jǐn)慎態(tài)度，這是正確的，但這導(dǎo)致過度供應(yīng)，導(dǎo)致低效。使用無(wú)服務(wù)器的方法，不再自己計(jì)算容量——讓無(wú)服務(wù)器供應(yīng)商提供的計(jì)算能力剛好滿足實(shí)時(shí)需求。供應(yīng)商可以綜合他的客戶的共同需求做出容量計(jì)算。
??這種差異將提升跨數(shù)據(jù)中心的資源使用效率，因此與傳統(tǒng)的容量管理方法相比，可以減少環(huán)境影響。
??對(duì)于任何外包策略，都是將一些系統(tǒng)控制權(quán)交給第三方供應(yīng)商。這種缺乏控制可能表現(xiàn)為系統(tǒng)停機(jī)、意外限制、成本更改、功能丟失、強(qiáng)制API升級(jí)等等。
??多租戶指多個(gè)不同客戶(或租戶)的軟件實(shí)例在同一臺(tái)機(jī)器上運(yùn)行，且可能在同一托管應(yīng)用程序中運(yùn)行的情況，這是實(shí)現(xiàn)規(guī)模經(jīng)濟(jì)效益的策略。服務(wù)供應(yīng)商盡其所能讓客戶覺得他們是唯一使用他們系統(tǒng)的人，而通常優(yōu)秀的服務(wù)供應(yīng)商在這方面做得很好。但是，沒有一個(gè)完美的多租戶解決方案，有時(shí)會(huì)在安全性(一個(gè)客戶能夠看到另一個(gè)客戶的數(shù)據(jù))、健壯性(一個(gè)客戶的軟件中的錯(cuò)誤導(dǎo)致另一個(gè)客戶的軟件出現(xiàn)故障)和性能(一個(gè)高負(fù)載的客戶導(dǎo)致另一個(gè)客戶的速度變慢)方面存在問題。
??這些問題并非無(wú)服務(wù)器系統(tǒng)獨(dú)有——它們存在于使用多租戶的許多其他服務(wù)產(chǎn)品中。AWS Lambda現(xiàn)在已經(jīng)足夠成熟，我們不希望看到它出現(xiàn)此類問題，但是你應(yīng)該注意任何不太成熟服務(wù)(無(wú)論是來(lái)自AWS還是其他供應(yīng)商)的此類問題。
??你從一個(gè)供應(yīng)商拿到的任何無(wú)服務(wù)器特性都很可能由另一個(gè)供應(yīng)商以不同方式實(shí)現(xiàn)。如果你想換供應(yīng)商幾乎肯定需要更新你的操作工具(部署、監(jiān)控、等等),可能需要改變代碼(例如,以滿足不同的 FaaS 接口),甚至可能需要改變?cè)O(shè)計(jì)或架構(gòu)。
??即使能夠輕松地遷移生態(tài)系統(tǒng)的一部分，你也可能會(huì)受到另一個(gè)體系結(jié)構(gòu)組件的更大影響。假設(shè)你正在使用AWS Lambda來(lái)響應(yīng)AWS Kinesis消息總線上的事件，盡管AWS Lambda、谷歌云功能和Microsoft Azure功能之間的差異可能相對(duì)較小，但仍然無(wú)法將后兩個(gè)供應(yīng)商實(shí)現(xiàn)直接連接到AWS的Kinesis流。這意味著，如果不遷移基礎(chǔ)設(shè)施的其它部分，就不可能將代碼從一個(gè)解決方案遷移到另一個(gè)解決方案。
??很多人都被這個(gè)想法嚇到了——如果今天選擇的云供應(yīng)商明天需要更改，還需要做很多工作，那么的確體驗(yàn)很差。因此，一些人采用“多云”方法，開發(fā)和操作應(yīng)用程序的方式與實(shí)際使用的云供應(yīng)商無(wú)關(guān)，但這通常比單云方法成本更高——因此，雖然供應(yīng)商綁定是一個(gè)合理的問題，但我仍然建議選擇一個(gè)你滿意的供應(yīng)商，并盡可能地利用它們的功能。
??采用無(wú)服務(wù)器方法會(huì)面臨大量安全問題。這里有一些需要考慮的事情：
??使用“完整的”BaaS體系結(jié)構(gòu)，服務(wù)器端不編寫自定義邏輯——全部在客戶機(jī)中編寫。這對(duì)于你的第一個(gè)客戶端平臺(tái)來(lái)說(shuō)可能很好，但是一旦你需要換一個(gè)平臺(tái)，你就需要重復(fù)實(shí)現(xiàn)該邏輯的一個(gè)子集，但在更傳統(tǒng)的體系結(jié)構(gòu)中你不需要這樣的重復(fù)工作。例如，如果在這種系統(tǒng)中使用BaaS數(shù)據(jù)庫(kù)，那么你的所有客戶機(jī)應(yīng)用程序(可能是web、原生iOS和原生Android)現(xiàn)在都需要能夠與供應(yīng)商數(shù)據(jù)庫(kù)通信，并且需要了解如何從數(shù)據(jù)庫(kù)模式映射到應(yīng)用程序邏輯。
??有了完整的BaaS體系結(jié)構(gòu)，就沒有機(jī)會(huì)為優(yōu)化服務(wù)器設(shè)計(jì)了?！昂蠖说角岸恕蹦Ｊ降拇嬖谑菫榱嗽诜?wù)器中抽象出整個(gè)系統(tǒng)的某些底層知識(shí)，在某種程度上是為了讓客戶端在移動(dòng)應(yīng)用程序中能夠更快地執(zhí)行操作，并使用更少的電池電量。這種模式不適用于完整的BaaS。
??對(duì)于完整的BaaS體系結(jié)構(gòu)，存在另一缺點(diǎn)：在這種體系結(jié)構(gòu)中，所有定制邏輯都位于客戶機(jī)中，并且只提供供應(yīng)商提供的后端服務(wù)。緩解這兩種情況的一種方法是采用FaaS或其他類型的輕量級(jí)服務(wù)器端模式，并將某些邏輯轉(zhuǎn)移到服務(wù)器。
??之前說(shuō)過：“當(dāng)涉及到本地時(shí)，F(xiàn)aaS函數(shù)有很大的限制。狀態(tài)。. .你不應(yīng)該假定一個(gè)函數(shù)的一次調(diào)用的狀態(tài)對(duì)同一函數(shù)的另一次調(diào)用是可用的。”。
??這種假設(shè)的原因是：對(duì)于FaaS，我們通常無(wú)法控制函數(shù)的主機(jī)容器何時(shí)啟動(dòng)和停止。
??那么，如果不能將狀態(tài)保存在內(nèi)存中，F(xiàn)aaS的狀態(tài)會(huì)如何變化呢?在許多情況下，使用快速NoSQL數(shù)據(jù)庫(kù)、進(jìn)程外緩存(例如Redis)或外部對(duì)象/文件存儲(chǔ)(例如S3)獲取是一些選項(xiàng)。但是這些都比內(nèi)存或機(jī)器上的持久性慢得多。你需要考慮應(yīng)用程序是否適合這種情況。
??這方面的另一個(gè)問題是內(nèi)存緩存。許多從外部存儲(chǔ)的大數(shù)據(jù)集讀取數(shù)據(jù)的應(yīng)用程序會(huì)在內(nèi)存中保留部分?jǐn)?shù)據(jù)集的緩存。你可能正在從數(shù)據(jù)庫(kù)中的“引用數(shù)據(jù)”表讀取數(shù)據(jù)，并使用Ehcache之類的東西?；蛘撸部梢詮闹付ň彺骖^的HTTP服務(wù)中讀取，在這種情況下，內(nèi)存中的HTTP客戶機(jī)可以提供本地緩存。
??FaaS確實(shí)允許使用一些本地緩存，如果你的函數(shù)使用得足夠頻繁，這可能是有用的。例如，對(duì)于AWS Lambda，我們通常希望一個(gè)函數(shù)實(shí)例能夠存在幾個(gè)小時(shí)，每隔幾分鐘至少使用一次。這意味著可以使用Lambda提供的(可配置的)3gb RAM，或512mb本地“/tmp”空間，對(duì)于某些緩存，可能足夠了。否則，不再需要假定進(jìn)程內(nèi)緩存，并且需要使用Redis或Memcached之類的低延遲外部緩存。然而，這需要額外的工作，可能會(huì)非常慢。
??前面描述的缺點(diǎn)可能總是存在于無(wú)服務(wù)器環(huán)境中。這些問題的解決方案在改進(jìn)，但畢竟是存在的。
??剩下的缺點(diǎn)完全歸結(jié)為目前的技術(shù)水平。隨著供應(yīng)商和/或英雄社區(qū)的意愿和投資，這些都可以被消滅。事實(shí)上，自本文的第一個(gè)版本以來(lái)，這個(gè)列表已經(jīng)縮小了。
??在我編寫本文的第一個(gè)版本時(shí)，AWS很少提供Lambda函數(shù)的配置方式。這個(gè)問題現(xiàn)在已經(jīng)得到了解決，但是如果你使用的是一個(gè)不太成熟的平臺(tái)，那么它仍然是值得檢查的。
??下面的例子，說(shuō)明為什么在處理FaaS時(shí)，“購(gòu)者自慎”是一個(gè)關(guān)鍵短語(yǔ)。AWS Lambda限制在給定時(shí)間內(nèi)可以運(yùn)行的Lambda函數(shù)的并發(fā)執(zhí)行次數(shù)。這個(gè)極限是1000;這意味著你可以在任何時(shí)候執(zhí)行一千個(gè)函數(shù)實(shí)例。如果你需要超過這個(gè)標(biāo)準(zhǔn)，可能會(huì)遇到異常、排隊(duì)和/或一般的慢下來(lái)。
??這里的問題是：這個(gè)限制是跨整個(gè)AWS帳戶的。一些組織使用相同的AWS帳戶進(jìn)行生產(chǎn)和測(cè)試。這意味著，如果你組織中的某地某人執(zhí)行了一種新的負(fù)載測(cè)試，并開始嘗試執(zhí)行1000個(gè)并發(fā)Lambda函數(shù)，將意外地關(guān)閉你的生產(chǎn)應(yīng)用程序。
??即使使用不同的AWS帳戶進(jìn)行生產(chǎn)和開發(fā)，一個(gè)過載的產(chǎn)品lambda(例如，處理來(lái)自客戶的批處理上傳)也可能導(dǎo)致獨(dú)立的受lambda支持的實(shí)時(shí)生產(chǎn)API變得無(wú)響應(yīng)。
??Amazon在這里通過保留并發(fā)性提供了一些保護(hù)。保留并發(fā)性允許你限制Lambda函數(shù)的并發(fā)性，這樣它就不會(huì)破壞你帳戶的其他部分，同時(shí)確保無(wú)論帳戶中的其他函數(shù)在做什么，始終有可用的容量。但是，默認(rèn)情況下不會(huì)為帳戶打開預(yù)留并發(fā)，因此需要小心管理。
??在本文前面我提到，如果AWS Lambda函數(shù)運(yùn)行時(shí)間超過5分鐘，則會(huì)中止它們。這兩年來(lái)一直是這樣的，AWS也沒有表現(xiàn)出任何想要改變的跡象。
??我之前談到了冷啟動(dòng)，并提到了關(guān)于這個(gè)主題的文章。隨著時(shí)間的推移，AWS已經(jīng)改進(jìn)了這一領(lǐng)域，但是仍然存在一些重大問題，特別是對(duì)于偶爾觸發(fā)的jvm實(shí)現(xiàn)函數(shù)和/或需要訪問VPC資源的函數(shù)。期待這方面將繼續(xù)改進(jìn)。
??好了，這已經(jīng)足夠去選擇AWS了。我相信其他供應(yīng)商也有一些問題。
??單元測(cè)試無(wú)服務(wù)器應(yīng)用程序非常簡(jiǎn)單，原因我在前面已經(jīng)討論過:編寫的任何代碼都“只是代碼”，而且在大多數(shù)情況下，不必使用一大堆定制庫(kù)或必須實(shí)現(xiàn)的接口。
??而另一方面，集成測(cè)試無(wú)服務(wù)器的應(yīng)用程序是困難的。在BaaS世界中，你依賴外部提供的系統(tǒng)，而不是(例如)自己的數(shù)據(jù)庫(kù)。那么，集成測(cè)試也應(yīng)該使用外部系統(tǒng)嗎?如果是，那么這些系統(tǒng)對(duì)測(cè)試場(chǎng)景有多大的適應(yīng)性?你能輕易的丟棄狀態(tài)嗎?你的供應(yīng)商能否為負(fù)載測(cè)試提供不同的計(jì)費(fèi)策略?
??如果你想為集成測(cè)試打樁那些外部系統(tǒng)，供應(yīng)商是否提供打樁模擬?如果是，樁的保真度如何?如果供應(yīng)商不提供樁，你自己將如何實(shí)現(xiàn)打樁?
??同樣的問題也存在于FaaS領(lǐng)域，盡管這一領(lǐng)域已經(jīng)有所改善?，F(xiàn)在可以在本地為L(zhǎng)ambda和Microsoft Azure運(yùn)行FaaS函數(shù)。然而，沒有一個(gè)本地環(huán)境可以完全模擬云環(huán)境;我不建議完全依賴本地FaaS環(huán)境。事實(shí)上，我還想更進(jìn)一步，建議你運(yùn)行自動(dòng)化集成測(cè)試的規(guī)范環(huán)境(至少作為部署管道的一部分)應(yīng)該是云，并且你應(yīng)該主要將本地測(cè)試環(huán)境用于交互式開發(fā)和調(diào)試。這些本地測(cè)試環(huán)境不斷改進(jìn)。
??還記得我在前幾節(jié)提到的在云中運(yùn)行集成測(cè)試時(shí)的跨帳戶執(zhí)行限制嗎?你可能希望至少將這些測(cè)試與你的生產(chǎn)云帳戶隔離。
??考慮集成測(cè)試重要原因是，我們使用無(wú)服務(wù)器FaaS與其他架構(gòu)相比，每個(gè)功能都要小得多，因此我們比與其他架構(gòu)風(fēng)格相比，更依賴集成測(cè)試。
??依賴基于云的測(cè)試環(huán)境，而不是在筆記本電腦上本地運(yùn)行所有東西，這對(duì)我來(lái)說(shuō)是一個(gè)相當(dāng)大的沖擊。但時(shí)代在變，我們從云計(jì)算中獲得的能力與谷歌等公司的工程師們十多年來(lái)所擁有的類似。Amazon現(xiàn)在甚至允許你在云中運(yùn)行IDE。我還沒有完全做到這一點(diǎn)——但它可能會(huì)到來(lái)。
??使用FaaS進(jìn)行調(diào)試是一個(gè)有趣的領(lǐng)域。這里已經(jīng)取得了一些進(jìn)展，主要與本地運(yùn)行FaaS函數(shù)有關(guān)。Microsoft為本地運(yùn)行但由遠(yuǎn)程事件觸發(fā)的函數(shù)提供了出色的調(diào)試支持。Amazon也提供類似的服務(wù)，但還沒有由生產(chǎn)事件觸發(fā)的機(jī)制。
??調(diào)試在云生產(chǎn)環(huán)境中實(shí)際運(yùn)行的函數(shù)是另一回事，Lambda至少還不支持這種功能，不過如果能看到這種功能就太好了。
??這是一個(gè)正在積極改進(jìn)的領(lǐng)域。AWS在改進(jìn)這方面已經(jīng)取得了巨大的進(jìn)步，稍后我將在“無(wú)服務(wù)器架構(gòu)的未來(lái)”一節(jié)中進(jìn)一步討論它。
??“發(fā)現(xiàn)”是微服務(wù)世界中經(jīng)常討論的主題:它是一個(gè)服務(wù)如何調(diào)用另一個(gè)服務(wù)的正確版本的問題。在無(wú)服務(wù)器的世界中，很少有關(guān)于發(fā)現(xiàn)的討論。起初這讓我擔(dān)心，但現(xiàn)在我不那么擔(dān)心了。許多無(wú)服務(wù)器的使用本質(zhì)上是事件驅(qū)動(dòng)的，在這里事件的使用者在某種程度上通常是自注冊(cè)的。對(duì)于面向API的FaaS用法，我們通常在API網(wǎng)關(guān)后面使用它們。在這種情況下，我們?cè)贏PI網(wǎng)關(guān)前面使用DNS，在網(wǎng)關(guān)后面使用自動(dòng)部署/流量轉(zhuǎn)移。甚至可以在API網(wǎng)關(guān)前面使用更多的層(例如，使用AWS CloudFront)來(lái)支持跨區(qū)域彈性調(diào)度。
??由于容器的短暫性，對(duì)FaaS來(lái)說(shuō)，監(jiān)控是一個(gè)棘手的領(lǐng)域。大多數(shù)云供應(yīng)商都提供了一定數(shù)量的監(jiān)控支持，我們也看到了許多來(lái)自傳統(tǒng)監(jiān)控廠商的第三方工作。不過，他們和你最終能做什么取決于供應(yīng)商提供給你的基本數(shù)據(jù)。在某些情況下，這可能是好的，但是對(duì)于AWS Lambda，至少，它是非?；A(chǔ)的。在這個(gè)領(lǐng)域，我們真正需要的是開放api和第三方服務(wù)提供更多的幫助能力。
??ThoughtWorks在其技術(shù)雷達(dá)出版物的一部分中，討論了過于強(qiáng)勢(shì)的API網(wǎng)關(guān)。雖然該鏈接一般指的是API網(wǎng)關(guān)(例如，對(duì)于那些傳統(tǒng)部署的微服務(wù)前端)，但它肯定可以作為HTTP前端到FaaS函數(shù)的API網(wǎng)關(guān)使用。問題是API網(wǎng)關(guān)提供了許多特定于應(yīng)用程序的邏輯。這種邏輯通常很難測(cè)試、版本控制，有時(shí)還很難定義。通常，這種邏輯最好像應(yīng)用程序的其他部分一樣保留在程序代碼中。
??如果我們將API網(wǎng)關(guān)視為BaaS，那么考慮它提供給我們的所有選項(xiàng)是否有價(jià)值，以便節(jié)省我們的工作。如果為每個(gè)請(qǐng)求使用API網(wǎng)關(guān)付費(fèi)，而不是按CPU利用率付費(fèi)，那么最大化地使用API網(wǎng)關(guān)的功能不是更劃算嗎?
??我的建議是明智地使用增強(qiáng)的API網(wǎng)關(guān)功能，并且只在它確實(shí)能夠長(zhǎng)期節(jié)省工作時(shí)才這樣做。絕對(duì)不要使用不能在源代碼可控的配置文件或部署腳本中表達(dá)的API網(wǎng)關(guān)特性。
??在前面提到過，無(wú)服務(wù)器并不是“無(wú)運(yùn)維”——從監(jiān)控、體系結(jié)構(gòu)伸縮、安全性和網(wǎng)絡(luò)的角度來(lái)看，還有很多工作要做。然而，在開始時(shí)很容易忽略這一點(diǎn)。這里的危險(xiǎn)正在被一種虛假的安全感所迷惑。也許你已經(jīng)啟動(dòng)并運(yùn)行了你的應(yīng)用程序，但它卻意外地出現(xiàn)在了***新聞上，突然間你需要處理的流量是原來(lái)的10倍，哎呀!你一下懵逼了。
??解決辦法是培訓(xùn)。使用無(wú)服務(wù)器系統(tǒng)的團(tuán)隊(duì)需要盡早考慮運(yùn)維活動(dòng)，供應(yīng)商和社區(qū)應(yīng)該提供教學(xué)幫助他們理解這意味著什么。
??我們即將結(jié)束對(duì)無(wú)服務(wù)器架構(gòu)世界的探索。最后，我將討論我認(rèn)為無(wú)服務(wù)器世界可能在未來(lái)幾個(gè)月和幾年發(fā)展的幾個(gè)領(lǐng)域。
??無(wú)服務(wù)器仍然是一個(gè)相當(dāng)新的世界。因此，上一節(jié)關(guān)于缺點(diǎn)的內(nèi)容非常廣泛，甚至沒有涵蓋我所能想到的所有內(nèi)容。無(wú)服務(wù)器的最重要發(fā)展將是減少固有的缺陷，并消除或改進(jìn)實(shí)施缺陷。
??工具仍然是無(wú)服務(wù)器的一個(gè)問題，這是因?yàn)樵S多技術(shù)和技術(shù)都是新的。部署/應(yīng)用程序綁定和配置在過去兩年中都得到了改進(jìn)，其中無(wú)服務(wù)器框架和Amazon的無(wú)服務(wù)器應(yīng)用程序模型處于領(lǐng)先地位。盡管亞馬遜和谷歌可以向微軟和Auth0尋求更多的靈感，但“前10分鐘”的體驗(yàn)并沒有想象中那么神奇。
??我很高興看到云供應(yīng)商積極解決的一個(gè)領(lǐng)域是更高級(jí)別的發(fā)布方法。在傳統(tǒng)系統(tǒng)中，團(tuán)隊(duì)通常需要編寫自己的流程來(lái)處理藍(lán)綠部署和canary發(fā)布等“流量轉(zhuǎn)移”思想?？紤]到這一點(diǎn)，Amazon支持Lambda和API網(wǎng)關(guān)的自動(dòng)流量轉(zhuǎn)移。在無(wú)服務(wù)器的系統(tǒng)中，這樣的概念更有用，因?yàn)橐淮?00個(gè)Lambda函數(shù)的系統(tǒng)原子版本構(gòu)成了許多單獨(dú)部署的組件。事實(shí)上，Nat Pryce向我描述了一種“混合臺(tái)”的方法，在這種方法中，我們可以在一個(gè)業(yè)務(wù)流中逐漸將一組組件引入和退出。
??分布式監(jiān)控可能是最需要改進(jìn)的領(lǐng)域。我們已經(jīng)從Amazon的 X-Ray和各種第三方產(chǎn)品中看到了早期的工作，但是這絕對(duì)不是一個(gè)已經(jīng)解決的問題。遠(yuǎn)程調(diào)試也是我希望看到更廣泛應(yīng)用的東西。Microsoft Azure函數(shù)支持這一點(diǎn)，但Lambda不支持。能夠在遠(yuǎn)程運(yùn)行的函數(shù)打斷點(diǎn)是一種非常強(qiáng)大的功能。
??最后,我希望看到改善的工具更有效地“元操作”——管理成百上千的FaaS功能,配置服務(wù)等。
??對(duì)于許多應(yīng)用程序來(lái)說(shuō)，F(xiàn)aaS缺乏持久的服務(wù)器狀態(tài)是可以接受的，但是對(duì)于許多其他應(yīng)用程序來(lái)說(shuō)，這是一個(gè)致命的問題——無(wú)論是對(duì)于大型緩存集還是對(duì)會(huì)話狀態(tài)的快速訪問。
??對(duì)于高吞吐量應(yīng)用程序，一個(gè)解決方案可能是供應(yīng)商在事件之間讓函數(shù)實(shí)例存活更長(zhǎng)一點(diǎn)，并使用常規(guī)的進(jìn)程內(nèi)緩存方法。由于緩存不會(huì)對(duì)每個(gè)事件都是熱的，所以這種方法不是100%有效的。對(duì)于使用傳統(tǒng)部署的自動(dòng)伸縮應(yīng)用程序來(lái)說(shuō)，也存在同樣的問題。
??更好的解決方案是非常低延遲地訪問進(jìn)程外數(shù)據(jù)，比如能夠以非常低的網(wǎng)絡(luò)開銷查詢Redis數(shù)據(jù)庫(kù)?？紤]到Amazon已經(jīng)在他們的Elasticache產(chǎn)品中提供了一個(gè)托管的Redis解決方案，而且他們已經(jīng)允許使用放置組對(duì)EC2(服務(wù)器)實(shí)例進(jìn)行相對(duì)定位，這看起來(lái)并不過分。
??但是，更有可能的是，我認(rèn)為我們將看到不同種類的混合(無(wú)服務(wù)器和非服務(wù)器)應(yīng)用程序架構(gòu)被采用，以考慮狀態(tài)外部化約束。以低延遲應(yīng)用程序?yàn)槔?你可能會(huì)看到一個(gè)常用方法：常駐服務(wù)器處理一個(gè)初始請(qǐng)求,收集所有必要的上下文來(lái)處理該請(qǐng)求的本地和外部狀態(tài), 然后將一個(gè)完全上下文化的請(qǐng)求傳遞給FaaS函數(shù)群,而不需要去外部查找數(shù)據(jù)。
??目前無(wú)服務(wù)器FaaS的某些缺點(diǎn)歸結(jié)為平臺(tái)的實(shí)現(xiàn)方式。執(zhí)行持續(xù)時(shí)間、啟動(dòng)延遲和跨功能限制是三個(gè)明顯的缺陷。這些問題可能會(huì)通過新的解決方案得到解決，也可能會(huì)有增加額外成本的變通辦法。例如，我認(rèn)為可以通過允許客戶總是在低延遲情況下請(qǐng)求一個(gè)FaaS函數(shù)的兩個(gè)實(shí)例，用來(lái)減少啟動(dòng)延遲，當(dāng)然客戶需要為此支付費(fèi)用。Microsoft Azure的功能具有這種理念的元素，它具有持久的功能，以及應(yīng)用程序服務(wù)計(jì)劃托管的功能。
??當(dāng)然，我們將看到平臺(tái)的改進(jìn)，而不僅僅是修復(fù)當(dāng)前的缺陷，這些改進(jìn)也將令人興奮。
??通過培訓(xùn)，許多特定于供應(yīng)商的無(wú)服務(wù)器固有缺陷正在得到緩解。讓一個(gè)或多個(gè)應(yīng)用程序供應(yīng)商托管這么多生態(tài)系統(tǒng)意味著什么？每個(gè)使用此類平臺(tái)的人都需要積極思考。我們需要考慮這樣的問題，我們是否需要考慮“設(shè)計(jì)來(lái)自不同供應(yīng)商的并行解決方案，以防其中一個(gè)不可用”和“在部分停機(jī)的情況下，應(yīng)用程序如何優(yōu)雅地降級(jí)?”這樣的問題。
??培訓(xùn)的另一個(gè)領(lǐng)域是技術(shù)操作。許多團(tuán)隊(duì)現(xiàn)在的系統(tǒng)管理員比以前少了，而無(wú)服務(wù)器架構(gòu)將加速這一變化。但是系統(tǒng)管理員不只是配置Unix盒和Chef腳本—他們通常是支持、網(wǎng)絡(luò)、安全等方面的前線人員。
??在一個(gè)無(wú)服務(wù)器的世界中，真正的DevOps文化變得更加重要，因?yàn)槟切┓窍到y(tǒng)管理員活動(dòng)仍然需要完成，而且現(xiàn)在通常是開發(fā)人員對(duì)它們負(fù)責(zé)。對(duì)于許多開發(fā)人員和技術(shù)領(lǐng)導(dǎo)來(lái)說(shuō)，這些活動(dòng)可能并不自然，因此培訓(xùn)和與操作人員的密切協(xié)作是重要的。
??最后，關(guān)于如何緩解缺陷問題:供應(yīng)商必須更加明確我們對(duì)他們平臺(tái)的期望，因?yàn)槲覀兏嗟匾蕾囁麄兲峁┩泄芄δ?。雖然遷移平臺(tái)是困難的，但這并非不可能，不值得信任的供應(yīng)商將看到他們的客戶將業(yè)務(wù)轉(zhuǎn)移到別處。
??我們對(duì)如何以及何時(shí)使用無(wú)服務(wù)器架構(gòu)的理解還處于初級(jí)階段?，F(xiàn)在，團(tuán)隊(duì)正在把各種各樣的想法扔到無(wú)服務(wù)器的平臺(tái)上，看看哪些是有用的。感謝拓荒者!我們開始看到推薦實(shí)踐模式的出現(xiàn)，而這些知識(shí)只會(huì)越來(lái)越多。
??我們看到的一些在應(yīng)用程序體系結(jié)構(gòu)中模式：例如，在FaaS函數(shù)變得笨拙之前，它們可以變得多大?假設(shè)我們能夠自動(dòng)地部署一組FaaS函數(shù)，那么創(chuàng)建這些組的好方法是什么?它們是否與我們當(dāng)前將邏輯聚合到微服務(wù)中的方式密切相關(guān)，或者架構(gòu)上的差異是否將我們推向了一個(gè)不同的方向?
??在無(wú)服務(wù)器應(yīng)用程序體系結(jié)構(gòu)中，一個(gè)特別有趣的活躍討論領(lǐng)域是它如何與事件思維交互。AWS Lambda的產(chǎn)品主管Ajay Nair在2017年對(duì)此做了一次精彩的演講，這也是CNCF無(wú)服務(wù)器工作組討論的主要領(lǐng)域之一。
??更進(jìn)一步，在FaaS和傳統(tǒng)的“始終在線”持久服務(wù)器組件之間創(chuàng)建混合架構(gòu)的好方法是什么?什么是將BaaS引入現(xiàn)有生態(tài)系統(tǒng)的好方法?相反，BaaS系統(tǒng)需要開始接受或使用更多自定義服務(wù)端代碼的警告信號(hào)是什么?
??我們還看到討論了更多的使用模式：FaaS的一個(gè)標(biāo)準(zhǔn)示例是媒體轉(zhuǎn)換，例如，每當(dāng)將大型媒體文件存儲(chǔ)到S3存儲(chǔ)桶中時(shí)，就會(huì)自動(dòng)運(yùn)行一個(gè)進(jìn)程，在另一個(gè)存儲(chǔ)桶中創(chuàng)建較小的版本。然而，我們現(xiàn)在也看到無(wú)服務(wù)器在數(shù)據(jù)處理管道、高度可伸縮的web api以及在操作中作為通用“粘合劑”代碼方面的重大應(yīng)用。其中一些模式可以作為通用組件實(shí)現(xiàn)，直接部署到組織中;我曾經(jīng)寫過關(guān)于Amazon的無(wú)服務(wù)器應(yīng)用程序存儲(chǔ)庫(kù)的文章，它是這種思想的早期形式。
??最后，隨著工具的改進(jìn)，我們開始看到推薦的操作模式。我們?nèi)绾魏侠淼貫镕aaS、BaaS和傳統(tǒng)服務(wù)器的混合架構(gòu)聚合日志記錄?如何最有效地調(diào)試FaaS函數(shù)?這些問題的許多答案——以及正在出現(xiàn)的模式——都來(lái)自云供應(yīng)商本身，我預(yù)計(jì)這一領(lǐng)域的活動(dòng)將會(huì)增長(zhǎng)。
??在寵物店的例子中,我們看到早些時(shí)候我給一個(gè)寵物店服務(wù)器分成幾個(gè)服務(wù)器端組件和一些邏輯轉(zhuǎn)移到客戶端,。但從根本上說(shuō)，這仍然是一個(gè)以客戶端為中心的架構(gòu),并且遠(yuǎn)程服務(wù)在已知位置。
??我們現(xiàn)在開始在無(wú)服務(wù)器世界中看到的是模糊的責(zé)任分配。一個(gè)例子是Amazon的Lambda@Edge產(chǎn)品:一種在Amazon CloudFront內(nèi)容交付網(wǎng)絡(luò)中運(yùn)行Lambda函數(shù)的方法。有了Lambda@Edge, Lambda函數(shù)就可以在全球范圍內(nèi)分布——一個(gè)工程師的一次上傳活動(dòng)就意味著該函數(shù)將被部署到全球100多個(gè)數(shù)據(jù)中心。
??此外，Lambda函數(shù)可以在設(shè)備上運(yùn)行，機(jī)器學(xué)習(xí)模型可以在移動(dòng)客戶端上運(yùn)行，在你了解它之前，“客戶端”和“服務(wù)器端”的分叉似乎不再有意義。無(wú)服務(wù)器將變得無(wú)區(qū)域。
??到目前為止，我所看到的FaaS的大多數(shù)用法都是將現(xiàn)有的代碼和設(shè)計(jì)思想“FaaSification”(FaaS化):將它們轉(zhuǎn)換為一組無(wú)狀態(tài)函數(shù)。這非常強(qiáng)大，但我希望我們將開始看到更多的抽象，可能還有語(yǔ)言，使用FaaS作為底層實(shí)現(xiàn)，讓開發(fā)人員受益于FaaS，而不需要將其應(yīng)用程序看作一組離散函數(shù)。
??例如，我不知道谷歌的Dataflow產(chǎn)品是否使用FaaS實(shí)現(xiàn)，但我可以想象有人創(chuàng)建了一個(gè)產(chǎn)品或開源項(xiàng)目，做類似的事情，并使用FaaS作為實(shí)現(xiàn)。這里的比較類似于Apache Spark。Spark是一個(gè)用于大規(guī)模數(shù)據(jù)處理的工具，它提供了非常高級(jí)的抽象，可以使用Amazon EMR和Hadoop作為其底層平臺(tái)。
??我認(rèn)為在無(wú)服務(wù)器系統(tǒng)的集成和驗(yàn)收測(cè)試方面還有很多工作要做，但是很多工作與以更傳統(tǒng)方式開發(fā)的“云原生”微服務(wù)系統(tǒng)相同。
??一個(gè)基本思想是在生產(chǎn)和監(jiān)控驅(qū)動(dòng)的開發(fā)中采用這樣的測(cè)試思想：一旦代碼通過了基本的單元測(cè)試驗(yàn)證，就可以將其部署到一個(gè)業(yè)務(wù)子集，并與上一個(gè)版本比較。這可以與我前面提到的業(yè)務(wù)轉(zhuǎn)移工具相結(jié)合。這并不適用于所有的上下文，但是對(duì)于許多團(tuán)隊(duì)來(lái)說(shuō)，是一個(gè)非常有效的工具。
??團(tuán)隊(duì)可以通過幾種方式使用無(wú)服務(wù)器，同時(shí)減少對(duì)特定云供應(yīng)商的依賴。
??無(wú)服務(wù)器框架的存在主要是為了簡(jiǎn)化無(wú)服務(wù)器應(yīng)用程序的運(yùn)維任務(wù)，但也提供了關(guān)于在何處以及如何部署此類應(yīng)用程序的余地。例如，如果能夠根據(jù)每個(gè)平臺(tái)的運(yùn)維能力輕松在AWS API網(wǎng)關(guān)+ Lambda和Auth0 webtask之間切換(即使是現(xiàn)在)，那將是非常棒的。
??其中一個(gè)棘手的方面是對(duì)抽象FaaS編碼接口建模，目前沒有標(biāo)準(zhǔn)化的指導(dǎo)，但是這正是關(guān)于CloudEvents的CNCF無(wú)服務(wù)器工作組的工作。
??但是，一旦運(yùn)維的復(fù)雜性浮出水面，為多個(gè)平臺(tái)提供抽象部署有多少價(jià)值就值得懷疑了。例如，在一個(gè)云中獲得正確的安全性在另一個(gè)云中可能是不同的。
??建議我們?cè)诓皇褂玫谌教峁┥痰那闆r下使用無(wú)服務(wù)器技術(shù)，這聽起來(lái)可能有些奇怪，但請(qǐng)考慮以下想法:
??現(xiàn)在已經(jīng)有了一個(gè)相當(dāng)大的無(wú)服務(wù)器社區(qū)，它有多個(gè)會(huì)議、許多城市的聚會(huì)和各種在線群組。我預(yù)計(jì)這一趨勢(shì)還會(huì)繼續(xù)發(fā)展，可能會(huì)像Docker和Spring這樣的社區(qū)一樣。
??盡管名稱令人困惑，但無(wú)服務(wù)器是一種體系結(jié)構(gòu)風(fēng)格，在這種體系結(jié)構(gòu)中，我們將自己的服務(wù)器端系統(tǒng)作為應(yīng)用程序的一部分運(yùn)行。通過兩種技術(shù)實(shí)現(xiàn)這一點(diǎn):BaaS和FaaS，前者將第三方遠(yuǎn)程應(yīng)用程序服務(wù)緊密集成到應(yīng)用程序的前端，后者將服務(wù)器端代碼從長(zhǎng)時(shí)間運(yùn)行的組件移動(dòng)到短暫的函數(shù)實(shí)例。
??無(wú)服務(wù)器并不是解決每個(gè)問題的正確方法，所以要小心那些說(shuō)它將取代你所有現(xiàn)有架構(gòu)的人。如果你現(xiàn)在嘗試使用無(wú)服務(wù)器系統(tǒng)，請(qǐng)小心，特別是在FaaS領(lǐng)域。雖然有豐富的(可伸縮的和節(jié)省的部署工作)資源可以利用，但也有調(diào)試和監(jiān)視的問題潛伏在角落中。
??但是，這些財(cái)富不應(yīng)該很快就被拋棄，因?yàn)闊o(wú)服務(wù)器架構(gòu)有許多積極的方面，包括降低操作和開發(fā)成本、更容易的操作管理和減少環(huán)境影響。但我認(rèn)為最重要的好處是減少了創(chuàng)建新應(yīng)用程序組件的反饋循環(huán)。我是“精益”方法的超級(jí)粉絲，主要是因?yàn)槲艺J(rèn)為將技術(shù)盡快呈現(xiàn)給終端用戶以獲得早期反饋是很有價(jià)值的，而無(wú)服務(wù)器產(chǎn)品上市時(shí)間的縮短正好符合這一理念。
??如今(2018年5月)，無(wú)服務(wù)器服務(wù)以及我們對(duì)它們的理解正處于“略顯笨拙的青春期”。在未來(lái)的幾年里，這個(gè)領(lǐng)域?qū)?huì)有很多的進(jìn)步，看看無(wú)服務(wù)器如何適應(yīng)我們的架構(gòu)工具集將是一件很有趣的事情。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼
