feat: استيراد كود سيرو إلى تريبز (سيرو @ecfe7568) — بلا تعديل

قرار المالك 2026-07-27: باك إند سيرو PHP هو المعتمد، وتطبيقاته المجرّبة ميدانياً تحل محل إعادة البناء المؤرشفة. سيرو نفسه لم يُمسّ. الخريطة: backend · payment_server · loction_server · ride_server · passenger_server · docker · dashboard · stress_test → الجذر siro_rider → apps/rider siro_driver → apps/driver siro_admin → dashboards/admin siro_service → dashboards/service android_bot → apps/android_bot socialBot → apps/socialBot نُسخ المتعقَّب في git سيرو فقط عبر `git archive` (3,198 ملفاً / ~169 م.ب) لا `cp -r` — فاستُثنيت مخلفات البناء تلقائياً. بلا أي تعديل محتوى عمداً: كل ما يلي يصير فرقاً مقروءاً مقابل المصدر. لم يُستورد وسببه: siromove.com (الموقع التسويقي يبقى marketing/ في تريبز، سيرو فيه 8 ملفات) · docs و planning (تريبز له docs/ الخاص) · deploy.sh (ليس نشراً على سيرفر بل `git add . && git push origin --all` — فخّ في مستودع آخر) · transit_dashboard (بانتظار قرار مصير backend-transit و dashboards/transit-web). ⚠️ لا يبني بعد — ثلاثة نواقص متوقعة ومقصودة: 1. `.env` و `lib/env/env.g.dart` غير متعقَّبين في سيرو (أسرار لكل مستأجر): كل تطبيق فلاتر يحتاج .env خاصاً ثم توليد env.g.dart بـ build_runner. 2. إعدادات Firebase (9 ملفات google-services.json و GoogleService-Info.plist) يستبعدها .gitignore تريبز — ولكل مستأجر مشروع Firebase خاص أصلاً. 3. apps/driver في سيرو يشير إلى `../../Intaleq/packages/get` خارج المستودع → يجب ضمّ الحزم داخله أسوة بـ apps/rider. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-27 05:14:13 +03:00
parent 9909d9b4c1
commit 4d8414c96b
3198 changed files with 766859 additions and 0 deletions
@@ -0,0 +1,79 @@
+# سيرو في حاويات — دليل التشغيل والفحص
+
+> الهدف: نسخة سيرو كاملة على سيرفر واحد داخل compose واحدة، والتطبيق لا يتغير فيه
+> شيء سوى الـ base URLs (تُبنى مرة واحدة بـ `.env` الجديد — envied وقت الترجمة).
+> القرارات والأسباب في `Tripz/docs/30-siro-port-plan.md` §5.
+
+## 0) قبل أي شيء — على السيرفر
+```bash
+df -h /                      # ⚠️ الصندوق المشترك مزمنياً ~90% ممتلئ — الصور والقواعد تحتاج ~4-6GB
+docker image prune -f        # نظّف أولاً، وإن لم تكفِ المساحة فالفحص على صندوق آخر
+```
+
+## 1) الإعداد (مرة واحدة)
+```bash
+cd /path/to/Siro/docker
+cp .env.example .env && nano .env      # املأ الأسرار من قيم اللايف — خاصة JWT_SECRET وكلمات MySQL
+# ⚠️ طابق أسماء القواعد في mysql/init/00-databases.sql مع ما يتوقعه الكود
+docker compose build
+# تبعيات composer للخدمات التي لا تحمل vendor/ داخلها:
+docker compose run --rm socket_driver composer install
+docker compose run --rm socket_passenger composer install
+docker compose run --rm --workdir /var/www/backend php composer install
+```
+
+## 2) التشغيل والاستيراد
+```bash
+docker compose up -d
+# استيراد السكيمات (أول مرة فقط):
+docker compose exec -T mysql mysql -uroot -p"$MYSQL_ROOT_PASSWORD" siro_primary  < ../backend/schema_primary.sql
+docker compose exec -T mysql mysql -uroot -p"$MYSQL_ROOT_PASSWORD" siro_ride     < ../backend/schema_ride.sql
+docker compose exec -T mysql mysql -uroot -p"$MYSQL_ROOT_PASSWORD" siro_tracking < ../backend/schema_tracking.sql
+docker compose exec -T mysql mysql -uroot -p"$MYSQL_ROOT_PASSWORD" siro_wallet   < ../payment_server/WalletDB.sql
+docker compose exec -T mysql mysql -uroot -p"$MYSQL_ROOT_PASSWORD" siro_location < ../loction_server/locationDB.sql
+```
+
+## 3) التحقق
+```bash
+docker compose ps                                   # الست خدمات up
+curl -s http://localhost:8080/backend/index.html    # nginx→ملفات
+curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8080/backend/connect.php   # يرد (401/400 طبيعي بلا JWT)
+curl -s http://localhost:8080/fpm-status            # حالة حوض fpm
+docker compose logs socket_driver | tail            # Workerman أقلع على 2020/2021
+```
+اتصال التطبيق للتجربة: `http://IP:8080/backend` + سوكيت `http://IP:2020` — فقط بدّل
+الـ base URLs في `.env` تبع التطبيق وأعد البناء. `APP_DOMAIN` فارغ = حارس
+REGION_MISMATCH متعطل أثناء التجربة.
+
+## 4) اختبار الضغط (الهدف: 10-20 ألف رحلة/ساعة)
+```bash
+cd ../stress_test && npm install
+# دخان أولاً (الأداة القديمة، دفعة صغيرة):
+node load_test.js --trips=10 -b http://localhost:8080/backend -s http://localhost:2020
+# ثم المعدل المستمر:
+node rate_test.js --rate 10000 --duration 10 -b http://localhost:8080/backend -s http://localhost:2020
+node rate_test.js --rate 20000 --duration 10 -b http://localhost:8080/backend -s http://localhost:2020
+node rate_test.js --rate 30000 --duration 5  ...   # حد الانهيار — أين تبدأ p95 بالقفز؟
+```
+**أثناء التشغيل راقب من طرفية ثانية:**
+```bash
+docker stats                                        # cpu/ذاكرة كل حاوية
+docker compose exec mysql sh -c 'tail -f /var/lib/mysql/slow.log'   # استعلامات >200ms
+watch -n2 'curl -s http://localhost:8080/fpm-status'                # طابور fpm (listen queue)
+```
+
+### قواعد قراءة النتيجة بصدق
+1. **سيناريو الاختبار أخف من الرحلة الحقيقية بـ 3-5×** (4 نداءات API + 6 نبضات موقع؛
+   الحقيقية فيها تسعير وبحث وقرب ودردشة). لتبنّي رقم "10k رحلة حقيقية بالذروة"
+   يجب أن يعبر الاختبار **30k** بنجاح >99% و p95<500ms.
+2. الصندوق مشغول ~40% بغيرنا — **افحص خارج الذروة وبجولات قصيرة (5-10 د)**،
+   وأعد الجولة مرتين للتأكد من ثبات الرقم.
+3. مولّد الحمل على نفس الصندوق يسرق ~5% CPU عند هذه المعدلات — مقبول؛ الأدق
+   تشغيله من جهاز آخر نحو `http://IP:8080`.
+4. المُلتزم به للعملاء = الرقم الذي عبر الاختبار، لا أكثر.
+
+## 5) ملاحظات أداء محسومة (لماذا الحاويات لا تبطئنا)
+- الحاوية على لينكس = عمليات عادية بنفس النواة (namespaces/cgroups) — **لا محاكاة ولا آلة افتراضية**. حمل CPU/ذاكرة ≈ صفر.
+- المكان الوحيد الذي يُخسر فيه أداء فعلاً: كتابة قاعدة البيانات فوق overlayfs — **محلول** بـ volume مسمّى (`mysql-data`).
+- أداء PHP الحقيقي يصنعه opcache + مقاس حوض fpm + فهارس MySQL — كلها مضبوطة في `php/` وليست متعلقة بالدوكر أصلاً.
+- التقسيم إلى 6 حاويات لا يكلف أداءً (نفس العمليات) ويعطي: إعادة تشغيل خدمة وحدها، حدود ذاكرة لكل خدمة، لوغات منفصلة، واستنساخ عميل = `clone + .env + up`.