أنماط هندسة Backend: من Monoliths إلى Microservices

TL;DR

• أنماط بنية Backend تحدد كيفية تفاعل مكونات البرمجيات وتوسعها وتطورها مع الوقت.
• الهياكل الأحادية بسيطة للبدء لكنها صعبة التوسع؛ الميكروسيرفيس تقدم مرونة مع تعقيد إضافي.
• التصاميم المُوجَّهة بالحدث والسيرفرلس مثالية للأحمال التفاعلية والقابلة للتوسع وفعالة من حيث التكلفة.
• اختر نمطًا بناءً على حجم فريقك، واحتياجات التوسع، ونضج العمليات.
• يجب أن تتطور استراتيجيات المراقبة والأمان والاختبار مع البنية المختارة.

---

ما ستتعلمه

• الأنماط الرئيسية لبنية Backend وكيف تختلف.
• كيف تقرر أي نمط يناسب مشروعك.
• أمثلة عملية للتنفيذ (مع مقاطع كود قابلة للتشغيل).
• المزالق الشائعة وكيفية تجنبها.
• رؤى واقعية من الأنظمة الكبيرة.

---

المتطلبات الأساسية

يجب أن يكون لديك:

• فهم أساسي لـ Backend الويب (واجهات برمجة التطبيقات HTTP، قواعد البيانات، إلخ).
• معرفة بواجهات REST أو GraphQL.
• بعض الخبرة مع Python أو Node.js.

---

أنماط بنية Backend هي العمود الفقري لكل نظام ويب حديث. تُحدد كيفية تواصل الخدمات، وتدفق البيانات، وتطور النظام مع التوسع. سواء كنت تبني منصة SaaS، أو API داخلي، أو نظام موزع كبير الحجم، فإن نمط بنية النظام سيؤثر على الأداء والصيانة والتكلفة.

لنستعرض الأنماط الأكثر شيوعًا:

1. البنية الأحادية
2. البنية الطبقية (N-tier)
3. بنية الميكروسيرفيس
4. البنية المُوجَّهة بالحدث
5. البنية السيرفرلس
6. البنية السداسية (Ports and Adapters)

لكل نمط مزاياه وعيوبه واستخداماته المثالية.

---

1. البنية الأحادية

نظرة عامة

البنية الأحادية تجمع جميع الوظائف — واجهة المستخدم، المنطق التجاري، ووصول البيانات — في وحدة واحدة قابلة للنشر. إنها أبسط طريقة لبدء نظام Backend.

رسم البنية

flowchart TD
    A[Client] --> B[Monolithic Application]
    B --> C[Database]

المزايا

• سهلة التطوير والنشر.
• سهلة الاختبار محليًا.
• تصحيح الأخطاء مباشر.

العيوب

• صعبة التوسع لمكونات محددة.
• نشر أبطأ مع نمو قاعدة الكود.
• ترابط مشدّد بين الوحدات.

متى تستخدم مقابل متى لا تستخدم

الوضعية	استخدم الأحادي	تجنب الأحادي
شركة ناشئة في مرحلة مبكرة	✅
مشروع فريق واحد	✅
بروتotyping سريع	✅
فرق متعددة مستقلة		❌
متطلبات توسع عالية أو وقت تشغيل مرتفع		❌

مثال: بنية Flask الأحادية البسيطة

from flask import Flask, jsonify, request

app = Flask(__name__)

@app.route('/API/v1/orders', methods=['POST'])
def create_order():
    data = request.json
    order_id = 123  # mock
    return jsonify({"order_id": order_id, "status": "created"})

if __name__ == '__main__':
    app.run(debug=True)

شغّله:

$ python app.py
 * Running on http://127.0.0.1:5000/

الإخراج:

POST /API/v1/orders -> {"order_id":123,"status":"created"}

المزالق الشائعة & الحلول

المزالق	الحلول
نمو قاعدة الكود بشكل لا يمكن التحكم فيه	إدخال حزم مُعَمَّدة مبكرًا
أوقات بناء طويلة	استخدام التخزين المؤقت CI والبناء التدريجي
مشكلات التوسع	إدخال التوسع الأفقي عبر الحاويات

---

2. البنية الطبقية (N-Tier)

نظرة عامة

البنية الطبقية تنظم الكود إلى طبقات منطقية — العرض، المنطق التجاري، ووصول البيانات. هذا النمط مستخدم على نطاق واسع في الأنظمة المؤسسية¹.

