原先，建立一個函式，預設具有300的併發數量上限。針對小的低頻業務，300 的併發值足夠使用。但是遇到業務量上漲、支撐大型運營活動等大併發的情況，開發者就需要透過提工單聯絡平臺方，申請提升函式併發額度。這樣可能導致：
每遇到一次大併發，就需要聯絡一次平臺方來提升配額，時效性弱。申請等待週期時會導致上漲的業務部分有損。在評估量級時，也可能出現評估不足，導致需要再次申請，低效。併發能力升級相對於原有的函式預設固定的併發值，本次上線的併發管理能力，有以下方面的最佳化：
將單一函式的併發調整放開給了出來，使用者可以自行來控制併發數。併發額度由單一的函式維度，移到了賬號維度。賬號下預設具有一定的併發額度，由賬號下的函式所共享的，不需要單獨為其中一個大併發的函式申請額度。因此，在當前的模式下，預設賬號具有的 128000 MB的額度，可以供 128 MB配置記憶體函式啟動執行1000個併發；在這種情況下，使用者無需去尋找平臺申請，就可以獲得比調整前更高的一個併發額度，用於支撐上漲的業務。
併發的處理由於賬號級別的額度是在賬號下的多個函式間共享的，在多個函式同時執行的情況下，因為流量突增、業務上漲導致併發增高的函式在佔用完全部空閒額度後，可能會和平穩執行的函式之間產生衝突。
這種情況下，有兩種解決方案：
一方面可以透過平臺申請提升更高的賬號額度，來滿足上漲業務帶來的併發上漲；
另外一方面，也可以透過將部分額度分配給具體函式，來保障具體函式的執行可靠性。
下面我將具體說一下第二種方式。舉個例子，在同樣的賬號下，函式 A 提供 H5 頁面用於秒殺的運營活動，函式 B 在進行後臺的流式資料處理。在 B 函式啟動了 300 併發進行業務處理時，運營活動會受限於 A 函式，最大僅能跑到 700 併發；而函式 A 的業務壓力下，如果 B 函式也有業務量上漲，將無配額可用導致無法啟動更多例項。
在上面的例子中，如果要保證 B 函式資料處理流程的可靠性，可以為這個函式設定到 350 的保留併發配額；此時，這個額度將從賬號維度劃給這個函式單獨使用，而運營活動所使用的 A 函式將僅僅可以最大使用的 650 併發的額度。函式 B 在設定到 350 的保留併發額度後，在業務持續上升後，最大也僅僅可以使用到配置的這個額度，此時，就算是賬號維度的額度仍然有剩餘時，B 函式也無法去使用。
透過保留額度的設定，一方面，我們可以對函式的執行進行保障，避免多個函式共享額度時，由於其他業務的函式佔用導致本函式無法執行產生損失，另外一方面，保留配額也定義了函式的執行額度上限。
因此，針對函式的併發管理控制，可以基於業務來進行更精細的控制，有以下三點建議：
針對開發測試階段的函式，由於請求量小，無業務壓力，併發也極少，可以不配置保留額度而僅僅使用賬號維度的共享額度；針對穩定執行的函式，併發通常是確定的，浮動範圍也不會很大，這個時候可以給這個函式設定稍微有一點餘量的保留額度，來保障函式的額度不受共享的影響；針對運營活動、有可能性突增併發的函式，可以利用賬號維度的高額度，來充分利用和支撐業務爆發。當前預置額度的設定，是設定在函式的版本上，也是從賬號維度的併發配額或函式上的保留額度中扣減下來的。
透過設定預置額度可以預想啟動所需量的併發例項，完成例項的初始化並等待事件的到來。針對函式的請求將不會有冷啟動時間，直接就可以在已經完成準備、初始化完成的例項中得到執行。
在時延敏感的業務，例如前端的 SSR 頁面響應；或者是初始化時間較長的業務，例如 AI 推理的模型載入過程；這些場景下，透過給函式設定上一定的預置可以保障業務更好的執行。
同時，預置的配額也不是例項併發的上限，在業務量上漲到超過已經預置的例項可以承載的時候，函式平臺仍然會根據函式的保留配額或者是賬號的配額，拉起更多的例項來支援業務執行。
併發使用場景設定建議一個賬號下有多個業務都在同時使用雲函式進行支撐時，函式的併發配額就需要進行按需排程。根據不同的業務特性來進行合理合適的設定。
例如有波峰波谷的前端業務，有平穩執行波動不大的資料處理業務，有偶爾才執行一次的定時運維任務，也有併發不大但是計算量重、計算時間長的影片處理業務；
在這些業務中，根據重要性、是否接受一定損失來說，又有不同的區分：前端業務保障使用者體驗，要求載入速度快，但是可以有一定的錯誤容忍度；資料處理的要求高，不能接收延遲、波動或失敗；定時運維任務偶爾執行，不用投入過多的關注，執行正常即可；而影片處理業務，可以接受按需排程，失敗時能自動重試就行。
根據不同的業務特性、容錯額度、業務波動情況、時延要求，我們就可以按照不同的情況來進行不同的設定。上述幾項業務中，併發設定有以下幾點建議：
對前端業務來說，要求載入速度快，但是有波峰波谷，這種情況我們就可以為函式配置一定量的預置額度，例如按最大使用量的60%來設定，但是同時不設定函式的保留額度，確保在高峰到來時能充分利用總配額；針對資料處理業務，波動不大但是容錯低，我們可以為函式配置一定量的保留額度，確保不會有其他業務使用的共享額度導致資料處理業務的問題；運維任務定時執行，沒有高要求，可以不做任何配置，使用賬號維度的配額來處理就行；針對影片處理業務，計算量大，而且可以按需排隊處理任務，我們設定好一定的保留額度，讓業務跑滿併發額度，充分利用好且控制好計算資源。保留配額另一種用法保留配額還有另外一種用法——對業務的限制或關停。在有緊急事項發生，例如漏洞攻擊、迴圈呼叫失控等情況出現時，為了避免有重大損失，可以透過設定保留配額，將額度控制在極小的值上來避免執行失控，甚至可以設定為 0 來關閉函式的執行。
記憶體和併發額度的關係當前額度按記憶體進行計算，配置記憶體大的函式，併發執行時佔用的額度多，而配置記憶體小的函式在多併發執行時佔用的額度小；
由於函式服務的資源用量計費項和函式的配置記憶體強相關，透過記憶體進行額度控制，一方面可以讓我們儘量採用合適的記憶體來實現業務，另外一方面，針對整體的支出也可以進行有效的控制。
總結透過提供多層次的併發配額管理能力，目前我們可以獲得更強的函式併發管理控制的許可權，無需再等待平臺方的調整就可以自行根據業務需求快速調整。