system design 101
1.0.0
【 ?? يوتيوب | ؟ النشرة الإخبارية 】
شرح الأنظمة المعقدة باستخدام الصور والمصطلحات البسيطة.
سواء كنت تستعد لمقابلة تصميم النظام أو كنت تريد ببساطة فهم كيفية عمل الأنظمة تحت السطح، نأمل أن يساعدك هذا المستودع على تحقيق ذلك.
تحدد أنماط البنية كيفية تفاعل المكونات المختلفة لواجهة برمجة التطبيقات (API) مع بعضها البعض. ونتيجة لذلك، فإنها تضمن الكفاءة والموثوقية وسهولة التكامل مع الأنظمة الأخرى من خلال توفير نهج قياسي لتصميم وبناء واجهات برمجة التطبيقات. فيما يلي الأنماط الأكثر استخدامًا:
صابون:
ناضجة وشاملة، وعلى أساس XML
الأفضل لتطبيقات المؤسسات
مريح:
طرق HTTP الشائعة وسهلة التنفيذ
مثالية لخدمات الويب
الرسم البيانيQL:
لغة الاستعلام، طلب بيانات محددة
يقلل من حمل الشبكة، واستجابات أسرع
جي آر بي سي:
مخازن مؤقتة للبروتوكولات حديثة وعالية الأداء
مناسبة لبنيات الخدمات الصغيرة
مقبس الويب:
اتصالات مستمرة وثنائية الاتجاه في الوقت الفعلي
مثالي لتبادل البيانات بزمن وصول منخفض
خطاف ويب:
عمليات الاسترجاعات HTTP المستندة إلى الأحداث وغير المتزامنة
يخطر الأنظمة عند وقوع الأحداث
عندما يتعلق الأمر بتصميم واجهة برمجة التطبيقات (API)، فإن لكل من REST وGraphQL نقاط قوة ونقاط ضعف خاصة بهما.
يوضح الرسم البياني أدناه مقارنة سريعة بين REST وGraphQL.
استراحة
GraphQL
يعتمد الاختيار الأفضل بين REST وGraphQL على المتطلبات المحددة لفريق التطبيق والتطوير. يعد GraphQL مناسبًا جيدًا لاحتياجات الواجهة الأمامية المعقدة أو المتغيرة بشكل متكرر، بينما يناسب REST التطبيقات التي تفضل العقود البسيطة والمتسقة.
لا يعتبر أي من نهجي واجهة برمجة التطبيقات بمثابة حل سحري. من المهم تقييم المتطلبات والمقايضات بعناية لاختيار النمط المناسب. يعد كل من REST وGraphQL خيارين صالحين لعرض البيانات وتشغيل التطبيقات الحديثة.
يُطلق على RPC (استدعاء الإجراء البعيد) اسم " بعيد " لأنه يتيح الاتصالات بين الخدمات البعيدة عندما يتم نشر الخدمات على خوادم مختلفة ضمن بنية الخدمات الصغيرة. من وجهة نظر المستخدم، فهو بمثابة استدعاء دالة محلية.
يوضح الرسم البياني أدناه تدفق البيانات الإجمالي لـ gRPC .
الخطوة 1: يتم إجراء مكالمة REST من العميل. يكون نص الطلب عادةً بتنسيق JSON.
الخطوات من 2 إلى 4: تتلقى خدمة الطلب (عميل gRPC) مكالمة REST، وتحولها، وتقوم بإجراء استدعاء RPC لخدمة الدفع. يقوم gRPC بتشفير كعب العميل إلى تنسيق ثنائي ويرسله إلى طبقة النقل ذات المستوى المنخفض.
الخطوة 5: يرسل gRPC الحزم عبر الشبكة عبر HTTP2. بسبب التشفير الثنائي وتحسينات الشبكة، يُقال إن gRPC أسرع بـ 5 مرات من JSON.
الخطوات من 6 إلى 8: تتلقى خدمة الدفع (خادم gRPC) الحزم من الشبكة، وتقوم بفك تشفيرها، واستدعاء تطبيق الخادم.
الخطوات من 9 إلى 11: يتم إرجاع النتيجة من تطبيق الخادم، ويتم تشفيرها وإرسالها إلى طبقة النقل.
الخطوات من 12 إلى 14: تتلقى خدمة الطلب الحزم وتفك تشفيرها وترسل النتيجة إلى تطبيق العميل.
يوضح الرسم البياني أدناه مقارنة بين الاستطلاع وWebhook.
لنفترض أننا ندير موقعًا للتجارة الإلكترونية. يقوم العملاء بإرسال الطلبات إلى خدمة الطلب عبر بوابة API، والتي تذهب إلى خدمة الدفع لإجراء معاملات الدفع. ثم تتحدث خدمة الدفع إلى مزود خدمة الدفع الخارجي (PSP) لإكمال المعاملات.
هناك طريقتان للتعامل مع الاتصالات مع مزود خدمة الدفع الخارجي.
1. الاقتراع القصير
بعد إرسال طلب الدفع إلى مزود خدمة الدفع، تستمر خدمة الدفع في سؤال مزود خدمة الدفع عن حالة الدفع. بعد عدة جولات، يعود جهاز PSP أخيرًا بالحالة.
الاقتراع القصير له عيبان:
2. الخطاف الإلكتروني
يمكننا تسجيل خطاف ويب مع الخدمة الخارجية. وهذا يعني: معاودة الاتصال بي على عنوان URL معين عندما يكون لديك تحديثات بشأن الطلب. عندما يكمل مزود خدمة الدفع (PSP) المعالجة، سيقوم باستدعاء طلب HTTP لتحديث حالة الدفع.
بهذه الطريقة، يتم تغيير نموذج البرمجة، ولن تحتاج خدمة الدفع إلى إهدار الموارد لاستقصاء حالة الدفع بعد الآن.
ماذا لو لم يتصل PSP أبدًا؟ يمكننا إعداد وظيفة التدبير المنزلي للتحقق من حالة الدفع كل ساعة.
غالبًا ما يُشار إلى خطافات الويب على أنها واجهات برمجة التطبيقات العكسية أو واجهات برمجة التطبيقات الدافعة لأن الخادم يرسل طلبات HTTP إلى العميل. نحتاج إلى الانتباه إلى ثلاثة أشياء عند استخدام خطاف الويب:
يوضح الرسم البياني أدناه 5 حيل شائعة لتحسين أداء واجهة برمجة التطبيقات (API).
ترقيم الصفحات
يعد هذا تحسينًا شائعًا عندما يكون حجم النتيجة كبيرًا. يتم بث النتائج مرة أخرى إلى العميل لتحسين استجابة الخدمة.
التسجيل غير المتزامن
يتعامل التسجيل المتزامن مع القرص لكل مكالمة ويمكن أن يبطئ النظام. يرسل التسجيل غير المتزامن السجلات إلى مخزن مؤقت خالٍ من القفل أولاً ويعود على الفور. سيتم مسح السجلات إلى القرص بشكل دوري. وهذا يقلل بشكل كبير من حمل الإدخال/الإخراج.
التخزين المؤقت
يمكننا تخزين البيانات التي يتم الوصول إليها بشكل متكرر في ذاكرة التخزين المؤقت. يمكن للعميل الاستعلام عن ذاكرة التخزين المؤقت أولاً بدلاً من زيارة قاعدة البيانات مباشرة. في حالة فقدان ذاكرة التخزين المؤقت، يمكن للعميل الاستعلام من قاعدة البيانات. تقوم ذاكرة التخزين المؤقت مثل Redis بتخزين البيانات في الذاكرة، وبالتالي فإن الوصول إلى البيانات يكون أسرع بكثير من قاعدة البيانات.
ضغط الحمولة
يمكن ضغط الطلبات والاستجابات باستخدام gzip وما إلى ذلك بحيث يكون حجم البيانات المرسلة أصغر بكثير. يؤدي هذا إلى تسريع عملية التحميل والتنزيل.
تجمع الاتصال
عند الوصول إلى الموارد، غالبًا ما نحتاج إلى تحميل البيانات من قاعدة البيانات. يؤدي فتح اتصالات قاعدة البيانات المغلقة إلى إضافة حمل كبير. لذلك يجب علينا الاتصال بقاعدة البيانات عبر مجموعة من الاتصالات المفتوحة. تجمع الاتصال مسؤول عن إدارة دورة حياة الاتصال.
ما هي المشكلة التي يحلها كل جيل من HTTP؟
ويوضح الرسم البياني أدناه الميزات الرئيسية.
تم الانتهاء من HTTP 1.0 وتوثيقه بالكامل في عام 1996. ويتطلب كل طلب إلى نفس الخادم اتصال TCP منفصلاً.
تم نشر HTTP 1.1 في عام 1997. يمكن ترك اتصال TCP مفتوحًا لإعادة الاستخدام (الاتصال المستمر)، ولكنه لا يحل مشكلة حظر HOL (رأس الخط).
حظر HOL - عند استنفاد عدد الطلبات المتوازية المسموح بها في المتصفح، تحتاج الطلبات اللاحقة إلى انتظار اكتمال الطلبات السابقة.
تم نشر HTTP 2.0 في عام 2015. وهو يعالج مشكلة HOL من خلال تعدد إرسال الطلبات، مما يزيل حظر HOL في طبقة التطبيق، ولكن لا يزال HOL موجودًا في طبقة النقل (TCP).
كما ترون في الرسم البياني، قدم HTTP 2.0 مفهوم "تدفقات" HTTP: وهو تجريد يسمح بتعدد عمليات تبادل HTTP المختلفة على نفس اتصال TCP. لا يلزم إرسال كل تيار بالترتيب.
تم نشر المسودة الأولى لـ HTTP 3.0 في عام 2020. وهو الوريث المقترح لـ HTTP 2.0. ويستخدم QUIC بدلاً من TCP لبروتوكول النقل الأساسي، وبالتالي إزالة حظر HOL في طبقة النقل.
يعتمد QUIC على UDP. يقدم تيارات كمواطنين من الدرجة الأولى في طبقة النقل. تشترك تدفقات QUIC في نفس اتصال QUIC، لذلك لا يلزم وجود مصافحات إضافية وبدء تشغيل بطيء لإنشاء تدفقات جديدة، ولكن يتم تسليم تدفقات QUIC بشكل مستقل بحيث لا يؤثر فقدان الحزمة الذي يؤثر على تدفق واحد في معظم الحالات على التدفقات الأخرى.
يوضح الرسم البياني أدناه الجدول الزمني لواجهة برمجة التطبيقات (API) ومقارنة أنماط واجهة برمجة التطبيقات (API).
بمرور الوقت، تم إصدار أنماط معمارية مختلفة لواجهة برمجة التطبيقات (API). كل واحد منهم لديه أنماطه الخاصة لتوحيد تبادل البيانات.
يمكنك التحقق من حالات الاستخدام لكل نمط في الرسم التخطيطي.
يوضح الرسم البياني أدناه الاختلافات بين تطوير الكود الأول وتطوير واجهة برمجة التطبيقات أولاً. لماذا نريد النظر في التصميم الأول لواجهة برمجة التطبيقات (API)؟
من الأفضل التفكير في مدى تعقيد النظام قبل كتابة التعليمات البرمجية وتحديد حدود الخدمات بعناية.
يمكننا الاستهزاء بالطلبات والاستجابات للتحقق من صحة تصميم واجهة برمجة التطبيقات (API) قبل كتابة التعليمات البرمجية.
يسعد المطورون بهذه العملية أيضًا لأنه يمكنهم التركيز على التطوير الوظيفي بدلاً من التفاوض على التغييرات المفاجئة.
يتم تقليل احتمال حدوث مفاجآت في نهاية دورة حياة المشروع.
نظرًا لأننا صممنا واجهة برمجة التطبيقات (API) أولاً، فيمكن تصميم الاختبارات أثناء تطوير الكود. بطريقة ما، لدينا أيضًا TDD (التصميم القائم على الاختبار) عند استخدام التطوير الأول لواجهة برمجة التطبيقات (API).
تنقسم رموز الاستجابة لـ HTTP إلى خمس فئات:
معلوماتية (100-199) نجاح (200-299) إعادة توجيه (300-399) خطأ العميل (400-499) خطأ في الخادم (500-599)
ويوضح الرسم البياني أدناه التفاصيل.
الخطوة 1 - يرسل العميل طلب HTTP إلى بوابة API.
الخطوة 2 - تقوم بوابة API بتوزيع السمات الموجودة في طلب HTTP والتحقق من صحتها.
الخطوة 3 - تقوم بوابة واجهة برمجة التطبيقات (API) بإجراء عمليات فحص قائمة السماح/قائمة الرفض.
الخطوة 4 - تتحدث بوابة API مع موفر الهوية للمصادقة والترخيص.
الخطوة 5 - يتم تطبيق قواعد تحديد المعدل على الطلب. إذا تجاوز الحد، يتم رفض الطلب.
الخطوتان 6 و7 - الآن بعد أن اجتاز الطلب عمليات التحقق الأساسية، تعثر بوابة API على الخدمة ذات الصلة للتوجيه إليها عن طريق مطابقة المسار.
الخطوة 8 - تقوم بوابة API بتحويل الطلب إلى البروتوكول المناسب وإرساله إلى الخدمات الصغيرة الخلفية.
الخطوات من 9 إلى 12: يمكن لبوابة API التعامل مع الأخطاء بشكل صحيح، والتعامل مع الأخطاء إذا استغرق الخطأ وقتًا أطول للتعافي (انقطاع الدائرة). يمكنه أيضًا الاستفادة من مكدس ELK (Elastic-Logstash-Kibana) للتسجيل والمراقبة. نقوم أحيانًا بتخزين البيانات مؤقتًا في بوابة API.
يوضح الرسم البياني أدناه تصميمات واجهة برمجة التطبيقات النموذجية مع مثال لعربة التسوق.
لاحظ أن تصميم واجهة برمجة التطبيقات (API) ليس مجرد تصميم مسار URL. في معظم الأحيان، نحتاج إلى اختيار أسماء الموارد والمعرفات وأنماط المسار المناسبة. ومن المهم أيضًا تصميم حقول رأس HTTP مناسبة أو تصميم قواعد فعالة لتحديد المعدل داخل بوابة API.
كيف يتم إرسال البيانات عبر الشبكة؟ لماذا نحتاج إلى العديد من الطبقات في نموذج OSI؟
يوضح الرسم البياني أدناه كيفية تغليف البيانات وإلغاء تغليفها عند إرسالها عبر الشبكة.
الخطوة 1: عندما يرسل الجهاز "أ" البيانات إلى الجهاز "ب" عبر الشبكة عبر بروتوكول HTTP، تتم أولاً إضافة رأس HTTP في طبقة التطبيق.
الخطوة 2: ثم تتم إضافة رأس TCP أو UDP إلى البيانات. يتم تغليفه في مقاطع TCP في طبقة النقل. يحتوي الرأس على المنفذ المصدر، والمنفذ الوجهة، ورقم التسلسل.
الخطوة 3: يتم بعد ذلك تغليف المقاطع برأس IP في طبقة الشبكة. يحتوي رأس IP على عناوين IP المصدر/الوجهة.
الخطوة 4: تتم إضافة مخطط بيانات IP إلى رأس MAC في طبقة ارتباط البيانات، مع عناوين MAC للمصدر/الوجهة.
الخطوة 5: يتم إرسال الإطارات المغلفة إلى الطبقة المادية وإرسالها عبر الشبكة في وحدات بت ثنائية.
الخطوات من 6 إلى 10: عندما يستقبل الجهاز ب البتات من الشبكة، فإنه ينفذ عملية إلغاء التغليف، وهي معالجة عكسية لعملية التغليف. تتم إزالة الرؤوس طبقة تلو الأخرى، وفي النهاية، يستطيع الجهاز ب قراءة البيانات.
نحتاج إلى طبقات في نموذج الشبكة لأن كل طبقة تركز على مسؤولياتها الخاصة. يمكن لكل طبقة الاعتماد على الرؤوس لمعالجة التعليمات ولا تحتاج إلى معرفة معنى البيانات من الطبقة الأخيرة.
الرسم البياني أدناه يوضح الاختلافات بين ؟؟؟؟؟؟؟ ؟؟؟؟؟ و ؟؟؟؟؟؟؟؟ ؟؟؟؟؟؟.
الوكيل الأمامي هو خادم يقع بين أجهزة المستخدم والإنترنت.
يتم استخدام الوكيل الأمامي بشكل شائع من أجل:
الوكيل العكسي هو خادم يقبل طلبًا من العميل، ويعيد توجيه الطلب إلى خوادم الويب، ويعيد النتائج إلى العميل كما لو كان الخادم الوكيل قد عالج الطلب.
الوكيل العكسي مفيد من أجل:
يوضح الرسم البياني أدناه 6 خوارزميات شائعة.
جولة روبن
يتم إرسال طلبات العميل إلى مثيلات الخدمة المختلفة بترتيب تسلسلي. عادةً ما يُطلب من الخدمات أن تكون عديمة الجنسية.
لزجة جولة روبن
يعد هذا تحسينًا لخوارزمية round-robin. إذا كان طلب أليس الأول يذهب إلى الخدمة "أ"، فإن الطلبات التالية تذهب إلى الخدمة "أ" أيضًا.
جولة روبن المرجحة
يمكن للمسؤول تحديد الوزن لكل خدمة. الأشخاص ذوو الوزن الأعلى يتعاملون مع طلبات أكثر من غيرهم.
التجزئة
تطبق هذه الخوارزمية وظيفة التجزئة على عنوان IP أو عنوان URL للطلبات الواردة. يتم توجيه الطلبات إلى المثيلات ذات الصلة بناءً على نتيجة دالة التجزئة.
اتصالات أقل
يتم إرسال طلب جديد إلى مثيل الخدمة مع أقل الاتصالات المتزامنة.
أقل وقت للاستجابة
يتم إرسال طلب جديد إلى مثيل الخدمة بأسرع وقت استجابة.
يوضح الرسم البياني أدناه مقارنة بين عنوان URL وURI وURN.
يرمز URI إلى معرف الموارد الموحد. فهو يحدد موردًا منطقيًا أو ماديًا على الويب. URL وURN هما أنواع فرعية من URI. يحدد URL موقع المورد، بينما يقوم URN بتسمية المورد.
يتكون URI من الأجزاء التالية: المخطط:[//authority]path[?query][#fragment]
يرمز URL إلى محدد موقع الموارد، وهو المفهوم الأساسي لـ HTTP. إنه عنوان مورد فريد على الويب. ويمكن استخدامه مع بروتوكولات أخرى مثل FTP وJDBC.
URN لتقف علي اسم المورد الموحد. ويستخدم مخطط الجرة. لا يمكن استخدام URNs لتحديد موقع المورد. يتكون المثال البسيط الوارد في الرسم التخطيطي من مساحة اسم وسلسلة خاصة بمساحة الاسم.
إذا كنت ترغب في معرفة المزيد من التفاصيل حول هذا الموضوع، فإنني أوصي بتوضيح W3C.
القسم 1 - SDLC مع CI/CD
تتكون دورة حياة تطوير البرمجيات (SDLC) من عدة مراحل رئيسية: التطوير والاختبار والنشر والصيانة. يقوم CI/CD بأتمتة هذه المراحل ودمجها لتمكين الإصدارات بشكل أسرع وأكثر موثوقية.
عندما يتم دفع التعليمات البرمجية إلى مستودع git، فإنها تؤدي إلى عملية إنشاء واختبار تلقائية. يتم تشغيل حالات الاختبار الشاملة (e2e) للتحقق من صحة الكود. إذا نجحت الاختبارات، فيمكن نشر التعليمات البرمجية تلقائيًا إلى التدريج/الإنتاج. إذا تم العثور على مشكلات، فسيتم إرسال الكود مرة أخرى إلى التطوير لإصلاح الأخطاء. توفر هذه الأتمتة تعليقات سريعة للمطورين وتقلل من مخاطر الأخطاء في الإنتاج.
القسم 2 - الفرق بين CI وCD
يعمل التكامل المستمر (CI) على أتمتة عملية الإنشاء والاختبار والدمج. يتم إجراء اختبارات كلما تم التزام التعليمات البرمجية لاكتشاف مشكلات التكامل مبكرًا. وهذا يشجع على الالتزام المتكرر للتعليمات البرمجية والتعليقات السريعة.
يعمل التسليم المستمر (CD) على أتمتة عمليات الإصدار مثل تغييرات البنية التحتية والنشر. فهو يضمن إمكانية إصدار البرامج بشكل موثوق في أي وقت من خلال سير العمل الآلي. قد يقوم القرص المضغوط أيضًا بأتمتة خطوات الاختبار والموافقة اليدوية المطلوبة قبل نشر الإنتاج.
القسم 3 - خط أنابيب CI/CD
يحتوي خط أنابيب CI/CD النموذجي على عدة مراحل متصلة:
التخطيط: تستخدم شركة Netflix Engineering JIRA للتخطيط وConfluence للتوثيق.
البرمجة: Java هي لغة البرمجة الأساسية للخدمة الخلفية، بينما يتم استخدام لغات أخرى لحالات استخدام مختلفة.
البناء: يتم استخدام Gradle بشكل أساسي للبناء، وتم تصميم مكونات Gradle الإضافية لدعم حالات الاستخدام المختلفة.
التعبئة والتغليف: يتم تعبئة الحزمة والتبعيات في Amazon Machine Image (AMI) للإصدار.
الاختبار: يؤكد الاختبار على تركيز ثقافة الإنتاج على بناء أدوات الفوضى.
النشر: تستخدم Netflix جهاز Spinnaker المدمج ذاتيًا لنشر طرح الكناري.
المراقبة: تتمركز مقاييس المراقبة في نظام Atlas، ويتم استخدام Kayenta للكشف عن الحالات الشاذة.
تقرير الحادث: يتم إرسال الحوادث وفقًا للأولوية، ويتم استخدام PagerDuty للتعامل مع الحادث.
تعد أنماط الهندسة هذه من بين الأنماط الأكثر استخدامًا في تطوير التطبيقات، سواء على منصات iOS أو Android. لقد قدمها المطورون للتغلب على قيود الأنماط السابقة. إذًا، كيف يختلفون؟
الأنماط هي حلول قابلة لإعادة الاستخدام لمشاكل التصميم الشائعة، مما يؤدي إلى عملية تطوير أكثر سلاسة وكفاءة. إنها بمثابة مخططات لبناء هياكل برمجية أفضل. هذه بعض الأنماط الأكثر شيوعًا:
يعد اختيار قاعدة البيانات المناسبة لمشروعك مهمة معقدة. العديد من خيارات قاعدة البيانات، كل منها يناسب حالات استخدام مختلفة، يمكن أن تؤدي بسرعة إلى إرهاق اتخاذ القرار.
نأمل أن توفر ورقة الغش هذه توجيهًا رفيع المستوى لتحديد الخدمة المناسبة التي تتوافق مع احتياجات مشروعك وتجنب المخاطر المحتملة.
ملحوظة: لدى Google وثائق محدودة لحالات استخدام قاعدة البيانات الخاصة بها. على الرغم من أننا بذلنا قصارى جهدنا للنظر في ما هو متاح وتوصلنا إلى الخيار الأفضل، إلا أن بعض الإدخالات قد تحتاج إلى أن تكون أكثر دقة.
ستختلف الإجابة حسب حالة الاستخدام الخاصة بك. يمكن فهرسة البيانات في الذاكرة أو على القرص. وبالمثل، تختلف تنسيقات البيانات، مثل الأرقام والسلاسل والإحداثيات الجغرافية وما إلى ذلك. قد يكون النظام ثقيل الكتابة أو ثقيل القراءة. تؤثر كل هذه العوامل على اختيارك لتنسيق فهرس قاعدة البيانات.
فيما يلي بعض هياكل البيانات الأكثر شيوعًا المستخدمة لفهرسة البيانات:
ويوضح الرسم البياني أدناه العملية. لاحظ أن بنيات قواعد البيانات المختلفة تختلف، ويوضح الرسم البياني بعض التصاميم المشتركة.
الخطوة 1 - يتم إرسال عبارة SQL إلى قاعدة البيانات عبر بروتوكول طبقة النقل (egTCP).
الخطوة 2 - يتم إرسال عبارة SQL إلى محلل الأوامر، حيث تمر عبر التحليل النحوي والدلالي، ويتم إنشاء شجرة استعلام بعد ذلك.
الخطوة 3 - يتم إرسال شجرة الاستعلام إلى المحسن. يقوم المحسن بإنشاء خطة التنفيذ.
الخطوة 4 - يتم إرسال خطة التنفيذ إلى المنفذ. يقوم المنفذ باسترداد البيانات من التنفيذ.
الخطوة 5 - توفر طرق الوصول منطق جلب البيانات المطلوب للتنفيذ، واسترداد البيانات من محرك التخزين.
الخطوة 6 - تحدد أساليب الوصول ما إذا كانت عبارة SQL للقراءة فقط. إذا كان الاستعلام للقراءة فقط (عبارة SELECT)، فسيتم تمريره إلى مدير المخزن المؤقت لمزيد من المعالجة. يبحث مدير المخزن المؤقت عن البيانات الموجودة في ذاكرة التخزين المؤقت أو ملفات البيانات.
الخطوة 7 - إذا كان البيان عبارة عن تحديث أو إدراج، فسيتم تمريره إلى مدير المعاملات لمزيد من المعالجة.
الخطوة 8 - أثناء المعاملة، تكون البيانات في وضع القفل. وهذا مضمون من قبل مدير القفل. كما أنه يضمن خصائص ACID للمعاملة.
تعد نظرية CAP واحدة من أشهر المصطلحات في علوم الكمبيوتر، لكنني أراهن أن المطورين المختلفين لديهم فهم مختلف. دعونا نتفحص ما هو ولماذا يمكن أن يكون مربكًا.
تنص نظرية CAP على أن النظام الموزع لا يمكنه توفير أكثر من ضمانتين من هذه الضمانات الثلاثة في وقت واحد.
الاتساق : يعني الاتساق أن جميع العملاء يرون نفس البيانات في نفس الوقت بغض النظر عن العقدة التي يتصلون بها.
التوفر : يعني التوفر أن أي عميل يطلب البيانات يحصل على استجابة حتى لو كانت بعض العقد معطلة.
تسامح القسم : يشير القسم إلى انقطاع الاتصال بين عقدتين. التسامح مع القسم يعني استمرار النظام في العمل على الرغم من أقسام الشبكة.
قد تكون صيغة "2 من 3" مفيدة، ولكن هذا التبسيط قد يكون مضللاً .
اختيار قاعدة البيانات ليس بالأمر السهل. إن تبرير اختيارنا بناءً على نظرية CAP ليس كافيًا. على سبيل المثال، لا تختار الشركات Cassandra لتطبيقات الدردشة لمجرد أنها نظام AP. هناك قائمة من الخصائص الجيدة التي تجعل من Cassandra خيارًا مرغوبًا فيه لتخزين رسائل الدردشة. نحن بحاجة إلى حفر أعمق.
"يحظر CAP جزءًا صغيرًا فقط من مساحة التصميم: التوفر المثالي والاتساق في وجود الأقسام، وهو أمر نادر". مقتبس من الورقة: CAP بعد اثني عشر عامًا: كيف تغيرت "القواعد".
النظرية هي حوالي 100٪ من التوافر والاتساق. ستكون المناقشة الأكثر واقعية هي المفاضلة بين زمن الوصول والاتساق عندما لا يكون هناك قسم للشبكة. راجع نظرية PACELC لمزيد من التفاصيل.
هل نظرية CAP مفيدة بالفعل؟
أعتقد أنه لا يزال مفيدًا لأنه يفتح عقولنا لمجموعة من مناقشات المقايضة، ولكنه جزء فقط من القصة. نحن بحاجة إلى التعمق أكثر عند اختيار قاعدة البيانات الصحيحة.
يتم تنفيذ عبارات SQL بواسطة نظام قاعدة البيانات في عدة خطوات، منها:
يعد تنفيذ SQL أمرًا معقدًا للغاية وينطوي على العديد من الاعتبارات، مثل:
في عام 1986، أصبحت SQL (لغة الاستعلام الهيكلية) هي المعيار. وعلى مدار الأربعين عامًا التالية، أصبحت اللغة السائدة في أنظمة إدارة قواعد البيانات العلائقية. يمكن أن تستغرق قراءة أحدث المعايير (ANSI SQL 2016) وقتًا طويلاً. كيف يمكنني تعلم ذلك؟
هناك 5 مكونات للغة SQL:
بالنسبة لمهندس الواجهة الخلفية، قد تحتاج إلى معرفة معظمها. كمحلل بيانات، قد تحتاج إلى فهم جيد لـ DQL. حدد المواضيع الأكثر صلة بك.
يوضح هذا الرسم البياني المكان الذي نقوم فيه بتخزين البيانات في بنية نموذجية.
هناك طبقات متعددة على طول التدفق.
هناك 3 أسباب رئيسية كما هو موضح في الرسم البياني أدناه.
سؤال: متجر الذاكرة الشهير الآخر هو Memcached. هل تعرف الاختلافات بين Redis وMemcached؟
ربما لاحظت أن نمط هذا المخطط يختلف عن مشاركاتي السابقة. واسمحوا لي أن أعرف أي واحد تفضله.
هناك ما هو أكثر في Redis من مجرد التخزين المؤقت.
يمكن استخدام redis في مجموعة متنوعة من السيناريوهات كما هو موضح في الرسم البياني.
حصة
يمكننا استخدام redis لمشاركة بيانات جلسة المستخدم بين الخدمات المختلفة.
مخبأ
يمكننا استخدام redis لتخزين الكائنات أو الصفحات ، خاصة بالنسبة لبيانات نقطة الساخنة.
قفل موزع
يمكننا استخدام سلسلة redis لاكتساب الأقفال بين الخدمات الموزعة.
عداد
يمكننا حساب عدد الإعجابات أو عدد القراءات للمقالات.
محدد معدل
يمكننا تطبيق محدد معدل لبعض IPS المستخدم.
مولد الهوية العالمية
يمكننا استخدام redis int للمعرف العالمي.
عربة التسوق
يمكننا استخدام تجزئة Redis لتمثيل أزواج القيمة الرئيسية في عربة التسوق.
حساب احتباس المستخدم
يمكننا استخدام صورة نقطية لتمثيل تسجيل الدخول إلى المستخدم يوميًا وحساب احتباس المستخدم.
قائمة انتظار الرسائل
يمكننا استخدام قائمة لقائمة انتظار الرسائل.
تصنيف
يمكننا استخدام Zset لفرز المقالات.
عادة ما يتطلب تصميم أنظمة واسعة النطاق دراسة متأنية للتخزين المؤقت. فيما يلي خمس استراتيجيات للتخزين المؤقت التي يتم استخدامها بشكل متكرر.
يوضح الرسم البياني أدناه بنية خدمة microservice النموذجية.
فوائد الخدمات المجهرية:
الصورة تساوي ألف كلمة: 9 أفضل الممارسات لتطوير الخدمات المجهرية.
عندما نطور الخدمات المجهرية ، نحتاج إلى متابعة أفضل الممارسات التالية:
ستجد أدناه مخططًا يوضح مكدس Tech Microservice ، سواء لمرحلة التطوير أو للإنتاج.
هناك العديد من قرارات التصميم التي ساهمت في أداء كافكا. في هذا المنشور ، سنركز على اثنين. نعتقد أن هذين يحملان أكبر وزن.
يوضح الرسم البياني كيف يتم نقل البيانات بين المنتج والمستهلك ، وماذا تعني الصفر.
2.1 يتم تحميل البيانات من القرص إلى ذاكرة التخزين المؤقت
2.2 يتم نسخ البيانات من OS Cache إلى تطبيق Kafka
2.3 تطبيق Kafka ينسخ البيانات في المخزن المؤقت للمقبس
2.4 يتم نسخ البيانات من المخزن المؤقت للمقبس إلى بطاقة الشبكة
2.5 ترسل بطاقة الشبكة البيانات إلى المستهلك
3.1: يتم تحميل البيانات من القرص إلى OS Cache 3.2 OS Cache مباشرة نسخ البيانات إلى بطاقة الشبكة عبر الأمر sendFile () 3.3 ترسل بطاقة الشبكة البيانات إلى المستهلك
نسخة Zero هي اختصار لحفظ نسخ البيانات المتعددة بين سياق التطبيق وسياق kernel.
يوضح الرسم البياني أدناه اقتصاديات تدفق دفع بطاقة الائتمان.
1. حامل البطاقة يدفع تاجر 100 دولار لشراء منتج.
2. يستفيد التاجر من استخدام بطاقة الائتمان مع ارتفاع حجم المبيعات ويحتاج إلى تعويض المصدر وشبكة البطاقات لتوفير خدمة الدفع. يحدد البنك المستحيل رسومًا مع التاجر ، يسمى "رسوم الخصم التاجر".
3 - 4. يحتفظ البنك المكتسب بمبلغ 0.25 دولار كعلامة الحصول على العلامات ، ويتم دفع 1.75 دولار إلى البنك المصدر كرسوم تبادل. يجب أن تغطي رسوم الخصم التاجر رسوم التبادل.
يتم تحديد رسوم التبادل بواسطة شبكة البطاقات لأنه أقل كفاءة لكل بنك إصدار للتفاوض على الرسوم مع كل تاجر.
5. تقوم شبكة البطاقات بإعداد تقييمات الشبكة والرسوم مع كل بنك ، والتي تدفع شبكة البطاقات لخدماتها كل شهر. على سبيل المثال ، تتقاضى Visa تقييمًا بنسبة 0.11 ٪ ، بالإضافة إلى رسوم استخدام بقيمة 0.0195 دولار ، لكل انتقاد.
6. حامل البطاقة يدفع البنك المصدر لخدماته.
لماذا يجب تعويض البنك المصدر؟
تعمل Visa و MasterCard و American Express كشبكات بطاقات لتطهير الأموال وتسويتها. يمكن أن يكون البنك الذي يحصل على البطاقة والبنك الذي يصدر البطاقة - وغالبًا ما يكونان مختلفًا. إذا كانت البنوك ستسدد المعاملات واحدة تلو الأخرى دون وسيط ، فسيتعين على كل بنك تسوية المعاملات مع جميع البنوك الأخرى. هذا غير فعال للغاية.
يوضح الرسم البياني أدناه دور VISA في عملية دفع بطاقة الائتمان. هناك تدفقان معنيان. يحدث تدفق التفويض عندما يمرب العميل بطاقة الائتمان. يحدث التقاط وتدفق التسوية عندما يريد التاجر الحصول على المال في نهاية اليوم.
الخطوة 0: تصدر البطاقة تصدر بطاقات الائتمان للبطاقات لعملائها.
الخطوة 1: يريد حامل البطاقة شراء منتج ويضرب بطاقة الائتمان في محطة Point of Sale (POS) في متجر التاجر.
الخطوة 2: ترسل محطة نقاط البيع المعاملة إلى البنك الذي حصل عليه ، والذي قدم محطة نقاط البيع.
الخطوتين 3 و 4: يرسل بنك الاستحواذ المعاملة إلى شبكة البطاقات ، وتسمى أيضًا مخطط البطاقة. ترسل شبكة البطاقة المعاملة إلى البنك المصدر للموافقة عليه.
الخطوات 4.1 و 4.2 و 4.3: يتجمد البنك المصدر الأموال إذا تمت الموافقة على المعاملة. يتم إرسال الموافقة أو الرفض مرة أخرى إلى المستحوذ ، وكذلك محطة نقاط البيع.
الخطوتين 1 و 2: يريد التاجر جمع الأموال في نهاية اليوم ، لذلك ضربوا "التقاط" على محطة نقاط البيع. يتم إرسال المعاملات إلى المستحوذ على الدفعة. يرسل Acquirer ملف الدُفعات مع معاملات إلى شبكة البطاقات.
الخطوة 3: تنفذ شبكة البطاقات المقاصة للمعاملات التي تم جمعها من مختلف المشترين ، وترسل ملفات المقاصة إلى بنوك إصدار مختلفة.
الخطوة 4: تؤكد البنوك المصدرة صحة ملفات المقاصة ، وتحويل الأموال إلى البنوك المستحوذ عليها ذات الصلة.
الخطوة 5: بنك الاستحواذ ثم ينقل الأموال إلى بنك التاجر.
الخطوة 4: تقوم شبكة البطاقات بمسح المعاملات من مختلف البنوك الحصول على. المقاصة هي عملية يتم فيها تقليل معاملات الإزاحة المتبادلة ، وبالتالي يتم تقليل عدد المعاملات الكلية.
في هذه العملية ، تأخذ شبكة البطاقات عبء التحدث إلى كل بنك وتتلقى رسوم الخدمة في المقابل.
ما هو UPI؟ UPI هو نظام دفع فوري في الوقت الفعلي التي طورتها مؤسسة المدفوعات الوطنية في الهند.
يمثل 60 ٪ من معاملات البيع بالتجزئة الرقمية في الهند اليوم.
UPI = لغة ترميز الدفع + معيار للمدفوعات القابلة للتشغيل البيني
ظهرت مفاهيم DevOps و SRE و Platform Engineering في أوقات مختلفة وتم تطويرها من قبل مختلف الأفراد والمنظمات.
تم تقديم DevOps كمفهوم في عام 2009 من قبل باتريك ديبويس وأندرو شيفر في مؤتمر Agile. لقد سعوا إلى سد الفجوة بين تطوير البرمجيات والعمليات من خلال الترويج لثقافة تعاونية والمسؤولية المشتركة عن دورة حياة تطوير البرمجيات بأكملها.
كانت Google رائدة في SRE ، أو هندسة موثوقية الموقع ، في أوائل العقد الأول من القرن العشرين لمواجهة التحديات التشغيلية في إدارة الأنظمة المعقدة على نطاق واسع. طورت Google ممارسات وأدوات SRE ، مثل نظام إدارة مجموعة BORG ونظام مراقبة Monarch ، لتحسين موثوقية خدماتها وكفاءتها.
يعد هندسة المنصات مفهومًا أحدث ، بناءً على أساس SRE Engineering. الأصول الدقيقة لهندسة المنصات أقل وضوحًا ، لكن من المفهوم عمومًا أنها امتداد لممارسات DevOps و SRE ، مع التركيز على تقديم منصة شاملة لتطوير المنتجات التي تدعم منظور العمل بأكمله.
تجدر الإشارة إلى أنه في حين ظهرت هذه المفاهيم في أوقات مختلفة. ترتبط جميعها بالاتجاه الأوسع المتمثل في تحسين التعاون والأتمتة والكفاءة في تطوير البرمجيات وعملياتها.
K8S هو نظام تزامن حاويات. يتم استخدامه لنشر الحاويات وإدارتها. يتأثر تصميمه بشكل كبير بنظام Borg الداخلي لشركة Google.
تتكون مجموعة K8S من مجموعة من آلات العمال ، تسمى العقد ، التي تعمل على تشغيل تطبيقات الحاويات. كل مجموعة لديها عقدة عامل واحد على الأقل.
تستضيف عقدة العمال (S) القرون التي هي مكونات عبء عمل التطبيق. تدير طائرة التحكم العقد العامل والقرون في الكتلة. في بيئات الإنتاج ، تعمل طائرة التحكم عادةً عبر أجهزة كمبيوتر متعددة ، وعادة ما تعمل الكتلة على عقد متعددة ، مما يوفر تحمل الأعطال وتوافر عالي.
خادم API
يتحدث خادم API إلى جميع المكونات في مجموعة K8S. يتم تنفيذ جميع العمليات على القرون عن طريق التحدث إلى خادم API.
مجدول
يراقب Scheduler عبء عمل POD ويعين تحميلات على القرون التي تم إنشاؤها حديثًا.
مدير وحدة التحكم
يقوم مدير وحدة التحكم بتشغيل وحدات التحكم ، بما في ذلك وحدة تحكم العقدة ، وحدات التحكم في الوظائف ، ووحدة التحكم في نقطة النهاية ، ووحدة تحكم ServiceAccount.
الخ
ETCD هو متجر قيمة رئيسي يستخدم كمتجر دعم Kubernetes لجميع بيانات الكتلة.
قرون
POD عبارة عن مجموعة من الحاويات وهي أصغر وحدة تديرها K8S. تحتوي القرون على عنوان IP واحد مطبق على كل حاوية داخل القرنة.
kubelet
وكيل يعمل على كل عقدة في الكتلة. إنه يضمن أن الحاويات تعمل في جراب.
بروكسي كوبي
Kube-Proxy هو وكيل شبكة يعمل على كل عقدة في المجموعة الخاصة بك. يوجه حركة المرور القادمة إلى عقدة من الخدمة. تقوم بإعادة توجيه طلبات العمل إلى الحاويات الصحيحة.
ما هو Docker؟
Docker هو منصة مفتوحة المصدر تتيح لك حزم التطبيقات وتوزيعها وتشغيلها في حاويات معزولة. إنه يركز على الحاويات ، مما يوفر بيئات خفيفة الوزن التي تغلف التطبيقات وتبعياتها.
ما هو Kubernetes؟
Kubernetes ، وغالبًا ما يشار إليها باسم K8S ، هي منصة تزامن حاوية مفتوحة المصدر. يوفر إطار عمل لأتمتة نشر التطبيقات المخصصة للحاويات وتوسيعها وإدارتها عبر مجموعة من العقد.
كيف يختلف كلاهما عن بعضهما البعض؟
Docker: يعمل Docker على مستوى الحاوية الفردية على مضيف نظام تشغيل واحد.
يجب عليك إدارة كل مضيف وإعداد الشبكات ، وسياسات الأمان ، ويمكن أن تكون التخزين لحاويات متعددة ذات صلة معقدة.
Kubernetes: يعمل Kubernetes على مستوى الكتلة. إنه يدير تطبيقات حاوية متعددة عبر مضيفين متعددين ، وتوفير أتمتة للمهام مثل موازنة التحميل ، والتوسيع ، وضمان الحالة المطلوبة للتطبيقات.
باختصار ، يركز Docker على حاويات الحاويات وتشغيلها على المضيفين الفرديين ، بينما تتخصص Kubernetes في إدارة الحاويات وتنسيقها على نطاق واسع عبر مجموعة من المضيفين.
يوضح الرسم البياني أدناه بنية Docker وكيف يعمل عندما ندير "Docker Build" و "Docker Pull" و "Docker Run".
هناك 3 مكونات في هندسة Docker:
عميل Docker
يتحدث عميل Docker إلى Docker Daemon.
مضيف Docker
يستمع Docker Daemon لطلبات Docker API ويدير كائنات Docker مثل الصور والحاويات والشبكات والمجلدات.
سجل Docker
يقوم سجل Docker بتخزين صور Docker. Docker Hub هو سجل عام يمكن لأي شخص استخدامه.
لنأخذ الأمر "Docker Run" كمثال.
بادئ ذي بدء ، من الضروري تحديد مكان تخزين رمزنا. الافتراض الشائع هو أن هناك موقعين فقط - أحدهما على خادم بعيد مثل GitHub والآخر على جهازنا المحلي. ومع ذلك ، هذا ليس دقيقًا تمامًا. يحتفظ Git بثلاثة مخزن محلي على جهازنا ، مما يعني أنه يمكن العثور على رمزنا في أربعة أماكن:
معظم أوامر GIT تنقل الملفات بشكل أساسي بين هذه المواقع الأربعة.
يعرض الرسم البياني أدناه سير عمل GIT.
GIT هو نظام التحكم في الإصدار الموزع.
يحتفظ كل مطور بنسخة محلية من المستودع الرئيسي والتعديلات ويلتزم بالنسخة المحلية.
الالتزام سريع للغاية لأن العملية لا تتفاعل مع المستودع البعيد.
في حالة تعطل المستودع البعيد ، يمكن استرداد الملفات من المستودعات المحلية.
ما هي الاختلافات؟
