هجرة كشوف المرتبات المربعة من متراصة إلى خدمات مصغرة
تخيل ملعب كرة قدم كبير به العديد من الكرات المتناثرة حوله. هناك لاعبون تتمثل مهمتهم في مسح الملعب في كل كرة وتحديد ما إذا كان يجب ركل الكرة أو تخطيها. لكل كرة تحتاج إلى ركلها، يحتاج اللاعب إلى الاستفسار من المدرب عن مدى دقة ركل الكرة. في نموذج الاقتراع هذا، هناك عبء كبير من المسؤولية يقع على عاتق كل من اللاعبين والمدرب. أيضًا، يتم إيداع العديد من الكرات، والتي لم يكن مطلوبًا اتخاذ أي إجراء بشأنها. هذه هي قصة ما قبل الهجرة.
في قصة ما بعد الترحيل، يقف اللاعبون في مواقع ميدانية محددة، ويتم وضع الكرات التي تحتاج إلى الركل في قائمة الانتظار بجانب اللاعبين المعينين. يقوم اللاعبون بركل الكرات الموجودة في قائمة الانتظار في اتجاهات محددة إلى موقع قائمة الانتظار التالية، بناءً على الأسهم الوامضة على الكرة.
سياق
توفر Square Payroll خدمات كشوف المرتبات للشركات الصغيرة. اليوم، توجد البنية التحتية التي تدعم هذه المسؤوليات إلى حد كبير في كتلة روبي متراصة تدعمها MySQL. بفضل نجاح المنتج الكبير ونمو المستخدمين، أصبحت Square Payroll الآن في مرحلة تحفزنا فيها خدمة عملائنا على الانتقال إلى بنية أكثر قابلية للتوسع. يركز هذا المستند على خطوة مبكرة ناجحة في هذه الرحلة، مع التركيز على إعادة تصميم نظام الإيداع الضريبي الخاص بنا باستخدام بنية AWS بدون خادم.
يعد موضوع الترحيل من متراصة إلى الخدمات المصغرة نوعًا شائعًا نسبيًا في صناعة التكنولوجيا. هذه التجربة هي مكافأة يحظى بامتياز الشركات الناجحة للقيام بها. عادة، يتم سرد هذه القصص على مستوى أعلى. في المقابل، سنركز في هذه المقالة على مثال أضيق ونبحث بشكل أعمق في التفاصيل. على وجه الخصوص، سنناقش موقفًا غير تافه واجهناه والذي تم تصميمه خصيصًا لاستخدام دالة الخطوة لتقليل تعقيد الكود وزيادة الشفافية.
المصطلح
- Sidekiq هو برنامج جدولة عمل في الخلفية في Ruby.
- إدارة تطوير التوظيف (EDD) في كاليفورنيا، هي إدارة تابعة لحكومة كاليفورنيا تجمع ضرائب البطالة من أرباب العمل في كاليفورنيا.
- Amazon Web Services (AWS) هي شركة تابعة لشركة Amazon توفر منصات الحوسبة السحابية عند الطلب.
- تطبيق أو تطبيق Square، هو تطبيق مستقل داخل Square ، مرتبط بمركز التكلفة والمالكين ومجموعة من خيارات البنية التحتية والتخزين.
خلفية
بالنسبة إلى كشوف رواتب Square ، فإن “كرات كرة القدم” من الصور الافتتاحية هي ما نسميه “المهام”. المهام عبارة عن صفوف في جدول قاعدة البيانات. يمثل كل صف أو مهمة في نموذج البيانات مثيلاً لسير العمل. على سبيل المثال، قد يكون سير العمل الفردي: دفع الضريبة X، لصاحب العمل Y، للوكالة Z، بالاقتران مع الحدث W.
تعتمد بنية المهام إلى حد كبير على استطلاعات الرأي، وتعتمد اليوم على أكثر من 100 وظيفة cron مميزة تعمل وفقًا لجدول زمني ثابت واستقصاء منتظم لأي عمل متاح للقيام به.
الأهداف
أهداف التصميم الهندسي
- الهندسة سوف تكون مدفوعة الحدث. سنبدأ سير العمل المدعوم من AWS برسالة حدث تحتوي على معلومات تلخص جميع المعلومات المطلوبة لتقدم المهمة. لن يكون لدينا أي استفسارات حول قواعد بيانات كشوف المرتبات من خدمة تقديم كشوف المرتبات.
- سيكون تدفق المعلومات على أساس الدفع. مع دفع كشوف المرتبات للعمل، إلى إيداعات كشوف المرتبات، وإيداع كشوف المرتبات التي تعيد التحديثات إلى قائمة الرواتب المتراصة.
- سيكون Lambdas مصممي الخرائط لغرض واحد يأخذون المدخلات ويؤدون العمل وينتجون المخرجات. لن تحتاج Lambdas إلى منطق شرطي أو تكوين. سيتم تفويض المنطق الشرطي إلى موارد المكونات القابلة للتكوين، مثل حالات اختيار وظيفة الخطوة.
التصميم الفني
لقد أنشأنا تطبيقًا أو خدمة جديدة “بدون خادم” من AWS، لتقديم كشوف المرتبات. يتكون تطبيق إيداعات كشوف المرتبات من عدد من خدمات الإيداع الصغيرة التي تشمل lambdas ووظائف خطوة SQS و dynamoDB و SecretManager. ينقسم تطبيق إيداعات كشوف المرتبات إلى مستودعين جديدين: إيداعات كشوف المرتبات وإيداع كشوف المرتبات. يحتوي مستودع إيداعات كشوف المرتبات على منطق الأعمال الخاص بنا وكود المصدر لـ lambdas. تُعد ملفات tf-payroll-filings عبارة عن مستودع تكوين terraform نستخدمه لبناء موارد AWS الخاصة بنا. يساعد فصل طبقات الكود والتكوين في وحدات إعادة الشراء المختلفة في الحفاظ على تركيز كل ريبو على هيكل وتصميم أغراض أكثر تفردًا. تسمح عمليات إعادة الشراء المنفصلة أيضًا بمرونة البناء / النشر، وتقليل نصف قطر الانفجار لتغييرات التعليمات البرمجية.
يرسل تطبيق Square payroll حدثًا في شكل رسالة SQS إلى خدمة حفظ كشوف المرتبات. يتضمن هذا الحدث جميع المعلومات المطلوبة التي تحتاجها خدمة حفظ كشوف المرتبات لإكمال الإيداع. تنشر خدمة حفظ كشوف المرتبات تحديثات على خدمة كشوف المرتبات المربعة عند نقاط تسجيل الوصول الثابتة وعندما يكون الإيداع في حالة طرفية. يتم تحديث الترحيلات بين كشوف المرتبات المربعة وخدمة تقديم كشوف المرتبات عبر SQS. يعد استخدام SQS كعملية اتصال موحدة ثنائية الاتجاه للخدمة بين كشوف المرتبات المربعة وملفات كشوف المرتبات مناسبًا جيدًا للخلفية، والطبيعة غير المتزامنة للملفات، ويوفر قوة النظام في شكل تحمل الخطأ 1، ويسمح بسهولة الملاحظة 2.
يسمح هذا التصميم المعماري بتغليف منطق الإيداع والبيانات في خدمة إيداعات كشوف المرتبات. تحتوي قائمة إعادة إيداعات كشوف المرتبات الجديدة على منطق أعمال تقديم كشوف المرتبات والذي يمكن إزالته من قائمة الرواتب. بالإضافة إلى ذلك، تم إنشاء جدول DynamoDB في حساب AWS لإيداع كشوف المرتبات، ويستخدم للتنفيذ الداخلي لسير عمل الإيداعات، وهذه البيانات الداخلية ليست مطلوبة من قِبل كشوف رواتب Square أو تعرضها.
التغييرات المعمارية
التصميم الموجود مسبقًا
موضوع هذه المقالة هو ترحيل مهمة واحدة تمثل سير العمل المسؤول عن صاحب عمل واحد (ER) يدفع إعاقة الولاية (SDI) وضرائب دخل الولاية (SIT) إلى كاليفورنيا (CA) EDD. يجب دفع هذه الضرائب على أساس كل قائمة رواتب.
في التصميم الموجود مسبقًا، تتضمن عملية إنشاء سير العمل والتقدم فيه وقيادته حتى الاكتمال 3 نقاط دخول مميزة. يتم إنشاء مهمة بالحالة التي تم إنشاؤها بواسطة وظيفة غير متزامنة بعد أن يقوم صاحب عمل CA بتشغيل كشوف المرتبات لدفع رواتب موظفيهم. يلتقط هذا الصف في قاعدة بيانات المهام التزام التقارير الإلكترونية بدفع الضرائب إلى المرجع المصدق بالإضافة إلى بعض البيانات الوصفية للإيداع. استعلامات وظيفة Sidekiq cron لجميع المهام التي تم إنشاؤها أو IN_PROGRESS وتطلق المهام غير المتزامنة لتقدم المهمة. تستدعي المهام غير المتزامنة التي تم إطلاقها طريقة روبي استنادًا إلى الحالة الحالية وخطوة المهمة كما هي مخزنة في قاعدة البيانات. يمكن أن تكون طريقة Ruby هذه عبارة عن طريقة no-op أو تقوم بتغيير حالة المهام أو الخطوة بحيث يقوم مثيل لاحق لعامل استقصاء المهمة باستدعاء طريقة Ruby جديدة / مختلفة في المهمة.
ومع ذلك، فإن التقدم في مهمة الاقتراع ليس القصة بأكملها. كجزء من تقدم مهمة الاقتراع، يتم إرفاق “اتصال خارجي” بالمهمة التي تمثل محتوى ما سيتم إرساله إلى وكالة CA EDD من أجل مطالبة CA بخصم ER للضرائب المطلوبة. هناك نوعان من وظائف cron الأخرى المسؤولة عن تقدم الاتصالات التي يعتمد عليها سير عمل المهمة. يستعلم أحد مهام cron عن عمليات الإرسال الجاهزة للإرسال ويرسلها دفعة واحدة إلى CA. تقوم وظيفة cron المستقلة الأخرى باستطلاعات الرأي والتحقق من حالة جميع عمليات الإرسال المرسلة. تعمل هاتان الوظيفتان كرون للتواصل معًا على تحديث حالة الاتصال الخارجي بعد العمل عليهما.
في النهاية، عندما تقوم مهام الإرسال والتحقق من cron بتقدم الاتصال الخارجي إلى حالة طرفية، فإن عامل استقصاء المهمة سيدرك هذا التحديث ويتقدم بالمهمة نحو الإكمال. انظر الرسم البياني أدناه للحصول على التفاصيل.
نقاط الألم مع التصميم الموجود مسبقًا
مع التصميم الموجود مسبقًا، واجهنا المشكلات التالية:
- عدم التوفر الكبير. يعتمد التصميم الموجود مسبقًا على وقت تشغيل خادم Sidekiq. يمكن إيقاف عمليات Sidekiq على سبيل المثال عن طريق نشر التعليمات البرمجية أو عن طريق نشاط آخر على العقد المشتركة. في بعض الحالات، يمكن أن يتسبب إغلاق عامل المهمة فجأة في حدوث أخطاء في الاتصالات أو الاتصالات الجارية.
- بنية غير فعالة وقاعدة بيانات ثقيلة. يعتمد نظام مهام الاقتراع الحالي لدينا على الانطلاق الجانبي لتحسين المهام إلى الخطوة التالية. في كثير من الحالات، نتحقق كثيرًا من العمل الذي يتعين القيام به، مما يؤدي إلى عدم تنفيذ العمليات. في حالات أخرى، نسمح بفواصل زمنية غير ضرورية بين الخطوات. توتر بنية الاستقصاء، وتقتصر على مجموعة MySQL الخاصة بنا، حيث يجب أن تبدأ كل خطوة استقصاء من خلال الاستعلام عن قاعدة البيانات للحصول على المعلومات المطلوبة لأداء هدفها. فيما يتعلق بالمثال الخيالي في البداية، فإن مجموعة MySQL هنا هي المدرب الذي يجب أن يوجه كل لاعب لكيفية ركل كل كرة.
- انخفاض السرعة الهندسية وزيادة الأخطاء. نحن نفتقر إلى رؤية واضحة ومثبتة للمستقبل في مسار المهام من خلال سير عملها. على سبيل المثال، يمكن أن يؤدي استخدام المهام السابقة كأمثلة إلى توقعات قديمة. وبالمثل، فإن استخدام أمثلة المسار السعيد يمكن أن يغيب عن مسارات الحالة الحادة. تؤدي هذه الرؤية المحدودة إلى تقليل السرعة الهندسية ومزيد من الوقت في فرز الأخطاء أو تكرار المهام. تتشابك التعليمات البرمجية الموجودة مسبقًا مع منطق الأعمال وتوجيه التكوين. يعتمد رمزنا أيضًا بشكل كبير على الاختبار الشامل والتكامل. إن الجمع بين هذين العاملين يجعل من الصعب تغطية جميع المواقف تمامًا بسبب التفريع المنطقي.
تصميم جديد يحركه الحدث
في التصميم الجديد، استخدمنا AWS Step Functions كحل مثالي خارج الصندوق لموقفنا لاستبدال الحاجة إلى ثلاث وظائف cron. سمحت لنا وظائف الخطوة بتنسيق سير عملنا بشفافية من خلال تجميع الإجراءات (Lambdas) والتدفقات (الاختيارات والانتظار) معًا، مع الحفاظ على رمز تعقيد lambdas في حده الأدنى.
يوضح المثالان التاليان بعضًا من قيمة استخدام دالة الخطوة.
قديم: استخدمنا وظيفة cron لاستقصاء حالة الإرسال التي تعود مبكرًا ما لم تكن الحالة ناجحة. جديد: استخدمنا وظيفة الخطوة “إجراء لامدا” لجلب حالة الإرسال ثم تكوين “اختيار” وظيفة الخطوة لمقارنة الحالة مع المخرجات المتوقعة وإما الانتظار لإعادة المحاولة، أو التقدم في المهمة.
قديم: تشارك المهام بشكل متكرر في سير عمل مشترك، مع عدم وجود بعض المهام التي تحتوي على خطوات معينة في سير عملها.
على سبيل المثال، تحتوي جميع مهام ضرائب الدفع على خطوة تسمى WAIT_FOR_DEBITS حيث ننتظر اسميًا خصمًا من صاحب العمل من قبلنا، حتى نتمكن من الالتفاف ودفع الخصم للوكالة الحكومية دون تكبد خسارة المخاطر. ومع ذلك، بالنسبة لبعض المهام التي يتم فيها دفع الأموال مباشرة من صاحب العمل إلى جهة حكومية، ليست هناك حاجة لخطوة الانتظار هذه. تم تضمين منطق ما إذا كان يمكن تخطي خطوة الانتظار بشكل تافه في شكل فحص شرطي في التعليمات البرمجية المصدر. كنا نطبق مبدأ “لا تكرر نفسك” (DRY) على تصميم سير العمل، على حساب تعقيد الكود وانخفاض شفافية النظام.
جديد: أنشأنا وظيفة خطوة فريدة لتتوافق بشفافية مع كل سير عمل فريد. ما زلنا نطبق DRY، ولكن بدلاً من تطبيق DRY على التصميم، فإننا نطبق DRY على الكود المصدري عن طريق إعادة استخدام lambdas عبر وظائف الخطوة المختلفة. بالإضافة إلى ذلك، لم تعد Lambdas الخاصة بنا بحاجة إلى التفريع الشرطي للتحقق مما إذا كانت خطوتها تنطبق حيث يتم تضمين lambdas فقط في مهام سير العمل حيث تكون هناك حاجة إليها في الواقع.
ما يلي هو التصميم الجديد لسير عمل المهمة.
تحديثات لقاعدة بيانات Square Payroll
يتم إرسال التحديثات إلى قاعدة بيانات Square Payroll من lambdas عبر SQS. التحديثات محدودة لأنواع تحديث معينة. يتم تغليف معالجة الرسائل في وحدة خدمة تحديث عميق.
تشير الرسائل في SQS إلى أي من واجهات برمجة التطبيقات المدعومة يتم استخدامها وتتضمن الوسائط المطلوبة. يتم تمرير الطوابع الزمنية إلى واجهة برمجة التطبيقات حيث يمكن أن يكون هناك تأخير أو استهلاك خارج الطلب للتحديثات بين كشوف المرتبات وإيداع كشوف المرتبات.
تغييرات نموذج البيانات
لا توجد تغييرات على نموذج بيانات Square Payroll MySQL. وبدلاً من ذلك، أضفنا نموذج بيانات جديدًا إلى خدمة تقديم كشوف المرتبات الجديدة في شكل جدول مفرد من DynamoDB . يحتوي هذا الجدول على البيانات التي تم تخزينها مسبقًا في كشوف المرتبات.
خاتمة
في Square Payroll ، نحن حاليًا في منعطف مثير للغاية للمنتج. نحن نخطط ونتخذ استثمارات أساسية في تصميم معماري حديث وقابل للتطوير. لا تزال الرحلة في مرحلة مبكرة، لذلك نتطلع إلى مشاركة الغوص العميق في المستقبل في أجزاء أخرى من مجموعة التكنولوجيا لدينا. الأهم من ذلك، إذا كان هذا العمل مثيرًا لك، فيرجى التواصل معنا! لدينا الكثير لنفكر فيه ونبني معًا.
المصدر: developer
شاهد المزيد:
