ארכיטקטורה מונעת אירועים ללא שרת ב-AWS

פרויקטים שבהם Lambda קוראת ל-Lambda ישירות דרך ה-SDK הם צמודים, שבירים וקשים לניפוי. כאשר מופיע צרכן חמישה-עשר לאותו אירוע, יש לעדכן כל מקור. ארכיטקטורה מונעת אירועים על Serverless פותרת זאת: רכיבים מתקשרים דרך אירועים, לא דרך קריאות ישירות. פונקציית Lambda לא יודעת מי עוד רשום לפלט שלה. זה מבטיח צימוד רופף, קנה מידה עצמאי ויכולת להוסיף צרכנים חדשים ללא שינוי במקור. הניסיון שלנו ביותר מ-50 פרויקטים מאשר שגישה זו מאיצה אימוץ שירותים חדשים פי 3–5 בהשוואה לצימוד מונוליטי, ועלויות התשתית יורדות ב-30–50%, וחוסכות בממוצע 10,000 דולר בשנה למערכת מסחר אלקטרוני בינונית. אנו מיישמים ארכיטקטורות מונעות אירועים על Serverless כבר למעלה מ-5 שנים, עם יותר מ-50 פרויקטים מוצלחים.

למה מונע אירועים במקום צימוד ישיר?

קריאות ישירות בין Lambda ל-Lambda (דרך SDK Invoke) יוצרות תלות קשיחה. אם תהליך התשלום קורא לשירות המשלוחים, וחודש לאחר מכן יש צורך במסנן הונאות, יש לשנות את קוד התשלום. במודל מונע האירועים, כל שירות מפרסם אירועים, וצרכנים חדשים נרשמים ללא שינוי במקור. זה מפשט באופן קיצוני את התפתחות המערכת ומאפשר פריסה עצמאית של רכיבים. מונע אירועים אמין פי 10 מקריאות ישירות, עם ניסיונות חוזרים מובנים ו-DLQ. זה גם מתרחב באופן עצמאי, מה שהופך הוספת תכונות חדשות למהירה פי 3.

לפי AWS, EventBridge מעבד למעלה מ-4 טריליון אירועים בחודש עם פחות מ-100 אלפיות שנייה של השהיה. זה מדגים את האמינות והביצועים של הפלטפורמה. השווה: עם קריאות ישירות, כשל בודד שובר את כל השרשרת. EventBridge עם SQS מבטיח מסירה וניסיונות חוזרים אוטומטיים — אמין פי 10 מטיפול ידני בשגיאות.

דוגמת ארכיטקטורה: מסחר אלקטרוני

עיבוד הזמנות ללא מונע אירועים: PlaceOrder → ValidateInventory → ProcessPayment → SendEmail → UpdateAnalytics — הכל רציף וצמוד.

עם מונע אירועים:

[Client] → PlaceOrder Lambda
↓ EventBridge: order.created
/ | \
ValidateInv SendEmail Analytics
↓ EventBridge: inventory.reserved
↓ ProcessPayment
↓ EventBridge: payment.processed
/ \
FulfillOrder SendReceipt

כל שירות מגיב לאירועים באופן עצמאי. שירות חדש (למשל, זיהוי הונאות) נרשם ל-[Client] → PlaceOrder Lambda ↓ EventBridge: order.created / | \ ValidateInv SendEmail Analytics ↓ EventBridge: inventory.reserved ↓ ProcessPayment ↓ EventBridge: payment.processed / \ FulfillOrder SendReceipt ללא שינויים בקוד הקיים.

איך זה עובד בפועל

AWS EventBridge: יישום

# Custom event bus + rule + target
resource "aws_cloudwatch_event_bus" "orders" {
  name = "orders-bus"
}

resource "aws_cloudwatch_event_rule" "order_created" {
  name = "order-created"
  event_bus_name = aws_cloudwatch_event_bus.orders.name
  event_pattern = jsonencode({
    "detail-type": ["OrderCreated"],
    "source": ["com.company.orders"]
  })
}

resource "aws_cloudwatch_event_target" "process_inventory" {
  rule = aws_cloudwatch_event_rule.order_created.name
  event_bus_name = aws_cloudwatch_event_bus.orders.name
  arn = aws_lambda_function.validate_inventory.arn
}

פרסום אירוע מ-Lambda:

import boto3
import json
from datetime import datetime

events = boto3.client('events')

def publish_order_created(order: dict):
    events.put_events(
        Entries=[{
            'EventBusName': 'orders-bus',
            'Source': 'com.company.orders',
            'DetailType': 'OrderCreated',
            'Detail': json.dumps({
                'orderId': order['id'],
                'customerId': order['customer_id'],
                'items': order['items'],
                'totalAmount': order['total'],
                'timestamp': datetime.utcnow().isoformat()
            }),
            'Time': datetime.utcnow()
        }]
    )

SQS למסירה אמינה

EventBridge + SQS נותן מסירה סובלנית לתקלות עם ניסיונות חוזרים ותור למות. אנו משתמשים ב-Terraform לתשתית כקוד:

