نواة AurabaseRust: واجهة خلفية موحدة كخدمة

تقوم معظم Postgres BaaS مفتوحة المصدر بحزم خدماتها بلغات متعددة. هذا ليس حكمًا قيميًا - بل هو حقيقة معمارية لها عواقب ملموسة: مثل العديد من سلاسل الترجمة واتفاقيات الخطأ ومنطق المصادقة التي يجب الحفاظ عليها في التزامن كما توجد لغات قيد التشغيل.

في Aurabase، طبقة المنتج التي نكتبها ونحافظ عليها بأنفسنا - البوابة، والمصادقة، وقاعدة البيانات، والوقت الفعلي، والتخزين، والإشعارات، والذكاء الاصطناعي، والتزويد، وإدارة الحساب - هي مساحة عمل Cargo واحدة، ولغة واحدة، وسلسلة بناء واحدة. هذا هو الاختيار الذي يوثقه هذا الملف.

يعلن الجذر Cargo.toml عن مساحة عمل Cargo في محلل v2 مع 18 عضوًا: 11 خدمة أعمال، وaura-cliCLI، و5 مكتبات مشتركة، وaurabase-rsSDK. هذه هي القائمة الفعلية، كما تظهر في المستودع.

[workspace]
resolver = "2"

members = [
    # الخدمات (11)
    "services/aura-gateway", "services/aura-auth", "services/aura-db",
    "services/aura-provisioner", "services/aura-realtime", "services/aura-storage",
    "services/aura-functions", "services/aura-notifications", "services/aura-ai",
    "services/aura-migrator", "services/aura-control",
    # أدوات
    "aura-cli",
    # ليب (5)
    "libs/aura-core", "libs/aura-crypto", "libs/aura-db-adapters",
    "libs/aura-migrations", "libs/aura-telemetry",
    "aurabase-rs",
]

التبعيات المشتركة موجودة في [workspace.dependencies]: Axum 0.8 (مع WebSockets، ومتعددة الأجزاء، ووحدات الماكرو)، Tokio، Tower/Tower-HTTP، SQLx 0.8 (Postgres + MongoDB عبر mongodb لمحرك NoSQL الثانوي)، async-nats 0.47، sqlparser 0.53 (التحقق من صحة SQL لـ NL2SQL)، oauth2 5، jsonwebtoken 10، واثنين من libs الأداء الموجودة في كل خدمة تقريبًا: mimalloc كمخصص عام وmoka/dashmap لذاكرة التخزين المؤقت في الذاكرة.

يوثق ملف تعريف الإصدار خيارًا مفترضًا: panic = "unwind" بدلاً من "abort". تعليق الملف واضح بذاته - يتم عزل حالة الذعر في معالج Axum/Tokio بواسطة وقت التشغيل (يرجع الطلب المتأثر 500) بدلاً من إسقاط العملية بأكملها وقطع الطلبات المنافسة. إن زيادة أداءabort (حوالي 1 إلى 2% من RPS) لا تستحق فقدان العزل، وفقًا لهذه الملاحظة نفسها. هذه مقايضة بين الموثوقية والسرعة موثقة في الكود، وليست مطالبة تسويقية.

cargo build --workspace واحد يجمع كل شيء. يقوم cargo test --workspace واحد بتشغيل مجموعة الاختبار بأكملها. cargo clippy --workspace --all-targets -- -D warnings واحد يربط المنتج بأكمله بنفس القواعد. تفاصيل هذه البنية - وراثة التبعيات، والرسم البياني الداخلي بين libs والخدمات، والمزالق التي واجهناها أثناء تطويرها - هي موضوع مقال مخصص: هندسة مساحة عمل Cargo، وكيفية بناء واجهة خلفية Rust متعددة الخدمات.

خطوط الصدأ حسب الخدمة (ابحث عن الخدمات -اسم '*.rs' | xargs wc -l، 23 أغسطس 2026):

السيطرة على الهالة

36 024

هالة ديسيبل

30 255

هالة المصادقة

28 431

مزود الهالة

28 271

إشعارات الهالة

18 498

سوف يكون

18 305

بوابة الهالة

16 938

هالة في الوقت الحقيقي

16 799

تخزين الهالة

13 747

وظائف الهالة

11 619

مهاجر الهالة

538

باستثناء libs المشتركة (محولات aura-db: 24,725 سطرًا، aura-core: 7,259، هجرة الهالة: 3,641، aura-crypto: 2,718، قياس الهالة عن بعد: 201)، وCLI (aura-cli: 9,845) وRust SDK (aurabase-rs: 6,363). aura-migrator، وهي مهمة ترحيل تستخدم لمرة واحدة وليست خادم HTTP طويل الأمد، تظل عمدًا أصغر خدمة في مساحة العمل.

كل خدمة عبارة عن ثنائي Axum/Tokio مستقل، بتكوينه ومنفذه الخاصين. يكشف عشرة من الأحد عشر عن /health و/metrics ويعلنون أن mimalloc هو المُخصص العام - الاستثناء الوحيد، aura-migrator، هو مهمة ذات غرض واحد وليس خادمًا يعمل بشكل مستمر.

يتحدث aura CLI (≈ 9,800 سطر) مع نفس واجهات برمجة التطبيقات مثل مجموعات SDK - وليس له مسار مميز. يوجد المرجع الكامل لكل خدمة في وثائق بنية ومرجع CLI.

في المكدس متعدد اللغات، يجب إعادة تنفيذ قاعدة الأمان - تنسيق الخطأ، وحماية SSRF، وتحديد المعدل - في كل لغة، وغالبًا ما تتغير بمرور الأشهر. يقوم Aurabase بتشفيرها مرة واحدة، في مساحة العمل lib، والتي تستهلكها جميع الخدمات المعنية.

النتيجة المباشرة: ينتشر التصحيح الأمني في aura-core - حماية SSRF، على سبيل المثال - إلى كل خدمة مستهلك في cargo buildالتالية، وليس من خلال خمس تصحيحات منفصلة بخمس لغات.

aura-gateway يفصل بين سطحين ليس لهما نفس العملاء ولا نفس نموذج المصادقة. يتلقى مستوى البيانات (المنفذ 8080، المتغير GATEWAY_PORT) حركة مرور SDK/التطبيق، والتي تمت مصادقتها بواسطة مفتاح واجهة برمجة التطبيقات (apikeyأو X-API-Key أو ?apikey=). يستقبل مستوى الإدارة (المنفذ 8090، MANAGEMENT_PORT) حركة مرور الاستوديو/المسؤول، والتي تمت مصادقتها بواسطة وحدة تحكم JWT (Authorization: Bearer).

// مستوى البيانات - مفتاح API
.route("/v1/auth/{*path}", any(auth_proxy))
.route("/v1/db/{*path}", any(db_proxy))
.route("/v1/realtime/ws", get(realtime_ws_proxy))
.route("/v1/realtime/sse", get(realtime_sse_proxy))
.route("/v1/storage/{*path}", any(storage_proxy))
.route("/v1/notifications/{*path}", any(notifications_proxy))
.route("/v1/ai/{*path}", any(ai_dispatcher))
.route("/v1/functions/{*path}", any(functions_proxy))

// خطة الإدارة — وحدة تحكم JWT
.route("/v1/control/{*path}", any(control_proxy))

يحمل كل مستوى مجموعته الخاصة من البرامج الوسيطة - تعريف الاستعلام، وسجل الوصول، وحد المعدل، والمصادقة (خاصة بالطائرة)، وقاطع الدائرة، ثم الوكيل - التي يتم تنفيذها في وحدات منفصلة (middleware/rate_limit.rs, middleware/circuit_breaker.rs, middleware/auth_data_plane.rs, middleware/auth_management_plane.rs) بدلاً من سلسلة واحدة مشتركة عن طريق الخطأ بين سطحين لا ينبغي أن يثق كل منهما في الآخر بنفس الطريقة. طريق.

الترتيب الدقيق للبرامج الوسيطة، وتحديد المعدل لكل هدف ووكيل NATS/HTTP هو موضوع مقال مخصص: بوابة مزدوجة المستوى، تصميم بوابة API لمستوى البيانات/مستوى الإدارة في Rust.

واجهة REST API التي تم إنشاؤها ذاتيًا والتي تستهلكها SDK ليست وحدة Rust داخلية: إنها النسخة الثنائية الحقيقية PostgREST (postgrest/postgrest:v12.2.8) ، المنتشرة في نسختين متماثلتين لكل مشروع مخصص (deploy/cnpg/tenant-postgrest.yaml)، في نفس الموقع مع مثيل CNPG الخاص بالمستأجر. يقوم aura-provisioner بإنشاء هذا النشر، ويتحقق aura-db من نقطة النهاية الخاصة به OPTIONS بعد كل إعادة تحميل للمخطط للتأكد من أن PostgREST قد أخذ تغيير DDL في الاعتبار.

هذا خيار معماري مفترض، وليس اختصارًا: PostgREST هو مشروع ناضج ومعتمد على نطاق واسع، ولن تؤدي إعادة كتابة سلوكه شيئًا فشيئًا في Rust إلى أي شيء. يركز عمل Aurabase's Rust على — التوجيه متعدد المستأجرين، والتزويد، وعزل الشبكة بواسطة NetworkPolicy، والمصادقة المشتركة مع البوابة، وإعادة تحميل المخطط المنسق — وليس داخل محرك الاستعلام نفسه. ما يغطيه هذا التوافق حقًا، وأين يتوقف، هو موضوع مقال منفصل: PostgREST والتوافق الفعلي وبدائل.

نفس المنطق من جانب GraphQL: يتم تثبيت ملحق Postgres pg_graphql (حزمة .deb المترجمة مسبقًا، الإصدار 1.6.1) في صورة CNPG المخصصة ويتم تنشيطه عند الطلب لكل مشروع عبر نقطة النهاية POST /v1/control/projects/{project_id}/graphql/enable - وليس محرك GraphQL المعاد كتابته أيضًا. التفاصيل والمقارنة الصادقة مع Hasura وPostGraphile: Native GraphQL API على Postgres مع pg_graphql.

لا يعتمد عزل المستأجرين المتعددين على مرشح WHERE tenant_id = ? المضاف بواسطة تطبيق ORM: يمر كل طلب عبر دور aura_authenticator، الذي ينفذ نطاق معاملة SET LOCAL ROLE tenant_<uuid> قبل تنفيذ الطلب - بالضبط النموذج الذي تتوقعه PostgREST نفسها. يقوم الأمان على مستوى الصف بالباقي، على مستوى المحرك، وليس على مستوى رمز العمل.

لا تشترك جميع المشاريع في نفس طوبولوجيا Postgres. يعرض رمز aura-provisioner نوع ProjectInstanceKind مع متغيرين حقيقيين على الأقل: FullyDedicated (مثيل CNPG مخصص بالكامل للمشروع) وSharedClusterDedicated (المخطط المعزول بواسطة RLS على مجموعة CNPG مشتركة). تحدد الخطة المشتركة الهيكل - فهي ليست وعدًا موحدًا بـ "قاعدة مخصصة للجميع".

تعلن عشر من خدمات الأعمال الأحد عشر أن async-nats هي تبعية مباشرة في Cargo.toml — فقط aura-migrator لا تستغني عنها. ما لا يقوله اسم الصندوق هذا: تستخدم هذه الخدمات في كل مكان تقريبًا واجهة برمجة تطبيقات NATS الأساسية (Client::publish / publish_with_headers, التسليم مرة واحدة على الأكثر بدون استمرار أو إعادة تشغيل)، وليس JetStream. هذه هي الحالة التي تم التحقق منها في التعليمات البرمجية للاستخدامات الثلاثة الأكثر أهمية: توزيع PostgreSQL CDC على aura-realtime، وإخطار وظائف Edge Functions في aura-functions (يعيش DLQ نفسه في Postgres، وليس في NATS)، وتوفير الأحداث بين aura-provisioner وبقية الأسطول.

يظهر JetStream - وضع استمرارية NATS والتدفقات المسماة - فقط في موقع واحد تم التحقق منه في monorepo: المثيل المشترك KV Store في aura-realtime (الحاوية aura_presence، مخزن الذاكرة، 60 ثانية max_age)، الذي يزامن الأشخاص المتصلين بأي قناة عبر مثيلات متعددة من ws-front - حالة مشتركة للمثيلات المشتركة، وليس دفق من الأحداث لاعادتها. لم يتم العثور على تدفقات JetStream المستمرة في أي مكان آخر في مساحة العمل. إن تفاصيل خط أنابيب CDC - wal2json، واختيار cdc-worker الفريد بواسطة Lease Kubernetes، وتوزيع NATS الأساسي إلى النسخ المتماثلة ws-front، وإعادة التحقق من RLS بواسطة المشترك - هي موضوع مقال مخصص: بث PostgreSQL CDC مع NATS. تغطي وثائق Realtime الاستخدام على جانب SDK.

