سيؤدي تعلم أنماط الخدمات المصغرة الخمسة هذه إلى جعلك مهندسًا أفضل

بالنسبة للعديد من المهندسين ، قد يكون الدخول في الخدمات المصغرة أمرًا صعبًا ، لأنه من الصعب تحديد المكان الذي يجب رسم الخطوط فيه. بالنسبة لي ، 80٪ من الخدمات تندرج في واحدة من خمس فئات ، وتقسيم المسؤوليات بهذه الطريقة يسمح لك بالتفكير في كيفية هندسة الميزات عن طريق خدمات الأنابيب معًا كما تفعل في البرمجة النصية لـ Unix shell.

لنتحدث للحظة عن القاسم المشترك بين جميع الخدمات المصغرة. يعرّفها إريك إيفانز ، والد التصميم المستند إلى المجال ، على النحو التالي: “[الخدمات] التي يمكنها استهلاك الرسائل وإنتاجها”. (https://www.youtube.com/watch؟v=yPvef9R3k-M)

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

يمكن تقسيم هذه الرسائل مرة أخرى إلى فئتين: الأحداث والأوامر.

قبل أن نبدأ على الرغم من ذلك ، ولأن السياق مهم ، سمعت لأول مرة عن أنماط الخدمات المصغرة هذه من مات والترز ، مؤسس ناقل خدمة المكتبة. Servicebus هو تعديل العقدة لمكتبة .Net شهيرة تسمى NServiceBus ، تم إنشاؤها ونشرها بواسطة Udi Dahan.

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

إذا كنت من مطوري Go أو Python الذين يرغبون في المساهمة في هذه القضية ، فأرسل إليّ رسالة!

وبدون مزيد من اللغط ، أنماط الخدمات المصغرة الخمسة.

1. خدمات النماذج

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

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

التحديث: 1/7/19 – راجع مقالتي الجديدة على HackerNoon التي تتحدث عن مصادر الأحداث للنماذج.

2. خدمات المزيل

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

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

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

تخيل لو كان مهندسو التطبيق لديك يستخدمون شيئًا مثل Meteor مع MongoDB – فقد حصلوا للتو على مخزون في الوقت الفعلي من نظام خارجي دون الحاجة إلى كتابة سطر من التعليمات البرمجية. يعمل هذا أيضًا بشكل رائع مع RethinkDB المقترنة باشتراكات GraphQL!

3. خدمات البوابة

يمكن استخدام خدمات البوابة بشكل مشابه جدًا لاستخدام عوامل عدم التطابق. وبدلاً من الاتصال بقاعدة بيانات ، فهو اتصال بواجهة برمجة تطبيقات.

كنت أعمل مؤخرًا مع محرك توصيات يسمى LiftIgniter ، والذي يحتاج مخزوننا إلى المزامنة. تشترك الخدمة في أحداث stock.product.updated و stock.product.added وتنشر البيانات المنسقة في نقاط النهاية المناسبة.

في وقت لاحق ، تمت إضافة خدمة إضافية تستمع لنفس الأحداث ، ومن خلال إنشاء خدمة Magento Gateway ، تمكنا من تحديث متجر التجارة الإلكترونية باستمرار مع مستويات المخزون المتغيرة أيضًا!

4. خدمات المبتعث

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

عادةً ما تنتج خدمات المستقبِل الرسائل فقط. تتضمن هذه الخدمات عادةً إما تلقي API POST عبر HTTP ، أو تشغيل وظيفة CRON ، والكشط في فترة زمنية. يتم بعد ذلك نشر البيانات التي تم جلبها أو استلامها إلى النظام باستخدام اللغة العالمية (AMQP w / JSON).

5. خدمات المحول

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

خدمات واجهة برمجة التطبيقات

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

يجب أن تظل خدمات واجهة برمجة التطبيقات خفيفة الوزن. إذا كنت تبني مجموعة كاملة من منطق الأعمال في واجهة برمجة تطبيقات ، فأنت بذلك تبني وحدة متراصة. إنه أفضل قليلاً من الجمع بين التطبيق والخادم الذي اعتدنا أن نراه مع بنى “n-tier” ، ولكنه يؤدي في النهاية إلى “Big Ball of Mud” أو “Spaghetti Code” سيئة السمعة أيضًا.

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

أنظمة أحادية الاتجاه

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

إذا اتبعت الأنماط المذكورة أعلاه ، فستستخدم ما يسمى أحيانًا أكثر تعقيدًا بفصل مسؤولية استعلام الأوامر أو CQRS. تستهلك Model Services الأوامر ، ويتم إنتاج الأحداث التي يتم استهلاكها بواسطة Denormalizer أو Gateway Services ، والتي تعمل على تحديث نماذج القراءة. ثم يتم إجراء الاستعلامات مقابل نموذج القراءة.

نظرًا لأنك تستخدم رسائل غير قابلة للتغيير ، فإن هذا يجعل “تحديد مصادر الأحداث” النمط المثالي لبناء خدمات النموذج. هناك إنشاء آخر لـ Matt Walters يستحق التحقق منه ، وهو إطار عمل مصغر يسمى [sourced] (https://github.com/mateodelnorte/sourced) يعمل بشكل متناغم مع servicebus ، لإضافة إمكانات “مصادر الأحداث” بسهولة لاستهلاك أحداث خدمتك ، واستمرارها في قاعدة البيانات.

خاتمة

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

إذا لم تكن قد قرأت مقالتي الأخرى ، فاقرأها أيضًا “الألغاز العشر لبنية خدمات مصغرة فعالة”! وهو يغطي المكونات التي تشكل بنية الخدمات المصغرة.

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

هل أنت مهتم بالاستماع إلى My DevOps Journey ، بدون شهادات AWS غير المجدية؟ اقرأها الآن على HackerNoon. يعد DevOps شرطًا أساسيًا للخدمات المصغرة الفعالة.

شكرًا على القراءة! إذا تابعتني وأعطيتني 50 تصفيق ، فسيساعدني ذلك حقًا في الوصول إلى المزيد من الأشخاص! انقر و #HODL زر التصفيق أدناه ؛)

إذا كنت ترغب في التواصل معي ، يمكنك مراسلتي على LinkedIn أو Twitter.