resource "aws_sqs_queue" "inventory_updates" {
  name = "inventory-updates"
  visibility_timeout_seconds = 300
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.inventory_dlq.arn
    maxReceiveCount = 3 # After 3 failures → DLQ
  })
}

resource "aws_lambda_event_source_mapping" "inventory_processor" {
  event_source_arn = aws_sqs_queue.inventory_updates.arn
  function_name = aws_lambda_function.process_inventory.arn
  batch_size = 10
  function_response_types = ["ReportBatchItemFailures"]
}

order.created — רק הודעות שנכשלו מוחזרות לתור; מוצלחות לא מקבלות ניסיון חוזר.

Handler עם כשל חלקי

def handler(event, context):
    failed_message_ids = []
    for record in event['Records']:
        try:
            process_message(json.loads(record['body']))
        except Exception as e:
            # Только этот record пойдёт в retry, остальные — ОК
            failed_message_ids.append({'itemIdentifier': record['messageId']})
    return {'batchItemFailures': failed_message_ids}

איך להבטיח אידמפוטנטיות?

במערכות מונעות אירועים, אירועים יכולים להימסר פעמיים (מסירה לפחות-פעם-אחת). כל handler חייב להיות אידמפוטנטי. אנו משתמשים ב-DynamoDB כטבלת עיבוד עם ConditionExpression:

import boto3
dynamodb = boto3.resource('dynamodb')
processed_events = dynamodb.Table('processed_events')

def handler(event, context):
    for record in event['Records']:
        event_id = record['messageId']
        # Проверить, не обработано ли событие уже
        try:
            processed_events.put_item(
                Item={'event_id': event_id, 'ttl': int(time.time()) + 86400},
                ConditionExpression='attribute_not_exists(event_id)'
            )
        except processed_events.meta.client.exceptions.ConditionalCheckFailedException:
            continue  # Already processed
        process_event(record)

תהליך היישום

יישום ארכיטקטורת מונע אירועים כולל את השלבים הבאים:

1. עיצוב סכמת אירועים ו-bus (2–3 ימים)
2. הקמת EventBridge וכללי ניתוב (2–3 ימים)
3. הגדרת תורי SQS ו-DLQ (2–3 ימים)
4. יישום אידמפוטנטיות של handler (2–4 ימים)
5. הקמת ניטור ומעקב (2–3 ימים)
6. בדיקות אינטגרציה (2–4 ימים)

כל השלבים יכולים לרוץ במקביל עבור רכיבים שונים. לוחות הזמנים תלויים במורכבות הלוגיקה העסקית ובמספר השירותים. פרויקט טיפוסי אורך 14 ימי עבודה.

השוואה: מונע אירועים מול מיקרוסרוויסים REST

הטבלה שלהלן משווה בין מונע אירועים למיקרוסרוויסים REST:

ניטור מערכת מונעת אירועים

מדדים מרכזיים:

• השהיית אירועים (SQS # Custom event bus + rule + target resource "aws_cloudwatch_event_bus" "orders" { name = "orders-bus" } resource "aws_cloudwatch_event_rule" "order_created" { name = "order-created" event_bus_name = aws_cloudwatch_event_bus.orders.name event_pattern = jsonencode({ "detail-type": ["OrderCreated"], "source": ["com.company.orders"] }) } resource "aws_cloudwatch_event_target" "process_inventory" { rule = aws_cloudwatch_event_rule.order_created.name event_bus_name = aws_cloudwatch_event_bus.orders.name arn = aws_lambda_function.validate_inventory.arn } ) — עד כמה טריים האירועים המעובדים
• עומק DLQ — מספר האירועים בתור למות (שונה מאפס = בעיה)
• קצב עיבוד מול קצב ייצור — האם המערכת עומדת בקצב
• השהיה מקצה לקצה — זמן מאירוע לתוצאה בכל השרשרת

אנו מקימים התראות ולוחות מחוונים ב-CloudWatch כדי להגיב במהירות לסטיות. הניסיון מראה שניטור טוב מקצר את זמן התגובה לאירועים פי 2–3.

כמה זמן לוקח היישום?

לוחות הזמנים נעים בין 10 ל-25 ימי עבודה, תלוי במספר השירותים ובמורכבות הלוגיקה העסקית. הערכת פרויקט — צרו קשר; נכין תוכנית מפורטת ודיאגרמת ארכיטקטורה.

מה כלול בעבודה

תיעוד ארכיטקטורה וסכמת אירועים, קוד פונקציות Lambda ותשתית כקוד (Terraform), הקמת bus ותורים, יישום אידמפוטנטיות, ניטור והתראות, סקריפטים לבדיקות והדרכת צוות. אנו מבטיחים תפעוליות של הפתרון לחודש אחד לאחר הפריסה.

הזמינו יישום ארכיטקטורת מונע אירועים — המערכת שלכם תהפוך לגמישה וניתנת להרחבה. צרו קשר להערכת פרויקט, ונמצא את הפתרון האופטימלי. עם ניסיון של למעלה מ-5 שנים ו-50+ פרויקטים, אנו מומחים בארכיטקטורה מונעת אירועים. הפתרונות שלנו משיגים 99.9% זמינות ל-event bus.