ما الذي يجذب المطورين للخدمات الصغيرة كثيرا؟ لا توجد تقنية ثورية وراءها ؛ المزايا على المونوليث مثيرة للجدل تمامًا. فقط السهولة التي تسمح لك بها أدوات التطوير والنشر الحديثة بإنشاء أنظمة للتشغيل على آلاف الخوادم. نقترح تتبع المسار إلى اللحظة الحالية ، عندما يكون تطوير ونشر هذا النظام الموزع ممكنًا بواسطة مطور واحد. شارك ألكسندر تريكليبوف ، holonavt ، مهندس شركة برومسفاز بنك ، في تطوير البرمجيات لأكثر من 15 عامًا حول كيفية تطور تقنيات المحاكاة الافتراضية ، وما الدور الذي لعبته حاويات Linux و Docker و Kubernetes. بدأ بـ C ++ ، ثم تحول إلى Java. قام مؤخرًا بتطوير خلفية مصرفية على منصة Spring Cloud.
إذا استدعينا عمليات التنفيذ الأولى لتنفيذ البرنامج النصي (Java Script ، VB Script) كجزء من عرض الصفحات في المستعرض ، فإن هذه كانت عبارة عن تسلسل تعليمات من سلسلة واحدة. نفس جافا سكريبت - إنها مهمة واحدة. إذا تم تنفيذ JS في صفحة ويب واحدة ، وفشل أو تأخر أحد التعليمات القابلة للتنفيذ ، فكل شيء يحدث على الصفحة ، يتم تجميد جميع التعليمات البرمجية. ولا يمكنك فعل أي شيء ، فقط أغلق الصفحة أو أعد تحميلها ، وأحيانًا المتصفح أو نظام التشغيل بأكمله.
من الواضح أنها لم تكن مريحة للغاية. خاصة عندما تفكر في حقيقة أن تعدد المهام / تعدد المهام كان بالفعل في كل مكان: المعالجات وأنظمة التشغيل والتطبيقات (ما لم يكن نظام التشغيل الأول للأجهزة المحمولة عبارة عن مهمة واحدة) ، وكان JS لا يزال مترابطًا واحدًا. ماذا حدث بعد ذلك؟ بدأت الأطر المختلفة في الظهور واحدة تلو الأخرى ، بطريقة أو بأخرى لحل هذه المشكلة. صدر الفيسبوك رد فعل ، أصدرت جوجل الزاوي.
تعدد المهام الأمامية والخلفية
كيف تجعل تعدد المهام من نظام واحد المهام؟ خذ التعليمات وانتشر عبر التدفقات المختلفة ، بالإضافة إلى مراقبة هذه التدفقات بالطبع. من المؤكد أنك لا تزال تتذكر كيف ظهرت فجأة في أحد إصدارات FB القدرة على كتابة رسالة في وقت واحد ومراقبة التغييرات في الشريط. وإذا سقط الشريط فجأة ، استمرت الرسائل في العمل. ثم ظهرت أول واجهة مستخدم على واجهة التفاعل المعيارية. بمساعدة الإطار ، بدأت تعدد المهام للعمل من خارج منطقة الجزاء.
ما علاقة كل ذلك بالخدمات الدقيقة؟ عندما بدأت واجهة المستخدم لبنوك الإنترنت في تقديم وظائف واسعة إلى حد ما ، أصبح التجميد ، وحتى أكثر من ذلك ، سقوط التطبيق ، حدثًا صادمًا للمستخدمين. بعد كل شيء ، كان هناك شيء واحد عندما تعطل Facebook ، وشيء آخر - عندما قمت للتو بدفع الرهن العقاري ، ولم تظهر الأموال في حسابك ، لأنه كان هناك فشل في شكل أرصدة الحساب.
ظهرت فكرة بسيطة - عناصر واجهة مستخدم مستقلة تسمح بربط Angular و React بعناصر خلفية خلفية مستقلة بنفس القدر. كل عنصر من عناصر الواجهة الخلفية المستقلة عبارة عن خدمة متناهية الصغر يمكنها التوسع والارتفاع بعد الفشل ، إلخ.
من المهم بناء واجهة المستخدم بشكل صحيح بحيث يتم تعديلها اعتمادًا على مكونات الواجهة الخلفية المتاحة. إذا لم ينجح شيء ما في الواجهة الخلفية ، فأنت لا تعرض الوظيفة المقابلة في واجهة المستخدم ، أو تعرضها بطريقة افتراضية - يمكنك تغيير لون الخط إلى الرمادي أو عرض لوحة فارغة مع النقش "معلومات رصيد الحساب غير متاحة. اتصل مرة أخرى غدا "في الواقع ، يساعد هذا المزيج من عناصر واجهة المستخدم مع الخدمات الدقيقة على زيادة الموثوقية والقابلية للتوسعة لتطبيق مصرفي.
من Titanic إلى Docker
في رأيي ، فإن السبب الرئيسي الذي جعل الخدمات الصغيرة تحظى بشعبية كبيرة ، على الرغم من استهلاك الذاكرة الكبير والنفقات العامة في قوة الحوسبة ، هو التحلل. أما الخدمات الأخرى ، إلى حد كبير ، فلا تتمتع بمزايا كبيرة مقارنة بالحجارة المتجانسة. التحلل ، في فهمي ، هو عندما يتم تقسيم الوظيفة إلى كتل مستقلة معينة للإطلاق والنشر. هذا يعني أنه بينما تعمل بقية الكتل ، يمكن تحديثها ، غالبًا دون إيقاف عملها (أزرق ، أخضر - نشر) ، ورفع مثيل إضافي.
كل هؤلاء التقنيين لم يظهروا بالأمس ولا أول من أمس. تم تطوير حلول الحوسبة الموزعة مرة أخرى في أيام الحواسيب المركزية لأن نقص موارد الحوسبة ظهر على الفور تقريبًا بمجرد ظهور هذه الموارد.
بدأوا في معرفة كيفية توزيع كل هذا بشكل عقلاني ، على سبيل المثال ، الحسابات الرسومية في محطات Silicon Graphix. كان كل شيء باهظ الثمن ، وكانت هذه الحلول متاحة فقط للمؤسسات الكبيرة ، ناهيك عن المطورين الأفراد. كانت المحطات نفسها وبرامج الخادم مكلفة للغاية ، لذلك تم تطوير القدرات المقابلة لـ Linux kernel. على سبيل المثال - حوسبة رسومات الحاسوب لمشاهد فيلم "Titanic" ، الذي تم إصداره في عام 1997 ، تم إجراؤه على خوادم معالجات ألفا التي تعمل بنظام Linux. لقد تم بالفعل تطوير واختبار معظم الحلول اللازمة لتشغيل الأنظمة الموزعة في ذلك الوقت. ولكن كان لا يزال من الصعب على أحد المتخصصين استخدام جميع هذه التقنيات ، حيث يتطلب تجميع وتسليم ودعم مثل هذا النظام تكاليف عمالية خطيرة.
في البداية ، كانت هناك خوادم فعلية فقط تحتاج إلى التوجيه بطريقة ما ، ثم بدأ عصر المحاكاة الافتراضية ، وظهرت الأجهزة الافتراضية ، وأصبح العمل أكثر متعة ، ولكن لا يزال بدء وإيقاف تشغيل الآلة الافتراضية إجراءً كثيفًا على الموارد. وأردت أن يحدث ذلك بسرعة بدء عملية داخل نظام التشغيل. ارتبطت خطوة كبيرة نحو إطلاق التكنولوجيا "في الناس" بظهور حاويات لينكس.
إن حاوية Linux هي تقريبًا عملية نظام ، ولكنها تحتوي على واجهة شبكية خاصة بها وأكثر من ذلك بكثير جعلتها تقريبًا مثل آلة افتراضية. لماذا تقريبا؟ لأن الجهاز الظاهري يرتفع في بيئة معزولة إلى حد ما. تستخدم حاوية Linux نظام التشغيل الأصلي ، وتحتوي كل حاوية على نسختها الخاصة من نظام التشغيل Linux ، ولكن يتم بث مكالمات النظام إلى نواة نظام التشغيل الأصلي.
هذا له مزاياه - عند إنشاء حاوية LXC ، لا تحتاج إلى إعادة رفع النواة. ومع ذلك ، كان العمل مع حاويات LXC في شكلها الأصلي يستغرق وقتًا طويلاً وغير مريح. في الواقع في وقت ما ظهر Docker. أخذ هذا القرار كل الاهتمام بنشر وإدارة حاويات لينكس ، وكشف واجهة أكثر ملاءمة.
كان ظهور Docker هو الدافع لنشر بنية الخدمات الصغيرة على نطاق واسع. نعم ، تم اختراع التقنيات لفترة طويلة ، ولكن لم تظهر إمكانية استخدامها بسهولة إلا في هذه اللحظة. الآن ، باستخدام Docker ، يمكن للمطور إقران عدة أجهزة افتراضية وتنظيم نظام حوسبة موزعة ، ثم تحديثه وقياسه ديناميكيًا باستخدام أمرين.
وهكذا ، سمحت إمكانات التحلل لدائرة واسعة من المطورين بتحويل متراصة إلى مجموعة من الخدمات الدقيقة داخل الحاويات. ومع ذلك ، نشأت صعوبات جديدة هنا. عندما يكون هناك عشرات الحاويات ومبعثرة عبر عدة خوادم ، فأنت بحاجة إلى إدارتها بطريقة أو بأخرى ومرافقتها وأداء تنسيقها. ظهرت بالفعل حلول مثل Docker Swarm و Kubernetes هنا. تلقى المطور الفردي أداة قوية جديدة.
الخدمات الصغيرة في البنوك
ما هو الوضع مع الخدمات الصغيرة في الصناعة المصرفية؟ كم عدد المطلوب ، على سبيل المثال ، لدعم الخدمات المصرفية عبر الإنترنت؟ هناك مثال جيد: في المملكة المتحدة ، يوجد بنك رقمي بالكامل - مونزو ، ليس لديه مكتب خلفي ، ولا فروع ، ولا موقع ويب ، وكل ذلك في الأساس في تطبيق الهاتف المحمول. بدأ كل شيء مع 40 خدمة صغيرة ، ثم ارتفع عددهم إلى 300 ، الآن أكثر.
إذا نظرت إلى التنفيذ في Promsvyazbank ، فلدينا أنظمة بها ما يصل إلى 40 خدمة صغيرة منتشرة.
بالتوازي ، يتم تطوير أنظمة التطوير التي تسمح باستخدام الأسطر القليلة من التعليمات البرمجية لتطوير المكونات الرئيسية لنظام الخدمات الصغيرة ، والتي يمكن قياسها وتحديثها بكل بساطة. تحظى جميع هذه الميزات بشعبية كبيرة في بناء أنظمة التعلم الآلي ، وتحليل كميات كبيرة من البيانات في الوقت الفعلي (Cloud Streaming ، وما إلى ذلك).
سيخبر ألكسندر تريخليبوف عن تجربته التطويرية القائمة على هندسة الخدمات الصغيرة في تقرير "الخدمات الصغرى - تحمل الخطأ القائم على الوحدات النمطية من النهاية إلى النهاية" في مهرجان عمال الإنترنت 404 ، الذي سيعقد في 6-7 أكتوبر 2018 في سمارة.