هناك
العديد من أنواع بنيات البرمجيات مع إيجابياتها وسلبياتها. بعد ذلك ، سنتحدث عن ميزات أكثرها شيوعًا ونتحدث عن انتقالنا إلى الخدمات الصغيرة.
/ libreshot / PDأنواع بنيات البرمجيات
عمارة ذات طبقات
هذه واحدة من أكثر البنايات شيوعًا. على أساسها ، تم بناء العديد من الأطر الكبيرة - Java EE ، Drupal ، Express. ربما يكون المثال الأكثر شهرة لهذه الهندسة المعمارية هو نموذج شبكة
OSI .
ينقسم النظام إلى مستويات يتفاعل كل منها مع مستويين مجاورين فقط. لذلك ، فإن الاستعلامات إلى قاعدة البيانات ، التي تقع عادة في نهاية سلسلة التفاعل ، تمر بالتسلسل عبر كل "طبقة".
لا تتضمن العمارة أي عدد إلزامي من المستويات - يمكن أن يكون هناك ثلاثة أو أربعة أو خمسة أو أكثر. في معظم الأحيان ، يتم استخدام أنظمة ثلاثية المستويات: مع مستوى العرض التقديمي (العميل) ، والمستوى المنطقي ، ومستوى البيانات.
تم كتابة عدد لا يحصى من الكتب والمقالات حول العمارة متعددة المستويات. وكانت هناك آراء مختلفة حول مزاياها وعيوبها.
الإيجابيات:يؤدي كل مستوى من هذه البنية مجموعة محدودة للغاية من الوظائف (التي لا تتكرر من طبقة إلى أخرى) ولا تعرف كيف يتم ترتيب المستويات الأخرى. لذلك ، يمكن تغيير "محتويات" المستويات دون مخاطر الصراعات العالمية بين الطبقات.
بشكل عام ، تنتشر التطبيقات متعددة المستويات على نطاق واسع بحيث يتم إنشاء مولدات قوالب خاصة لتطويرها. على سبيل المثال ،
يقدم LASG لـ Visual Studio العديد من طرق إنشاء التعليمات البرمجية التي تعمل على أتمتة المهام الروتينية وتساعد في بناء مستويات التطبيق.
العيوب:في البرمجة ، هناك قول بأن أي مشكلة يمكن حلها بإضافة مستوى آخر من التجريد. ومع ذلك ، يمكن أن يؤدي هذا النهج في نهاية المطاف إلى سوء تنظيم التعليمات البرمجية وإرباك المطورين.
تنشأ مشكلة أخرى من هذا - السرعة المنخفضة. تبدأ الكثير من المعلومات بالمرور بلا فائدة من طبقة إلى أخرى ، دون استخدام منطق الأعمال.
تسمى هذه المشكلة في بعض الأحيان
باسم نمط مكافحة الحوض ، وهو نمط تصميم عندما يبدأ عدد العمليات غير المجدية في الانتشار على العمليات المفيدة.
قد يكون من الصعب أيضًا العثور على أخطاء في أنظمة متعددة المستويات. قبل إدخال قاعدة البيانات ، تمر المعلومات عبر جميع المستويات (نظرًا لأن قاعدة البيانات هي المكون النهائي). إذا كانت هذه المعلومات تالفة لسبب ما (أو فُقدت على طول الطريق) ، فعندئذٍ من أجل العثور على خطأ ، يجب عليك تحليل كل مستوى على حدة.
صالح جيد:- لإنشاء تطبيقات جديدة تحتاج للنشر بسرعة. هذا هو نوع من "قالب للأغراض العامة".
عندما بدأنا العمل على الأنظمة الداخلية لمزود البنية التحتية الافتراضية لدينا في 1cloud ، استخدمنا هذا النوع الخاص من الهندسة المعمارية. في البداية ، لم تكن لدينا مهمة إنشاء خدمة IaaS قادرة على معالجة حركة مرور عشرات أو مئات الآلاف من المستخدمين. لقد قررنا إطلاق المنتج بسرعة في السوق والبدء في تطوير قاعدة عملاء وحل مشكلات التوسع كلما أصبحت متاحة (والآن نقوم بنقل جميع الأنظمة إلى بنية خدمة صغيرة ، والتي سيتم مناقشتها لاحقًا).
بين المطورين هناك رأي مفاده أنه ليس من الضروري منذ الأيام الأولى للمشروع إعداده للأحمال الضخمة (كتابة برنامج إثبات مستقبلي). قد تختلف المتطلبات الفعلية للتطبيق أو الخدمة عن التوقعات ، وقد تتغير أهداف العمل . لذلك ، رمز مكتوب مع مراعاة المخاطر المستقبلية البعيدة تصبح دينًا تقنيًا. - وفقًا لأوريلي ، تعد الهندسة المعمارية ذات الطبقات خيارًا طبيعيًا للعديد من تطبيقات المؤسسات. نظرًا لأن الشركات (خاصة الكبيرة منها) غالبًا ما تشترك في الكفاءات: هناك فريق مسؤول عن الواجهة الأمامية ، فهناك أشخاص مسؤولون عن النهاية الخلفية ، وما إلى ذلك. هذا يعني التقسيم الطبيعي للتطبيقات إلى مستويات: يعمل بعض المطورين على العميل ، والبعض الآخر على المنطق.
هناك علاقة مماثلة بين هيكل المنظمة ونهج تطوير التطبيقات تمليها أيضًا قانون كونواي ، الذي تمت صياغته في عام 1967. يقرأ: "عند تطوير نظام ، تضطر المنظمات إلى الالتزام بمخطط يكرر هيكل الاتصالات داخل الشركة."
العمارة الموجهة نحو الحدث
في هذه الحالة ، يصف المطور سلوك (ردود الفعل) للبرنامج عند حدوث أي أحداث. يعتبر حدث في النظام تغييرًا كبيرًا في حالته.
يمكنك رسم تشابه مع شراء سيارة في المقصورة. عندما تعثر السيارة على مالك جديد ، يتغير حالتها من "للبيع" إلى "بيع". يطلق هذا الحدث عملية التحضير لما قبل البيع - تركيب معدات إضافية ، والتحقق من الحالة الفنية ، والغسيل ، وما إلى ذلك.
عادة ما يحتوي النظام الذي يحركه الحدث على مكونين: مصادر الأحداث (الوكلاء) والمستهلكين (الأحواض). عادة ما يكون هناك نوعان من الأحداث أيضًا: حدث بدء وحدث يستجيب له المستهلكون.
مكتبة جافا سوينغ مثال على تنفيذ مثل هذه الهندسة. إذا كان الفصل بحاجة إلى تنبيه بشأن حدث ما ، فسيقوم المطور بتنفيذ ما يسمى المستمع - ActionListener (وهو "يمسك" بالحدث المقابل) ، ويلحقه بالكائن الذي يمكن لهذا الحدث إنشاؤه.
يتم توفير كود التنفيذ التالي لهذه الآلية في الويكي:
public class FooPanel extends JPanel implements ActionListener { public FooPanel() { super(); JButton btn = new JButton("Click Me!"); btn.addActionListener(this); this.add(btn); } @Override public void actionPerformed(ActionEvent ae) { System.out.println("Button has been clicked!"); } }
مزايا العمارة:نظرًا لأن التطبيقات تتكون من عدد كبير من الوحدات غير المتزامنة (التي لا تحتوي على معلومات حول تنفيذ بعضها البعض) ، فمن السهل قياسها. يتم تجميع هذه الأنظمة كمنشئ - لا تحتاج إلى تسجيل التبعيات ، فقط قم بتنفيذ وحدة نمطية جديدة. بالإضافة إلى ذلك ، يسمح النموذج غير المتزامن بأداء تطبيق عالي.
العيوب:وتعقد الطبيعة غير المتزامنة لمثل هذه التطبيقات التصحيح. يمكن أن يؤدي حدث واحد إلى عدة سلاسل من الإجراءات في وقت واحد. إذا كان هناك الكثير من هذه السلاسل ، فقد
يكون من الصعب فهم سبب الفشل بالضبط. لحل المشكلة ، علينا
أن نحدد الظروف الصعبة للتعامل مع الأخطاء. من هنا تأتي مشكلة تسجيل الدخول - من
الصعب بناء السجلات.
مناسب ل:- إنشاء أنظمة غير متزامنة. هذا واضح لأن العمارة نفسها تتكون من عدد كبير من الوحدات غير المتزامنة.
- يمكن استخدامه لإنشاء واجهة مستخدم. تعمل صفحة الويب كحاوية يتم فيها عزل كل مكون من مكوناتها ويستجيب لإجراءات مستخدم معينة.
- لتنظيم الرسائل بين أنظمة المعلومات المختلفة.
العمارة Microkernel
يتكون هذا النوع من الهندسة المعمارية من مكونين: جوهر النظام والمكونات الإضافية. الإضافات مسؤولة عن منطق الأعمال ، وتدير النواة تحميلها وتفريغها.
كمثال على بنية microkernel ،
يوفر كتاب O'Reilly Eclipse IDE. هذا محرر بسيط يفتح الملفات ، ويسمح بتحريرها وتشغيل عمليات الخلفية. ولكن مع إضافة المكونات الإضافية (على سبيل المثال ، مترجم Java) ، تتوسع وظائفه.
استخدمت بنية microkernel في وقت واحد نظام تشغيل Symbian للأجهزة المحمولة (تم إيقاف التطوير في عام 2012). في مجهرها الصغير كان برنامج جدولة المهام وأنظمة إدارة الذاكرة وبرامج التشغيل ، وكان نظام الملفات والمكونات المسؤولة عن الاتصالات الهاتفية بمثابة المكونات الإضافية.
مزايا العمارة:من السهل نقل تطبيق من بيئة إلى أخرى ، حيث يلزم تعديل النوى الصغيرة فقط. يعمل الفصل بين السياسات عالية المستوى والآليات منخفضة المستوى على تبسيط دعم النظام ويضمن قابليته للتوسع.
العيوب:ينخفض أداء التطبيق إذا قمت بتوصيل عدد كبير جدًا من الوحدات النمطية. ومع ذلك ، قد يكون من
الصعب العثور على توازن بين عدد المكونات الإضافية وعدد مهام النوى الصغيرة (عادة ما تحتوي فقط على التعليمات البرمجية المستخدمة بشكل متكرر).
من الصعب أيضًا تحديد مقدمًا (قبل تطوير التطبيق) الدرجة المثلى لتفتيت شفرة النوى الصغيرة. ويكاد يكون من المستحيل تغيير النهج في وقت لاحق.
مناسب لـ:- إنشاء تطبيقات قابلة للتوسيع يستخدمها عدد كبير من الأشخاص. على سبيل المثال ، يحتوي نظام تشغيل iPhone على جذور "microkernel" - استوحى مطوروه من Mach (هذا هو أحد الأمثلة الأولى على microkernel).
- إنشاء تطبيقات بفصل واضح بين الأساليب الأساسية والقواعد عالية المستوى.
- تطوير الأنظمة مع مجموعة قواعد متغيرة ديناميكيًا يجب تحديثها بشكل متكرر.
الخدمات الدقيقة
على غرار العمارة التي يحركها الحدث و microkernel. ولكن يتم استخدامها عندما يمكن تقسيم مهام التطبيق الفردية بسهولة إلى وظائف صغيرة -
خدمات مستقلة . يمكن كتابة هذه الخدمات بلغات برمجة مختلفة لأنها تتواصل مع بعضها البعض باستخدام REST API (على سبيل المثال ، باستخدام
JSON أو
Thrift ).
يقرر المطور في النسب التي تنقسم فيها الشفرة ، لكن سام نيومان ، مؤلف كتاب "
إنشاء خدمات صغيرة "
، يوصي بتخصيص أكبر عدد ممكن من أسطر التعليمات البرمجية للخدمة الصغيرة كما يمكن للفريق إعادة إنتاجها خلال أسبوعين. ووفقا له ، فإن هذا سيسمح بتجنب "الانتفاخ" المفرط للهندسة المعمارية.
في معظم الأحيان ، يتم إطلاق الخدمات الدقيقة في ما يسمى الحاويات. يمكن الوصول إلى هذه الحاويات عبر الشبكة من خلال الخدمات والتطبيقات الصغيرة الأخرى ، ويديرها نظام التنسيق كل هذه الأمثلة: تشمل Kubernetes و Docker Swarm ، إلخ.
المزايا:تعمل بنية الخدمات المصغرة على تبسيط قياس التطبيق. لتنفيذ ميزة جديدة ، ما عليك سوى كتابة خدمة جديدة. إذا لم تعد هناك حاجة إلى الوظيفة ، يمكن تعطيل الخدمة الصغيرة. تعد كل خدمة صغيرة مشروعًا منفصلاً ، وبالتالي فمن السهل توزيع العمل عليها بين فرق التطوير.
اقرأ المزيد عن آليات التحجيم لأنظمة الخدمات الصغيرة في كتاب مارتن ل. أبوت ، فن قابلية التوسع.
العيوب:من الصعب البحث عن الأخطاء. على عكس الأنظمة المتجانسة (عندما تكون جميع الوظائف في نفس النواة) ، قد يكون من الصعب تحديد سبب "سقوط" الطلب. لمزيد من التفاصيل ، عليك الذهاب إلى سجلات عملية "المذنب" (إذا كان هناك العديد ، فإن المشكلة تتفاقم).
يؤدي هذا إلى إنشاء حمل إضافي لنقل الرسائل بين الخدمات الصغيرة. وفقًا لتقديراتنا ، يمكن أن يصل نمو تكاليف الشبكة إلى 25٪.
عيب آخر هو
الحاجة إلى طرح مفهوم الاتساق النهائي (
التماسك على المدى الطويل ). تمتلك الخدمات الدقيقة مستودعات البيانات الخاصة بها ، والتي يمكن الوصول إليها عن طريق الخدمات الدقيقة الأخرى. لا يتم توزيع المعلومات حول التغييرات على هذه البيانات على الفور من خلال النظام. لذلك ، تنشأ المواقف عندما تكون بعض الخدمات الدقيقة (وإن كانت لفترة قصيرة للغاية) بيانات قديمة.
مكان الاستخدام:- في المشاريع الكبيرة ذات الحمولة العالية. على سبيل المثال ، يتم استخدام الخدمات الدقيقة بواسطة منصات التدفق. يمكن تحجيم أنظمة تقديم المحتوى وخدمات الدعم الأخرى بشكل مستقل عن بعضها البعض ، والتكيف مع تغييرات التحميل.
- في الأنظمة التي تستخدم الموارد "المختلطة". إذا كان جزء من التطبيق يحتاج إلى مزيد من وقت المعالج ، والثاني - الذاكرة ، فمن المنطقي تقسيمها إلى خدمات دقيقة. ثم يمكن استضافتها على أجهزة مختلفة - مع وحدة معالجة مركزية قوية أو كمية كبيرة من الذاكرة ، على التوالي.
- عندما تكون هناك حاجة للأمن . نظرًا لأن الخدمات الصغيرة معزولة وتتواصل عن طريق واجهة برمجة التطبيقات ، فإنه يمكن ضمان نقل المعلومات التي تحتاجها خدمة معينة فقط. هذا مهم عند العمل مع كلمات المرور أو بيانات بطاقة الدفع.
لماذا ننتقل إلى الخدمات الصغيرة في 1cloud
كما قلنا من قبل ، فإن أساس الخدمات التي نقدمها (
سحابة خاصة ،
خوادم افتراضية ،
تخزين سحابي للكائنات ، وما إلى ذلك) يعتمد على بنية متعددة المستويات. أظهرت نفسها على الجانب الجيد ، ولكن الآن بدأت قدرتها على التوسع تنفد.
لقد أصبحنا شركاء أكثر فأكثر يقدمون حلولهم بناءً على منصة الامتياز الخاصة بنا. هناك مواقع وخدمات نائية يصعب إدارتها من نقطة واحدة (على وجه الخصوص ، توجد معداتنا في العديد من مراكز البيانات
في روسيا وكازاخستان وروسيا البيضاء ).
لتسهيل توسيع الوظائف الحالية وتقديم ميزات جديدة ، نقوم بنقل بنيتنا الأساسية بالكامل إلى الخدمات الصغيرة في
1cloud .
نريد فصلها إلى وحدات منفصلة وبدلاً من الحصول على قاعدة بيانات معقدة واحدة N بسيطة. وبالتالي ، في الهيكل الجديد ، سيكون لكل ميزة قاعدة بيانات منفصلة. وهو أكثر ملاءمة وكفاءة في الدعم والتطوير.
سنكون قادرين على تقسيم العمل على الخدمات بين العديد من المطورين (تسليط الضوء على التخصصات في الشركة) والتوسع بشكل أفقي بشكل فعال - عند الضرورة ، سنقوم ببساطة بربط الخدمات الصغيرة الجديدة.
سيحصل عملائنا أيضًا على عدد من المزايا. نظرًا لأن الخدمات الصغيرة غير متصلة ببعضها البعض ، فعندما تفشل خدمة معينة ، لن تكون سوى الخدمة متاحة ، وستستمر بقية الخدمات في العمل بشكل طبيعي. علاوة على ذلك ، حتى في حالة حدوث انخفاض عالمي في خدمتنا ، ستستمر لوحة التحكم في العمل.
سيلاحظ العملاء من كازاخستان وبيلاروسيا (وبلدان أخرى حيث سنفتح مكاتب تمثيلية) زيادة كبيرة في سرعة واستجابة الواجهات ، حيث سيتم وضع لوحات التحكم محليًا.
ما تم بالفعل
حتى الآن قمنا بتنفيذ أول تجربة تجريبية فقط: "خدمة المراقبة". سيتم نقل الخدمات المتبقية إلى مسار جديد في نهاية 2018 - بداية 2019.
في الوقت نفسه ، تضع الهندسة المعمارية الجديدة الأساس التكنولوجي للمرحلة التالية - الهجرة إلى الحاويات. الآن نستخدم البنية الأساسية لـ Windows ، وللتحول إلى الحاويات ، نحتاج إلى إعادة كتابة جميع التعليمات البرمجية المتراكمة إلى .NetCore ونقلها إلى Linux.
نخطط لبدء انتقال جديد في بداية 2019 وإنهائه في نهاية العام المقبل.
بكلمات بسيطة حول ما يستحق أن نتذكره عن الهندسة المعمارية- بنية متعددة المستويات - ينقسم التطبيق إلى مستويات ، يؤدي كل منها مجموعة محددة بدقة من الوظائف. يمكن تعديل كل مستوى على حدة. من بين أوجه القصور هي السرعة المنخفضة للرمز وصعوبة العثور على الأخطاء.
مناسبة لتطوير التطبيقات التي تحتاج إلى طرحها بسرعة في السوق. كثيرا ما تستخدم لإنشاء خدمات المؤسسة. - بنية موجهة نحو الحدث - هنا يصف المطور رد فعل النظام على أي أحداث. على سبيل المثال ، إذا تم تلقي البيانات ، اكتبها في ملف. من السهل توسيع نطاق التطبيقات المستندة إلى بنية موجهة للأحداث ، نظرًا لأن جميع معالجات الأحداث لا تعرف أي شيء عن تنفيذ بعضها البعض. ومع ذلك ، فإن تصحيح هذه الأنظمة أمر صعب - يمكن أن يتسبب إجراء واحد في عدة سلاسل من الإجراءات في وقت واحد (من الصعب فهم أيها تسبب في الفشل).
تستخدم لإنشاء أنظمة غير متزامنة وتنظيم الواجهات الرسومية وأنظمة الرسائل. - بنية Microkernel - تتكون من مكونين رئيسيين: الإضافات والنواة. الإضافات مسؤولة عن منطق الأعمال ، والنواة مسؤولة عن تحميلها وتفريغها. يبسط هذا الفصل بين المهام دعم النظام. ومع ذلك ، يمكن أن يؤثر على الأداء - يعتمد بشكل مباشر على عدد الوحدات المتصلة والنشطة.
وهي مناسبة لتطوير التطبيقات القابلة للتوسيع التي يستخدمها عدد كبير من الأشخاص ، والأنظمة التي تحتوي على مجموعة من القواعد التي يجب تحديثها غالبًا (الإضافات تضمن سهولة التحديث). - بنية الخدمات الصغيرة - تنقسم التطبيقات إلى وظائف - خدمات صغيرة. إن كل خدمة صغيرة هي مكون مستقل له منطق أعمال خاص به. تتواصل هذه المكونات مع بعضها باستخدام API. من السهل تطوير هذه التطبيقات (من الممكن توزيع العمل بين فرق التطوير) ، ولكن من الصعب تصحيحه.
تستخدم في المشاريع الكبيرة ذات الحمولة العالية ، والتي تتطلب مزيدًا من الأمان.
ماذا نكتب أيضًا على مدونة 1cloud: