بطريقة أو بأخرى ، اتضح تاريخياً أن صناعة تكنولوجيا المعلومات لأي سبب من الأسباب تنقسم إلى معسكرين مشروطين: معًا ومعارضان. علاوة على ذلك ، يمكن أن يكون موضوع الجدل تعسفيًا تمامًا. ما هو نظام التشغيل الأفضل: Win أو Linux؟ على هاتف ذكي يعمل بنظام Android أو iOS؟ احتفظ بكل شيء في السحاب أو قم بالتحميل إلى وحدة تخزين RAID الباردة ووضع مسامير في مكان آمن؟ هل PHN schnicks له الحق في أن يسمى المبرمجين؟ هذه النزاعات ، في بعض الأحيان ، موجودة بشكل حصري بطبيعتها وليس لها أي أساس آخر إلى جانب الاهتمام بالرياضة.
لقد حدث ما حدث أنه مع ظهور الحاويات وكل هذا المطبخ المحبب الذي يحتوي على عامل رصيف وأطقم K8 مشروطة ، بدأ النزاع بين المحترفين والخداع في استخدام فرص جديدة في مناطق مختلفة من الواجهة الخلفية. (سنبدي تحفظًا مقدمًا بأنه على الرغم من أنه سيتم في كثير من الأحيان الإشارة إلى Kubernetes كأوركسترا في هذه المناقشة ، فإن اختيار هذا الصك لا يهم. بدلاً من ذلك ، يمكنك استبدال أي أداة أخرى تبدو أكثر ملاءمة لك ومألوفة لك.)
وعلى ما يبدو ، ستكون حجة بسيطة حول وجهي العملة الواحدة. بنفس القدر من القسوة والقسوة مثل المواجهة الأبدية Win vs Linux ، حيث يوجد عدد كافٍ من الناس لأنفسهم في مكان ما بين. هذا فقط في حالة النقل بالحاويات ليست بهذه البساطة. عادة في مثل هذه النزاعات ، لا يوجد الجانب الأيمن ، ولكن في حالة "تطبيق" أو "عدم تطبيق" حاويات لتخزين قاعدة البيانات كل شيء يحصل رأسا على عقب. لأنه بمعنى ما كلا المؤيدين والمعارضين لمثل هذا النهج على حق.
الجانب المشرق
يمكنك أن تصف بإيجاز حجج "الجانب المشرق" بعبارة واحدة: "مرحبًا ، 2k19 خارج النافذة!" يبدو الأمر وكأنه شعوبية ، بالطبع ، لكن إذا بحثت في الموقف بالتفصيل ، فإن له مزاياه. سنحللها الآن.
افترض أن لديك مشروع ويب كبير. يمكن أن يتم بناؤه في البداية على أساس نهج الخدمة المجهرية ، أو في مرحلة ما جاء به بطريقة تطورية - وهذا ليس مهمًا للغاية ، في الواقع. لقد بعثرت مشروعنا على خدمات ميكروية منفصلة ، وقمت بإعداد تزامن ، وموازنة التحميل ، والتوسع. والآن ، بضمير مرتاح ، اشرب مشروب موخيتو في أرجوحة أثناء تأثير هابر ، بدلاً من رفع الخوادم الساقطة. ولكن يجب أن تكون جميع الإجراءات متسقة. في كثير من الأحيان فقط التطبيق نفسه هو حاويات - رمز. ماذا لدينا بجانب الكود؟
الحق ، البيانات. جوهر أي مشروع هو بياناته: يمكن أن يكون إما DBMS نموذجي - MySQL ، أو Postgre ، أو MongoDB ، أو وحدة تخزين تستخدم للبحث (ElasticSearch) ، وتخزين القيمة الرئيسية للتخزين المؤقت - على سبيل المثال ، redis ، إلخ. سنتحدث عن خيارات تنفيذ الواجهة الخلفية الملتوية عندما تعطل قاعدة البيانات بسبب استفسارات مكتوبة بشكل سيئ ، وبدلاً من ذلك سنتحدث عن ضمان التسامح مع الخطأ لقاعدة البيانات ذاتها تحت تحميل العميل. في الواقع ، عندما نقوم بتعبئة تطبيقنا في حاوية ونسمح له بالتوسع بحرية في التعامل مع أي عدد من الطلبات الواردة ، فهذا يزيد بشكل طبيعي من التحميل على قاعدة البيانات.
في الواقع ، أصبحت قناة الوصول إلى قاعدة البيانات والخادم الذي تدور عليه عين الإبرة في الواجهة الخلفية الحاوية الجميلة. في نفس الوقت ، فإن الدافع الرئيسي للمحاكاة الافتراضية للحاوية هو قابلية التنقل واللدونة للهيكل ، مما يجعل من الممكن تنظيم توزيع حمل الذروة عبر البنية التحتية بأكملها المتاحة لنا بأكبر قدر ممكن من الكفاءة. وهذا هو ، إذا لم نقم بنقل كل العناصر المتوفرة في النظام ونقلها إلى كتلة ، فإننا نرتكب خطأً خطيراً للغاية.
من المنطقي أكثر بكثير تجميع ليس فقط التطبيق نفسه ، ولكن أيضا الخدمات المسؤولة عن تخزين البيانات. عند تجميع ونشر العمل بشكل مستقل وتوزيع حمل خوادم الويب في k8s ، نحل بالفعل مشكلة مزامنة البيانات - نفس التعليقات على المنشورات ، إذا كنت تأخذ نوعًا من الوسائط أو منصة المدونة كمثال. في أي حال ، نبدأ تمثيل intracluster ، حتى الظاهري ، لقاعدة البيانات كخدمة خارجية. والسؤال هو أن قاعدة البيانات نفسها لم يتم تجميعها بعد - خوادم الويب المنتشرة في المكعب تأخذ معلومات حول التغييرات من قاعدة القتال الثابتة لدينا ، والتي تدور بشكل منفصل.
يشعر الصيد؟ نحن نستخدم k8s أو Swarm من أجل توزيع التحميل وتجنب سقوط خادم الويب الرئيسي ، لكننا لا نفعل ذلك لقاعدة البيانات. ولكن بعد كل شيء ، إذا تعطلت قاعدة البيانات ، فليس هناك فائدة في البنية التحتية المجمعة بالكامل - ما فائدة صفحات الويب الفارغة التي تُرجع خطأ في الوصول إلى قاعدة البيانات؟
هذا هو السبب في أن خوادم الويب لا تحتاج فقط إلى التجميع ، كما هو معتاد ، ولكن أيضًا البنية التحتية لقاعدة البيانات. وبهذه الطريقة فقط يمكننا أن نضمن أن عناصر من نفس الهيكل تعمل بكامل طاقتها في فريق واحد ، ولكن في الوقت نفسه ، تكون مستقلة عن بعضها البعض. في الوقت نفسه ، حتى لو انهار نصف مجموعتنا الخلفية تحت الحمل - سيبقى الباقي ، وسيساعد نظام مزامنة قاعدة البيانات مع بعضها البعض داخل المجموعة وإمكانية التوسع غير المحدود ونشر مجموعات جديدة في الوصول بسرعة إلى القدرات المطلوبة - ستكون هناك رفوف في مركز البيانات .
بالإضافة إلى ذلك ، يسمح لك نموذج قاعدة البيانات الموزعة في مجموعات بأخذ قاعدة البيانات نفسها إلى حيث تدعو الحاجة ؛ إذا كنا نتحدث عن خدمة عالمية ، فمن غير المنطقي إلى حد ما تحريف مجموعة ويب في مكان ما في منطقة سان فرانسيسكو وفي نفس الوقت قيادة الحزم عند الوصول إلى قاعدة البيانات في منطقة موسكو والعكس بالعكس.
أيضًا ، يتيح لك نقل البيانات في قاعدة البيانات إنشاء جميع عناصر النظام في نفس المستوى من التجريد. وهو ما يجعل بدوره من الممكن إدارة هذا النظام مباشرة من الكود ، من قبل المطورين ، دون مشاركة نشطة من المشرفين. لقد اعتقد المطورون أنهم يحتاجون إلى DBMS منفصل لمشروع فرعي جديد - سهل! كتب ملف yaml ، تم الرفع إلى المجموعة وقمت بإنهائه.
حسنا ، بالطبع ، العملية الداخلية مبسطة إلى حد كبير. أخبرني ، كم مرة قمت فيها بالتحديق في اللحظات التي دفع فيها عضو جديد في الفريق يديه إلى قاعدة البيانات القتالية للعمل؟ أي واحد ، في الواقع ، هو الغزل الآن؟ بالطبع ، كلنا هنا بالغون ، وفي مكان ما لدينا نسخة احتياطية جديدة ، بل وأكثر من ذلك - وراء رف مع خيار الجدة والزلاجات القديمة - نسخة احتياطية أخرى ، ربما حتى في مخزن بارد ، لأنه بمجرد اشتعال النار في مكتبك. ومع ذلك ، فإن كل إدخال لعضو جديد في الفريق يتمتع بالوصول إلى البنية التحتية القتالية ، وبالطبع إلى قاعدة البيانات القتالية ، هو دلو من validol لكل من حوله. حسنًا ، من يعرف المبتدئ ، ربما كان يحدق؟ مخيف ، توافق.
حاويات ، وفي الواقع ، طوبولوجيا قاعدة البيانات المادية الموزعة لمشروعك يساعد على تجنب مثل هذه اللحظات الصالحة. لا تثق مبتدئ؟ حسنا! سنرفع المجموعة الخاصة بها ونفصلها عن باقي مجموعات قاعدة البيانات - المزامنة فقط عن طريق الضغط اليدوي والتناوب المتزامن لمفتاحين (قائد فريق واحد ، المشرف الثاني). والجميع سعداء.
والآن حان الوقت لتغيير الأحذية في معارضي حاويات قواعد البيانات.
الجانب المظلم
بحجة أنه ليس من الضروري تخزين قاعدة البيانات في حاويات ومواصلة تدويرها على خادم مركزي واحد ، فإننا لن ننتقل إلى خطاب الأرثوذكسية والبيانات مثل "الأجداد قلبوا قاعدة البيانات على الأجهزة ، وسنقوم!" بدلاً من ذلك ، دعونا نحاول التوصل إلى موقف يمكن أن يحقق فيه النقل بالحاويات أرباحًا حقيقية.
يجب أن تعترف بأن المشروعات التي تحتاج حقًا إلى قاعدة في الحاوية يمكن حسابها على أصابع اليد الواحدة باعتبارها ليست أفضل مشغل لآلة الطحن. بالنسبة للجزء الأكبر ، حتى استخدام k8s أو Docker Swarm ضروري - غالبًا ما يلجأون إلى هذه الأدوات نظرًا لطبيعة الضجيج العامة للتكنولوجيا ومنشآت "سبحانه وتعالى" في شخص الأجناس لدفع كل شيء إلى السحب والحاويات. حسنًا ، لأنه الآن من المألوف والجميع يفعل ذلك.
على الأقل في نصف الحالات ، يكون استخدام kubernetis أو مجرد عامل ميناء في مشروع أمرًا ضروريًا. والسؤال هو أنه ليس كل الفرق أو شركات الاستعانة بمصادر خارجية المعينة لخدمة البنية التحتية للعميل على علم بذلك. الأسوأ - عندما يتم فرض الحاويات ، لأنها ترتفع في كمية معينة من العملات المعدنية للعميل.
بشكل عام ، هناك رأي مفاده أن مكعب عامل النقل / المافيا يسحق بغباء العملاء الذين يستعينون بمصادر خارجية لقضايا البنية التحتية هذه. في الواقع ، من أجل العمل مع المجموعات ، فإنك تحتاج إلى مهندسين قادرين على ذلك وفهموا بنية الحل المطبق بشكل عام. بطريقة ما وصفنا بالفعل قضيتنا مع إصدار ريبابليك - حيث قمنا بتدريب فريق العميل على العمل في حقائق kubernetis ، وكان الجميع راضين. وكان لائق. غالبًا ما يأخذ "المنفذون" في K8s البنية الأساسية للعميل كرهينة - والآن فهم فقط كيف يعمل كل شيء هناك ، لا يوجد متخصصون من جانب العميل.
الآن تخيل أننا بهذه الطريقة لا نعطي جزء خادم الويب فقط إلى الاستعانة بمصادر خارجية ، ولكن أيضًا صيانة قاعدة البيانات. قلنا أن الديسيبل قلب ، وفقدان القلب مميت لأي كائن حي. باختصار ، فإن الآفاق ليست هي الأفضل. لذلك ، بدلاً من الضجيج kubernetis ، ينبغي ببساطة ألا تغضب العديد من المشاريع من تعريفة AWS العادية ، والتي سوف تحل جميع المشاكل المتعلقة بالتحميل على موقع الويب / المشروع. لكن AWS لم تعد من المألوف ، والعروض باهظة الثمن أكثر من المال - لسوء الحظ ، في بيئة تكنولوجيا المعلومات أيضًا.
حسنا. ربما يحتاج المشروع حقًا إلى التجميع ، ولكن إذا كان كل شيء واضحًا مع التطبيقات عديمة الجنسية ، فكيف يمكننا تنظيم توفير لائق لاتصال الشبكة لقاعدة البيانات المجمعة؟
إذا كنا نتحدث عن حل هندسي سلس ، والذي يبدو أنه الانتقال إلى k8s ، فإن صداعنا الرئيسي هو تكرار البيانات في قاعدة بيانات مجمعة. بعض نظم إدارة قواعد البيانات مبدئية تمامًا في البداية لتوزيع البيانات بين الحالات الفردية الخاصة بها. كثيرون آخرون لا يرحبون بذلك. وفي كثير من الأحيان ، فإن الحجة الرئيسية في اختيار DBMS لمشروعنا ليست القدرة على التكرار بأقل تكلفة من الموارد والهندسة. خاصة إذا لم يكن المشروع قد تم تخطيطه في الأصل كخدمة ميكروية ، ولكنه تطور ببساطة في هذا الاتجاه.
لا نحتاج إلى التحدث عن سرعة محركات أقراص الشبكة - فهي بطيئة. أي ما زلنا لا نملك إمكانية حقيقية ، في هذه الحالة ، لترقية مثيل DBMS في مكان ما ، حيث يوجد المزيد ، على سبيل المثال ، قدرات المعالج أو ذاكرة الوصول العشوائي المجانية. نحن نواجه بسرعة كبيرة أداء النظام الفرعي للقرص الافتراضي. وفقًا لذلك ، يجب أن يتم تثبيت DBMS على مجموعة الأجهزة الشخصية الخاصة بها على مقربة. أو ، من الضروري فصل المزامنة السريعة بما فيه الكفاية لمزامنة البيانات مع الاحتياطيات المقدرة.
استمرار موضوع FS الظاهري: وحدات التخزين Docker ، للأسف ، ليست خالية من المتاعب. بشكل عام ، في مثل هذه الحالة مثل التخزين الموثوق للبيانات على المدى الطويل ، أود أن أديرها باستخدام أكثر البرامج الفنية بساطة. إن إضافة طبقة تجريد جديدة من حاوية FS إلى المضيف الرئيسي FS يمثل خطراً بحد ذاته. ولكن عندما تكون هناك أيضًا صعوبات في نقل البيانات بين هذه الطبقات في تشغيل نظام دعم النقل بالحاويات ، فإن ذلك سيكون كارثة حقًا. في الوقت الحالي ، يبدو أن معظم المشكلات المعروفة للإنسانية التقدمية قد تم القضاء عليها. لكنك تفهم بنفسك ، فكلما كانت الآلية أكثر تعقيدًا ، كلما كانت كسرها أسهل.
في ضوء كل هذه "المغامرات" ، من المربح وأسهل بكثير الاحتفاظ بقاعدة البيانات في مكان واحد ، وحتى إذا كنت بحاجة إلى حاوية التطبيق ، فدعه يدور بنفسه ومن خلال بوابة التوزيع يتلقى اتصالًا متزامنًا مع قاعدة البيانات ، التي سيتم قراءتها وكتابتها مرة واحدة فقط في مكان واحد. هذا النهج يقلل من احتمال وجود أخطاء وسوء التزامن إلى الحد الأدنى من القيم.
ما الذي يؤدي بنا إلى؟ بالإضافة إلى ذلك ، فإن نقل قاعدة البيانات في الحاوية يكون مناسبًا حيث توجد حاجة حقيقية إليه. لا يمكنك حشر قاعدة التطبيق بالكامل وتحريفها كما لو كان لديك أكثر من عشرين خدمة microservices - هذا لا يعمل. وهذا يجب أن يكون مفهوما بوضوح.
بدلا من الإخراج
إذا كنت تنتظر النتيجة الواضحة "إضفاء الطابع الافتراضي على قاعدة البيانات أم لا" ، فنحن نشعر بخيبة أمل: لن تكون هنا. لأنه عند إنشاء أي حل للبنية التحتية ، لا ينبغي للمرء أن يسترشد بالموضة والتقدم ، ولكن أولاً وقبل كل شيء ، بالحس السليم.
هناك مشاريع تناسب المبادئ والأدوات التي تأتي مع kubernetis تمامًا ، وفي مثل هذه المشروعات ، يأتي السلام على الأقل في المنطقة الخلفية. وهناك مشاريع لا تحتاج إلى حاويات ، ولكن بنية تحتية عادية للخادم ، لأنها في الأساس لا يمكن إعادة قياسها إلى نموذج مجموعة خدمات microservice ، لأنها ستقع.