الرسم البياني

flowchart TD
    A[Client] --> B[Presentation Layer]
    B --> C[Business Logic Layer]
    C --> D[Data Access Layer]
    D --> E[Database]

المزايا

• فصل واضح بين الاهتمامات.
• سهولة الاختبار والصيانة.
• يعمل بشكل جيد مع إطارات عمل MVC.

السلبيات

• قد تؤدي إلى زيادة الحمل على الأداء بسبب الطبقات المتعددة.
• التغييرات في طبقة واحدة قد تؤثر على الطبقات الأخرى.

هيكل المجلدات النموذجي

/backend
  ├── presentation/
  │   └── API.py
  ├── business/
  │   └── services.py
  ├── data/
  │   └── repository.py
  └── app.py

متى تستخدم

• تطبيقات المؤسسات.
• أنظمة ذات حدود مجال واضحة.
• عندما تكون قابلية الصيانة أهم من الأداء الخام.

---

3. Microservices Architecture

نظرة عامة

Microservices تقسم النظام إلى خدمات صغيرة قابلة للنشر بشكل مستقل. كل خدمة تمتلك بياناتها ومنطقها².

رسم توضيحي

flowchart TD
    A[API Gateway] --> B[User Service]
    A --> C[Order Service]
    A --> D[Payment Service]
    B --> E[User DB]
    C --> F[Order DB]
    D --> G[Payment DB]

المزايا

• نشر وتوسيع مستقل.
• مرونة التكنولوجيا.
• عزل الأعطال.

السلبيات

• اتصال معقد بين الخدمات.
• مشكلات في اتساق البيانات الموزعة.
• يتطلب نضج DevOps.

مثال: Python FastAPI Microservice

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Payment(BaseModel):
    amount: float
    user_id: int

@app.post("/payments")
def process_payment(payment: Payment):
    return {"status": "success", "amount": payment.amount}

تشغيله:

$ uvicorn main:app --reload

الإخراج:

POST /payments -> {"status":"success","amount":100.0}

متى تستخدم مقابل متى لا تستخدم

الوضعية	استخدم Microservices	تجنب Microservices
أنظمة كبيرة ومعقدة	✅
فرق متعددة	✅
حاجة إلى توسيع مستقل	✅
فريق صغير أو MVP		❌
خبرة محدودة في DevOps		❌

مثال واقعي

تقوم الخدمات الكبيرة عادة باعتماد microservices لدعم النشر المستقل للفِرق والتوسع². وفقًا لمدونة Netflix Tech، تطورت بنية خلفية النظام إلى مئات من microservices لتحقيق المرونة والقابلية للتوسع³.

المزالق الشائعة والحلول

المزلق	الحلول
عدد كبير من الخدمات	ابدأ بحدود خشنة
اتصال معقد	استخدم طوابير الرسائل أو شبكة الخدمة
تصحيح أخطاء الأنظمة الموزعة	قم بتنفيذ تسجيل مركزي وتتبع

---

4. Event-Driven Architecture

نظرة عامة

الأنظمة المُحفَّزة بالأحداث تستخدم اتصالًا غير متزامن عبر الأحداث. المُنتِجون يُصدرون أحداثًا، المستهلكون React لهم⁴.

مخطط

flowchart LR
    A[Producer] --> B[Event Bus]
    B --> C[Consumer 1]
    B --> D[Consumer 2]

المزايا

• عزل عالٍ.
• قابلية توسعة طبيعية.
• مثالية للمعالجة في الوقت الفعلي.

العيوب

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

مثال: مستهلك أحداث بايثون

import json
import pika

def callback(ch, method, properties, body):
    event = json.loads(body)
    print(f"Received event: {event}")

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='events')
channel.basic_consume(queue='events', on_message_callback=callback, auto_ack=True)

print('Waiting for events...')
channel.start_consuming()

متى تستخدم

• التحليلات في الوقت الفعلي.
• أنظمة إنترنت الأشياء.
• اتصال الميكروخدمات المُعزولة.

اعتبارات الأداء

الأنظمة المُحفَّزة بالأحداث تحسن عادةً الإنتاجية للأحمال المحدودة بـ I/O⁵. ومع ذلك، يعتمد التأخير على أداء وسيط الرسائل وموثوقية الشبكة.

---

