رحلة شوبروكيت نحو الميكروسيرفيسز: الجزء الأول

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ستستمر Shoprocket في رحلتها نحو الخدمات المصغرة. نتطلع إلى إخباركم والمزيد في الجزء الثاني!