تحرير

مشاركة عبر

اعتبارات البيانات للخدمات المصغرة

Azure DevOps

توضح هذه المقالة اعتبارات إدارة البيانات في هيكل الخدمات المصغرة. نظرًا لأن كل خدمة مصغرة تدير بياناتها الخاصة، فإن تكامل البيانات وتناسقها تمثل تحديًا كبيرًا.

المبدأ الأساسي للخدمات المصغرة هو أن كل خدمة تدير بياناتها الخاصة. يجب ألا تشارك خدمتان مخزن بيانات. بل تكون كل خدمة مسؤولة عن مخزن البيانات الخاص بها، والذي لا يمكن للخدمات الأخرى الوصول إليه مباشرة.

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

Diagram of a wrong approach to CQRS

يؤدي هذا النهج بطبيعة الحال إلى استمرارية متعددة التقنيات — استخدام تقنيات تخزين بيانات متعددة داخل تطبيق واحد. قد تتطلب إحدى الخدمات قدرات المخطط عند القراءة لقاعدة بيانات مستندات. قد تحتاج خدمة أخرى إلى التكامل المرجعي الذي يوفره نظام إدارة قواعد البيانات الارتباطية (RDBMS). كل فريق حر في اتخاذ أفضل خيار لخدمته.

إشعار

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

التحديات

تنشأ بعض التحديات من هذا النهج الموزع لإدارة البيانات. أولًا، قد يكون هناك تكرار عبر مخازن البيانات، مع ظهور نفس عنصر البيانات في أماكن متعددة. على سبيل المثال، قد يتم تخزين البيانات كجزء من عملية، ثم تخزينها في مكان آخر لإعداد التحليلات أو التقارير أو الأرشفة. يمكن أن تؤدي البيانات المكررة أو المقسمة إلى مشكلات في تكامل البيانات وتناسقها. عندما تمتد علاقات البيانات إلى خدمات متعددة، لا يمكنك استخدام تقنيات إدارة البيانات التقليدية لفرض العلاقات.

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

نهج إدارة البيانات

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

  • تبنى الاتساق النهائي حيثما كان ذلك ممكنًا. فهم الأماكن في النظام حيث تحتاج إلى تناسق قوي أو عمليات ACID، والأماكن التي يكون فيها التناسق النهائي مقبولًا.

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

  • بالنسبة للعمليات، استخدم أنماطًا مثل مشرف وكيل المجدولوعملية التعويض للحفاظ على اتساق البيانات عبر العديد من الخدمات. قد تحتاج إلى تخزين جزء إضافي من البيانات التي تسجل حالة وحدة العمل التي تمتد عبر خدمات متعددة، لتجنب الفشل الجزئي بين خدمات متعددة. على سبيل المثال، احتفظ بعنصر عمل في قائمة انتظار معمرة أثناء إجراء عملية متعددة الخطوات.

  • خزن البيانات التي تحتاجها الخدمة فقط. قد تحتاج الخدمة فقط إلى مجموعة فرعية من المعلومات حول كيان مجال. على سبيل المثال، في سياق ربط الشحن، علينا معرفة العميل المرتبط بتسليم معين. ولكننا لا نحتاج إلى عنوان فاتورة العميل - الذي تتم إدارته بواسطة السياق المرتبط بالحسابات. يمكن أن يساعد التفكير بعناية في المجال واستخدام نهج DDD.

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

  • راجع نمط الهيكل المستند إلى الأحداث. في نمط الهيكل هذا، تنشر الخدمة حدثًا عند حدوث تغييرات على نماذجها أو كياناتها العامة. يمكن للخدمات المهتمة الاشتراك في هذه الأحداث. على سبيل المثال، يمكن لخدمة أخرى استخدام الأحداث لإنشاء طريقة عرض مجسدة للبيانات الأكثر ملاءمة للاستعلام.

  • يجب على الخدمة التي تمتلك الأحداث نشر مخطط يمكن استخدامه لأتمتة تسلسل الأحداث وإلغاء تسلسلها، لتجنب الاقتران المحكم بين الناشرين والمشتركين. ضع في اعتبارك مخطط JSON أو إطار عمل مثل Microsoft Bond أو Protobuf أو Avro.

  • على نطاق واسع، يمكن أن تصبح الأحداث بمثابة ازدحام على النظام، لذا فكر في استخدام التجميع أو الدفعات لتقليل الحمل الإجمالي.

مثال: اختيار مخازن البيانات لتطبيق تسليم الطائرات بدون طيار

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

تلخيصًا لما سبق، يحدد هذا التطبيق العديد من الخدمات المصغرة لجدولة عمليات التسليم بواسطة الطائرات بدون طيار. عندما يقوم المستخدم بجدولة تسليم جديد، يتضمن طلب العميل معلومات حول التسليم، مثل مواقع الاستلام والتسليم، وحول الحزمة، مثل حجمها ووزنها. تُعرف هذه المعلومات وحدة عمل.

تهتم خدمات الواجهة الخلفية المختلفة بأجزاء مختلفة من المعلومات في الطلب، كما تحتوي على ملفات تعريف مختلفة للقراءة والكتابة.

Diagram of data considerations

خدمة التسليم

تخزن خدمة التسليم معلومات حول كل عملية تسليم مجدولة حاليًا أو جارية. وهي تستمع للأحداث من الطائرات بدون طيار، وتتعقب حالة عمليات التسليم الجارية. كما ترسل أحداث المجال مع تحديثات حالة التسليم.

من المتوقع أن يتحقق المستخدمون بشكل متكرر من حالة التسليم أثناء انتظار حزمتهم. لذلك، تتطلب خدمة التسليم مخزن بيانات يؤكد على معدل النقل (القراءة والكتابة) عبر التخزين طويل الأجل. بالإضافة إلى ذلك، لا تقوم خدمة التسليم بإجراء أي استعلامات أو تحليلات معقدة، بل تحضر ببساطة أحدث حالة لتسليم معين. اختار فريق خدمة التسليم Azure Cache for Redis لأداء القراءة والكتابة العالي ليها. المعلومات المخزنة في Redis قصيرة الأجل نسبيًا. بمجرد اكتمال التسليم، تكون خدمة محفوظات التسليم هي نظام السجل.

خدمة محفوظات التسليم

تستمع خدمة محفوظات التسليم لأحداث حالة التسليم من خدمة التسليم. تقوم بتخزين هذه البيانات في تخزين طويل الأجل. هناك حالتا استخدام مختلفتان لبيانات المحفوظات هذه، والتي لها متطلبات تخزين بيانات مختلفة.

السيناريو الأول هو تجميع البيانات لغرض تحليل البيانات، من أجل تحسين الأعمال أو تحسين جودة الخدمة. لاحظ أن خدمة محفوظات التسليم لا تقوم بإجراء التحليل الفعلي للبيانات. إنها مسؤولة فقط عن الاستيعاب والتخزين. لهذا السيناريو، يجب تحسين التخزين لتحليل البيانات عبر مجموعة كبيرة من البيانات، باستخدام نهج مخطط عند القراءة لاستيعاب مجموعة متنوعة من مصادر البيانات. يعد Azure Data Lake Store مناسبا لهذا السيناريو. Data Lake Store هو نظام ملفات Apache Hadoop متوافق مع نظام Hadoop للملفات الموزعة (HDFS) ويتم ضبطه لأداء سيناريوهات تحليلات البيانات.

السيناريو الآخر هو تمكين المستخدمين من البحث عن محفوظات التسليم بعد اكتمال التسليم. لم يتم تحسين Azure Data Lake لهذا السيناريو. للحصول على الأداء الأمثل، توصي Microsoft بتخزين بيانات السلسلة الزمنية في Data Lake في مجلدات مقسمة حسب التاريخ. (راجع ضبط Azure Data Lake Store لتحقيق أفضل أداء). ومع ذلك، فإن هذه البنية ليست مثالية للبحث عن السجلات الفردية حسب المعرف. ما لم تكن تعرف الطابع الزمني أيضًا، يتطلب البحث حسب المعرف مسح المجموعة بأكملها ضوئيًا. لذلك، تخزن خدمة محفوظات التسليم أيضا مجموعة فرعية من البيانات التاريخية في Azure Cosmos DB للبحث بشكل أسرع. لا تحتاج السجلات إلى البقاء في Azure Cosmos DB إلى أجل غير مسمى. يمكن أرشفة عمليات التسليم القديمة — على سبيل المثال، بعد شهر. يمكن القيام بذلك عن طريق تشغيل عملية دفعية عرضية. يمكن أن تقلل أرشفة البيانات القديمة من تكاليف Cosmos DB مع الاحتفاظ بالبيانات المتاحة لإعداد التقارير التاريخية من Data Lake.

خدمة الحزمة

تخزن خدمة الحزمة معلومات حول جميع الحزم. متطلبات التخزين للحزمة هي:

  • التخزين طويل الأجل.
  • قادر على التعامل مع حجم كبير من الحزم، مما يتطلب معدل نقل عالي للكتابة.
  • دعم الاستعلامات البسيطة حسب معرف الحزمة. لا توجد صلات معقدة أو متطلبات للتكامل المرجعي.

نظرا لأن بيانات الحزمة ليست ارتباطية، فإن قاعدة البيانات الموجهة للمستندات مناسبة، ويمكن ل Azure Cosmos DB تحقيق إنتاجية عالية باستخدام المجموعات المقسمة. الفريق الذي يعمل على خدمة الحزمة على دراية بمكدس MEAN (MongoDB وExpress.js وAngularJS وNode.js)، لذلك يقومون بتحديد MongoDB API ل Azure Cosmos DB. يتيح لهم ذلك الاستفادة من تجربتهم الحالية مع MongoDB، مع الحصول على فوائد Azure Cosmos DB، وهي خدمة Azure مدارة.

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

تعرف على أنماط التصميم التي يمكن أن تساعد في التخفيف من بعض التحديات الشائعة في هيكل الخدمات المصغرة.

أنماط التصميم للخدمات المصغرة