منصة الولادة

لقد تغير العالم. أشعر بها في الماء ، أراها في الأرض ، أشعر بها في الهواء. ذهب كل ما كان موجودا ، ولم يعد هناك من يتذكره.
من فيلم "سيد الخواتم: زمالة الخاتم"

هناك 100500 مقالة وتقرير على الإنترنت حول موضوع "كيف رأينا متراصة" ، وليس لدي أي رغبة في كتابة واحدة أخرى. حاولت أن أذهب إلى أبعد من ذلك قليلاً وأقول كيف أدت التغييرات التكنولوجية إلى ظهور منتج جديد تمامًا (المفسد: كتبنا الصندوق ، وكتبنا المنصة). المقالة إلى حد كبير مراجعة ، دون تفاصيل فنية. التفاصيل سوف تأتي لاحقا.

سيكون حول موقع لوحة التحكم وخادم Vepp. هذا هو منتج ISPsystem حيث أقود التطوير. اقرأ عن إمكانات اللوحة الجديدة في مقال آخر ، هنا - فقط حول التكنولوجيا. لكن أولاً ، كالعادة ، القليل من التاريخ.

الجزء 1. من الضروري تغيير شيء ما

تقوم شركتنا بكتابة برامج لاستضافة خدمات التشغيل الآلي لأكثر من 15 عامًا. خلال هذا الوقت ، تغيرت عدة أجيال من منتجاتنا. عندما تحولنا من الثانية إلى الرابعة ، قمنا بتغيير Perl إلى C ++ وبدأنا البيع المجاني لبرنامجنا ... عندما تحولنا من الرابع إلى الخامس ، سعياً وراء السرعة ، تحولنا من تطبيق أحادي الترابط إلى متعدد الخيوط (من متراصة تحتوي على جميع منتجاتنا إلى في إطار).

ولكننا لم نتغير فحسب ، بل كان عملاؤنا ومنافسونا يتغيرون ، فمنذ 10 إلى 15 عامًا كان مالك الموقع على دراية فنية جيدة (كان الآخرون مهتمين بشكل ضعيف بالإنترنت) ، يمكن أن يكون هذا الشخص الآن غير مرتبط بأي حال من الأحوال. هناك العديد من الحلول المنافسة. في ظل هذه الظروف ، لا يكفي مجرد تشغيل منتج ما ، فمن الضروري أن يكون سهل الاستخدام وسهل الاستخدام.

إعادة تصميم البطولية

أصبح هذا التغيير من جميع النواحي الأكثر وضوحا. طوال هذا الوقت ، ظلت واجهة منتجاتنا دون تغيير وموحدة تقريبًا. لقد كتبنا بالفعل عن هذا بشكل منفصل - وجهة نظر من UX. في الجيل الخامس من المنتجات ، حدد واجهة برمجة التطبيقات مظهر النماذج والقوائم. والتي ، من ناحية ، مكنت من تنفيذ العديد من الأشياء دون إشراك مطوري الواجهة الأمامية ، من ناحية أخرى ، أدت إلى نداءات معقدة للغاية ، مما يؤثر في بعض الأحيان على معظم النظام ، وقيد بشكل كبير القدرة على تغيير الواجهة. بعد كل شيء ، أي تغيير هو حتما تغيير في API. وهذا كل شيء ، مرحباً بالتكامل!

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

في واجهة برمجة التطبيقات (API) الجديدة ، تحولنا إلى عمليات ذرية صغيرة وبسيطة ، وتم ترك مطوري Frontend بإجراءات معقدة. يتيح لك ذلك تنفيذ واجهة معقدة وتغييرها دون التأثير على واجهة برمجة التطبيقات الأساسية ، وبالتالي ، دون كسر التكامل.

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

تقليل وقت الاستجابة والإخطارات الفورية

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

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

في الجيل الجديد من المنتجات ، نستخدم websocket للتسليم الفوري للحدث.

استخدم أول تطبيق longpoll ، ولكن المطورين الواجهة كانت غير مريحة مع هذا النهج.

HTTP الاتصالات الداخلية

HTTP كوسيلة نقل فاز. الآن ، بأي لغة ، يتم تطبيق خادم HTTP في ثوان (إذا كنت google ، ثم في دقائق). حتى محليًا ، من الأسهل تكوين طلب HTTP من حظر البروتوكول.

في الجيل السابق ، كانت الإضافات (الإضافات) عبارة عن تطبيقات تم إطلاقها ، عند الضرورة ، باسم CGI. ولكن من أجل كتابة ملحق طويل العمر ، كان علي أن أحاول بشدة: كتابة مكون إضافي في C ++ وإعادة بنائه مع كل تحديث منتج.

لذلك ، في الجيل السادس ، تحولنا إلى التفاعل الداخلي عبر HTTP ، وأصبحت الامتدادات ، في الواقع ، خوادم WEB صغيرة.

واجهة برمجة تطبيقات جديدة (ليست مناسبة تمامًا)

