Service Mesh وميكروخدمات TypeScript: دليل شامل 2024

عندما تصبح الميكروخدمات كثيرة جدًا

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

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

ما هو Service Mesh بعبارات بسيطة

تخيل أن كل ميكروخدمة TypeScript لديك هي موظف في مكتب كبير. بدون Service Mesh، يجب على كل موظف أن يمد الكابلات بنفسه، ويضبط الهاتف، ويتأكد من عدم التنصت عليه. مع Service Mesh، يتولى قسم تكنولوجيا معلومات خاص هذه المهمة، حيث يربط لكل موظف "مساعد شخصي" (sidecar proxy).

في عالم التكنولوجيا، يُسمى هذا المساعد Envoy Proxy، ويدير هذه البنية التحتية بأكملها منسق مثل Istio أو Linkerd. الأمر الأكثر متعة هو أن كود TypeScript الخاص بك يظل دون تغيير تقريبًا.

الإمكانيات الرئيسية لـ Service Mesh

\n
• إدارة حركة المرور - توجيه ذكي، اختبار A/B، إصدارات تدريجية
\n
• الأمان - تشفير تلقائي mTLS بين الخدمات
\n
• المراقبة - مقاييس، سجلات، تتبع "مدمج"
\n
• المرونة - إعادة محاولات، قاطع الدائرة، مهلات زمنية على مستوى البنية التحتية
\n

لماذا تستفيد ميكروخدمات TypeScript بشكل خاص من Service Mesh

TypeScript هي لغة ذات نظام أنواع قوي، لكن بيئة التشغيل الأساسية لها (Node.js) لا تشتهر دائمًا بأداء الإدخال والإخراج. عندما تكتب ميكروخدمة باستخدام TypeScript، كل طلب HTTP إضافي، كل تنفيذ يدوي لإعادة المحاولات أو مصافحة TLS - هو حمل إضافي على Event Loop.

يتولى Service Mesh هذا الحمل بنفسه. يظل كود TypeScript الخاص بك نظيفًا: فقط يستقبل الطلبات ويستجيب لها، بينما يقوم Envoy بكل "الأعمال السباكة". هذا مهم بشكل خاص عندما يكون لديك عشرات الميكروخدمات - كل منها بمنطق إعادة المحاولة والمهلات الزمنية الخاص به.

مثال عملي: ميكروخدمة TypeScript تحت Service Mesh

لنتخيل أن لدينا ميكروخدمتين باستخدام TypeScript: user-service و order-service. يجب أن تحصل order-service على بيانات المستخدم. بدون Service Mesh، كنا سنكتب شيئًا مثل:

// بدون Service Mesh - إدارة HTTP يدوية\nimport axios from 'axios';\n\nclass UserClient {\n    private baseUrl = 'http://user-service:3000';\n    private retries = 3;\n\n    async getUser(id: string): Promise<User> {\n        for (let i = 0; i < this.retries; i++) {\n            try {\n                const response = await axios.get(`${this.baseUrl}/users/${id}`, {\n                    timeout: 5000,\n                    httpsAgent: new https.Agent({ rejectUnauthorized: true })\n                });\n                return response.data;\n            } catch (error) {\n                if (i === this.retries - 1) throw error;\n                await delay(1000 * Math.pow(2, i));\n            }\n        }\n    }\n}

ومع Service Mesh يتحول هذا إلى:

// مع Service Mesh - مجرد طلب HTTP\nimport axios from 'axios';\n\nclass UserClient {\n    async getUser(id: string): Promise<User> {\n        const response = await axios.get(`http://user-service/users/${id}`);\n        return response.data;\n    }\n}

هل لاحظت الفرق؟ كل التعقيد - إعادة المحاولات، المهلات الزمنية، التشفير - قد