تصميم تطبيقات بدون خوادم

في الجزء الحادي والعشرين بنينا API من ثلاث قطع. التطبيق الحقيقي يحتاج أكثر: عملية من عدة خطوات ممكن تفشل في النص، ومستخدمين يسجلون دخول، وأشياء لازم تصير بعد الطلب بدون ما ينتظرها أحد.

هذا الجزء يكمل الصورة بخدمتين زيادة، ثم يطبق كل شي على تصميمين.

Step Functions: سير العمل #

الطلب فيه فحص مخزون، ثم تحصيل المبلغ، ثم شحن. تقدر تخلي كل دالة تستدعي اللي بعدها، بس وين تكون إعادة المحاولة؟ وش يصير لو فشل الدفع بعد ما حجزت المخزون؟ ومين يقول لك وين الطلب 1001 الحين؟

Step Functions يطلع هذا المنطق من كودك إلى آلة حالات (State Machine): تعريف للخطوات ووش يصير بعد كل وحدة، وتشوفه كرسم في الكونسول.

كل خطوة تقدر تستدعي دالة Lambda أو خدمات AWS كثيرة مباشرة، والتعريف يتكفل باللي كنت بتكتبه بيدك:

هذا شكل إعادة محاولة الدفع والتقاط فشله:

"TakePayment": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": { "FunctionName": "take-payment", "Payload.$": "$" },
  "Retry": [{
    "ErrorEquals": ["States.TaskFailed"],
    "IntervalSeconds": 2,
    "BackoffRate": 2,
    "MaxAttempts": 3
  }],
  "Catch": [{
    "ErrorEquals": ["States.ALL"],
    "Next": "CancelOrder"
  }],
  "Next": "Ship"
}

Cognito: مستخدمينك #

IAM لفريقك وخدماتك، مو لمليون شخص يستخدمون تطبيقك. Amazon Cognito يعطي تطبيقك مستخدمينه، وله جزئين سهل تخلط بينهم:

User Pools تتكفل بالتسجيل والدخول، واستعادة كلمة المرور، والتحقق بعدة عوامل، والدخول بحسابات مثل Google أو هوية الشركة. وAPI Gateway وموزع الحمل ALB يقدرون يتحققون من توكناته مباشرة. والمجموعات الجديدة تستخدم خطة Essentials افتراضياً، وفيه كمان Lite الأرخص بميزات أقل، وPlus بحماية متقدمة.