5. بنية الخادم غير المُستَعْمَل

نظرة عامة

الخادم غير المُستَعْمَل يُجرِّد إدارة البنية التحتية. تعمل الوظائف عند الطلب، وتتوسع تلقائيًا⁶.

مخطط

flowchart TD
    A[Client Request] --> B[API Gateway]
    B --> C[Lambda Function]
    C --> D[Database]

المزايا

• لا إدارة خوادم.
• التقسيم التلقائي والدفع حسب الاستخدام.
• مثالية للأحمال غير المتوقعة.

العيوب

• تأخير بدء التشغيل البارد.
• وقت تنفيذ محدود.
• الارتباط بالمزود.

مثال: AWS Lambda (بايثون)

def handler(event, context):
    order_id = event.get('order_id')
    return {"status": "processed", "order_id": order_id}

النشر عبر AWS CLI:

$ aws lambda create-function --function-name processOrder --runtime python3.10 \
  --role arn:aws:iam::123456789:role/lambda-role --handler lambda_function.handler \
  --zip-file fileb://function.zip

متى تستخدم مقابل متى لا تستخدم

الحالة	استخدم Serverless	تجنب Serverless
أحمال متقلبة	✅
تطبيقات موجهة بالأحداث	✅
مهام قابلة للتنبؤ وطويلة الأمد		❌
أنظمة زمن حقيقي منخفضة التأخير		❌

---

6. Hexagonal (Ports and Adapters) Architecture

نظرة عامة

Hexagonal architecture (المعروف أيضًا باسم Ports and Adapters) يعزل المنطق الأساسي عن الاعتماديات الخارجية⁷.

مخطط

flowchart TD
    A[Adapters] --> B[Ports]
    B --> C[Domain Core]
    C --> D[Ports]
    D --> E[Adapters]

المزايا

• قابلية اختبار عالية.
• سهولة تغيير الأنظمة الخارجية.
• فصل واضح للمنطق التجاري.

مثال لهيكل المجلدات

/app
  ├── domain/
  │   └── models.py
  ├── ports/
  │   └── repository.py
  ├── adapters/
  │   ├── db_adapter.py
  │   └── api_adapter.py
  └── main.py

متى تستخدم

• المجالات التجارية المعقدة.
• الأنظمة التي تتطلب صيانة طويلة الأمد.

---

جدول المقارنة

النمط	قابلية التوسع	التعقيد	النشر	مثالي لـ
Monolithic	منخفضة	منخفضة	بسيط	فرق صغيرة، MVPs
Layered	متوسطة	متوسطة	متوسط	تطبيقات المؤسسات
Microservices	مرتفعة	مرتفعة	معقد	أنظمة كبيرة الحجم
Event-Driven	مرتفعة	مرتفعة	معقد	أنظمة زمن حقيقي
Serverless	مرتفعة	متوسطة	بسيط	أحمال متقلبة
Hexagonal	متوسطة	متوسطة	متوسط	أنظمة موجهة بالمجال

---

استراتيجيات الاختبار

الهندسة	الاختبار الموصى به
Monolithic	وحدة + تكامل
Microservices	عقد + نهاية إلى نهاية
Event-Driven	اختبارات موجهة بالمستهلك
Serverless	محاكاة محلية + تكامل

مثال: Pytest لخدمة ميكرو

def test_payment_process(client):
    response = client.post('/payments', json={'amount': 100, 'user_id': 1})
    assert response.status_code == 200
    assert response.json()['status'] == 'success'

---

اعتبارات الأمان

• المصادقة والتفويض: استخدم OAuth 2.0 أو JWT لحماية API⁸.
• التحقق من البيانات: تحقق دائمًا من المدخلات عند الحدود.
• إدارة الأسرار: استخدم المتغيرات البيئية أو مديري الأسرار.
• أمن الشبكة: طبق قواعد TLS وجدران الحماية.
• OWASP Top 10: راجع وخفف المخاطر الشائعة بانتظام⁸.

---

قابلية المراقبة والمراقبة

• المقاييس: استخدم Prometheus أو CloudWatch.
• التتبع: نفذ OpenTelemetry للتتبع الموزع.
• السجلات: جمع السجلات باستخدام ELK أو Loki.

مثال: تهيئة السجلات (Python)

import logging.config

