أهلاً بكم! لدينا أخبار رائعة، ستطلق OTUS الدورة مرة أخرى في يونيو ، فيما يتعلق بالموضوع الذي نشارك فيه تقليديًا المواد المفيدة معك.
إذا صادفت موضوع الخدمات الصغيرة هذا دون أي سياق، فسوف يُغفر لك اعتقادك أنه غريب بعض الشيء. إن تقسيم التطبيق إلى أجزاء متصلة بواسطة شبكة يعني بالضرورة إضافة أوضاع معقدة للتسامح مع الأخطاء إلى النظام الموزع الناتج.
على الرغم من أن هذا النهج يتضمن تقسيمه إلى العديد من الخدمات المستقلة، إلا أن الهدف النهائي هو أكثر بكثير من مجرد تشغيل هذه الخدمات على أجهزة مختلفة. نحن نتحدث هنا عن التفاعل مع العالم الخارجي، والذي يتم توزيعه أيضا في جوهره. ليس بالمعنى التقني، بل بمعنى النظام البيئي الذي يتكون من العديد من الأشخاص والفرق والبرامج، وكل جزء من هذه الأجزاء يحتاج بطريقة ما إلى القيام بعمله.
فالشركات، على سبيل المثال، هي عبارة عن مجموعة من الأنظمة الموزعة التي تساهم بشكل جماعي في تحقيق هدف ما. لقد تجاهلنا هذه الحقيقة لعقود من الزمن، محاولين تحقيق التوحيد عن طريق ملفات FTPing أو استخدام أدوات تكامل المؤسسات مع التركيز على أهدافنا المعزولة. ولكن مع ظهور الخدمات تغير كل شيء. لقد ساعدتنا الخدمات على النظر إلى ما هو أبعد من الأفق ورؤية عالم من البرامج المترابطة التي تعمل معًا. ومع ذلك، من أجل العمل بنجاح، من الضروري التعرف على عالمين مختلفين بشكل أساسي وتصميمهما: العالم الخارجي، حيث نعيش في نظام بيئي يضم العديد من الخدمات الأخرى، وعالمنا الشخصي الداخلي، حيث نحكم بمفردنا.
هذا العالم الموزع يختلف عن العالم الذي نشأنا فيه واعتدنا عليه. مبادئ بناء العمارة المتجانسة التقليدية لا تصمد أمام النقد. لذا فإن الحصول على هذه الأنظمة بالشكل الصحيح هو أكثر من مجرد إنشاء رسم تخطيطي رائع للوحة المعلومات أو إثبات رائع للمفهوم. والنقطة المهمة هنا هي التأكد من أن مثل هذا النظام يعمل بنجاح على مدى فترة طويلة من الزمن. ولحسن الحظ، كانت الخدمات موجودة منذ بعض الوقت، على الرغم من أنها تبدو مختلفة. لا تزال ذات صلة، حتى أنها محنكة مع Docker وKubernetes ولحية محببة قليلاً.
لذلك سننظر اليوم في كيفية تغير القواعد، ولماذا نحتاج إلى إعادة التفكير في الطريقة التي نتعامل بها مع الخدمات والبيانات التي تنقلها إلى بعضها البعض، ولماذا سنحتاج إلى أدوات مختلفة تمامًا للقيام بذلك.
التغليف لن يكون صديقك دائمًا
يمكن للخدمات الصغيرة أن تعمل بشكل مستقل عن بعضها البعض. هذه الخاصية هي التي تمنحهم القيمة الأكبر. تسمح هذه الخاصية نفسها للخدمات بالتوسع والنمو. ليس من حيث التوسع إلى كوادريليونات من المستخدمين أو بيتابايت من البيانات (على الرغم من أن ذلك يمكن أن يساعد في هذا الأمر أيضًا)، ولكن من حيث التوسع من حيث الأشخاص مع نمو الفرق والمؤسسات بشكل مستمر.
ومع ذلك، فإن الاستقلال سلاح ذو حدين. وهذا يعني أن الخدمة نفسها يمكن تشغيلها بسهولة وبشكل طبيعي. ولكن إذا تم تنفيذ وظيفة ما ضمن خدمة تتطلب استخدام خدمة أخرى، فسينتهي بنا الأمر إلى إجراء تغييرات على كلتا الخدمتين في وقت واحد تقريبًا. من السهل القيام بذلك في وحدة متراصة، ما عليك سوى إجراء تغيير وإرساله للإصدار، ولكن في حالة مزامنة الخدمات المستقلة سيكون هناك المزيد من المشكلات. التنسيق بين الفرق ودورات الإصدار يدمر خفة الحركة.
كجزء من النهج القياسي، يحاولون ببساطة تجنب التغييرات الشاملة المزعجة، وتقسيم الوظائف بين الخدمات بوضوح. يمكن أن تكون خدمة تسجيل الدخول الموحد مثالًا جيدًا هنا. ولها دور محدد بوضوح يميزها عن الخدمات الأخرى. ويعني هذا الفصل الواضح أنه في عالم يتسم بالتغير السريع في الطلب على الخدمات المحيطة به، فمن غير المرجح أن تتغير خدمة تسجيل الدخول الموحد. إنه موجود ضمن سياق محدود للغاية.
المشكلة هي أنه في العالم الحقيقي، لا تستطيع خدمات الأعمال الحفاظ على نفس الفصل التام بين الأدوار طوال الوقت. على سبيل المثال، تعمل نفس خدمات الأعمال إلى حد كبير مع البيانات الواردة من خدمات أخرى مماثلة. إذا كنت منخرطًا في تجارة التجزئة عبر الإنترنت، فستصبح معالجة تدفق الطلبات أو كتالوج المنتجات أو معلومات المستخدم مطلبًا للعديد من خدماتك. ستحتاج كل خدمة إلى الوصول إلى هذه البيانات لتعمل.
تشترك معظم خدمات الأعمال في نفس تدفق البيانات، لذا فإن عملها متشابك دائمًا.
وبهذا نصل إلى نقطة مهمة تستحق الحديث عنها. وفي حين تعمل الخدمات بشكل جيد بالنسبة لمكونات البنية التحتية التي تعمل بشكل منفصل إلى حد كبير، فإن معظم خدمات الأعمال ينتهي بها الأمر إلى أن تكون متشابكة بشكل أوثق.
انقسام البيانات
قد تكون الأساليب الموجهة نحو الخدمة موجودة بالفعل، لكنها لا تزال تفتقر إلى المعرفة حول كيفية مشاركة كميات كبيرة من البيانات بين الخدمات.
المشكلة الرئيسية هي أن البيانات والخدمات لا يمكن فصلهما. فمن ناحية، يشجعنا التغليف على إخفاء البيانات بحيث يمكن فصل الخدمات عن بعضها البعض وتسهيل نموها وإجراء المزيد من التغييرات. ومن ناحية أخرى، نحتاج إلى أن نكون قادرين على تقسيم البيانات المشتركة والسيطرة عليها بحرية، تمامًا مثل أي بيانات أخرى. النقطة المهمة هي أن تكون قادرًا على بدء العمل فورًا، بحرية كما هو الحال في أي نظام معلومات آخر.
ومع ذلك، فإن أنظمة المعلومات لا علاقة لها بالتغليف. في الواقع، الأمر عكس ذلك تمامًا. تفعل قواعد البيانات كل ما في وسعها لتوفير الوصول إلى البيانات التي تخزنها. أنها تأتي مع واجهة تعريفية قوية تسمح لك بتعديل البيانات حسب حاجتك. تعتبر هذه الوظيفة مهمة في مرحلة البحث الأولية، ولكن ليس لإدارة التعقيد المتزايد لخدمة تتطور باستمرار.
وهنا تنشأ معضلة. تناقض. تفرع ثنائي. ففي نهاية المطاف، تهدف أنظمة المعلومات إلى توفير البيانات، بينما تهدف الخدمات إلى إخفاءها.
هاتان القوتان أساسيتان. إنهم يدعمون الكثير من عملنا، ويكافحون باستمرار من أجل التميز في الأنظمة التي نبنيها.
مع نمو أنظمة الخدمة وتطورها، فإننا نرى عواقب انقسام البيانات بعدة طرق. إما أن تنمو واجهة الخدمة، لتوفر نطاقًا متزايدًا من الوظائف وتبدأ في الظهور وكأنها قاعدة بيانات محلية فاخرة للغاية، أو سنشعر بالإحباط وننفذ طريقة ما لاسترداد مجموعات كاملة من البيانات أو نقلها بشكل جماعي من خدمة إلى أخرى.
وفي المقابل، فإن إنشاء شيء يشبه قاعدة بيانات محلية فاخرة سيؤدي إلى مجموعة كاملة من المشكلات. لن نخوض في تفاصيل حول سبب خطورته قاعدة بيانات مشتركة، دعنا نقول فقط أنها تمثل تكاليف هندسية وتشغيلية كبيرة للشركة التي تحاول استخدامه.
والأسوأ من ذلك هو أن حجم البيانات يؤدي إلى تضخيم مشاكل حدود الخدمة. كلما زاد عدد البيانات المشتركة داخل الخدمة، أصبحت الواجهة أكثر تعقيدًا وزادت صعوبة دمج مجموعات البيانات الواردة من خدمات مختلفة.
إن النهج البديل المتمثل في استخراج مجموعات البيانات بأكملها ونقلها له أيضًا مشاكله. يبدو النهج الشائع للإجابة على هذا السؤال هو ببساطة استرجاع مجموعة البيانات بأكملها وتخزينها، ثم تخزينها محليًا في كل خدمة مستهلكة.
المشكلة هي أن الخدمات المختلفة تفسر البيانات التي تستهلكها بشكل مختلف. هذه البيانات دائما في متناول اليد. يتم تعديلها ومعالجتها محليا. وسرعان ما يتوقفون عن وجود أي شيء مشترك مع البيانات الموجودة في المصدر.
كلما كانت النسخ أكثر قابلية للتغيير، كلما تغيرت البيانات بمرور الوقت.
ومما يزيد الطين بلة أن مثل هذه البيانات يصعب تصحيحها بأثر رجعي ( هذا هو المكان الذي يمكن أن يأتي للإنقاذ حقًا). في الواقع، بعض المشاكل التكنولوجية المستعصية التي تواجهها الشركات تنشأ من البيانات المتباينة التي تتضاعف من تطبيق إلى آخر.
لإيجاد حل لهذه المشكلة، نحتاج إلى التفكير بشكل مختلف حول البيانات المشتركة. يجب أن تصبح كائنات من الدرجة الأولى في البنى التي نبنيها. يطلق على هذه البيانات اسم "خارجية"، وهذه ميزة مهمة جدًا. نحتاج إلى التغليف حتى لا نكشف عن الأعمال الداخلية للخدمة، ولكننا نحتاج إلى تسهيل وصول الخدمات إلى البيانات المشتركة حتى يتمكنوا من أداء وظائفهم بشكل صحيح.
تكمن المشكلة في أن أيًا من النهجين غير مناسب اليوم، حيث لا تقدم واجهات الخدمة ولا الرسائل ولا قاعدة البيانات المشتركة حلاً جيدًا للعمل مع البيانات الخارجية. واجهات الخدمة غير مناسبة لتبادل البيانات على أي نطاق. تقوم المراسلة بنقل البيانات ولكنها لا تخزن محفوظاتها، وبالتالي تصبح البيانات تالفة بمرور الوقت. تركز قواعد البيانات المشتركة بشكل كبير على نقطة واحدة، مما يعيق التقدم. نحن حتمًا نعلق في دائرة فشل البيانات:
دورة فشل البيانات
التدفقات: نهج لا مركزي للبيانات والخدمات
ومن الناحية المثالية، نحتاج إلى تغيير الطريقة التي تعمل بها الخدمات مع البيانات المشتركة. عند هذه النقطة، يواجه أي من النهجين الانقسام المذكور، إذ لا يوجد غبار سحري يمكن نثره عليه ليختفي. ومع ذلك، يمكننا إعادة التفكير في المشكلة والتوصل إلى حل وسط.
وينطوي هذا الحل الوسط على درجة معينة من المركزية. يمكننا استخدام آلية السجل الموزع لأنها توفر تدفقات موثوقة وقابلة للتطوير. نريد الآن أن تكون الخدمات قادرة على الانضمام إلى هذه المواضيع المشتركة والعمل عليها، ولكننا نريد تجنب خدمات God المركزية المعقدة التي تقوم بهذه المعالجة. ولذلك، فإن الخيار الأفضل هو بناء معالجة التدفق في كل خدمة للمستهلك. بهذه الطريقة، ستتمكن الخدمات من دمج مجموعات البيانات من مصادر مختلفة والعمل معها بالطريقة التي تحتاجها.
إحدى الطرق لتحقيق هذا النهج هي من خلال استخدام منصة البث. هناك العديد من الخيارات، ولكن اليوم سننظر إلى كافكا، حيث أن استخدام معالجة الدفق الخاصة به يسمح لنا بحل المشكلة المعروضة بشكل فعال.
يتيح لنا استخدام آلية التسجيل الموزعة اتباع المسار المعتاد واستخدام الرسائل للعمل معها . يعتبر هذا النهج يوفر قياسًا وتقسيمًا أفضل من آلية الطلب والاستجابة لأنه يمنح التحكم في التدفق إلى المتلقي بدلاً من المرسل. ومع ذلك، يجب أن تدفع مقابل كل شيء في هذه الحياة، وهنا تحتاج إلى وسيط. لكن بالنسبة للأنظمة الكبيرة، فإن المقايضة تستحق العناء (وهو ما قد لا يكون هو الحال بالنسبة لتطبيق الويب العادي الخاص بك).
إذا كان الوسيط مسؤولاً عن التسجيل الموزع بدلاً من نظام المراسلة التقليدي، فيمكنك الاستفادة من الميزات الإضافية. يمكن أن يتوسع النقل بشكل خطي تقريبًا مثل نظام الملفات الموزع. يمكن تخزين البيانات في السجلات لفترة طويلة، لذلك لا نحصل على تبادل الرسائل فحسب، بل نحصل أيضًا على تخزين المعلومات. تخزين قابل للتطوير دون الخوف من الحالة المشتركة القابلة للتغيير.
يمكنك بعد ذلك استخدام معالجة التدفق ذات الحالة لإضافة أدوات قاعدة البيانات التعريفية إلى الخدمات المستهلكة. هذه فكرة مهمة جدا. بينما يتم تخزين البيانات في تدفقات مشتركة يمكن لجميع الخدمات الوصول إليها، فإن التجميع والمعالجة التي تقوم بها الخدمة تكون خاصة. يجدون أنفسهم معزولين ضمن سياق محدود للغاية.
القضاء على انقسام البيانات عن طريق فصل تيار الحالة غير القابل للتغيير. ثم قم بإضافة هذه الوظيفة إلى كل خدمة تستخدم معالجة الدفق الحالة.
وبالتالي، إذا كانت خدمتك بحاجة إلى العمل مع الطلبات، أو كتالوج المنتجات، أو المستودع، فسيكون لها حق الوصول الكامل: أنت وحدك من سيقرر البيانات التي سيتم دمجها، ومكان معالجتها، وكيف يجب أن تتغير بمرور الوقت. على الرغم من مشاركة البيانات، إلا أن العمل معها يتم بشكل لا مركزي تمامًا. يتم إنتاجه داخل كل خدمة، في عالم يسير فيه كل شيء وفقًا لقواعدك.
مشاركة البيانات دون المساس بسلامتها. قم بتغليف الوظيفة، وليس المصدر، في كل خدمة تحتاج إليها.
يحدث أن البيانات يجب أن يتم نقلها بشكل جماعي. في بعض الأحيان تتطلب الخدمة مجموعة بيانات تاريخية محلية في محرك قاعدة البيانات المحدد. الحيلة هي أنه يمكنك ضمان إمكانية استعادة نسخة من المصدر، إذا لزم الأمر، عن طريق الوصول إلى آلية التسجيل الموزعة. تقوم الموصلات في كافكا بعمل رائع في هذا.
لذلك، فإن النهج الذي نناقشه اليوم له العديد من المزايا:
- تُستخدم البيانات في شكل تدفقات مشتركة، والتي يمكن تخزينها في سجلات لفترة طويلة، كما أن آلية العمل مع البيانات المشتركة مثبتة في كل سياق على حدة، مما يسمح للخدمات بالعمل بسهولة وسرعة. وبهذه الطريقة، يمكن موازنة الانقسام في البيانات.
- يمكن دمج البيانات الواردة من خدمات مختلفة بسهولة في مجموعات. يؤدي ذلك إلى تبسيط التفاعل مع البيانات المشتركة ويلغي الحاجة إلى الاحتفاظ بمجموعات البيانات المحلية في قاعدة البيانات.
- تعمل معالجة التدفق ذو الحالة على تخزين البيانات مؤقتًا فقط، ويظل مصدر الحقيقة هو السجلات العامة، لذا فإن مشكلة تلف البيانات بمرور الوقت ليست حادة جدًا.
- تعتمد الخدمات في جوهرها على البيانات، مما يعني أنه على الرغم من الكميات المتزايدة باستمرار من البيانات، لا يزال بإمكان الخدمات الاستجابة بسرعة لأحداث الأعمال.
- تقع مشكلات قابلية التوسع على عاتق الوسيط، وليس الخدمات. وهذا يقلل بشكل كبير من تعقيد خدمات الكتابة، حيث ليست هناك حاجة للتفكير في قابلية التوسع.
- لا تتطلب إضافة خدمات جديدة تغيير الخدمات القديمة، وبالتالي يصبح ربط الخدمات الجديدة أسهل.
كما ترون، هذا أكثر من مجرد راحة. لقد تلقينا مجموعة من الأدوات التي تتيح لك العمل مع البيانات المشتركة بطريقة لا مركزية.
لم تتم تغطية جميع الجوانب في مقالة اليوم. ما زلنا بحاجة إلى معرفة كيفية تحقيق التوازن بين نموذج الطلب والاستجابة والنموذج القائم على الحدث. لكننا سنتعامل مع هذا في المرة القادمة. هناك موضوعات تحتاج إلى التعرف عليها بشكل أفضل، على سبيل المثال، لماذا تعتبر معالجة التدفق الحالة جيدة جدًا. سنتحدث عن هذا في المقال الثالث. وهناك بنيات قوية أخرى يمكننا الاستفادة منها إذا لجأنا إليها، على سبيل المثال، . إنه يغير قواعد اللعبة بالنسبة لأنظمة الأعمال الموزعة لأنه يوفر ضمانات للمعاملات في شكل قابل للتطوير. وهذا ما سيتم مناقشته في المقالة الرابعة. وأخيرًا، سنحتاج إلى مراجعة تفاصيل تنفيذ هذه المبادئ.
لكن في الوقت الحالي، تذكر فقط هذا: إن انقسام البيانات هو القوة التي نواجهها عند بناء خدمات الأعمال. ويجب أن نتذكر هذا. الحيلة هي قلب كل شيء رأسًا على عقب والبدء في التعامل مع البيانات المشتركة ككائنات من الدرجة الأولى. توفر معالجة الدفق الحالة حلاً وسطًا فريدًا لهذا الغرض. إنه يتجنب "المكونات الإلهية" المركزية التي تعيق التقدم. علاوة على ذلك، فإنه يضمن سرعة وقابلية التوسع والمرونة لخطوط تدفق البيانات ويضيفها إلى كل خدمة. لذلك، يمكننا التركيز على التيار العام للوعي الذي يمكن لأي خدمة الاتصال به والعمل مع بياناتها. وهذا يجعل الخدمات أكثر قابلية للتطوير والتبادل والاستقلالية. لذا فهي لن تبدو جيدة فقط على السبورات البيضاء واختبارات الفرضيات، ولكنها أيضًا ستعمل وتتطور لعقود من الزمن.
المصدر: www.habr.com