Identity Pools تبدل التوكن بمفاتيح مؤقتة مربوطة بدور IAM، ومتغير في السياسة يحصرها في بيانات المستخدم نفسه. مثلاً كل مستخدم يوصل لمجلده فقط في S3:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::recipe-photos/users/${cognito-identity.amazonaws.com:sub}/*"
}

التصميم الأول: تطبيق جوال #

خلنا نصمم تطبيق لمشاركة الوصفات: المستخدمين يسجلون دخول، ويكتبون وصفات، ويرفعون صور، والوصفات المشهورة تنقرأ أكثر بكثير مما تنكتب. كل متطلب له قطعته:

ليه الصورة تروح مباشرة لـ S3 بدل ما تمر عبر الـ API؟ لأن API Gateway حده 10 MB، ولأنك بتدفع وقت Lambda بس عشان تمرر بايتات. والروابط الموقّعة خيار ثاني ممتاز هنا، لو ما تحتاج Identity Pools.

ولاحظ وين يقع كل كاش: كاش API Gateway يوقف الطلب قبل ما يوصل للدالة، فيناسب الردود اللي ما تختلف من مستخدم لآخر. وDAX يخلي الدالة تشتغل، ويريح الجدول من القراءة.

التصميم الثاني: موقع عالمي #

الحين دليل سفر ينقرأ حول العالم: صفحات ثابتة، وAPI صغير، وإيميل ترحيب لما يسجل أحد، وصور مصغرة للصور اللي يرفعها المستخدمين.

تابعه قطعة قطعة:

• الصفحات: حاوية S3 خاصة وقدامها CloudFront مع OAC، فالحاوية تبقى مقفلة والموقع سريع في كل مكان.
• الـ API: API Gateway وLambda وDynamoDB، وGlobal Tables تقرب البيانات من المستخدمين في كل منطقة.
• إيميل الترحيب: الـ API ما يرسله. المستخدم الجديد ينكتب في الجدول، وDynamoDB Streams يشغّل دالة، وهي ترسل عبر SES. ولو فشل الإيميل، التسجيل ما يتأثر.
• الصور المصغرة: صورة تنزل في S3 تشغّل دالة Lambda تكتب نسخة أصغر. وللتعامل مع الموجات أو الوصول لأكثر من خدمة، حط SQS أو SNS بينهم.

ما فيه سيرفر واحد هنا، ولما ما يكون فيه زوار، الفاتورة تقرب من تكلفة التخزين فقط. والفكرة في آخر مسارين وحدة: الطلب يخلص بسرعة، والباقي يصير بالأحداث.

الخدمات المصغرة (Microservices) #

لما يكبر التطبيق، الفرق تقسمه إلى خدمات صغيرة، كل وحدة لها شغلها وقاعدة بياناتها وجدول إطلاقها. وعندهم طريقتين للتواصل:

وكل خدمة تقدر تختار اللي يناسبها: Lambda للطلبات المتفرقة، وFargate للحمل الثابت، وEC2 للمتطلبات الخاصة. بس لهذا كله ثمن: إطلاقات أكثر، ومراقبة أكثر، وأعطال أصعب في تتبعها بين الخدمات. فلا تبدأ من هنا لتطبيق صغير، وقسّم بس لما تحتاج فعلاً.

ربح رخيص: CloudFront قدام اللي عندك #

مو كل تحسين يحتاج إعادة كتابة. تخيل تطبيق على مجموعة Auto Scaling يوزع ملفات تحديث كبيرة. يوم الإطلاق، كل مستخدمينك يحملون بنفس الوقت: السيرفرات تتضاعف، وفاتورة نقل البيانات تقفز.

حط CloudFront قدامه، وما تغير شي ثاني. الملفات ما تتغير، فتناسب الكاش جداً: أغلب الطلبات توقف عند الحافة، والمجموعة بالكاد تكبر، والبيانات الخارجة عبر CloudFront أرخص من الخروج المباشر. شغل دقايق ممكن يرجع لك أكثر من إعادة تصميم.

مبادئ التصميم #

وما يلزم تبدأ من الصفر. AWS Serverless Application Repository يخليك تلقى تطبيقات جاهزة بدون سيرفرات، وتضبط كم قيمة، وتنشرها بكم ضغطة.

عملي: ملف يشغّل دالة #

في الجزء الخامس عشر وعدنا نطبق أحداث S3. بنسوي مسار الصور المصغرة بتبسيط واحد: بدل مكتبة صور، الدالة تحول ملف نصي إلى حروف كبيرة. والمسار نفسه تماماً. من CloudShell:

BUCKET=series-events-$RANDOM$RANDOM
aws s3 mb s3://$BUCKET

cat > trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "lambda.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

ROLE_ARN=$(aws iam create-role --role-name series-events-role \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn --output text)

aws iam attach-role-policy --role-name series-events-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

aws iam put-role-policy --role-name series-events-role \
  --policy-name bucket-access --policy-document "{
    \"Version\": \"2012-10-17\",
    \"Statement\": [{
      \"Effect\": \"Allow\",
      \"Action\": [\"s3:GetObject\", \"s3:PutObject\"],
      \"Resource\": \"arn:aws:s3:::$BUCKET/*\"
    }]
  }"

اكتب الدالة وأنشئها. ولو جاك خطأ عن الدور، انتظر كم ثانية وأعد الأمر:

cat > app.py <<'EOF'
from urllib.parse import unquote_plus
import boto3

s3 = boto3.client("s3")

def handler(event, context):
    for record in event["Records"]:
        bucket = record["s3"]["bucket"]["name"]
        key = unquote_plus(record["s3"]["object"]["key"])
        body = s3.get_object(Bucket=bucket, Key=key)["Body"].read().decode()
        name = key.split("/")[-1]
        s3.put_object(Bucket=bucket, Key=f"processed/{name}", Body=body.upper())
EOF

zip -q function.zip app.py

FN_ARN=$(aws lambda create-function --function-name series-events \
  --runtime python3.13 --handler app.handler --role $ROLE_ARN \
  --zip-file fileb://function.zip \
  --query FunctionArn --output text)

aws lambda wait function-active-v2 --function-name series-events

اسمح لـ S3 يستدعي الدالة، ثم قل للحاوية ترسل لها أحداث مجلد uploads/ فقط:

aws lambda add-permission --function-name series-events \
  --statement-id s3-trigger --action lambda:InvokeFunction \
  --principal s3.amazonaws.com --source-arn arn:aws:s3:::$BUCKET \
  --query Statement --output text > /dev/null

cat > notify.json <<EOF
{
  "LambdaFunctionConfigurations": [{
    "LambdaFunctionArn": "$FN_ARN",
    "Events": ["s3:ObjectCreated:*"],
    "Filter": {"Key": {"FilterRules": [{"Name": "prefix", "Value": "uploads/"}]}}
  }]
}
EOF

aws s3api put-bucket-notification-configuration --bucket $BUCKET \
  --notification-configuration file://notify.json

ارفع ملف، وانتظر كم ثانية، ثم اقرأ النتيجة:

echo "hello from s3" > note.txt
aws s3 cp note.txt s3://$BUCKET/uploads/note.txt

aws s3 cp s3://$BUCKET/processed/note.txt -

يطبع HELLO FROM S3. رفعت ملف، وكود اشتغل لحاله.

نظّف قبل ما تكمل:

aws s3 rb s3://$BUCKET --force
aws lambda delete-function --function-name series-events
aws logs delete-log-group --log-group-name /aws/lambda/series-events
aws iam delete-role-policy --role-name series-events-role \
  --policy-name bucket-access
aws iam detach-role-policy --role-name series-events-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
aws iam delete-role --role-name series-events-role

عملي: سير عمل يقرر #

بنكتب آلة حالات تطالع مبلغ الطلب: المبلغ السالب يفشل، والكبير يروح للمراجعة، والباقي ينقبل. وتستخدم خطوات داخلية فقط، فتحتاج دور بدون صلاحيات:

cat > trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "states.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

FLOW_ROLE=$(aws iam create-role --role-name series-flow-role \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn --output text)

cat > flow.json <<'EOF'
{
  "StartAt": "CheckAmount",
  "States": {
    "CheckAmount": {
      "Type": "Choice",
      "Choices": [
        {"Variable": "$.amount", "NumericLessThanEquals": 0, "Next": "Rejected"},
        {"Variable": "$.amount", "NumericGreaterThan": 1000, "Next": "NeedsReview"}
      ],
      "Default": "Approved"
    },
    "NeedsReview": {"Type": "Pass", "Result": {"status": "review"}, "End": true},
    "Approved": {"Type": "Pass", "Result": {"status": "approved"}, "End": true},
    "Rejected": {"Type": "Fail", "Error": "InvalidAmount", "Cause": "The amount must be positive"}
  }
}
EOF

أنشئها. وهنا برضو، لو جاك خطأ عن الدور، انتظر كم ثانية وأعد الأمر:

FLOW_ARN=$(aws stepfunctions create-state-machine --name series-order \
  --definition file://flow.json --role-arn $FLOW_ROLE \
  --query stateMachineArn --output text)

شغّلها بثلاث طلبات:

try_order() {
  RUN=$(aws stepfunctions start-execution --state-machine-arn $FLOW_ARN \
    --input "$1" --query executionArn --output text)
  sleep 2
  aws stepfunctions describe-execution --execution-arn $RUN \
    --query "[status,output]" --output text
}

try_order '{"amount": 250}'
try_order '{"amount": 5000}'
try_order '{"amount": -5}'

بيطلع لك approved، ثم review، ثم FAILED. الحين افتح Step Functions في الكونسول، واختر series-order، ثم أي تنفيذ. بتشوف الرسم والمسار اللي مشى عليه ملوّن، وهذا اللي بتطالعه لما يعلق طلب في الإنتاج.

aws stepfunctions delete-state-machine --state-machine-arn $FLOW_ARN
aws iam delete-role --role-name series-flow-role

الخلاصة #

• Step Functions يطلع الخطوات وإعادة المحاولة والفشل من كودك إلى سير عمل تشوفه.
• User Pool يجاوب من هو المستخدم، وIdentity Pool يعطيه مفاتيح مؤقتة لـ AWS.
• التصميم الجيد يخلص الطلب بسرعة، ويترك الباقي للأحداث.
• خل الملفات الكبيرة تروح مباشرة لـ S3، وحط الكاش وين يوقف أكبر قدر من الشغل.
• الخدمات المصغرة لها ثمن، فقسّم بس لما تحتاج فعلاً.

اختبر نفسك #

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

بهذا نكمل قسم التطبيقات الحديثة. تطبيقك الحين يطلع بيانات كثيرة، بس وش تقول لك؟ في الجزء الثالث والعشرين نبدأ قسم البيانات والذكاء الاصطناعي، ونحلل البيانات بـ Athena وRedshift وGlue.