كيف نبني #1: كيف نبني تويتر؟

thamood
2014-04-01T06:27:27+00:00

هذا الموضوع ليس طلباً للمساعدة بل موضوع لمشاركة الخبرات، ودعونا نفكر كيف نقوم ببناء خدمة معينة ومن ثم نقترح التقنيات المختلفة التي يمكن أن نستخدمها في بناء خدمة مشابهة، ولم علينا أن نتجنب إستخدم لغة برمجة معينة او تقنية قواعد بيانات معينة.

اليوم فكرت بأن نبدأ بتويتر:

ماهي لغات البرمجة المناسبة؟
قواعد البيانات؟
هل سيكون هناك أكثر لغة برمجة مستخدمة؟
كيف سيتم خزن البيانات؟

بالطبع توجد بعض المحاضرات التي تتحدث عن تويتر وكيف تم بناؤه ولكن الفكرة ليس تقليدهم بل إقتراح حلول مناسبة شبيهة أو بديلة مع شرح الأسباب.

يرجى الدخول لحسابك أو تسجيل حساب لتستطيع إضافة تعليق

حساب جديد دخول

فعلى سبيل المثال سنحتاج الى بناء الموقع ووظائفه (Functionality) على شكل Web API ليتم استخدامها لاحقا من اكثر من جهة ولن يقتصر استدعائها عن طريق الموقع فحسب (تطبيق هاتف على سبيل المثال).

وأيضا بحاجة إلى Web Sockets لنقوم بتعريف الإتصال بين المستخدم والخادم ووضعة في جدول خاص لعمل Push للـ Notifications في حال وصولها. من الأمثلة عليها SignalR داخل .NET Framework.

كذلك يجب أن يتم استخدام خدمة Shorten URL لتقليل حجم الروابط التي يتم مشاركتها مع الاخرين.

JQuery و Javascript للتحقق من كافة المدخلات بدون الحاجة للوصول الى الخادم وكذلك لاستخدام ajax أثناء ورود تحديثات جديدة.

munzir أضف ردا

تحتاج إلى فريموورك لجهة المستخدم كا angularJS أو amberJS

OssamaZ أضف ردا

العمل على الـ Back-end كـ web API يلزم بشكل أو بآخر تطوير الـ Front-end كموديولز بشكل منفصل (تقريبا). بعبارة أخرى، استخدام فريموورك جافاسكريبت (MV*) أمر لا مفر منه. وعند التطوير، و بحكم أننا نتعامل مع وظائف الموقع كـ API، فالإستعانة بفريموورك للـ Front-end سيمكننا من التوسع لاحقا و بنية التطبيق ككل ستكون مستجيبة لهذا التوسع دون مشكلة (Scalable Architecture).

الإعتماد على jQuery فقط لا يجدي، فحتى عمليات بسيطة كـ Dom Manipulation سينتج عنها آلاف من الأسطر و الدوال المرتبطة بينها، أما عند القيام باتصالات غير متزامنة مع السيرفر أو مع أي واجهة تطبيق أخرى فبسرعة سيتحول الكود لما يسمى الـ Callback Hell.

مسألة أخرى لا تقل أهمية عن ما تم ذكره، هو بنية الـ API التي سيتم استخدامها للربط بين الـ Back-end و الـ Front-end و مع تطبيق الموبايل (الذي يجب أن تتم برمجته بطبيعة الحال)، يجب أن تكون مصممة بشكل يسهل التعامل معها و يسهل تطويرها دون مشاكل..

أنصح من يهتم بتصميم الـ Backend APIs ومطوري المواقع بصفة عامة أن يشاهد هذا الفيديو حول تصميم RESTful API سهلة و منظمة و قابلة للتوسع بشكل مميز:

ملاحظة: ما هو أفضل تعريب لـ Scalable Architecture؟ المرجو الإفادة :)

خالد الحضري أضف ردا

أكبر تحدي سيكون قواعد البيانات وطرق تخزين البيانات

خالد السعدي أضف ردا

اعتقد بعدم أهمية نوعية اللغة مقارنة بطريقة تطبيقها على المشروع المراد تنفيذه، والمفترض في حالة تطوير مشروع كبير جداً استخدام عدة لغات في نفس الوقت في افضل مكان له، مثلا نستخدم Node.js مع socket io في تنفيذ الخواص التي تعمل دائماً مثل push notification و chat. و PHP لعرض الصفحات في البداية مثلاً مع مسرعاتها الخاصة مثل Alternative PHP Cache و spdy. وبالنسبة لقواعد البيانات فالاسهل هي mysql لكن لا تخدم بطريقة سهله في حالة وجود استخدام كبير ومعلومات كثيرة , يمكن استخدام No sql db للتوسع مثل MongoDB أو cassandra.