في الأجيال السابقة من المنتجات ، مررنا جميع المعلمات من خلال GET أو POST. إذا لم تكن هناك مشاكل خاصة مع GET - حجمها صغير ، فلن يكون هناك في حالة اختبار POST طريقة للتحقق من الوصول أو إعادة توجيه الطلب حتى تتم قراءته بالكامل.

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

الآن يتم تمرير اسم الوظيفة في URI ، ويكون التفويض حصريًا في الرؤوس. وهذا يسمح لك بإجراء جزء من الشيكات قبل قراءة نص الطلب.

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

لقد قمنا بتطبيق القدرة على تنفيذ الاستعلام الدفعي. في الواقع ، هذه خدمة منفصلة تقبل قائمة بالطلبات وتنفذها بالتسلسل. يمكنه أيضًا استعادة العمليات المكتملة بالفعل في حالة حدوث خطأ.

عاشت SSH!

القرار الآخر الذي اتخذناه استنادًا إلى تجربتنا السابقة هو العمل مع الخادم فقط من خلال SSH (حتى لو كان خادمًا محليًا). في البداية ، عملنا مع الخادم المحلي في VMmanager و ISPmanager ، وعندها فقط جعلنا من الممكن إضافة خوادم إضافية عن بُعد. هذا أدى إلى الحاجة لدعم تطبيقين.

وعندما رفضنا العمل مع الخادم المحلي ، اختفت الأسباب الأخيرة لاستخدام المكتبات الأصلية لنظام تشغيل المستخدم. معهم ، لقد تعذبنا منذ تأسيس الشركة. لا ، للمكتبات المحلية مزاياها ، ولكن هناك عيوب أكثر.

ميزة الجمع المطلقة هي استهلاك أقل لكل من القرص والذاكرة ، وقد يكون هذا مهمًا للغاية للعمل داخل VDS. من بين العيوب - استخدام مكتبة لا تتحكم بإصدارها يمكن أن يؤدي إلى نتائج غير متوقعة ، مما يزيد بشكل كبير من العبء على كل من التطوير والاختبار. عيب آخر هو عدم القدرة على استخدام أحدث إصدارات المكتبات و C ++ الحديثة (على سبيل المثال ، في CentOS 6 حتى C ++ 11 غير مدعوم بالكامل).

العادات القديمة

تغيير النهج والتحول إلى تقنيات جديدة ، واصلنا العمل بالطريقة القديمة. هذا أدى إلى صعوبات.

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

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

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

يمكن وصف عادة أخرى على النحو التالي: لماذا تكتب خدمة أخرى ، إذا كان يمكنك تعليم هذه الخدمة الحالية. أول ما نخرج عنه من متراصة لدينا هو آلية الترخيص. ولكن يبدو أن الإغراء دفع جميع المكونات الشائعة إلى هذه الخدمة ، كما هو الحال في COREmanager (الإطار الأساسي لمنتجات الجيل الخامس).

الجزء 2. الجمع بين غير متوافق

في البداية ، تم تنفيذ طلبات القراءة والكتابة من خلال عملية واحدة. عادةً ما تقوم طلبات الكتابة بحظر الطلبات ، لكنها سريعة جدًا: لقد كتبت إلى قاعدة البيانات ، وأنشأت مهمة ، وأجبت عليها. مع طلب القراءة ، القصة مختلفة. إنشاء مهمة عليها أمر صعب. يمكن أن تولد استجابة ضخمة نوعا ما ، وماذا تفعل مع هذه الإجابة إذا كان العميل لا يعود بعد ذلك؟ كم لتخزينه؟ ولكن في الوقت نفسه ، تتم معالجة طلبات القراءة بشكل متوازي. أدت هذه الاختلافات إلى مشاكل في إعادة تشغيل هذه العمليات. دورات حياتها ببساطة غير متوافقة!

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

استخدم الجيل السابق من منتجاتنا على نطاق واسع من المواضيع. لكن كما أظهرت الممارسة ، لم ينقذنا الكثير. بسبب الأقفال العديدة ، نادراً ما تجاوز الحمل على وحدة المعالجة المركزية 100٪. لقد سمح ظهور عدد كبير من الخدمات المنفصلة بسرعة إلى حد ما بالتخلي عن تعدد العمليات لصالح العمل غير المتزامن والمترابط.

أثناء عملية التطوير ، حاولنا استخدام التدفقات مع عدم التزامن (دفعة :: Asio تسمح بذلك). ولكن هذا النهج من المرجح أن يجلب إلى مشروعك جميع أوجه القصور في كلا النهجين مما يعطي أي مزايا واضحة: سيكون عليك الجمع بين الحاجة إلى التحكم عند الوصول إلى الكائنات المشتركة وصعوبة كتابة التعليمات البرمجية غير المتزامنة.

الجزء 3. كما كتبنا المربع ، وكتب المنصة

يتم ترتيب جميع الخدمات في حاويات والعمل مع خادم العميل عن بعد. ولماذا ثم وضع التطبيق على خادم العميل؟ هذا هو السؤال الذي طرحته على الإدارة عندما حان الوقت لتعبئة المنتج الناتج للتثبيت على الخادم.

