العالم لا يقف ساكنا. التقدم يخلق تحديات تكنولوجية جديدة. وفقًا للمتطلبات المتغيرة ، يجب أيضًا تطوير بنية نظم المعلومات. اليوم سوف نتحدث عن الهندسة الموجهة للأحداث ، والقدرة التنافسية ، والتزامن ، وعدم التزامن ، وكيفية العيش بسلام مع كل هذا في إرلانج.
مقدمة
بناءً على حجم النظام الذي يتم تصميمه ومتطلباته ، نختار نحن المطورين طريقة تبادل المعلومات في النظام. في معظم الحالات ، لتنظيم تفاعل الخدمات ، قد يكون خيار العمل عبارة عن مخطط مع وسيط ، على سبيل المثال ، يعتمد على RabbitMQ أو kafka. لكن في بعض الأحيان يكون تدفق الأحداث و SLA ومستوى التحكم في النظام أمرًا لا يناسبنا. بالطبع ، يمكنك تعقيد النظام قليلاً من خلال تحمل مسؤولية طبقة النقل وتكوين الكتلة ، على سبيل المثال باستخدام ZeroMQ أو nanomsg. ولكن إذا كان لدى النظام نطاق ترددي كافٍ وقدرات مجموعة Erlang قياسية ، فإن مسألة إدخال كيان إضافي تتطلب دراسة مفصلة ومبررات اقتصادية.
موضوع التطبيقات الموزعة التفاعلية واسع النطاق. للمحافظة على تنسيق المقال ، سيكون موضوع مناقشة اليوم فقط بيئات متجانسة مبنية على أساس Erlang / Elixir. يسمح النظام البيئي Erlang / OTP بهندسة تفاعلية منخفضة التكلفة. ولكن على أي حال ، نحن بحاجة إلى طبقة مراسلة.
الأساس النظري
التصميم يبدأ بتعريف الأهداف والقيود. الهدف الرئيسي ليس في التنمية من أجل التنمية. نحتاج إلى الحصول على أداة آمنة وقابلة للتطوير على أساسها يمكننا إنشاء تطبيقات حديثة على مستويات مختلفة ، والأهم من ذلك: من خادم واحد يخدم جمهوراً صغيراً ، يمكن أن يتطور فيما بعد إلى مجموعات تصل إلى 50 إلى 60 عقدة ، تنتهي بنقابات اتحاد. وبالتالي ، فإن الهدف الرئيسي هو زيادة الأرباح عن طريق تقليل تكلفة التطوير وملكية النظام النهائي.
هناك 4 متطلبات رئيسية للنظام النهائي:
- مع التوجه اليومي.
النظام جاهز دائمًا لتمرير مجرى الأحداث من خلاله وتنفيذ الإجراءات اللازمة ؛ - M asshtabiruemost.
كتل الفردية يمكن تحجيمها عموديا وأفقيا. يجب أن يكون النظام بأكمله قادرًا على حصر النمو الأفقي ؛ - عن التسامح مع الخطأ.
يجب أن تكون جميع المستويات وجميع الخدمات قادرة على التعافي تلقائيًا من حالات الفشل ؛ - وقت استجابة مضمون.
الوقت ثمين ويجب على المستخدمين عدم الانتظار لفترة طويلة.
تذكر حكاية خرافية قديمة عن "المحرك الصغير الذي يمكن أن" ، ويعرف أيضا باسم "المحرك الذي يمكن"؟ لكي يخرج النظام المصمم بنجاح من مرحلة النموذج الأولي وأن يكون تقدميًا ، يجب أن يفي أساسه بالحد الأدنى لمتطلبات SMOG .
يتم إضافة شيء آخر إلى المراسلة كأداة للبنية التحتية وأساس لجميع الخدمات: سهولة الاستخدام للمبرمجين.
توجيه الحدث
لكي ينمو التطبيق من خادم واحد إلى كتلة ، يجب أن توفر بنيته اتصال ضعيف. يلبي النموذج غير المتزامن هذا المطلب. في ذلك ، يعتني المرسل والمستلم تحميل المعلومات للرسالة ولا تقلق بشأن الإرسال والتوجيه داخل النظام.
التدرجية
قابلية التوسع وأداء النظام يقفان جنبًا إلى جنب. يجب أن تكون مكونات التطبيق قادرة على استخدام جميع الموارد المتاحة. كلما زادت كفاءة استخدامنا للقدرات وكلما زادت طرق المعالجة لدينا إلى الحد الأمثل ، قل إنفاق الأموال على المعدات.
Erlang يخلق بيئة تنافسية للغاية داخل جهاز واحد. يمكن تعيين التوازن بين التزامن والتزامن عن طريق تحديد عدد مؤشرات ترابط نظام التشغيل المتوفرة لـ Erlang VM وعدد أجهزة الجدولة التي تستخدم مؤشرات الترابط هذه.
لا تملك عمليات Erlang حالة مشتركة وتعمل في وضع عدم الحظر. يوفر هذا زمنًا منخفضًا نسبيًا وعرض نطاق ترددي أعلى من التطبيقات التقليدية المبنية على حظر المزامنة. يهتم برنامج جدولة Erlang بالتوزيع العادل لوحدة المعالجة المركزية (CPU) و IO ، وغياب الأقفال يسمح للتطبيق بالاستجابة حتى في أوقات الذروة أو حالات الفشل.
على مستوى المجموعة ، توجد أيضًا مشكلة في إعادة التدوير. من المهم أن يتم تحميل جميع الأجهزة في المجموعة بشكل متساوٍ وأن الشبكة غير محملة بشكل زائد. تخيل موقفًا: تهبط حركة مرور المستخدم على موازنات واردة (haproxy ، nginx ، إلخ) ، ويقومون بتوزيع طلبات المعالجة بالتساوي قدر الإمكان بين مجموعة المؤخرات المتاحة. ضمن إطار البنية التحتية للتطبيق ، الخدمة التي تنفذ الواجهة المطلوبة هي الميل الأخير فقط ، وستحتاج إلى طلب عدد من الخدمات الأخرى للرد على الطلب الأولي. تتطلب الاستعلامات الداخلية أيضًا التوجيه والموازنة.
لإدارة تدفقات البيانات بشكل فعال ، يجب أن توفر المراسلة للمطورين واجهة للتحكم في التوجيه وموازنة التحميل. بفضل هذا ، سيتمكن المطورون من استخدام أنماط الخدمات المصغرة (مجمع ، وكيل ، سلسلة ، فرع ، إلخ) ، لحل كل من المهام القياسية ونادراً ما تنشأ.
من منظور العمل ، تعد قابلية التوسع أحد أدوات إدارة المخاطر. الشيء الرئيسي هو تلبية طلبات العملاء من خلال استخدام المعدات على النحو الأمثل:
- مع زيادة في قدرة المعدات نتيجة للتقدم. لن يكون خاملاً بسبب عيوب البرامج. يقوم Erlang بقياس رأسيًا تمامًا ويمكنه دائمًا إعادة تدوير جميع مراكز وحدة المعالجة المركزية والذاكرة المتاحة ؛
- في البيئات الملبدة بالغيوم ، يمكننا التحكم في كمية المعدات حسب الحمل الحالي أو المتوقع وضمان SLA.
خطأ التسامح
النظر في اثنين من البديهيات: "الفشل غير مقبول" و "الفشل سيكون دائما". بالنسبة للشركات ، فإن فشل البرامج هو خسارة المال ، والأسوأ من ذلك ، السمعة. تحقيق التوازن بين الخسائر المحتملة وتكلفة تطوير البرامج التي تتحمل الأخطاء ، يمكنك غالبًا إيجاد حل وسط.
على المدى القصير ، توفر البنية ذات التسامح مع الأخطاء المال عند شراء حلول التجميع بنظام تسليم المفتاح. أنها باهظة الثمن ، ولها أيضا أخطاء.
على المدى الطويل ، تدفع بنية تحمل الأخطاء مرارًا وتكرارًا تكاليف تطبيقه في جميع مراحل التطوير.
تتيح لك المراسلة داخل قاعدة الكود في مرحلة التصميم أن تفصل بالتفصيل تفاعل المكونات داخل النظام. يعمل ذلك على تبسيط مهمة الاستجابة وإدارة حالات الفشل ، حيث أن جميع المكونات المهمة تتعامل مع حالات الفشل ، ويعرف النظام الناتج كيفية العودة تلقائيًا إلى وضعها الطبيعي بعد الفشل حسب التصميم.
حنان
بغض النظر عن حالات الفشل ، يجب أن يستجيب التطبيق للطلبات وتلبية اتفاقيات مستوى الخدمة. الحقيقة هي أن الناس لا يريدون الانتظار ، لذلك يجب ضبط العمل. من المتوقع أن تكون التطبيقات أكثر استجابةً للغاية.
تعمل التطبيقات المستجيبة على مقربة من وضع الوقت الفعلي. يعمل Erlang VM في وضع الوقت الحقيقي الناعم. بالنسبة لبعض المناطق ، مثل تبادل التبادل ، والطب ، وإدارة المعدات الصناعية ، من الصعب وضع الوقت الحقيقي.
الأنظمة المستجيبة تعزز UX وتساعد الشركات.
النتيجة الأولية
في تخطيط هذه المقالة ، أردت مشاركة تجربة إنشاء وسيط مراسلة وبناء أنظمة معقدة على أساسه. لكن الجزء النظري والتحفيزي اتضح أنه واسع النطاق.
في الجزء الثاني من المقال ، سأتحدث عن الفروق الدقيقة في تطبيق نقاط التبادل وقوالب الرسائل وتطبيقاتها.
في الجزء الثالث ، نأخذ في الاعتبار المشكلات العامة المتعلقة بتنظيم الخدمات والتوجيه والموازنة. دعونا نتحدث عن الجانب العملي للتوسعة والتسامح مع الخطأ للأنظمة.
نهاية الجزء الاول.
صورة @ lucabravo .