按計劃的時間間隔處理批量檔案是當今企業應用程式系統中最常用的自動化任務之一。這種型別的批處理檔案處理可用於各種用例，例如建立備份，分析日誌，執行計算等。

在本文中，我們將構建一個滿足以下要求的批處理檔案處理解決方案。

1. 外部應用程式以隨機​​時間間隔將檔案上載到預配置的位置（這超出了我們的實現範圍）。
2. 我們的應用程式每隔1小時檢查一次該檔案位置，並逐個處理當前存在的所有檔案。
3. 成功處理檔案後，將刪除該檔案以防止重複處理。
4. 處理完當前批次的所有檔案後，將向處理預先配置的電子郵件地址或多個地址傳送包含處理詳細資訊（已處理檔案總數，成功處理的數量和失敗次數）的通知。

現在我們有兩種主要方法來構建此解決方案。一種是傳統方法，另一種是現代無伺服器方法。讓我們首先簡要介紹一下傳統方法及其缺點。然後使用後一種方法來構建此解決方案。

傳統方法

如果我們考慮傳統方法，完整解決方案將包含以下元件：

• 外部應用程式將檔案上載到的SFTP伺服器，我們的應用程式將從中讀取這些檔案。
• 我們的應用程式用於傳送通知電子郵件的電子郵件伺服器或第三方電子郵件服務提供商。
• 將執行我們的應用程式的應用程式伺服器
• 我們的應用程式將安排cron任務以1小時的間隔觸發某個例程，此例程將從SFTP伺服器獲取檔案列表，處理每個例程並最終傳送通知電子郵件。

儘管這種方法效果很好並且已經使用了很多年，但是與它相關的缺點很少。其中主要的是成本。在這裡，您需要維護SFTP伺服器，應用程式伺服器以及可能還有電子郵件伺服器。即使外部應用程式即使在一兩天內沒有上傳任何檔案，您仍然必須保持SFTP伺服器全天候執行並支付費用，因為您不知道何時上傳檔案。應用程式伺服器也是如此。根據您的處理型別，單個批處理過程可能只需幾分鐘。因此，在觸發下一個批處理之前，您的應用程式伺服器不會執行任何有效的工作，除非您在其中部署其他一些應用程式。

除此之外，您還需要開發一個複雜的應用程式，它不僅包含您的處理邏輯，還包含與與其他系統（如SFTP和電子郵件）互動相關的重要應用程式邏輯。

無伺服器方法

但是現在變得越來越突出的無伺服器模式使得這種情況出乎意料地簡單且具有成本效益。例如，如果您使用AWS S3進行檔案儲存，則只需支付檔案大小。如果您使用AWS Lambda進行處理，您只需要支付實際處理時間，而不是空閒時間的一分錢。

如何整合AWS元件以構建我們的解決方案。

1. 配置S3儲存桶以儲存檔案，直到它們被處理為止。
2. 一個SNS主題配置為釋出處理的通知和所需的電子郵件地址訂閱了它。
3. 一個LAMBDA功能與必要的許可權，程式從S3儲存讀取檔案，處理它們，刪除處理的檔案，最後將通知傳送到SNS主題。
4. 甲的CloudWatch預定事件被配置為在1小時的時間間隔以觸發lambda函式。