هذا هو الفارق الدقيق الأكثر أهمية في هذا الملف، والخروج الحقيقي الوحيد عن الصدأ النقي في كود منتج Aurabase. تحمل كل دالة حقل runtime بقيمة "wasm" أو "deno". يختار معالج الاستدعاء مسار التنفيذ وفقًا لذلك - المقتطف الفعلي، الذي تم التعليق عليه في الكود نفسه:

// الإرسال وفقًا لوقت التشغيل: WASM (wasmtime) أو Deno (V8 المعزول عبر وقت تشغيل الحافة)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // وكيل لوقت تشغيل Aura-Edge-V8 المعزول (supabase/edge-runtime، MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

وضع wasm أصلي: aura-functions يعتمد مباشرة على Wasmtime (الإصدار 43، ميزات async و cranelift) وينفذ الوحدة في نفس عملية الصدأ، مع عد الوقود والانقطاع حسب العصر وحدود الذاكرة عبر StoreLimits. وضع deno - الذي يستخدم افتراضيًا في محرر الاستوديو، للتوافق المباشر تقريبًا Deno.serve() مع كود Supabase الموجود - يفوض التنفيذ إلى aura-edge-runtime، وهي خدمة TypeScript منفصلة تتكون من حوالي 550 سطرًا، تم تصميمها بشكل صريح - يستشهد بها تعليق رأس الملف المصدر نفسه - على supabase/edge-runtime (ترخيص MIT)، الذي يعزل كل استدعاء في V8 المعزول الخاص به.

للحصول على المستند الإرشادي لكلا مساري النشر، راجع Edge Functions. للحصول على دليل ترحيل Deno من Supabase، راجع ترحيل مشروع Supabase إلى Aurabase، الذي وثق بالفعل هذا التمييز قبل هذا الملف.

إذا قمت فقط باستدعاء واجهة برمجة التطبيقات (API) من خلال SDK، فستكون هذه البنية غير مرئية - وهذا هو الهدف. إنه مهم بشكل أساسي لثلاثة جماهير: أولئك الذين يقيمون الموثوقية التشغيلية للواجهة الخلفية متعددة المستأجرين قبل ترحيل بيانات الإنتاج إليها، وأولئك الذين يخططون للمساهمة في المستودع (MIT، monorepo الفردي)، وأولئك الذين يريدون فهم سبب انتشار التصحيح الأمني ​​على جانب Aurabase بسرعة وليس ببطء.

بشكل ملموس: يغطي IC واحد (cargo build --workspace, cargo test --workspace, cargo clippy --workspace --all-targets -- -D warnings) 90% أو أكثر من سطح المنتج. من المحتمل أن تؤثر مراجعة الكود على aura-core على عشر خدمات في وقت واحد - للأفضل (لا يضيع الإصلاح على طول الطريق) وللأسوأ (ينتشر التغيير المعزول بشكل سيء بنفس السرعة). إنه حل وسط، وليس حلاً سحريًا - ولهذا السبب بالتحديد نقوم بتوثيق البنية الفعلية بدلاً من ملخص تسويقي.

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

المجموعة أ – الإطار والهندسة المعمارية

Axum vs Actix-web: أي إطار عمل لواجهة Rust الخلفية في الإنتاج؟تم النشر

هندسة مساحة عمل الشحن: كيفية هيكلة واجهة خلفية متعددة الخدمات من Rustتم النشر

بوابة ثنائية المستوى: تصميم بوابة API لمستوى البيانات/مستوى الإدارة في Rustتم النشر

المجموعة ب - واجهة برمجة التطبيقات ذاتية الإنشاء في Postgres

PostgREST: ما يغطيه التوافق حقًا، وما هي البدائل الموجودةتم النشر

Native GraphQL API على Postgres مع pg_graphql: ما لا يفعله Hasura وPostGraphile بنفس الشيءتم النشر

RLS وقاعدة مخصصة لكل مشروع: اختيار العزل متعدد المستأجرين من Aurabaseتم النشر

المجموعة ج - الوقت الحقيقي والمراسلة

توزيع PostgreSQL CDC مع NATS: بنية الوقت الفعليتم النشر

المجموعة D - WebAssembly لوظائف الحافة

المجموعة E – الهجرة والبدائل

ترحيل مشروع Supabase إلى Aurabase دون إعادة كتابة سياسات RLS الخاصة بكتم النشر

الاستضافة الذاتية السيادية: وضع Aurabase في مواجهة BaaS الأصلي في الصدأ، قريبًا