成功實現邊緣編碼需要了解的六大經驗教訓
隨著企業急於獲得邊緣所能提供的低延遲、靈活性、成本和效能方面的好處,邊緣計算的需求正在急劇擴大。IDC估計,2022年全球在邊緣硬體、軟體和服務方面的支出將達到1760億美元,比上一年增長14.8%,到2025年將達到2740億美元。因此,你的開發者很可能現在就在開發邊緣應用,或者在不久的將來會這樣做。
然而,在你深入研究之前,有一些事情需要考慮。我作為企業架構師有與開發組織合作的經驗,讓我告訴你建立邊緣應用時的一些教訓。牢記這些教訓可以幫助你避免走彎路,並確保你充分利用邊緣所能提供的優勢。
教訓1:挑戰你的思維方式
很多時候,開發者在建立邊緣應用時,就好像它們與資料中心或雲端的應用一樣。但邊緣是一個不同的正規化,需要用不同的方法來編寫程式碼,也需要用深思熟慮的方法來選擇適合邊緣的應用。
大多數開發者習慣於集中式的計算環境,在少量的伺服器中擁有大量的計算資源。但是,邊緣計算將這種情況翻轉過來,相對適度的資源分佈在不同地點的許多伺服器上。這可能會影響任何一個邊緣工作負載的可擴充套件性。例如,一個使用大量記憶體的應用程式可能無法在成百上千的邊緣例項中很好地擴充套件。由於這個原因,大多數邊緣應用程式將是專門為邊緣設計的,而不是從現有的資料中心或雲部署中“提升和遷移”。
你需要認真思考邊緣架構如何影響你的應用,以及哪些應用將從這種分散式方法中受益。把邏輯帶到資料所在的地方通常更容易。因此,如果資料更加區域化,或者需要訪問大型集中式資料儲存,基於雲的方法可能是合理的。但是,當一個應用程式使用在邊緣產生的資料時--例如來自線上使用者的請求/響應、cookies和頭資訊--這就是邊緣計算真正可以大放異彩之處。
教訓2:不要忽視基礎知識
雖然將程式碼分佈到邊緣可以改善延遲和可擴充套件性,但它不會神奇地執行得更快。低效的程式碼在邊緣也會同樣低效。如前所述,邊緣的每個存在點都會比典型的集中式計算環境受到更多的資源限制,特別是在無伺服器的邊緣環境中。在為邊緣編寫程式碼時,最佳化效率對於充分利用這種架構至關重要。
當向邊緣推送功能相對快速和容易時,你仍然需要向管理其它程式碼那樣應用勤奮的管理流程。這包括良好的變更管理流程,將程式碼儲存在原始碼控制中,並使用程式碼審查來評估程式碼質量。
教訓3:重新思考可擴充套件性
在邊緣,你是在“擴大”而不是“增加”。因此,你需要開發程式碼以適應每個請求的約束,而不是從每個伺服器的約束角度考慮。這包括對記憶體用量、CPU週期和每次請求時間的約束。制約因素會因你所使用的邊緣平臺而不同,所以瞭解它們並相應地設計你的程式碼很重要。
一般來說,你想用每個操作所需的最小資料集來操作。例如,如果你在邊緣做A/B測試,你只想儲存你正在操作的特定請求或頁面所需的資料子集,而不是整個規則集。對於基於位置的體驗,你只需要在一個輕量級的查詢中儲存該邊緣例項所服務的特定州或地區的資料,而不是所有地區的資料。
教訓4:為可靠性編碼
確保邊緣應用程式的可靠性對於提供積極的使用者體驗是絕對必要的。請確保在你的QA計劃中包括測試邊緣程式碼。新增適當的錯誤處理也很重要,以確保你的程式碼能夠優雅地處理錯誤,包括計劃和測試事件發生時的回退行為。例如,如果你的程式碼超出了平臺的限制,要建立一個回退到一些預設的內容,這樣使用者就不會收到一個影響他們體驗的錯誤資訊。
進行分散式負載測試是一個很好的做法,可以確認你的應用程式的可擴充套件性。一旦你部署了程式碼,就繼續監測平臺,以確保不超過CPU和記憶體的限制,並跟蹤任何錯誤。
教訓5:最佳化效能
邊緣計算的主要好處是透過將資料和計算資源移至使用者附近而大幅減少延遲。當你在成百上千個存在點(PoPs)上進行擴充套件時,建立輕量級、高效的程式碼對於實現這一好處至關重要。完成一個功能所需的資料也應該在邊緣。開發需要從集中式資料儲存中獲取資料的程式碼會抹去邊緣提供的延遲優勢。
對高效執行的強調同樣適用於邊緣應用所利用的任何第三方程式碼。一些現有的程式碼庫是低效的,損害了效能或超過了邊緣平臺的CPU和記憶體限制。因此,在將任何程式碼納入邊緣部署之前,要仔細評估它。
教訓6:不要重複造輪子
雖然邊緣是一種新的模式,但這並不意味著你必須從頭開始編寫一切。大多數邊緣平臺都與各種內容分發網路(CDN)功能整合,允許你建立自定義邏輯,生成一個輸出訊號,提示現有的CDN功能,如快取。
把你的程式碼設計成可重用的也是一個好主意,這樣它既可以在邊緣也可以在集中的計算環境中執行。將核心功能抽象為不依賴瀏覽器、Node.JS或特定平臺功能的庫,可以使程式碼具有“同構性”,能夠在客戶端、伺服器和邊緣執行。
使用現有的開源庫是避免重寫通用功能的另一種方式。但要注意那些需要Node.JS或瀏覽器功能的庫。並考慮與你正在使用的邊緣平臺整合的第三方開發商合作,這可以節省時間和精力,同時提供成熟的互操作性優勢。
將這些經驗付諸實踐
為了說明這些最佳實踐的影響,請考慮一個真實的案例:一個組織在邊緣實施地理圍欄應用時遇到了困難。他們遇到了因超過平臺的CPU和記憶體限制而導致的高錯誤率問題。
看看他們是如何建立自己的應用程式的,他們有所有地理圍欄區域的資料,900KB的JSON,儲存在每個邊緣PoP中。使用一個CPU密集型演算法來檢查每個地理圍欄的興趣點,當在檢查前幾個區域沒有找到興趣點時,就會觸發CPU超時。
為了解決這個問題,每個地理圍欄區域的資料被轉移到一個鍵值儲存(KVS)中,每個區域儲存在一個單獨的條目中。增加了一個輕量級的檢查,以確定一個興趣點的可能的“候選區域”(通常是1到3個候選區域)。完整的資料和CPU密集型檢查只在候選區域進行,極大地減少了CPU的工作量。這些變化將錯誤率降低到可忽略的水平,同時改善了初始化時間並減少了記憶體的使用,如下圖所示。
圖1:成功率和錯誤率的前後對比(注意,成功和錯誤指標的尺度不同,因此不能直接比較)。
圖2:初始化時間的前後比較
圖3:之前和之後的記憶體使用情況比較(圖片來源:Akamai)
充分發揮邊緣的作用
邊緣計算為貼近使用者、快速高效地提供個性化使用者體驗的應用程式提供了巨大的優勢。成功的關鍵是確保應用程式是一個很好的邊緣平臺候選者,然後最佳化你的程式碼,以充分利用邊緣平臺的功能,同時在其限制條件下工作。
請注意我在與組織合作中所學到的經驗教訓,你可以以更快的速度獲得邊緣的優勢,且沒有令人頭疼的問題。
作者Josh Johnson是內容分發網路(CDN)和邊緣解決方案提供商Akamai的一名高階企業架構師。
來自 “ https://www.datanami.com/2022/06/27/coding-for-the ”,原文連結:http://blog.itpub.net/69925873/viewspace-2903122/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 初入軟體「江湖」的萌新需要了解的五個經驗教訓
- 來自10位成功IT人士的23條經驗教訓
- 來說說成功的雲遷移的10個經驗教訓
- 面試經驗之教訓面試
- 企業在機器學習應用中需要吸取的經驗和教訓機器學習
- 需求分析經驗及教訓
- 從邊緣走向中心,邊緣計算出現三大門派和六大趨勢
- 經驗教訓,慎用Oracle的審計Oracle
- 一個小碼農這半年的經驗和教訓
- 程式碼審查的5點經驗教訓總結
- 經驗教訓:Instacart 的實時機器學習之旅 - shu機器學習
- 成功專案經理的經驗教訓——鼓勵靈活的體制和行為(轉)
- 微服務遷移:經驗教訓微服務
- 採用 SOA 最佳實踐,借鑑經驗教訓
- Heap使用Postgres SQL後的經驗教訓SQL
- 引入新程式語言的經驗教訓
- 使用MongoDB血淚般的經驗教訓MongoDB
- 關於Web 2.0 的SOA 經驗教訓Web
- 建立機器學習實戰系統的十大經驗教訓機器學習
- [譯] Data Binding 庫使用的經驗教訓
- 我的軟體開發中經驗教訓
- 艱困之道中學到的經驗教訓
- 建立安卓應用的 30 個經驗教訓安卓
- Go 併發程式設計中的經驗教訓Go程式設計
- 20+條軟體開發的經驗教訓
- 來自10位 IT 大牛的23條經驗教訓
- 「譯文」Google SRE 二十年的經驗教訓Go
- 安裝pytorch-gpu的經驗與教訓PyTorchGPU
- 口袋妖怪Go手遊的幾個經驗教訓Go
- 17個創業公司的失敗經驗教訓創業
- 作為專案經理的7個經驗教訓總結
- 經驗&教訓分享:我的第一個機器學習專案機器學習
- 《神鬼寓言》的開發中有些什麼經驗教訓?
- Supercell成立10週年的10條經驗和教訓
- 大規模執行 Apache Airflow 的經驗教訓 - shopifyApacheAI
- 新人入職100天,聊聊自己的經驗&教訓
- 大資料要牢記的5大經驗教訓大資料
- Storm在spider.io應用的經驗教訓ORMIDE