LOGGING_CONFIG = {
    'version': 1,
    'formatters': {
        'default': {'format': '[%(asctime)s] %(levelname)s in %(module)s: %(message)s'}
    },
    'handlers': {
        'console': {'class': 'logging.StreamHandler', 'formatter': 'default'}
    },
    'root': {'level': 'INFO', 'handlers': ['console']}
}

logging.config.dictConfig(LOGGING_CONFIG)
logging.info("Service started")

---

الأخطاء الشائعة التي يرتكبها الجميع

1. الهندسة المفرطة المبكرة: لا تبدأ باستخدام microservices لـ MVP صغير.
2. تجاهل observability: Logging و tracing ضرورية لأنظمة distributed systems.
3. تجاهل CI/CD: Automated testing و deployment pipelines ضرورية.
4. خلط sync و async flows بشكل خاطئ: يؤدي إلى performance bottlenecks.

---

دليل استكشاف الأخطاء وإصلاحها

المشكلة	السبب المحتمل	الحل
أوقات استجابة بطيئة	Blocking I/O	استخدم async frameworks
فشل الخدمة المتقطع	Network timeouts	أضف retries و circuit breakers
عدم تناسق البيانات	Eventual consistency غير معالجة	Implement idempotent consumers
فشل النشر	Version mismatch	Use container version pinning

---

دراسة حالة واقعية: التطور من Monolith إلى Microservices

تبدأ الرحلة النموذجية بـ Monolith — سهل البناء، صعب التوسع. مع نمو حركة المرور، تقسم الفرق الخدمات (مثل المدفوعات، الطلبات، المستخدمين) إلى microservices. كل خدمة تكتسب استقلالية لكنها تُدخل تعقيدًا موزعًا. اتبعت شركات التكنولوجيا الكبرى مسارات مشابهة، متوجهة نحو microservices وأنظمة event-driven للscalability و resilience³.

---

متى تستخدم مقابل متى لا تستخدم Framework

flowchart TD
    A[Start Project] --> B{Team Size > 5?}
    B -->|Yes| C{High Scalability Needed?}
    B -->|No| D[Monolith]
    C -->|Yes| E[Microservices]
    C -->|No| F[Layered or Hexagonal]

---

الاستنتاجات الرئيسية

هندسة Backend تدور حول التنازلات. ابدأ ببساطة، وتطور بوعي.

• Monoliths رائعة للسرعة.
• Microservices تتألق في scale.
• الأنماط Event-driven و serverless تجلب elasticity.
• Observability و testing و security يجب أن تتطور مع architecture.

---

الأسئلة الشائعة

1. ما هي أفضل architecture لشركة ناشئة؟
Monolith أو layered architecture — بسيط، سريع، وسهل التكرار.

2. هل يمكنني خلط patterns؟
نعم، Hybrid architectures شائعة (مثل microservices باستخدام event-driven communication).

3. كيف أقوم بالانتقال من monolith إلى microservices؟
ابدأ باستخراج bounded contexts — خدمة واحدة في كل مرة.

4. هل serverless جاهز للإنتاج؟
نعم، للعديد من الأحمال. فقط انتبه لـ cold starts و vendor lock-in.

5. كيف أراقب microservices بشكل فعال؟
استخدم distributed tracing (OpenTelemetry) و centralized logging.

---

الخطوات التالية

• حاول بناء نظام event-driven صغير باستخدام RabbitMQ أو Kafka.
• جرّب AWS Lambda لـ serverless API.
• استكشف domain-driven design لتحديد حدود microservices.

---

الهوامش

1. Microsoft Docs – Layered Architecture Guidelines: https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier ↩

2. Martin Fowler – Microservices Guide: https://martinfowler.com/microservices/ ↩ ↩²

3. Netflix Tech Blog – تطور إلى Microservices: https://netflixtechblog.com/ ↩ ↩²

4. وثائق AWS – Event-Driven Architecture: https://docs.aws.amazon.com/whitepapers/latest/event-driven-architecture/ ↩

5. توثيق Python AsyncIO: https://docs.python.org/3/library/asyncio.html ↩

6. دليل مطوري AWS Lambda: https://docs.aws.amazon.com/lambda/latest/dg/welcome.html ↩

7. Alistair Cockburn – Hexagonal Architecture: https://alistair.cockburn.us/hexagonal-architecture/ ↩

8. OWASP Top 10 المخاطر الأمنية: https://owasp.org/www-project-top-ten/ ↩ ↩²