VOL63: Top 16 Kubernetes Essential Components
أهلًا وسهلا بكم في العدد الثالث والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثالث والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Top 16 Kubernetes Essential Components
How LinkedIn Improves Microservices Performance With Protobuf
High Availability in Distributed Systems
CQRS Architecture Pattern
الإصدار الأول من مدونات فطين في تصميم النظم
Top 16 Kubernetes Essential Components
يعتبر K8s أشهر الـ Orchestrators حاليًا وبتظهر أهميته في الشركات الكبيرة وبيئات ال Microservices المعقدة لأنه يقدر يدير ويسهل عملية نشر التطبيقات بطريقة منظمة وقابلة للتوسع. هنتكلم بشكل مختصر عن أهم المكونات وإزاي بتتواصل مع بعضها البعض.
أهم مكونات Kubernetes الأساسية
1- Container: هي حاوية تحمل بداخلها التطبيق مع بيئة كاملة تشمل كل ما يحتاجه من اعتماديات ليعمل.
2- Pod: أصغر وحدة Deployable في K8s ، تحتوي على حاوية واحدة أو أكثر تُدار معًا وتشارك نفس الـ IP والـ Volume.
3- Node: خادم (فعلي أو افتراضي) يعمل عليه K8s ويشغّل الـ Pods. وتسمي ال Node ب Worker Node عندما تقوم بتشغيل ال(Pods) التي تم جدولة تشغيلها من قبل الـ Master.
4- Cluster: يُسمي النظام الذي يديره K8S بال Cluster ويتكون من مجموعة من الـ Nodes تُدار كوحدة واحدة لتشغيل التطبيقات.
5- Control Plane: أو تسمى بال Master Node وهي المسؤولة عن إدارة الـ Cluster بأكمله عن طريق عدة مكونات.
6- Kubelet: هو Agent يعمل على كل Node. وظيفته هي التأكد من أن الحاويات تعمل كما هو متوقع في الPod, بيعمل دا في عدة خطوات زي التواصل مع ال Control Panel وكذلك مع الـ Container runtime وتجميع تقارير عن حالة ال Containers وإرسالها لـ Control Panel.
7- Kube-proxy: المكون المسؤول عن إدارة الشبكة وتوجيه ال traffic لل worker node وال Service الصحيحة.
8- API Server: هو العنصر الرئيسي في الـ Control Plane، ويُعتبر البوابة (Gateway) التي يتفاعل من خلالها كل شيء داخل أو خارج الـ cluster مع k8s.
9- Controller manager: هو المسؤول عن إدارة الحالة داخل الـ cluster والتأكد من أن كل شيء يعمل كما هو "مطلوب" (وفقًا لتعريفك في ملفات YAML مثل Deployments، ReplicaSets، إلخ).
10- Scheduler: مكون من مكونات الـ Control Plane بيحدد أين يجب تشغيل الـ Pods, فوقت ما تطلب إنشاء Pod جديد بيقوم ال Scheduler باختيار الـ Node المناسبة من حيث الموارد وال Constraints لإنشاء الPod.
11- ETCD: هي قاعدة البيانات الأساسية والمركزية التي يستخدمها k8s لتخزين الحالة الكاملة لـ cluster. وهي بالأساس Key-value Store لضمان البساطة والسرعة في تخزين واسترجاع بيانات الـ cluster وبتعتبر هي ال Source of truth لباقي ال Cluster.
12- Service: هي كيان بيوفّر نقطة وصول ثابتة وثابتة الاسم (Stable Endpoint) لمجموعة من الـ Pods، حتى لو تغيّرت أو أُعيد تشغيلها.لأن ال Pods لما يعاد تشغيلها ممكن ال IP الخاص بيها يتغير ووقتها أنت كمستخدم هتحتاج تغير طريقة تواصلك معها وعشان نتجنب دا بنقدم ال Service فتفضل طريقة التواصل للتطبيق أو الخدمة ثابتة بغض النظر عن تفاصيل التشغيل.
13- Kubectl: ال Command line interface الأساسية للتفاعل مع Kubernetes
14- ConfigMaps: تُستخدم لتخزين الإعدادات غير السرية للتطبيقات.
15- Secrets: تُستخدم لتخزين معلومات حساسة (مثل كلمات المرور ، مفاتيح API).
16- Ingress: هو عبارة عن Smart gateway تُستخدم لتوجيه الزيارات الخارجية (HTTP/HTTPS) القادمة من الإنترنت إلى داخل ال Cluster وتحديدًا إلى الـ Services وال Pods المناسبة.
How LinkedIn Improves Microservices Performance With Protobuf
كل يوم، لينكدإن بتتعامل مع مليارات الطلبات من الأعضاء عبر كل منصاتها، بما فيها تطبيقات الويب والموبايل.
من المهم جدًا إن الطلبات دي زي مشاهدة صفحات الشركات، قراءة مقالات على لينكدإن، أو مشاهدة الاتصالات Network Connections مع الناس، تتنفذ بسرعة وما يكونش فيه تأخير في تحميل الصفحات دي.
وعشان جزء مهم من أهداف لينكدإن هو جعل المحترفين في العالم أكثر إنتاجية ونجاح، فأوقات تحميل الصفحات بتلعب دور كبير في ده. علشان نضمن إن الأعضاء بيستمتعوا بتجربتهم على المنصة وبيتنقلوا بسرعة، فقاموا مؤخرًا ضايفين Encoding Solution في Rest.li اللي بيستعملوه بشكل كبير في الـ Microservices عندهم، وده اللي نتج عنه تقليل في الـ Latency وتحسين الـ Resource Utilization.
Rest.li
طورت ليندإن Rest.li وهو عبارة عن إطار عمل REST مفتوح المصدر تم بناؤه واستخدامه بشكل كبير في لينكدإن للتطوير من الـ Microservices عشان تلبية طلبات الأعضاء.
والـ Microservices بتنظم كل الـ Platforms اللي في لينكدإن كمجموعة من الـ Loosely Coupled Services، وبتتواصل من خلال بروتوكولات خفيفة. فمن خلال استعمال Rest.li مكنهم ده من بناء RESTful Architectures تكون قوية وقابلة للتوسع من خلال استعمال الـ Type-Safe Bindings والـ Uniform Interface Design، ومبادئ الـ Consistent Data Modeling.
ومن خلال طبقات مختلفة في الـ Tech Stack في لينكدإن، فيه أكتر من 50,000 API Endpoints لـ Rest.li مستخدمة في الـ Production في لينكدإن.
ومن ساعة تقديم Rest.li وهو بيستخدم JSON كـ Serialization Format افتراضي. وعلى الرغم من إن JSON كان بيخدمهم كويس جدًا من حيث دعم لغات البرمجة الواسع وسهولة القراءة البشرية (اللي بتسهل عملية تصحيح الأخطاء)، إلا إن أدائه وقت التشغيل كان بعيد عن المثالي. وعلى الرغم من إنهم حاولوا يحسنوا من أداء الـ Serialization في JSON في Rest.li، إلا إنه فضل يكون Bottleneck في كتير من الـ Performance Profiles.
فتعالوا نشوف مع بعض بعض التحديات اللي فريق المهندسين في لينكدإن واجهوها مع JSON والعملية اللي استخدموها لتقييم حلول جديدة وفي النهاية اختيارهم لـ Google Protocol Buffers (Protobuf) كبديل.
وهنشوف كمان تفاصيل دمج Protobuf في Rest.li والفوائد اللي نتجت عن ده، بما في ذلك تقليل الـ Latency بنسبة تصل إلى 60% وتحسين الـ Resource Utilization بنسبة 8%.
Addressing Challenges With JSON
كلنا عارفين ان JSON بيقدم دعم واسع للغات البرمجة وكمان سهل في القراءة البشرية. ومع ذلك، في لينكدإن، كان فيه بعض التحديات اللي نتج عنها Performance Bottlenecks.
التحدي الأول هو إن JSON تنسيق نصي، واللي بيكون كتير الكلام. وده طبعًا بيؤدي لزيادة في الـ Network Bandwidth وزيادة الـ Latency، وده أقل من المثالي.وعلى الرغم من إن الحجم ممكن يتحسن باستخدام خوارزميات الضغط القياسية زي gzip، إلا إن الضغط وفك الضغط برضو من الناحية التانية بيستهلك موارد أجهزة إضافية، وممكن يكون مكلف جدًا أو غير متاح في بعض البيئات.
التحدي الثاني هو إن بسبب الطبيعة النصية لـ JSON، كان الـ Serialization والـ Deserialization من ناحية الـ Latency والـ Throughput مش أحسن حاجة. وفي لينكدإن، بيستعملوا لغات Garbage Collected زي Java و Python، فتحسين الـ Latency والـ Throughput كان مهم لضمان الكفاءة.
فلما بحثوا عن بديل لـ JSON، كانوا عايزين بديل يلبي بعض المعايير :
أول حاجة كانوا محتاجينها هي Compact Payload Size عشان يحافظوا بالطبع على الـ Network Bandwidth ويقللوا الـ Latencies اللي بنتنج عن ده.كمان كانوا بيدوروا على كفاءة عالية في الـ Serialization والـ Deserialization عشان برضو يقللوا من الـ Latency ويحسنوا من الـ Throughput.
معيار تاني كان إنه يكون فيه دعم واسع للغات البرمجة - Rest.li بيستخدم في لغات برمجة متعددة (Java, Kotlin, Scala, ObjC, Swift, JavaScript, Python, Go) في لينكدإن، فكانوا عايزين دعم في كل لغات البرمجة المدعومة دي.
وأخيرًا، كانوا عايزين بديل ممكن يندمج بسهولة في آلية الـ Serialization الحالية لـ Rest.li. وده عشان يساعدهم انهم يكملوا استخدام الـ Data Modeling اللي موجودة اصلًا في Rest.li.
وبعد تقييم شامل لعدة تنسيقات زي Protobuf, Flatbuffers, Cap’n’Proto, SMILE, MessagePack, CBOR, و Kryo، قرروا إن Protobuf هو أفضل خيار لأنه أدى بشكل أكثر فعالية عبر المعايير المذكورة واللي كانوا حاطينها كأهداف محتاجين يوصلولها باستبدال JSON.
High Availability in Distributed Systems
في إحدى تجاربي المهنية الأخيرة، شغلت منصب ممثل العميل التقني (Technical Client Representative - TCR)، وهو دور يُعنى بتمثيل العميل تقنيًا مع الجهة المطوِّرة لمشروعه. في كثير من الحالات يلجأ العملاء "غير التقنيين" إلى هذا النوع من الأدوار كآلية لحماية أعمالهم و مصالحهم و ضمان توافق الحلول التقنية مع متطلباتهم.
من أبرز المحاور التي تعاملت معها في هذا الدور هي اتفاقية مستوى الخدمة (Service Level Agreement - SLA)، وهي وثيقة رسمية تُحدد مستوى الخدمة الذي يتوقعه العميل من مزوّد الخدمة.
ما هي اتفاقية مستوى الخدمة (SLA)؟
اتفاقية مستوى الخدمة (SLA) هي عقد رسمي يُبرم بين مُزود الخدمة والعميل، تُحدَّد فيه بوضوح مستوى الخدمة المتوقع تقديمه. تشمل هذه الاتفاقية عادةً معايير الأداء مثل:
نسبة توفّر النظام (Availability)
زمن الاستجابة (Response Time)
مدة حل المشاكل (Resolution Time)
تغطية الاختبارات (Test Coverage)
تُساهم هذه المعايير في ضبط توقعات العميل وحمايته من أي قصور تقني قد يضر بمصالحه، خاصة في حال عدم امتلاكه خلفية تقنية كافية.
خلال عملي على إعداد مستند دليل العمل (Playbook)، دائما ما كان العميل يُولي اهتمام خاص للنسب المئوية التي كُنت أقوم بتحديدها و التعقيب عليها، وبالأخص نسبة التوفّر (Availability)، و كان يُريد أن تكون النسبة 100% و هو أمر شبه مستحيل تقنيًا.
لذلك نلجأ إلى استخدام مفهوم الـ High Availability، الذي يعني قُدرة النظام على العمل بشكل مستمر وبدون انقطاع لفترات طويلة مع تقليل أوقات التوقف سواء كان مخطط أو غير مخطط لها.
معادلة حساب نسبة التوفر (Availability)
تُحسب نسبة التوفر (Availability) وفق المعادلة التالية:
Availability (%) = (Total operational time / Total time) × 100
مثال عملي:
عدد دقائق السنة: 365 يوم × 24 ساعة × 60 دقيقة = 525600 دقيقة
إذا كان مجموع فترات التوقف في السنة 500 دقيقة فإن:
وقت التشغيل الفعلي (Total operational time) سيكون 525600 - 500 = 525100 دقيقة
إذًا: Availability (%) ≈ (525100 / 525600) × 100 ≈ 99.905%
لكن السؤال المطروح: ماذا تُمثل نسبة 99.905% من الـ availability؟ و هل تُعتبر هذه النسبة مرتفعة كفاية؟
و الإجابة تعتمد على طبيعة النظام:
إذا كان النظام يُقدّم خدمة حسّاسة (Critical Service) مثل أنظمة الطيران أو البنوك حيث تؤدي دقيقة واحدة من التوقف إلى أضرار كبيرة، فهذه النسبة قد تكون غير كافية.
أما إذا كان النظام يتحمل بعض التوقفات البسيطة، فقد تكون النسبة مقبولة.
و هنا يتجلى دور اتفاقية SLA التي تُحدد منذ البداية نسبة التوفر (Availability) المطلوبة والتي يجب على مُزوّد الخدمة الالتزام بها.
مفهوم "عدد التسعات - Nines" في الـ Availability
يُستخدم مصطلح "عدد التسعات" للتعبير عن درجة التوفر (Availability):
99.9% (تُقرأ ثلاث تسعات): يُسمح بتوقف يصل حتى 8 ساعات و 46 دقيقة سنويًا.
99.99% (تُقرأ أربع تسعات): يُسمح بتوقف يصل حتى 52.6 دقيقة سنويًا.
99.999% (تُقرأ خمس تسعات): يُسمح بتوقف لا يتجاوز 5.26 دقائق سنويًا.
خصم 50% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :
Introduction Into System Design
How Uber Serves Over 40 Million Reads Per Second
How Discord Stores Trillions of Messages
Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution
Unlocking Notion's Power - The Data Model Explained
How Shopify Mitigates Deadlocks in High Concurrency Environments
How LinkedIn Improves Microservices Performance With Protobuf
How Figma Secures Internal Web Applications
How GitHub Improves Reliability of Code Push Processing
How Meta Leverages AI For Efficient Incident Response
How Stripe Architected Massive Scale Observability Solution on AWS
Change Data Capture at Pinterest
How Canva Built Scalable and Reliable Content Usage Counting Service
How Netflix Migrates Critical Traffic at Scale With No Downtime
How Slack Handles Billions of Tasks in Milliseconds
How YouTube Supports Billions of Users With MySQL
System Design Comprehensive Guide
تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇
وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
CQRS Architecture Pattern
بناء البرمجيات زي بناء المباني بالظبط محتاج ترتب أجزاء المبني وعلاقتهم ببعض بطريقة مناسبة لوظيفة المبني والمستخدمين, فالبيت مبني وكذلك الجامعة مبني ولكن الحجم, والوظيفة والمستخدمين مختلفين ومن هنا بتيجي فكرة ال Architectural Patterns في البرمجيات.
والشطارة بتكون في ازاي استخدم النمط الأكثر إفادة لوظيفة وحجم ونوع الاستخدام لمشروعي اللي شغال عليه.
Command Query Responsibility Segregation (CQRS)
في معظم مشاريعنا بنستخدم CRUD Pattern وبنعتمد علي الوظائف الأساسية فيه زي Create, Read, Update, Delete وبالفعل هو نمط مناسب للمشاريع البسيطة والصغيرة والمتوسطة في الحجم لأنه سهل.
ولكن في حالات بنحتاج فيها Data Manipulation اكثر من الـ CRUD يقدر يقدمه , زي اننا نشتغل في Business العلاقات فيه بين ال objects معقدة أكتر أو تطبيق يكون فيه استهلاك البيانات فيه عالي وكذلك كتابتها ودا بيوقعنا في مشكلة لأن متطلبات الـ Scaling في حالة الـ Heavy Reads تختلف عن متطلباته في حالة الـ Heavy Writes
ال CQRS اختصار لـ Command Query Responsibility Segregation أو Separation وهو نمط هدفه الفصل بين الـ Commands و الـ Queries في الكود وبنعّرف فيه:
الأوامر (Commands): : هي عملية كتابة أو تغيير البيانات وهي العمليات اللي فيها بتتغير حالة النظام. والأوامر جي بتقوم بـ "فعل" شيء وتؤثر على حالة النظام.
الاستعلامات (Queries): عملية قراءة البيانات وهي العمليات اللي بتسترجع بيانات و لكن لا تغير حالة النظام. بمعنى أنها "تسأل" عن شيء معين ولا تعدل أي شيء.
الـ CQRS يستخدم اثنين من الـ Models المختلفة عشان يحقق الأوامر (Commands) بالـ Model المناسب ليها و كذلك Model خاص بالـ للاستعلامات (Queries). وبما إن دا Architectural Pattern فبيسيب للمبرمج حرية اختيار وتنويع الـ Models اللي شايفها بتحقيق الهدفين دول وايه الأنسب لمشروعه وده بيدينا مرونة في التنفيذ.
كمان نقدر في تنفيذه نستخدم 2 من قواعد البيانات -الطريقة الأكثر شيوعًا- واحدة مخصصة للاستعلامات وواحدة للأوامر ويتعمل بينهم Synching.
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
