Get best of the week

انقسام البيانات: إعادة التفكير في العلاقة مع البيانات والخدمات

تحية للجميع! لدينا أخبار رائعة ، في يونيو ستطلق OTUS دورة "مهندس البرمجيات" مرة أخرى ، حيث نشارك معك المواد المفيدة تقليديًا.



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

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

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



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

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

لن يكون التغليف دائمًا صديقك


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



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



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



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


تستخدم معظم خدمات الأعمال نفس تدفق البيانات ، لذا فإن عملها متشابك دائمًا.

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

انقسام البيانات


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

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

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



وهنا تنشأ معضلة. تناقض. تفرع ثنائي. بعد كل شيء ، تدور أنظمة المعلومات حول توفير البيانات ، والخدمات تتعلق بالإخفاء.

هاتان القوتان أساسيتان. إنها تشكل أساس معظم عملنا ، وتسعى باستمرار للتميز في الأنظمة التي ننشئها.

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



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

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

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



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


كلما كانت النسخ أكثر قابلية للتغيير ، كلما اختلفت البيانات بمرور الوقت.

والأسوأ من ذلك ، أنه من الصعب تصحيح هذه البيانات في وقت لاحق ( يمكن لـ MDM أن تنقذ هنا). في الواقع ، بعض المشاكل التكنولوجية المستعصية التي تواجهها الشركة ترجع إلى البيانات غير المتجانسة التي تتضاعف من التطبيق إلى التطبيق.

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



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


دورة إفلاس البيانات

الجداول: نهج لامركزي للبيانات والخدمات


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

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

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



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

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

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


تخلص من انقسام البيانات بتقسيم التدفق المناعي للدول. ثم قم بإضافة هذه الميزة إلى كل خدمة باستخدام معالجة تدفق الحالة.

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


مشاركة البيانات حتى لا يتم انتهاك سلامتها. قم بتغليف دالة ، وليس مصدرًا ، في كل خدمة تحتاجها.

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

لذلك ، فإن النهج الذي تم النظر فيه اليوم له مزايا عديدة:

  • يتم استخدام البيانات في شكل تدفقات مشتركة يمكن تخزينها لفترة طويلة في السجلات ، ويتم توصيل آلية العمل مع البيانات المشتركة في كل سياق فردي ، مما يسمح للخدمات بالعمل بسرعة وسهولة. بهذه الطريقة ، يمكنك الموازنة بين انقسام البيانات.
  • , , . .
  • Stateful Stream Processing , , .
  • , , , -.
  • , . , .
  • , .

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

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



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


.

More articles:


All Articles