,
13 tweets,
2 min read
Read on Twitter
هذه السلسلة مقدمة لسلاسل بعدها عن كيف تصمم الأنظمة الكبيرة مثل Twitter و Facebook و LinkedIn و Uber و Whatsapp و غيرها . احتاج إلى تبسيط مفاهيم برمجية شائعة في مثل تلك الأنظمة تدعم تضخمها سواء من ناحية عدد المستخدمين او الخدمات او البنية التحتية من خوادم و غيرها .
لنفرض اننا نريد تطوير نظام بسيط مشابه لTwitter عندما نكتب تغريدة في Twitter في صفحة Web نستقبلها من خلال Method في Controller و نقوم بتخزينها في قاعدة بيانات من ثلاث جداول Tweets و Users , Mapping
سوف نحتاج Methods لحفظ و عرض تلك التغريدات سواء للعامة او بداخل صفحة المستخدم . بعد فترة احتجنا ان نضيف خاصية الاشعار , عندها نحتاج إلى تغيير الكلاس لإضافة Method جديدة داخل كلاس الTweet نسميها ()notify بجانب ()saveTweet .
هذا الطريقة تخالف مبدأ SRP لأن لكلاس Tweet قام بأكثر من وظيفة كالحفظ او الاشعار , و لذا أنشأنا فيه Event يخبرنا ان هناك تغريدة جديدة , و فصلنا الكلاسات التي نقوم بالاستماع إلى ذلك الحدث . هنا لن نضطر إلى تعديل الكلاس إذا اردنا اضافة اي خاصية جديدة .
مثلاً لو اردنا لاحقاً اضافة خاصية الLogging فسيكون من السهل ذلك بدون تغيير الكلاس الرئيسي . هذا جيد , بعد فترة زاد استخدام النظام من قبل المستخدمين و احتجنا مشاركة مبرمجين اخرين في المشروع من خلال Source Save ينسقون فيما بينهم بشأن رفع النُسخ الى الخادم .
بعد فترة تجمعت لدينا كمية من البيانات و احتجنا بعض الـ Data Analytics على جزئية الLogs . و قمنا لأجلها بتوظيف Data Scientists , ما زالت جزئية الLogging تعتمد على الEvents التي يطلقها الكلاس Tweet في نفس المشروع .
يمكن طبعاً فصل المشاريع لكن ستضل على نفس الخادم ( المعالج و الذاكرة ) . لكن ماذا لو احتجنا ان نجعل معالجة الLogging في نظام منفصل على خادم او عدة خوادم مستقل تماماً ؟ او DataCenter منفصل تماماً .
لحل هذه المشكلة لدينا خيارات كثيرة , قد نستخدم API و نستخدم تقنية الMicroservices أي نقسم النظام الكبير إلى انظمة صغيرة مستقلة بمبرمجينها و بقواعد بياناتها و حتى في لغة البرمجة بحيث نختار اللغة المناسبة لذلك الجزء . هناك مشكلة اخرى تظهر ..
لاحظ أن اي معلومة يحتاجها الLogging ستأتي عبر نظام Tweets و قبلها الAPI الذي استلمها من الFront-End ثم الى الAPI الذي ارسلها لنظام الLogging . ماذا لو حصلت مشكلة في ذلك النظام الاخر ؟ و لماذا نطيل الطريق ؟ و نضع إعتمادية لا نحتاجها .
لا يمكننا ان نخاطر بفقد أي عملية قام بها المستخدم , قد نتأخر في عرض البيانات له , لكن لن نفقد منه أي بيانات . لهذا السبب و اسباب اخرى كثيرة لا نستغني عن الMessaging Service الذي مهمته فقط تخزين اي طلب من المستخدم في Queue ثم تقوم الانظمة الاخرى بالاستماع اليه وتلقي تلك الرسائل.
بدل الدخول في التفاصيل البرمجية , ربما من الافضل ان نرى من الأعلى كيف تعمل الانظمة الكبيرة كتويتر و فيسبوك و غيرها و ماهي التقنيات المستخدمة في تلك المنصات الصخمة و التي تتغير من دون ان نشعر كمستخدمين فتويتر مثلاً استبعد Kafka في 2016 و عاد و استخدمها في 2018
هذه الامثلة ربما توصل الفكرة ان كل شيء قابل للتغيير و أن نكون مستعدين له دون ان نتشبث بتقنية او بمنتج او لغة محددة . غداً سأروي لكم قصة احد العمالقة .
source safe*
