عندما أدركنا أنه سيكون من الممل بالنسبة لنا عقد الاجتماع التالي ، قررنا تحويله إلى شيء أكثر نشاطًا. وهي ، في مبارزة ، في
مبارزة بين نهجين التكامل - ESB وموزع - الذي دافع عن شرف من قبل خبراء الوزن الثقيل. في هذا المنشور ، سوف نخبرك بكيفية نشوب المعركة ومعرفة الفائز.
بضع كلمات عن الشكل
تحدث ألكساندر تريكليبوف ، مهندس الشركة لدينا ، عن الحافلة المركزية. من أجل اللامركزية - أندريه تروشكين ، رئيس مركز الابتكار والتقنيات الواعدة في Promsvyazbank. لقد تناوبوا على تقديم تقارير عن تكنولوجياتهم وأجابوا على أسئلة مختلفة ، استفزازية وليست شديدة. هذا ما كان عليه الحال.
لماذا هو ESB بارد؟
بادئ ذي بدء ، يجب وضعه في معرفة وإخبار كيف بدأ كل شيء. ربما يتذكر الكثيرون أنه في المرحلة الأولى حدث كل شيء دون أي تكامل ، عندما يقوم كل نظام بالاتصال وإجراء اختبار التكامل الخاص به مع كل نظام آخر.
وفقًا لذلك ، إذا ترك شخص ما أو حدث له شيء آخر ، فلا أحد يعرف كيف سيعمل كل هذا. تفاعل كل كمبيوتر مع بعض الخوادم. ما البروتوكول ، أي نوع من التفاعل؟ فقط الشخص الذي عمل في النظام كان يعرف كل هذا.
ثم جاء الحافلة التكامل. لم يكن الأمر كذلك تمامًا ، ولكن لأنه تم جمع البروتوكولات الرئيسية وأساليب التفاعل عليها وكان من الممكن عدم إجبار النظام على وصف أي أشياء محددة. يمكنها التواصل معهم باستخدام خوارزمياتها الداخلية.
كذلك اتضح أنهم في معظم الأحيان يتواصلون مع الحافلة من خلال قوائم الانتظار أو من خلال REST.
مع مرور الوقت ، اختفت الحاجة إلى حافلة و REST في كثير من الحالات. ولكن بدا الأمر وكأنه تراجع ، تعلق الأسئلة المهمة مرة أخرى:
- كيف تنسق إذا لم يكن هناك الإطارات. أين سيحدث هذا؟
- ما يجب القيام به مع تنسيقات البيانات والبروتوكول؟
بالإضافة إلى ذلك ، فإن الأداء في النظام المركزي أفضل بكثير من الأداء في نظام التوزيع. يمكنك الاعتماد على السرعة وعلى مستوى الصوت وعلى توفرها. كل هذا لأنه نظام واحد يخدمه فريق معين.
ما مدى ضعف هذا النظام؟ ماذا يحدث إذا تم اختراق جهاز كمبيوتر واحد؟هناك دائما التكرار والمركزية. في حال تعطل أحدهم ، سيعمل النظام.
من المسؤول عن الإطارات؟ فريقك أو مطوري الطرف الثالث؟في الفريق الداخلي ، نحن نقدم الخدمات التشغيلية ، ونوفر الموثوقية والرصد. إذا لم ينجح شيء ما ، فنحن نعرف أين ننظر. هناك سؤال: "هل يمكن الوثوق بالموردين في مثل هذه الحالات وفرق الجهات الخارجية؟" هناك حاجة إلى مراقبة جيدة هنا. لأن الجودة ، على أي حال ، هي مسؤولية الفريق الداخلي.
مع نمو الحافلة ، لا تصبح الخدمات متصلة. هل تغير الخدمات مع الإصدارات أم ماذا؟ ماذا تفعل مع رشيق؟هنا نأتي إلى السؤال الأساسي.
التكامل ليس تطبيق. اعتادت أن تكون جزءًا ، لكنها الآن ليست كذلك. تطوير التكامل ليس تطوير التطبيقات. إنه تطوير تفاعلات التكامل أو التطوير في إطار مشروع منفصل ، ولكن ليس بالتحديد تطبيق واحد.
مخاوفك رشيقة مفهومة. يتم استخدام هذا النموذج عندما نصنع نظامًا منفصلًا متصل بالحافلة في مكان ما على الجانب. عندما عملت في بنك آخر ، كان هناك مثل هذا النظام: شهر من الاختبار ، شهر من التطوير. نتيجة لذلك ، يتم تنفيذ جميع تفاعلات التكامل بسرعة على الحافلة. أسرع مما يصفه المحللون ، لأن أنظمة التطوير معقدة وبسيطة للغاية. ويستخدم رشيقة في تطوير النظام النهائي.
كم من الوقت يبحث الفريق عن الخدمة التي يحتاجون إليها ، وأين يبحث عنها؟كل شخص لديه حلم أن هناك خريطة العالم التي تنتشر فيها جميع المناطق التجارية الرئيسية عبر القارات. وحتى يتم تنفيذها جزئيا. يذهب المحلل إلى هناك ويبدأ بالتجول بكثافة حول القارات ، وبعد فترة من الوقت يجد التفاعل المطلوب. علاوة على ذلك ، إذا كان كل شيء مناسبًا تمامًا ، فهو يستخدمه ببساطة. إذا لم يكن كذلك ، يصف في المعارف التقليدية الإضافات التي يحتاجها. سيكون من الرائع أن يكون لديك مثل هذا الخيار ، لكن الأنظمة الأقل ملائمة التي تتطلب الكثير من الوقت والجهد للعمل معها مناسبة.
أو ربما شبكة الخدمة هي أكثر برودة؟
بادئ ذي بدء ، لقد تغير الكثير بالفعل في 3-4 سنوات. لكن ماذا حدث بالضبط؟ لقد حدثت نفس التفاهة التي يكررها جميع المتحدثين بانتظام ، والتي لا يمكننا المرور بها ، وهي أن العالم يتغير.
متطلبات سرعة التغيير أصبحت ضخمة. في الوقت نفسه ، لا تختفي متطلبات الموثوقية ومتطلبات السلامة في أي مكان ، وتزداد متطلبات التحميل فقط. كما نرى ، يحاول الجميع الاستحواذ على حصته في السوق ، مما يؤدي حتماً إلى زيادة العبء على أنظمة الشركات ، وبالتالي على التكامل.
في الواقع ، ساعدت ESB في وقت واحد رائعًا كقالب للتطبيق الفني من حيث لامركزية التطبيقات ، وتخصيص المنطق بين التطبيقات المختلفة ، وجهاز موحد لدمج التطبيقات فيما بينها. دعنا نقول فقط موحد مشروط.
والآن ، دعونا نتخيل أنه لا يوجد 20 نظامًا في الشركة - فهي تسعى في النهاية إلى الانتقال إلى البنية التي تسمى الكلمة الطنانة "الخدمات المصغرة". وما هي الخدمة المجهرية؟ هناك العديد من التعريفات ، أحدها يستخدم بشكل دوري بواسطة Martin Fowler: إنها خدمة يستطيع المطور المتوسط تطويرها في سباق واحد. تخيل كم من هذه الخدمات ستكون في شركة كبيرة. على سبيل المثال ، تقدر Netflix عدد خدماتها الميكروية في 800-900. من حيث المبدأ ، في شركة تسعى لبناء نظام بيئي خارجي شريك ، يمكن لهذه الخدمات أن تتجاوز ألف. لكن كل من هذه الخدمات على المدى الطويل تتحمل عبءًا هائلاً ويجب أن تتطور بشكل مستقل.
ماذا عن الحافلة؟ إذا بقي الحافلة هذا المجمع المشترك بينهما ، فقد تبين أنه يصبح عنق الزجاجة ويؤخر تطوير الخدمات. ليس فقط لأنها تنتظر هذه الخدمات ذاتها ، ولكن لأنها تتطور كفريق منفصل ، من قبل أشخاص يمتلكون هذه التقنيات والمهارات نفسها.
والآن دعنا نتخيل: هناك عدة عشرات من فرق المنتجات تتطور وتعمل معنا. ورأى كل منهم العديد من الخدمات. والحافلة يقودها فريقان. بطبيعة الحال ، لن تتمكن هذه الفرق التي تتمتع بدرجة عالية من الاحتمال من تطوير هذا التكامل مع المستوى الضروري من السرعة والجودة.
السؤال الذي يطرح نفسه: "كيف يمكننا ضمان نفس السرعة بسرعة دون فقدان إمكانية الوصول ، والأمن ، وهلم جرا؟" الجواب بسيط للغاية: "دع هذه الخدمات تتفاعل مباشرة ، دون وسيط واضح".
ثم يتم طرح السؤال المهم التالي: "كيف تتعرف الخدمات على بعضها البعض؟" وهنا يكون الجواب بسيطًا جدًا أيضًا: يمكنك التوصل إلى نظام تقوم به الخدمات نفسها بالإبلاغ عن نفسها. وهذا هو ، في الوقت الذي يتم فيه تطوير الخدمة ، فإنها ستنشر بشكل مستقل معلومات عن نفسها في سجل معين. وبناءً على هذه المعلومات ، ستتمكن جميع الخدمات من بدء التفاعل معه.
وهكذا ، تم تشكيل مفهوم "شبكة" الخدمات - كما كان يسمى في الأصل ،
"شبكة الخدمة" . كنوع من المستوى المتوسط للتكامل بين الخدمات ، والذي يوفر مثل هذا التكامل ، كما لو كان حل سحابة.
تحاول الشركات الكبرى الآن حل مشكلات سرعة التطوير بالتوازي - لإيجاد حل عام معين ، يتم توزيعه وغالبًا ما يكون مضمنًا. في هذه الحالة ، تستخدم كل خدمة مجموعة معينة من المكتبات الجاهزة من أجل نشر المعلومات تلقائيًا إلى أحد السجلات عند النشر.
غالبًا ما يثار السؤال: "لكن ما علاقة نموذج البيانات الكنسي ، الذي كان مصدره كقاعدة عامة ESB ، والذي استثمر فيه الكثير من المال والجهد لتنفيذه وصيانته؟" بعد كل شيء ، كانت نموذجا يستخدم القياسية. إليك سؤال مضاد: "وما المزايا التي جلبتها لنا؟ ألم تكن هذه هي النقطة التي أخرت تطورنا؟ " في الواقع ، عند تطوير الخدمات ، يتوسع النموذج أكثر فأكثر. سيكون هناك دائمًا تحديات أحدث.
وبصراحة ، فإن
تكلفة إضافة أجهزة جديدة وتنظيم التفاعل وما إلى ذلك ، كقاعدة عامة ، أقل بكثير من تكلفة الحفاظ على نموذج بيانات ESB الكنسي حتى الآن .
أيضا ، والتكامل اللامركزي هو إلى حد كبير ضمان أن نفس توافر عالية. كل من خدمات microservices مستقلة ، بما في ذلك عن خدمات microservices الأخرى ، ولكنها تعتمد بشكل أساسي على الحمل الخارجي الذي يتم وضعها عليه. يمكن نشرها بالتوازي مع التكامل يمكن تنفيذها من الناحية التكنولوجية بشكل مستقل.
في بعض الأحيان ، لا يكون استخدام ESB ثقيلًا في الظروف الحديثة منطقيًا ، أو حتى العكس ، يقلل من جودة الحل. إن تطبيق التقنيات الخالية من الخوادم ، وهي البنية الأساسية ذاتها التي لا تتكيف مع الاحتياجات المؤقتة للحلول التي يتم إنشاؤها ، قد بدأت بالفعل ، ولكنها يتم تسليمها بالشكل المناسب لخدمة معينة. يبدو الأمر الآن وكأنه شيء بعيد المنال ، لكن العالم يتغير ، كما قيل بالفعل ، بسرعة كبيرة.
يذهب العديد من بائعي البرامج بهذه الطريقة من حيث حلول التكامل الخاصة بهم. هناك بالفعل أطر عمل تقوم بشكل أساسي بتطبيق مفهوم شبكة الخدمة (نفس Linkerd أو Istio). يحدث نفس الشيء بالفعل كجزء من استضافة عدد كبير من بروكسيات الشبكة وخدمات تكامل شبكات الخدمة. يوجد الكثير من الأشياء المشتركة مع شبكة الخدمة وأنظمة تزامن الحاويات مثل Kubernetes.
هل من الممكن بناء الموزعة على أساس ESB؟ وهذا هو ، هل من الممكن جعل آخر من نظام واحد؟ وإذا كان الأمر كذلك ، فما الهدف من هذه النزاعات؟هنا هيجل و "إنكاره للنفي" يتبادر إلى الذهن. عندما تتكرر فكرة واحدة على مستوى تاريخي أعلى. من الممكن أن تأتي من واحدة إلى أخرى ، في رأيي. سؤال آخر هو كيف سنذهب حول هذا الموضوع. في الواقع ، في جوهره ، فإن مفهوم الخدمات الدقيقة وتطبيقها يشبه في كثير من الأحيان مفهوم التكامل الذي كان في الأصل: تفاعل الخدمات الصغيرة فيما بينها ، مع بعضها.
هل من الممكن الوصول إلى التكامل وفقًا لمبادئ الشبكة ، إذا ذهبنا من ESB؟ في الواقع ، ريد هات ، آي بي إم الآن ، يتبع بالفعل نفس المبدأ. مجرد إلقاء نظرة على فهمهم لمفهوم تكدس التكامل والتكامل المرن (تكامل رشيق). أنها توفر عددًا كبيرًا من وكلاء التكامل غير المثقلين بالمنطق. أهم شيء هو الشفافية ومعرفة الخدمات المطلوبة من قبل جميع الداخلين الجدد إلى التفاعل.
هل يفهم البنك الذي تتعامل معه أن ESB قد عاشت أكثر من ذلك إذا استمرت في استثمار ميزانيات كبيرة في ذلك؟بصراحة ، قضايا الميزانية سر تجاري. أما بالنسبة للنهج المستخدمة ، فإننا في الوقت الحالي نعمل على تطوير موازٍ لطريقتين. يوجد في Promsvyazbank العديد من الأنظمة المرتبطة بالحافلة. لا تزال متكاملة عبر الحافلة. لكننا ، من جانبنا ، ندرك أن ESB هو نهج غير واعد وأنه أكثر كفاءة للاستثمار في عمليات التكامل الموزعة دون استخدام حافلة. هذه هي أولويتنا الاستراتيجية الآن.
أين هو المكان المناسب لرصد الأعمال التجارية في النظام الموزع؟في التكامل اللامركزي ، لا يستبعد وجود عدد كبير من الخدمات وجود مراقبة الأعمال. كل هذا يمكن وضعه على مستوى الأطر المعنية. وفقًا لذلك ، يمكن لهذا الرصد دمج المعلومات في وحدة تخزين معينة مسؤولة عن البيانات. يتم تحليل هذه البيانات هناك ، ويتم إعداد تقرير موجز.
كيف ترى خطة الانتقال إلى التكامل اللامركزي؟الانتقال إلى التكامل اللامركزي أمر منطقي في الاعتبار في سياق الانتقال إلى مبادئ معمارية جديدة. هذا انتقال معقد لا يمكن أن يحدث مرة واحدة. نعم ، يمكنك محاولة الاحتفاظ بها بتنسيق "الانفجار الكبير" ، لكن خيار السيناريو هذا ينطوي على مخاطر خطيرة. أكثر منطقية هو خيار إنشاء دائرة جديدة بالتوازي مع الدائرة الحالية ، وكما تم إنشاؤها (في الوضع التكراري) ، وإدخال منتجات جديدة فيها. مع تطور المحيط المعماري الجديد ، يمكن نقل هذه المنتجات من المشهد الحالي لتكنولوجيا المعلومات والتي صمدت أمام اختبار الزمن. هذا المسار طويل جدًا - يقدر بحوالي 4-5 سنوات - ولكن بسبب التكرار ، من الممكن الحصول على نتائج في وضع التشغيل الصناعي بالتتابع.
من فاز؟
بعد ثلاث جولات تفاعلية مع العروض التقديمية والأسئلة والأجوبة ، اختبأ الجمهور تحسبا لإعلان النتيجة النهائية. ربما تدرك أن الفائز في PSB Battle كان Andrey Trushkin والنظام الموزع.
في الختام ، نحن نقدم مقطع فيديو يساعدك على الشعور بأجواء معركتنا: