الجزء الأول: كيفية بناء بوابة API للخدمات المصغرة باستخدام OpenResty

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

ما الذي تفعله بوابة واجهة برمجة التطبيقات للخدمات المصغرة؟

دعنا أولاً نلقي نظرة على دور بوابة واجهة برمجة التطبيقات للخدمات المصغرة. الصورة أدناه هي وصف موجز:

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

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

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

1. صديقة للسحابة الأصلية، يجب أن تصبح البنية خفيفة الوزن وسهلة الحاوية.
2. الاتصال مع مكونات الإحصاء والمراقبة مثل Prometheus، Zipkin، SkyWalking.
3. دعم وكيل gRPC، وتحويل البروتوكول بين HTTP و gRPC، وتحويل طلب HTTP للمستخدم إلى طلب gRPC للخدمة الداخلية.
4. تحمل دور الطرف المعتمد لـ OpenID، والاتصال مع خدمات مزودي المصادقة مثل Auth0 و Okta، واعتبار أمان الحركة أولوية قصوى.
5. تحقيق Serverless من خلال تنفيذ وظائف المستخدم بشكل ديناميكي في وقت التشغيل، مما يجعل عقد حواف البوابة أكثر مرونة.
6. عدم قفل المستخدمين ودعم بنية النشر السحابية الهجينة.
7. يجب أن تكون عقدة البوابة بلا حالة ويمكن توسيعها وتقليصها حسب الرغبة.

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

من هذا المنظور، يمكن لبوابة واجهة برمجة التطبيقات أن تحل محل جميع وظائف NGINX وتتعامل مع حركة المرور الشمالية-الجنوبية؛ يمكنها أيضًا إكمال دور مستوى التحكم في Istio ومستوى البيانات في Envoy للتعامل مع حركة المرور الشرقية-الغربية.

لماذا نعيد اختراع العجلة؟

لأن مكانة بوابة واجهة برمجة التطبيقات للخدمات المصغرة مهمة جدًا، فقد كانت دائمًا ساحة معركة، وكانت عمالقة تكنولوجيا المعلومات التقليديين في هذا المجال لفترة طويلة. وفقًا لتقرير دورة حياة واجهة برمجة التطبيقات الذي أصدرته Gartner في عام 2018، فإن Google و CA و IBM و Red Hat و Salesforce هم جميعًا من الشركات الرائدة، و Apache APISIX، الذي هو أكثر دراية للمطورين، هو من بين الرؤى.

لذا، السؤال هو، لماذا يجب علينا إعادة اختراع عجلة جديدة؟

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

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

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

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

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

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

المكونات والمفاهيم الأساسية لبوابة واجهة برمجة التطبيقات

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

أولاً هو Route. يقوم بمطابقة طلب العميل من خلال تعريف بعض القواعد، ثم يقوم بتحميل وتنفيذ الإضافة المقابلة وفقًا لنتيجة المطابقة، ويقوم بتوجيه الطلب إلى المنبع المحدد. يمكن أن تتكون قواعد مطابقة المسارات هذه من host، uri، header، إلخ. الموقع المألوف في NGINX هو تنفيذ للمسار.

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

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

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

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

Route

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

يمكننا إكمال جميع التكوينات مباشرة في Route، وهو الأسهل. ولكن في حالة وجود العديد من واجهات برمجة التطبيقات والمنابع، فإن القيام بذلك سيسبب الكثير من التكوينات المكررة. في هذا الوقت، نحتاج إلى مفهومي Service و Upstream لإجراء طبقة من التجريد.

Service

دعنا ننظر إلى Service بعد ذلك. إنه تجريد لنوع معين من واجهة برمجة التطبيقات، ويمكن أيضًا فهمه على أنه تجريد لمجموعة من Routes. عادةً ما يكون له علاقة 1:1 مع خدمات المنبع، والعلاقة بين Routes و Services هي عادةً N:1. لقد استخدمت أيضًا صورة لتمثيل ذلك:

من خلال هذه الطبقة من التجريد لـ Service، يمكننا فصل الإضافات المكررة والمنابع. بهذه الطريقة، عندما تتغير الإضافة والمنبع، نحتاج فقط إلى تعديل Service بدلاً من تعديل البيانات المربوطة على عدة Routes.

Upstream

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

بهذه الطريقة، عندما تتغير عقدة المنبع، فإن Route غير مدركة تمامًا، ويتم معالجتها جميعًا داخل Upstream.

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

الخلاصة

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

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

التالي: الجزء 2: كيفية بناء بوابة واجهة برمجة تطبيقات للخدمات المصغرة باستخدام OpenResty الجزء 3: كيفية بناء بوابة واجهة برمجة تطبيقات للخدمات المصغرة باستخدام OpenResty