VOL:21 How LinkedIn Improves Microservices Performance With Protobuf
VOL:21 How LinkedIn Improves Microservices Performance With Protobuf
أهلًا وسهلا بكم في العدد الواحد والعشرين من النشرة الأسبوعية لاقرأ-تِك 🎉
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الواحد والعشرين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية, من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة, ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
How LinkedIn Improves Microservices Performance With Protobuf
Uber’s Docstore High Level Architecture
Linux Administration Series
OpenID Connect
Stackoverflow Developer Survey
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، كانوا عايزين بديل يلبي بعض المعايير:
Uber's Docstore Architecture
شركة Uber كانت بتستعمل الـ Schemaless Types من قواعد البيانات , واللي خلتها بعد كده تقابل شوية تحديات كبيرة والي خلتها تتجه لاستعمال Cassandra كـ Database وتبقى كـ General Purpose Database لمعظم الـ Business Verticals.
ولكن مع حجم الـ Scale بتاع Uber كان الـ Operations على Cassandra كبيرة جدًا ومش فعالة بالنسبة ليهم من ناحية الكفاءة بتاعتها والـ Scale بتاع Uber ، بالاضافة كمان لان Cassandra بتدعم الـ Eventual Consistency وده Consistency Level بالنسبة لـ Uber مكنش أفضل حاجة من ناحية المتطلبات بتاعتهم خصوصا ان هم بيطمحوا لتحقيق الـ Strict Serializability Consistency Level.
ومن ثم ظهر الحاجة لتصميم Docstore واللي مبني على MySQL.
Docstore
قاعدة البيانات دي بتتميز بعدة مميزات من ضمنها انها بتوفر الـ Strict Serializability Consistency Model على مستوى الـ Partition وده كان من ضمن المتطلبات اللي Uber عاوزة تحققها وبالتالي نقدر نستنج هنا ان Uber بتضحي بالـ Availability في سبيل الـ Consistency من ناحية نظرية الـ CAP Theorem.
كمان نقدر نـ Scale Horizontally واللي اتاح الفرصة لـ Uber انها بالشكل ده قاعدة البيانات تكون بتدعم وبتخدم عدد كبير من الـ Heavy Workloads اللي عندهم.
ومش بس كده ده كمان بتوفر مميزات كتير بتحسن من انتاجية المطورين زي الـ Transactions / Materialized Views / CDC بالإضافة للمرونة في عمل الـ Modeling للبيانات وكذلك وفرة من الـ Query Support اللي الـ Clients ممكن يكونوا محتاجينها.
Docstore Architecture
هنلاقي أن Docstore متقسمة بشكل رئيسي لثلاث أجزاء أو طبقات Layers:
1- الـ Stateless Query Engine Layer
2- الـ Stateful Storage Engine Layer
3- الـ Control Plane
Consistency Model
الـ Docstore زي ما قولنا بيوفر الـ Strict Serializability Consistency Model على الـ Partition Level.
وده بيضمن لنا خاصية لطيفة جدًا الا وهي ان الـ Users يقدروا يتخيلوا ان الـ Transactions بتحصل بشكل Sequentially وبالتالي بنتجنب مشاكل الـ Concurrency والـ Conflicts اللي ممكن تحصل.
بالإضافة لإن كمان الـ Transactions بتكون مرتبة وده معناه ان لو عندي Tx A و Tx B و A حصل قبل B فـ Tx A هيحصله Start و Commit قبل B. وده بيضمن ان الـ Read Operations دايما هترجع النتيجة الآخيرة من آخر عملية كتابة حصلت.
وعشان كده زي ماقولنا Docstore من منظور الـ CAP هي بتفضل الـ Consistency عن الـ Availability.
الشراكات - Sponsorship
جالنا الفترة اللي فاتت أسئلة من بعض الشركات انهم حابين يبقى في شراكات بينا وبينهم ، وبفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship وتقدروا تشوفوا التفاصيل من هنا 🚀
لا تدع شيء يفوتك!
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
Linux Administration Series
الـ Linux Administration بيختص بإدارة وتشغيل نظام التشغيل Linux. النظام ده يعتبر من أكتر الأنظمة قوة ومرونة وكمان مفتوح المصدر، يعني أي حد يقدر يطوره ويعدل فيه.
في شغل الـ Linux Admin، بتكون مسئول عن تشغيل السيرفرات وحمايتها، إدارة المستخدمين والصلاحيات بتاعتهم، وكمان متابعة الأداء بتاع النظام وتحديثه بانتظام. بتتعامل مع حاجات زي إعداد الشبكات، إدارة قواعد البيانات، تشغيل التطبيقات، وأتمتة العمليات باستخدام السكربتات.
وفي السلسلة دي هنشارك معاكوا بعض الملحوظات والـ Notes المرتبطة بالـ Linux Administration.
OpenID Connect
ال OpenID Connect هو واحد من أشهر طرق الـ User Authentication وأكثرها فعالية ومع ذلك فكرة عمله بسيطة جدًا!
الـ OpenID Connect هو Identity Layer فوق الـ OAuth2 ولكن اللي يهمنا حاليًا عن الـ OAuth إنه User Authorization Method فتركيزه الأساسي بيكون على "صلاحيات الوصول" Access Rights
ودا عن طريق "تفويض" الـ Third Party App إنه يوصل للمعلومات اللي محتاجها عن ال User أو يدير موارد محددة للـ User بدون معرفة كلمة السر الخاصة بيه ولذلك الـ OAuth مش بنستخدمه عشان نعمل Login ولكن بنستعمله للوصول لصلاحيات معينة في موقع تاني.
الـ OpenID Connect هيتيح لينا نفس المميزات ولكن هيحتاج يعرف هوية المستخدم وبياناته الشخصية عشان يتأكد من هويته.
هنلاحظ دايما واحنا بنعمل تسجيل في أي موقع إن فيه كذا طريقة
ممكن من خلال الـ Email والـ Password أو من خلال مثلا نستعمل Google / GitHub / Facebook وده اللي بقينا نشوفه حاليا في أغلب المواقع.
فالطرق التقليدية للـ User Authentication اللي بنضطر فيها مثلا ندخل الـ Email والـ Password كان بيوجد طرفين فقط هما الـ User والـ Website والـ Website بيتحقق بنفسه من هوية المستخدم ويستخرج الـ Access والـ Identity Tokens بنفسه.
ولكن في حالة استخدام الموقع للـ OpenID Protocol فهو بيفوض مهمة التأكد من الهوية دي للـ OpenID Provider وكذلك عملية إصدار الـ Tokens اللي هيتم استخدامها في عملية التواصل بين الموقع والمستخدم.
طب امتة نستخدم الـ OpenID Connect والـ OAuth وايه الفروقات بينهم وايه هي طريقة عمل الـ OpenID ده اللي هنعرفه من خلال المقال ده.
Stackoverflow Developer Survey
للسنة الـ 14 علي التوالي stackoverflow بيعمل الـ Developer survey. والاستبيان دا من أهم الاستبيانات في مجال التقنية عشان بيشارك فيه أكثر من 60 ألف مبرمج من حول العالم. ومش بس بيوفرلنا معلومات هامة عن الـTech Trends ولكن بيوفر تفاصيل عن الـ Professional Programmers وطبيعة الشغل والشركات والمرتبات وكذلك التقنيات الأجدد وانطباعات الناس عنها واستخدامهم ليها زي الـ AI.
Programming and Scripting Languages
السنة دي مكنش في تغيير كبير مقارنة بالسنة اللي فاتت من ناحية تبني لغات برمجة معينة فوق اخري, ولكن الفارق اللي واضح هو هبوط الـ Salaries اللي بيتقاضها مبرمجين اللغات الأكثر استخدامًا مقارنة بالعام الماضي, يمكن دا مع صعوبة الـ Job Hunting الفترة الأخيرة انعكس ان السوق ابتدي يـ Saturate من المبرمجين في التخصصات الشائعة.
👨💻 الـ Javascript مازالت الأشهر للسنة الـ 14 يليها الـ HTML/CSS في إشارة إن مرحلة الويب لازالت مسيطرة علي واقع التقنية والانترنت. ولكن المثير للاهتمام إن المبرمجين بيحبوا يشتغلوا ب TypeScript أكثر منVanilla Javascript فهل ابتدي يبقي عندنا وعي بعيوبها؟
😻 أكثر لغة محببة للمستخدميها هي Rust للسنة الثانية علي التوالي وهي بتستخدم بشكل أساسي في الـ Systems Engineering
🎒 لا يزال أغلبية الـ New Coders بيتجهوا للـ Python عشان يتعلموا البرمجة.
Web Frameworks
في القسم دا Node JS و React بيتصدروا القائمة كالعام الماضي بينما ابتدت تقل حصة Angular و Vue JS من السوق بنسب صغيرة لصالح Frameworks أخري.
Databases
الـ ٧ سنين الاخيرة شهدت صعود للـ PostgreSQL في مقابل الـ MySQL ودي تاني سنة تتربع فيها علي قمة قواعد البيانات المستخدمة من قبل المحترفين ولكن بيفضل MySQL هو البداية لأي حد جديد بيتعلم قواعد بيانات.
جزء من تفضيل PostgreSQL علي MySQL راجع لأنها بتحتوي علي Features أكثر وكذلك مناسبة أكثر للـ Write-Heavy Applications وبتطبق الـ Isolation بطريقة أفضل.
Artificial Intelligence
قسم الـ AI كان مركز علي انطباع المبرمجين عنه وطريقة استخدامهم ليه, وفقًا للاستبيان فحوالي 80% من المبرمجين بيستخدموه عشان يكتبلهم كود و حوالي 67% بيستخدموه للبحث عن إجابات كذلك فئة كبيرة بتستخدمه لاختبار الكود أو يساعدهم في ال Debugging و الاستبيان بيوضح إن الناس بتستخدمه كوسيلة للانتاجية وتسريع المهام الروتينية. الجدير بالذكر إن 70% من المشاركين مش شايفين ان ال AI خطر علي وظائفهم كمبرمجين فهل يكون ال AI فعلاً حليفًا لا عدوًا ؟!
شاركونا رأيكم في الاستبيان وإيه أكثر حاجات أثارت إنتباهكم وايه التقنيات الجديدة اللي متحمسين تجربوها السنة دي ❤️
مشاركة من أحمد عطية في مجتمع اقرأ-تِك 😂
وده بمناسبة الاوليمبياد 2024
تقدروا دلوقتي تشتركوا في اقرأ-تِك بخصم الـ 20% وتنضموا لمجتمع مهتم بالقراءة في هندسة البرمجيات بـ 50 جنيه بس 🎉
وتستمتعوا بحرية كاملة في قراءة المقالات في مواضيع مختلفة بجودة عالية زي:
Data Structure & Algorithms , System Design , Distributed Systems , Micro-Services, Clean Code, Refactoring, Databases , Web Development, DevOps وغيرهم كتير باللغة العربية!
بالاضافة لمحتوى ورقة وقلم اللي بنشرح فيه مفاهيم برمجية بطريقة سهلة وباستعمال صور توضيحية 🚀
ولو فيه مشاكل في الدفع الأونلاين فمتاح دلوقتي الاشتراك من خلال InstaPay و VodafoneCash 💪
تقدروا تتواصلوا معانا من خلال الـ WhatsApp Business أو من خلال الرسايل على مواقع التواصل الاجتماعي أو من خلال البريد الالكتروني contact@eqraatech.com 😍
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
