المقدمة

كل يوم، لينكدإن بتتعامل مع مليارات الطلبات من الأعضاء عبر كل منصاتها، بما فيها تطبيقات الويب والموبايل.
من المهم جدًا إن الطلبات دي زي مشاهدة صفحات الشركات، قراءة مقالات على لينكدإن، أو مشاهدة الاتصالات 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.

1. التحدي الأول هو إن JSON تنسيق نصي، واللي بيكون كتير الكلام. وده طبعًا بيؤدي لزيادة في الـ Network Bandwidth وزيادة الـ Latency، وده أقل من المثالي.وعلى الرغم من إن الحجم ممكن يتحسن باستخدام خوارزميات الضغط القياسية زي gzip، إلا إن الضغط وفك الضغط برضو من الناحية التانية بيستهلك موارد أجهزة إضافية، وممكن يكون مكلف جدًا أو غير متاح في بعض البيئات.
2. التحدي الثاني اللي واجهناه هو إن بسبب الطبيعة النصية لـ JSON، كان الـ Serialization والـ Deserialization من ناحية الـ Latency والـ Throughput مش أحسن حاجة. وفي لينكدإن، بيستعملوا لغات Garbage Collected زي Java و Python، فتحسين الـ Latency والـ Throughput كان مهم لضمان الكفاءة.

فلما بحثوا عن بديل لـ JSON، كانوا عايزين بديل يلبي بعض المعايير :

1. أول حاجة كانوا محتاجينها هي Compact Payload Size عشان يحافظوا بالطبع على الـ Network Bandwidth ويقللوا الـ Latencies اللي بنتنج عن ده.كمان كانوا بيدوروا على كفاءة عالية في الـ Serialization والـ Deserialization عشان برضو يقللوا من الـ Latency ويحسنوا من الـ Throughput.
2. معيار تاني كان إنه يكون فيه دعم واسع للغات البرمجة - Rest.li بيستخدم في لغات برمجة متعددة (Java, Kotlin, Scala, ObjC, Swift, JavaScript, Python, Go) في لينكدإن، فكانوا عايزين دعم في كل لغات البرمجة المدعومة دي.
3. وأخيرًا، كانوا عايزين بديل ممكن يندمج بسهولة في آلية الـ Serialization الحالية لـ Rest.li. وده عشان يساعدهم انهم يكملوا استخدام الـ Data Modeling اللي موجودة اصلًا في Rest.li.

وبعد تقييم شامل لعدة تنسيقات زي Protobuf, Flatbuffers, Cap’n’Proto, SMILE, MessagePack, CBOR, و Kryo، قرروا إن Protobuf هو أفضل خيار لأنه أدى بشكل أكثر فعالية عبر المعايير المذكورة واللي كانوا حاطينها كأهداف محتاجين يوصلولها باستبدال JSON.

Integrating Protobuf in Rest.li