隨著企業急于獲得邊緣所能提供的低延遲、靈活性、成本和性能方面的好處，邊緣計算的需求正在急劇擴大。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)

充分發揮邊緣的作用

邊緣計算為貼近用戶、快速高效地提供個性化用戶體驗的應用程序提供了巨大的優勢。成功的關鍵是確保應用程序是一個很好的邊緣平臺候選者，然后優化你的代碼，以充分利用邊緣平臺的功能，同時在其限制條件下工作。

請注意我在與組織合作中所學到的經驗教訓，你可以以更快的速度獲得邊緣的優勢，且沒有令人頭疼的問題。