على الشركة الناشئة أن تتقن قرارات معمارية قليلة في إصدارها الأول، ونادرًا ما تكون قرارات حجمٍ لم تبلغه بعد. فالقرارات التي تستحق العناية في المنتج الأولي (MVP) هي التي يسهل اتخاذها الآن ويصعب تغييرها لاحقًا: كيف تقسّم الكود إلى مجالات، ومن يملك أي بيانات، والعقود بين أجزاء النظام، وما الذي تراه في بيئة الإنتاج، وكيف تُطلق التغييرات وتتراجع عنها. أما الخدمات المصغّرة وتجزئة قواعد البيانات والنشر في عدة مناطق، فتستطيع عادةً الانتظار حتى تملك دليلًا حقيقيًا على حاجتك إليها.
ستجد لكل قرار من الخمسة ما الذي يكفي منه في مرحلة المنتج الأولي، ومتى تعيد النظر فيه مع نمو المنتج.
الخطة المبنية على عتبات أعداد المستخدمين تخمّن مشكلات قد لا يواجهها المنتج أبدًا. وقابلية التراجع معيار أفضل: فأنت تستبدل مكتبة تخزين مؤقت أو أداة سجلات في تغيير محدود عادةً، أما تغيير طريقة فصل بيانات المستأجرين، أو فك وحدات تقرأ جداول بعضها، فقد يستغرق شهورًا بعد أن يعتمد عليه العملاء والتكاملات.
أنفق وقت التصميم حيث يكون التراجع مكلفًا، وأبقِ ما سواه بسيطًا. ففريق صغير يُطلق تطبيقًا واحدًا بحدود داخلية واضحة سيجد تشغيله وتتبّع أخطائه وتغييره أسهل عادةً من مجموعة خدمات صُممت لحركة لم تصل بعد.
ابدأ بتطبيق واحد قابل للنشر، مقسّم إلى وحدات تحمل أسماء قدرات الأعمال، مثل الكتالوج والطلبات والفوترة والحسابات، لا أسماء الطبقات التقنية. وتعرض كل وحدة واجهة عامة صغيرة وتُبقي تفاصيلها الداخلية خاصة.
واجعل الحدود حقيقية:
- تتواصل الوحدات عبر واجهاتها، ولا تصل أبدًا إلى أصناف وحدة أخرى أو جداولها مباشرة.
- يضم الكود المشترك أدوات عامة فقط، ولا يضم أي قاعدة من قواعد الأعمال.
- تُفشل الفحوص الآلية، مثل قواعد الاعتماديات في البناء، عملية البناء حين يتجاوز الكود أي حد.
تنال بهذا معظم فائدة الخدمات المنفصلة في التصميم دون كلفتها التشغيلية. وإن احتاجت وحدة لاحقًا إلى توسع أو نشر أو تغيير مستقل، فحدودها مرسومة سلفًا، وقد يقل جهد إعادة الهيكلة عند فصلها. لكنك ما زلت بحاجة إلى إعادة تصميم حدود المعاملات وزمن الاستجابة ومعالجة الفشل لتناسب التشغيل الموزّع.
شكل 1: نظّم الكود حول قدرات الأعمال. ابدأ بتطبيق ذي وحدات واضحة.
خيار افتراضي جيد: لكل جدول خاص بالأعمال وحدة واحدة مسؤولة عنه، وهي وحدها التي تكتب فيه. وتطلب الوحدات الأخرى ما تحتاجه عبر واجهة المالك أو تتفاعل مع أحداثه. وهذا يقلل الارتباط المباشر بالبيانات، وإن بقيت مسارات العمل والمعاملات المشتركة بحاجة إلى تصميم صريح.
وإن كنت تخدم عدة عملاء من الشركات، فحدد نموذج تعدد المستأجرين مبكرًا، لأنه يشكّل كل استعلام وكل ترحيل وكل مراجعة أمنية:
- جداول مشتركة بمعرّف للمستأجر في الصفوف التابعة للمستأجر: أبسط تشغيلًا غالبًا، لكن كل استعلام يجب أن يرشّح بشكل صحيح، فافرض هذا الترشيح مركزيًا بدل الاعتماد على تذكّر كل مطوّر.
- مخطط أو قاعدة بيانات لكل مستأجر: قد يوفّر فصلًا أكبر وتصديرًا أسهل لكل عميل، مقابل عمل تشغيلي أكبر. وفصل المخططات وحده ليس حدًا أمنيًا؛ فبيانات الاعتماد وصلاحيات القاعدة وتفويض التطبيق هي التي يجب أن تفرض العزل.
وأيًّا كان اختيارك، فاختبر منع القراءة والكتابة غير المصرح بهما بين المستأجرين عبر الواجهات والتخزين المؤقت والمهام وفهارس البحث والتصدير. وقرّر مبكرًا أيضًا كيف تُطلق تغييرات المخطط: فالترحيلات المتوافقة مع الإصدار السابق، التي تسمح بعمل الكود القديم والجديد معًا، تجعل النشر والتراجع أكثر أمانًا بكثير. واستعد نسخة احتياطية عمدًا، في يوم هادئ، قبل أن تحتاج إليها.
العقود هي الاتفاقات بين أجزاء نظامك، وبين نظامك والعالم الخارجي، فاكتبها:
- واجهات API الخارجية: صِفها في مواصفة مثل OpenAPI، وحدد سياسة الإصدارات قبل أن يتكامل أول شريك، واجعل عمليات الكتابة متساوية الأثر (Idempotent) حتى لا يُنشئ طلب مُعاد إرساله طلب شراء أو دفعة مكررة.
- الأحداث: إن كانت الوحدات تتواصل عبر الأحداث، فامنح كل حدث مخططًا موثقًا ومالكًا، وتعامل مع أي تغيير فيه كما تتعامل مع تغيير واجهة API.
- الخدمات الخارجية: ضع مزوّدي الدفع والرسائل وأمثالهم خلف محوّل خاص بك حتى يبقى كود التكامل في مكان واحد. وقد يعني تبديل المزوّد مع ذلك ترحيل البيانات واستبدال الرموز وتغيير العقود واختبار الرحلة كاملة.
والعقود الواضحة هي أيضًا ما يجعل الفصل اللاحق آمنًا؛ فالواجهة الموثقة تحدّ مما يجب على المستدعين تغييره عند نقل الوحدة خلف حد شبكي، لكن الاتصال البعيد يجلب زمنًا وفشلًا جزئيًا وإعادة محاولات على المستدعين التعامل معها.
في الكتابات القابلة لإعادة المحاولة، اربط مفتاح منع التكرار بالمستأجر والعملية ومحتوى الطلب، واحفظ النتيجة ذريًا. ارفض إعادة استخدام المفتاح مع مدخلات مختلفة، واختبر المحاولات المتزامنة. وتحتاج الجهات المستهلكة للأحداث أيضًا إلى معالجة التكرار وسياسة صريحة للترتيب.
سيتعطل شيء ما في الإنتاج، وستحتاج حينها إلى رؤية ما حدث دون تخمين. فابنِ ذلك منذ أول نشر:
- سجلات منظمة تحمل معرّفًا للطلب يرافقه عبر الوحدات والمهام الخلفية.
- مقاييس لأهم رحلات المستخدم، مثل التسجيل وإتمام الشراء وإنشاء التقارير: كم ينجح، وكم يفشل، وكم يستغرق.
- تتبّع للطلبات البطيئة أو الفاشلة، لترى أي خطوة استهلكت الوقت.
- تنبيهات على الأعراض التي يلاحظها المستخدم، لا على كل تحذير داخلي.
وأبعد البيانات الشخصية عن السجلات أو أخفِها، وحدد مدة الاحتفاظ بها. والبيانات نفسها تفيد المعمارية أيضًا: فابنِ قرارات التخزين المؤقت والطوابير وفصل الوحدات على ما تراه في الإنتاج.
طريقة إطلاق التغييرات تحدد عدد المرات التي تستطيع فيها الإطلاق بأمان. فمن البداية:
- شغّل اختبارات آلية وانشر عبر خط مؤتمت لا يدويًا.
- استخدم مفاتيح الميزات لفصل نشر الكود عن إطلاق الميزة، فتستطيع إيقاف ميزة دون إعادة نشر.
- أطلق تدريجيًا حيث أمكن، للمستخدمين الداخليين أو لحصة صغيرة من الحركة أولًا.
- وثّق طريقة التراجع عن كل إصدار، بما في ذلك مصير البيانات التي كتبها الإصدار الجديد.
تحدّ الإصدارات الصغيرة من نطاق التأثر وتسهّل التدرّب على الاستعادة. لكن إطفاء مفتاح ميزة أو إعادة نشر الإصدار القديم لا يلغي كتابات البيانات أو الدفعات أو الرسائل. فحافظ على توافق المخططات، وخطط لمطابقة البيانات أو الإجراءات التعويضية، وأجّل الحذف النهائي حتى تتحقق من الاستعادة.
شكل 2: راقب كل إطلاق تدريجي. خطط لاستعادة البيانات أيضًا.
أعد النظر في القرارات الخمسة في محطات منتظمة، مثل ما قبل إطلاق كبير أو جولة تمويل، وكلما تغيّرت الأدلة. ومن الإشارات التي تستحق التصرف: وحدة تحتاج إلى توسع أو جدول نشر مختلف، أو حدود فرق تتصادم باستمرار في قاعدة كود واحدة، أو مستأجر تختلف متطلبات بياناته أو امتثاله عن الآخرين.
ويقدّم إطار AWS Well-Architected هيكلًا مفيدًا لهذه المراجعات عبر ركائزه الست: التميز التشغيلي، والأمان، والموثوقية، وكفاءة الأداء، وتحسين التكلفة، والاستدامة. وتستطيع استخدامه عدسةً للمراجعة دون أن تستخدم أي خدمة من AWS. وحين تحتاج وحدة فعلًا إلى الخروج، فأسلوب Strangler Fig في توجيه الحركة تدريجيًا إلى المكوّن الجديد ينطبق على نظامك الفتي كما ينطبق على البرمجيات القديمة؛ ويشرح دليلنا عن تحديث الأنظمة القديمة بنمط Strangler Fig خطواته.
وهناك قراران أسبق يشكّلان كل ذلك: قبل أن تبني أصلًا، تحقّق هل يغطي منتج SaaS حاجتك، مستعينًا بإطار المفاضلة بين SaaS والبرمجيات المخصصة. ثم اختر تقنية يستطيع فريقك دعمها لسنوات؛ وتوضح مقارنتنا بين Laravel وNode.js لواجهات API المؤسسية كيف تقرر بالأدلة.
وإن كنت تخطط لإصدار أول، فيمكن لفريق خدمة تصميم وتطوير المواقع أن يساعدك في إرساء هذه الأسس الخمسة دون مبالغة في البناء.
- Amazon Web Services. AWS Well-Architected Framework: الركائز الست المستخدمة في مراجعات المعمارية.
- Amazon Web Services. Strangler fig pattern، ضمن AWS Prescriptive Guidance: الاستبدال التدريجي خلف واجهة توجيه، مع تعايش المكوّنات القديمة والجديدة.
القرارات الخمسة وخياراتها الافتراضية الموصى بها إرشادات هندسية من تكنوستاك، لا متطلبات من AWS أو أي مزوّد آخر.
