تقوم بعض الشركات ، بما في ذلك عملائنا ، بتطوير المنتج من خلال شبكة شركاء. على سبيل المثال ، يتم دمج المتاجر الكبيرة عبر الإنترنت مع خدمة التوصيل - تطلب منتجًا وستتلقى قريبًا رقم تتبع للحزمة. مثال آخر هو عندما تشتري تأمينًا أو تذكرة Aeroexpress جنبًا إلى جنب مع تذكرة الطيران الخاصة بك.
لهذا ، يتم استخدام واجهة برمجة تطبيقات واحدة ، والتي يجب إصدارها للشركاء من خلال بوابة API. لقد حللنا هذه المشكلة. في هذا المقال سنخبرك بالتفاصيل.
معطى: نظام بيئي وبوابة API مع واجهة حيث يتم تسجيل المستخدمين وتلقي المعلومات وما إلى ذلك. نحن بحاجة إلى إنشاء بوابة API مريحة وموثوقة. في هذه العملية ، كان علينا أن نقدم
- تسجيل،
- التحكم في اتصال API ،
- مراقبة كيفية استخدام المستخدمين للنظام النهائي ،
- المحاسبة لمؤشرات الأعمال.
سنتحدث في المقال عن تجربتنا في إنشاء API Gateway ، والتي قمنا خلالها بحل المهام التالية:
- مصادقة المستخدم ،
- إذن المستخدم ،
- تعديل الطلب الأصلي ،
- طلب الوكلاء ،
- استجابة المعالجة اللاحقة.
هناك نوعان من إدارة API:
1. المعيار الذي يعمل على النحو التالي. قبل الاتصال ، يقوم المستخدم باختبار الميزات ، ثم يقوم بالدفع والتضمين في موقعه. غالبًا ما يتم استخدامها في الشركات الصغيرة والمتوسطة الحجم.
2. إدارة واجهة برمجة تطبيقات B2B الكبيرة ، عندما تتخذ الشركة قرارًا تجاريًا للاتصال لأول مرة ، تصبح شريكًا للشركة مع التزام تعاقدي ، ثم تتصل بواجهة برمجة التطبيقات (API). وبعد تسوية جميع الإجراءات الشكلية ، تحصل الشركة على وصول تجريبي وتجتاز الاختبار وتبدأ الإنتاج. لكن هذا غير ممكن بدون قرار إداري للاتصال.
لدينا الحل
في هذا الجزء ، سنتحدث عن إنشاء بوابة API.
المستخدمون النهائيون لبوابة API التي تم إنشاؤها هم شركاء لعملائنا. لدينا بالفعل العقود اللازمة لكل منهم. سنحتاج فقط إلى توسيع الوظيفة عن طريق تحديد الوصول الممنوح للبوابة. وفقًا لذلك ، يلزم وجود عملية اتصال وإدارة مضبوطة.
بالطبع ، كان من الممكن اتخاذ بعض الحلول الجاهزة لحل مشكلة إدارة API وإنشاء بوابة API على وجه الخصوص. على سبيل المثال ، قد يكون هذا. لم يناسبنا ، لأنه في حالتنا لدينا بالفعل بوابة API ونظام بيئي ضخم مبني حولها. تم تسجيل جميع المستخدمين بالفعل ، لقد فهموا بالفعل أين وكيف يمكنهم الحصول على المعلومات الضرورية. كانت الواجهات الضرورية موجودة بالفعل في بوابة API ، نحتاج فقط إلى بوابة API. في الواقع ، نحن منخرطون في تطويره.
ما نسميه بوابة API هو نوع من الوكيل. هنا مرة أخرى لدينا خيار - يمكنك كتابة الوكيل الخاص بك ، أو يمكنك اختيار شيء جاهز. في هذه الحالة ، ذهبنا في الاتجاه الثاني واخترنا حزمة nginx + Lua. لماذا؟ كنا بحاجة إلى برنامج موثوق ومختبَر يدعم القياس. بعد التنفيذ ، لم نرغب في التحقق من صحة منطق الأعمال وصحة الوكيل.
يحتوي كل خادم ويب على مسار معالجة الطلبات. في حالة nginx ، يبدو الأمر كما يلي:
(رسم تخطيطي من )
كان هدفنا هو التوافق مع خط الأنابيب هذا في نقطة يمكننا فيها تعديل الطلب الأصلي.
نريد إنشاء وكيل شفاف بحيث يظل الطلب وظيفيًا كما جاء. نحن نتحكم فقط في الوصول إلى واجهة برمجة التطبيقات النهائية ، ونساعد الطلب في الوصول إليها. في حالة عدم صحة الطلب ، يجب أن تعرض واجهة برمجة التطبيقات النهائية الخطأ ، ولكن ليس نحن. السبب الوحيد الذي يمكننا من رفض الطلب هو أن العميل ليس لديه حق الوصول.
موجود بالفعل لـ nginx في . Lua هي لغة برمجة نصية وخفيفة الوزن وسهلة التعلم. وبالتالي ، قمنا بتنفيذ المنطق الضروري باستخدام Lua.
تكوين nginx (تشبيهًا لمسار التطبيق) ، حيث يتم تنفيذ كل العمل ، مفهوم تمامًا. الجدير بالذكر هنا هو التوجيه الأخير - post_action.
location /middleware {
more_clear_input_headers Accept-Encoding;
lua_need_request_body on;
rewrite_by_lua_file 'middleware/rewrite.lua';
access_by_lua_file 'middleware/access.lua';
proxy_pass https://someurl.com;
body_filter_by_lua_file 'middleware/body_filter.lua';
post_action /process_session;
}
ضع في اعتبارك ما يحدث في هذا التكوين:
more_clear_input_headers - يمسح قيمة الرؤوس المحددة بعد التوجيه.
lua_need_request_body - يتحكم في ما إذا كان يجب قراءة نص الطلب الأصلي قبل تنفيذ توجيهات إعادة الكتابة / الوصول / access_by_lua أم لا. بشكل افتراضي ، لا يقرأ nginx نص طلب العميل ، وإذا كنت تريد الوصول إليه ، فيجب ضبط هذا التوجيه على on.
Rewrite_by_lua_file - مسار البرنامج النصي الذي يصف منطق تعديل الطلب
Access_by_lua_file - المسار إلى النص ، الذي يصف المنطق الذي يتحقق من الوصول إلى المورد.
proxy_pass - عنوان url الذي سيتم إرسال الطلب إليه بالوكيل.
body_filter_by_lua_file - مسار البرنامج النصي الذي يصف منطق تصفية الطلب قبل إعادته إلى العميل.
وأخيرا، post_action - أمر غير موثق رسميًا يمكنك من خلاله تنفيذ بعض الإجراءات الأخرى بعد الرد على العميل.
بعد ذلك ، سوف نصف بالترتيب كيف حللنا مشاكلنا.
التفويض / المصادقة وطلب التعديل
ترخيص
قمنا ببناء التفويض والمصادقة باستخدام الوصول إلى الشهادة. هناك شهادة الجذر. يتم إنشاء كل عميل جديد للعميل شهادته الشخصية ، والتي يمكنه من خلالها الوصول إلى واجهة برمجة التطبيقات. تم تكوين هذه الشهادة في قسم الخادم لإعدادات nginx.
ssl on;
ssl_certificate /usr/local/openresty/nginx/ssl/cert.pem;
ssl_certificate_key /usr/local/openresty/nginx/ssl/cert.pem;
ssl_client_certificate /usr/local/openresty/nginx/ssl/ca.crt;
ssl_verify_client on;تعديل
قد ينشأ سؤال عادل: ماذا نفعل مع عميل معتمد إذا أردنا فجأة فصله عن النظام؟ لا تقم بإعادة إصدار الشهادات لكافة العملاء الآخرين.
لذلك اقتربنا من المهمة التالية بسلاسة - تعديل الطلب الأصلي. الطلب الأولي للعميل ، بشكل عام ، غير صالح للنظام النهائي. تتمثل إحدى المهام في إضافة الأجزاء المفقودة إلى الطلب لجعله صالحًا. النقطة المهمة هي أن البيانات المفقودة تختلف من عميل لآخر. نعلم أن العميل يأتي إلينا بشهادة يمكننا من خلالها أخذ بصمة واستخراج بيانات العميل الضرورية من قاعدة البيانات.
إذا احتجت في وقت ما إلى فصل العميل عن خدمتنا ، فستختفي بياناته من قاعدة البيانات ولن يكون قادرًا على فعل أي شيء.
العمل مع بيانات العميل
كنا بحاجة إلى جعل الحل متاحًا للغاية ، لا سيما كيفية حصولنا على بيانات العملاء. تكمن الصعوبة في أن المصدر الأساسي لهذه البيانات هو خدمة تابعة لجهة خارجية لا تضمن عدم انقطاع وسرعة عالية بما فيه الكفاية.
لذلك ، احتجنا إلى ضمان التوافر العالي لبيانات العملاء. كأداة ، اخترناها الذي يزودنا بـ:
- الوصول السريع إلى البيانات
- القدرة على تنظيم مجموعة من عدة عقد مع تكرار البيانات على عقد مختلفة.
ذهبنا مع أبسط إستراتيجية لتسليم البيانات إلى ذاكرة التخزين المؤقت:
يتم العمل بنظام النهاية خلال الجلسات وهناك حد أقصى لعدد. إذا لم يقم العميل بإغلاق الجلسة ، فسيتعين علينا القيام بذلك.
تأتي بيانات الجلسة المفتوحة من النظام النهائي وتتم معالجتها مبدئيًا على جانب Lua. قررنا استخدام Hazelcast لتخزين هذه البيانات مع وظيفة .NET. ثم ، في بعض الفترات ، نتحقق من الحق في الحياة للجلسات المفتوحة ونغلق الجلسات الفاسدة.
الوصول إلى Hazelcast من كل من Lua و .NET
لا يوجد عملاء Lua للعمل مع Hazelcast ، ولكن لدى Hazelcast واجهة برمجة تطبيقات REST ، والتي قررنا استخدامها. ل NET هناك ، والتي خططنا من خلالها للوصول إلى بيانات Hazelcast على جانب .NET. لكنها لم تكن هناك.
عند تخزين البيانات عبر REST واسترداد البيانات عبر عميل .NET ، يتم استخدام أجهزة تسلسل مختلفة وأجهزة إزالة التسلسل. لذلك ، من المستحيل وضع البيانات من خلال REST ، ولكن الحصول عليها من خلال عميل .NET والعكس صحيح.
إذا كنت مهتمًا ، فسنخبرك المزيد عن هذه المشكلة في مقال منفصل. المفسد - على التخطيطي.
تسجيل الدخول والرقابة
معيار شركتنا للتسجيل من خلال .NET هو Serilog ، وتنتهي جميع السجلات في Elasticsearch ، ونقوم بتحليلها من خلال Kibana. أود أن أفعل شيئًا مشابهًا في هذه الحالة. الوحيد للعمل مع Elastic على Lua ، الذي تم العثور عليه ، كسر في أول طلب. واستخدمنا فلوينتد.
- حل مفتوح المصدر لتوفير طبقة واحدة لتسجيل التطبيقات. يسمح لك بجمع السجلات من طبقات مختلفة من التطبيق ، ثم بثها في مصدر واحد.
تعمل API Gateway في K8S ، لذلك قررنا إضافة حاوية بطلاقة في نفس الوحدة من أجل كتابة السجلات إلى منفذ tcp الحالي المفتوح بطلاقة.
اكتشفنا أيضًا كيف سيتصرف بطلاقة إذا لم يكن له صلة بـ Elasticsearch. لمدة يومين ، تم إرسال الطلبات باستمرار إلى البوابة ، وتم إرسال السجلات إلى بطلاقة ، ولكن تم حظرها من IP Elastic. بعد استعادة الاتصال ، تفوقت بطلاقة تمامًا على جميع السجلات في Elastic.
اختتام
سمح لنا النهج المختار للتنفيذ بتقديم منتج عملي حقًا لبيئة القتال في غضون 2.5 شهرًا فقط.
إذا حدث لك القيام بمثل هذه الأشياء في أي وقت ، فننصحك أولاً وقبل كل شيء بفهم المشكلة التي تحلها بوضوح وما هي الموارد التي لديك بالفعل. كن على دراية بتعقيدات التكامل مع أنظمة إدارة API الحالية.
افهم بنفسك ما الذي ستقوم بتطويره بالضبط - فقط منطق العمل لمعالجة الطلبات ، أو ، كما يمكن أن يكون في حالتنا ، الوكيل بأكمله. لا تنس أن كل ما تفعله بنفسك يجب أن يتم اختباره بدقة بعد ذلك.
المصدر: www.habr.com