غالباً المواقع الكبيرة تعمل على تقليل كمية الكود من خلال استخدام متكرر لل css ومكتبات الجافا سكربت و Jquery وعن طريق حفظها في الكلاينت باستخدام ال Cache. ومنها اذكر بعضها :

1- ارسال المعلومات للسيرفر والتأكد من صحة البيانات المدخلة Validation والتعامل مع الاخطاء بشكل اوتوماتيكي.

2- دوال لعرض المعلومات وقولبتها بدون الحاجة لكتابة دالة في كل صفحة وتكون قابلة للوصول في كل الموقع.

واحب أن اؤكد أن المفترض عند بداية مشروع جديد مثل تويتر وغيره, أن تبدأ بالاسهل والي ينفذ العمل بشكل اسرع, وليس الافضل، وحسب كلام مؤسس لعبة second life عند التقائي به, أن السرعة أهم من الجودة.

forabi أضف ردا

أعتقد أن لغة برمجة وحيدة ستكون كافية، JavaScript في بيئة Node.js من جهة الخادم مع قواعد بيانات MongoDB، يمكن التحكم بـwrite concerns وتحديد ما إذا كنا نريد معرفة هل تم حفظ البيانات إلى القرص أم تجاوز إجراء هذا لتسريع كتابة البيانات (مع المخاطرة باحتمال فقد بعض منها مثلاً)، قابلية التوسع لـMongoDB هائلة، ويمكن استخدام sharding لتقسيم البيانات على عدة مجموعات من الخوادم كل منها replica set مثلاً (أي مجموعة من الخوادم التي تحمل نفس القسم من البيانات والتي يمكن لإحداها أن تتولى استلام البيانات عند تعطل الآخرى)

forabi أضف ردا

وطبعاً من جهة العميل اللغات المعروفة JavaScript وHTML وCSS بإطار عمل مناسب. ربما من الأفضل أن يكون الموقع الرئيسي زبوناً للواجهة البرمجية كغيره من التطبيقات (API client)، وهو ما يفعله تويتر حالياً.

nizarnizario أضف ردا

اذن ماذا عن استخدام بايثون مع مكتبات DJANGO

هي ايضا خيار مناسب

ServeR00T أضف ردا

جميع لغات البرمجة تؤدي الغرض .. الفرق بسيط في الأداء

قواعد البيانات: بإمكانك البدء ب in memory database وبعد الانتشار تدعمها ب block database

hswelm أضف ردا

رغم انى لا أفقه شئ بخصوص البرمجة ولغاتها، الا أننى سعيد بهذا النقاش الجاد، وأرجو ان يسفر عن شئ ما على أرض الواقع.

-3

nizarnizario أضف ردا

لغات البرمجة المناسبة هي البي اتش بي و ملحقاتها (html javascript css) و الصور

قواعد البيانات الافضل بالنسبة لمثل هذه الاعمال هي ماي اس كيو ال

هذه اللغات كافية جدا

عن طريق قواعد البيانات طبعا

thamood أضف ردا

هل تعتقد أن php خيار مناسب؟ خصوصاً مع الضغط الهائل التي يتعرض له الموقع؟

بالطبع ستذكر لي أن فيسبوك قائم على php وهو شيء صحيح أيضاً ويعني أن php قادرة على هذا الشيء، ولكن أريد أن أخوض في أعماق البرمجة ولا أريد الإكتفاء بطرح رؤوس الأقلام، مثلاً:

كيف سيتم دفع التحديثات إلى المستخدم مثلاً؟ كيف سنقوم بتطبيق تقنية الـ push بشكل جيد؟
الأفضل في حالة التحديثات الكبيرة في تويتر أن يتم وضع قاعدة البيانات في الذاكرة والكتابة إلى القرص الصلب من فترة لفترة؟ (كيف سنقوم بذلك؟)

alsadi أضف ردا

فيسبوك يستخدمون نسخ معدلة من php. بمعنى أدق هم يستخدمون صيغة لغة php يتم تنفيذها من خلال مصنف خاص بهم اسمه hiphop انظر

https://www.facebook.com/no...

thamood أضف ردا

صحيح وقاموا لاحقا بإعادة تسميتها إلى HHVM والمتوفرة هنا:

لكن المشكلة هي أن فيسبوك قامت لاحقاً بإطلاق لغة هاك الشبيهة بلغة php وهذا الشيء قد يعني أن الشركة قد تتخلى عن php من أجل دفع لغتها (مالم تقم بتسليم التطوير للمجتمع المفتوح).

Lye أضف ردا

ال Facebook قد تحولت إلى إستخدام Hack منذ سنة.

و ال HHVM أي HipHop Virtual Machine قد بدأ كمحول لكود PHP إلى C++ ثم يقوم بعمل compile، أي كان عليك تحويل ملفاتك عند كل تعديل.

الفرق الآن هو أن كل شيء يعمل تلقائيا مع بعض التعديلات.

للإشارة بعض الدوال تعمل على PHP أسرع بينما بعضها تعمل على HHVM/Hack أسرع.

مع الإشارة إلى ال bugs على كل من HHVM/Hack و الذي نشر هذه التقنيات أحد تلك الأسباب ليساعد المجتمع في إختبارها.

-1

alsadi أضف ردا

الشاهد من كل ذلك أن php العادي غير مناسبة (وإلا لما دخلت فيسبوك في كل هذه الفوضى)

munzir أضف ردا

تويتر إستخدم الروبي اون ريلز في البدء ثم أنتقل إلى سكالا و غيرها ، كل لعة لها ميزاتها و مشاكلها ، بالمناسبة موقعي وورد برس و ياهو يعملان بال php . إنظر إلى الرابط التالي :

http://en.wikipedia.org/wik...

alsadi أضف ردا

فيسبوك وياهو يستعملان نسخ خاصة بهم من php بمعنى هم يستخدمون صياغة لغة php وليس مفسر لغة php المعروف.

موقع وردبرس لا يحتوي شيء آني real time أو ثنائي الإتجاه فهو يجلب أشياء من قاعدة البيانات يقولبها ثم يعرضها ثم تنتهي القصة. لا يوجد دردشة أو إظهر لنتائج تدفع من الخادم بعد تحميل الصفحة بناء على تفاعل.

كل لغة لها استخدامها والأشياء التي تجيدها فلا ندخلها فيما لا تتقنه. وبما أننا نتحدث عن تويتر. بعد أن تفتح موقع تويتر أو صفحة البحث عن هاشتاغ معين انتظر قليلا وستجد في رأس الصفحة عيارة "5 new tweets" لو أردت أن تفعل ذلك في php فإن هذا يعني أنك ستعمل ضربات ajax كل ثانية تجلب كل جديد لتظهر هذا الرقم. وإن كنت في صفحة بحث قد يعني هذا أنه لا يوجد أي cache لأن الناس تبحث عن أشياء مختلفة في الغالب. فلك أن تتخير عدد فلكي من الأشخاص المختلفين يرسل عدد فلكي من الإستعلامات المتواصلة كل ثانية كلها تطلب أشياء مختلفة دون أي cache.

munzir أضف ردا

نعم صحيح تختلف المفسرات المستخدمه من قبلهم و لكن يمكن للجميع الوصول إليها أي هي ليست بحكر على أحد و بالنسبة إلى عدم مقدرة ال php على دعم تطبيقات الreal time فهذا غير صحيح!! أن كنت تقصد الnon blocking io هنالك reactPHP و بالنسبة للajax و الوصول المستمر للبيانات كما التنبيهات فهنالك حلان ، إستخدام ال sockets !! "نعم موجودة""! أو الحل القديم بفتح إتصال مع الخادم و إنتظار الرد مع إطالة الفتره الزمنيه!!!! ، رجوعا لموضوع المفسرات! حتى scala و جافا يعملان على مفسرات jvm و هنالك من يستخدم jdk وهو حل مفتوح المصدر أما الnode.JS فهي تعمل على مفسر google v8 !!! . أخيرا ، ال php قد لاتكون اللغة المناسبة لهذا و لكن هل ruby on rilas المناسبة ؟!!! الآن لا بالطبع فهي تملك "مشاكل" شبيهه بباقي اللغات بإستثناء الnode.js ، و لكن أليست روبي هي اللغة+فريموورك التي كتب بها تويتر!!! .... لكل لغة متطلبات حالية و أخرى مستقبلية و قد لاتتوافق المرحلتين مايستدعي إستخدام حلول أخرى!

عفوا ،،،، الcache بما إنه وسيلة لتقليل عدد المرات التي يطلب الوصول فيها إلى قواعد البيانات "بالدرجة الأولى" فلم أفهم منك كيف سيختلف ذلك من لغة لأخرى!!!!!

-7