ما هي المنصة؟ أولاً ، نشرنا SaaS ، وهي خدمة تعمل على خوادمنا وتتيح لك تكوين الخادم الخاص بك. إذا استخدمت أي لوحة تحكم خادم واشتريتها بنفسك - فهذا هو الحل لك. لكنه لا يناسب مقدمي الخدمات: فهم ليسوا مستعدين لتوفير الوصول إلى خوادم عملائهم لشركة خارجية ، وأنا أفهمها جيدًا. هذا يثير تساؤلات حول كل من الأمن والتسامح مع الخطأ. لذلك ، قررنا منحهم SaaS بالكامل حتى يتمكنوا من نشرها في المنزل. إنه مثل Amazon ، حيث يمكنك تشغيله في مركز البيانات الخاص بك والاتصال بنظام الفواتير الخاص بك. أطلقنا على هذا الحل منصة.

لم يتم النشر الأول بسلاسة كبيرة. لكل مستخدم نشط ، رفعنا حاوية منفصلة. ترتفع حاويات الإرساء بسرعة ، لكن اكتشاف الخدمة لا يعمل على الفور: ليس المقصود منه رفع / إيقاف الحاويات بشكل ديناميكي خلال ثانية واحدة. ومن لحظة الرفع إلى اللحظة التي يمكن فيها استخدام الخدمة ، في بعض الأحيان تمر دقائق !!!

لقد كتبت بالفعل أن مستخدم الاستضافة قد تغير كثيرًا خلال العقد الماضي. تخيل الآن: إنها تشتري مضيفًا منك - وتمكّن من الوصول إلى القشرة. WTF؟!؟! لاستخدامه ، سيضطر أولاً إلى العثور على بعض عملاء SSH (في Windows ، قد يصبح هذا مشكلة - لا يوجد عميل افتراضيًا ، أنا صامت عمومًا عن عملاء الأجهزة المحمولة).

بعد أن يتمكن من الوصول إلى وحدة التحكم ، يحتاج إلى تثبيت اللوحة. وهذه العملية هي أيضا ليست سريعة. وإذا حدث خطأ ما؟ على سبيل المثال ، قد يقوم RosKomNadzor بحظر الخوادم التي يتم منها تنزيل حزم نظام التشغيل الخاص بك. مع مثل هذه الأخطاء ، سيتم ترك المستخدم وجها لوجه.



يمكنك القول أن المستخدم في معظم الحالات يتلقى اللوحة المثبتة بالفعل من قبل المضيف ، وما سبق لا ينطبق عليه. ربما. لكن اللوحة التي تعمل على الخادم تستهلك الموارد التي دفعتها مقابلها (تشغل مساحة على القرص ، وتأكل المعالج والذاكرة). يعتمد أدائها بشكل مباشر على أداء الخادم (تعطل الخادم - تعطل اللوحة).

ربما لا يزال هناك أولئك الذين لا يستخدمون أي لوحات ويفكرون: هذا لا يهمني. ولكن ربما على الخادم الخاص بك ، إذا كان لديك واحدة ، لا يزال هناك نوع من اللوحة قائم ويستهلك الموارد ، لكنك لا تستخدمه فقط؟

يقول المضيفون الروس: "لذلك ، إنه أمر رائع ، أنت تساعدنا في بيع الموارد". يضيف آخرون: "لماذا ننفق مواردنا في نشر منصة تستهلك أكثر من لوحة قائمة بذاتها؟"

هناك العديد من الإجابات على هذا السؤال.

1. تحسين جودة الخدمة: يمكنك التحكم في إصدار اللوحة - تحديثها بسرعة عند ظهور وظائف جديدة أو اكتشاف أخطاء ؛ يمكنك الإعلان عن الأسهم مباشرة في اللوحة.
2. على نطاق البنية التحتية ، يمكنك حفظ القرص والذاكرة والمعالج ، حيث يتم إطلاق بعض العمليات فقط لخدمة المستخدمين النشطين ، والبعض الآخر يخدم العديد من العملاء في نفس الوقت.
3. لا يحتاج الدعم إلى تحليل ما إذا كان السلوك ميزة خاصة بإصدار معين من اللوحة أو خطأ. إنه يوفر الوقت.

اشترى الكثير من عملائنا تراخيص في حزم ثم قاموا بتزييفها ، وإعادة بيعها لعملائهم. لم تعد هناك حاجة للقيام بذلك ، من حيث المبدأ ، عمل بلا معنى. بعد كل شيء ، الآن هذا هو منتج واحد.

بالإضافة إلى ذلك ، أتيحت لنا الفرصة لاستخدام حلول ثقيلة ، مما يوفر وظائف لا يمكن الوصول إليها من قبل. على سبيل المثال ، تتطلب خدمة الحصول على لقطات شاشة للموقع إطلاق chromium مقطوعة الرأس. لا أظن أن المستخدم سيكون سعيدًا للغاية إذا نفد الذاكرة بسبب هذه العملية وأطلق النار على نفسه ، على سبيل المثال ، MySQL.

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

لم تنته القصة بعد ، لكن ما حدث يمكن عرضه على موقع Vepp .