تقوم بعض الشركات ، بما في ذلك عملائنا ، بتطوير المنتج من خلال شبكة تابعة. على سبيل المثال ، يتم دمج المتاجر الكبيرة عبر الإنترنت مع خدمة التوصيل - يمكنك طلب البضائع وسرعان ما تتلقى رقم تتبع للطرد. مثال آخر - جنبا إلى جنب مع تذكرة سفر ، يمكنك شراء التأمين أو تذكرة Aeroexpress.
لهذا ، يتم استخدام واجهة برمجة تطبيقات واحدة ، والتي يجب إصدارها إلى الشركاء من خلال واجهة برمجة تطبيقات البوابة. لقد حللنا هذه المشكلة. هذه المادة سوف توفر التفاصيل.
المقدمة: النظام البيئي وبوابة واجهة برمجة التطبيقات (API) مع واجهة حيث يتم تسجيل المستخدمين ، وتلقي المعلومات ، إلخ. نحن بحاجة إلى جعل API بوابة مريحة وموثوق بها. في هذه العملية ، كنا بحاجة لتقديم
- تسجيل
- تحكم اتصال API
- مراقبة كيفية استخدام المستخدمين للنظام النهائي
- محاسبة مؤشرات العمل.
في هذه المقالة ، سنتحدث عن تجربتنا في إنشاء واجهة برمجة تطبيقات عبّارة البوابة ، والتي حللنا خلالها المهام التالية:
- مصادقة المستخدم
- إذن المستخدم
- تعديل الطلب الأصلي ،
- طلب وكيل
- بعد معالجة الاستجابة.
هناك نوعان من إدارة API:
1. قياسي ، والذي يعمل على النحو التالي. قبل الاتصال ، يقوم المستخدم باختبار الاحتمالات ، ثم يدفع ويدمج على موقعه. في معظم الأحيان يتم استخدامه في الشركات الصغيرة والمتوسطة الحجم.
2. تصبح إدارة API B2B الكبيرة ، عندما تتخذ الشركة قرارًا تجاريًا حول الاتصال ، شركة شريكة ذات التزام تعاقدي ، ثم تتصل بـ API. وبعد تسوية جميع الإجراءات ، تحصل الشركة على اختبار الوصول ، وتجتاز الاختبار وتذهب إلى المبيعات. لكن هذا غير ممكن بدون قرار الإدارة بالاتصال.
قرارنا
في هذا الجزء ، سنتحدث عن إنشاء واجهة برمجة تطبيقات Gateway.
المستخدمون النهائيون للبوابة التي تم إنشاؤها إلى API هم شركاء عملائنا. لكل منهم ، لدينا بالفعل العقود اللازمة. سنحتاج فقط إلى توسيع الوظيفة ، مع الإشارة إلى الوصول الممنوح إلى البوابة. وفقًا لذلك ، هناك حاجة إلى عملية اتصال ومراقبة محكومة.
بالطبع ، يمكن للمرء أن يأخذ بعض الحلول الجاهزة لحل مهمة إدارة API وإنشاء بوابة API على وجه الخصوص. على سبيل المثال ، يمكن أن يكون
Azure API Management . لم يناسبنا ذلك ، لأنه في حالتنا كان لدينا بالفعل بوابة API ونظام بيئي ضخم تم بناؤه حوله. تم بالفعل تسجيل جميع المستخدمين ، وقد فهموا بالفعل أين وكيف يمكنهم الحصول على المعلومات اللازمة. الواجهات الضرورية موجودة بالفعل في مدخل واجهة برمجة التطبيقات ، نحتاج فقط إلى بوابة API. في الواقع ، بدأنا في تطويره.
ما نسميه بوابة API هو نوع من الوكيل. هنا كان لدينا مرة أخرى خيار - يمكنك كتابة وكيلك ، أو يمكنك اختيار شيء جاهز. في هذه الحالة ، ذهبنا في الاتجاه الثاني واخترنا حزمة nginx + Lua. لماذا؟ كنا بحاجة إلى برنامج موثوق ومختبر يدعم التحجيم. بعد التنفيذ ، لم نرغب في التحقق من صحة منطق العمل وصحة الوكيل.
أي خادم ويب لديه خط أنابيب معالجة الطلب. في حالة nginx ، يبدو كما يلي:
(مخطط من
جيثب لوا إنجنكس )
كان هدفنا هو الاندماج في خط الأنابيب هذا في الوقت الذي يمكننا فيه تعديل الطلب الأصلي.
نريد إنشاء وكيل شفاف حتى يظل الطلب وظيفيًا كما هو. نحن فقط نسيطر على الوصول إلى واجهة برمجة التطبيقات النهائية ، نحن نساعد طلب الوصول إليها. في حالة عدم صحة الطلب ، يجب أن يعرض واجهة برمجة التطبيقات النهائية الخطأ ، ولكن ليس لنا. السبب الوحيد وراء رفضنا للطلب هو عدم توفر إمكانية الوصول إلى العميل.
بالنسبة إلى nginx ، يوجد بالفعل
ملحق في
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 بقراءة نص طلب العميل ، وإذا كنت بحاجة إلى الوصول إليه ، فيجب تعيين هذا التوجيه على.
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;
تعديلقد يطرح سؤال عادل: ماذا تفعل مع عميل معتمد إذا أردنا فجأة فصله عن النظام؟ لا تقم بإعادة إصدار الشهادات لجميع العملاء الآخرين.
لذلك نحن بسلاسة وتناولنا المهمة التالية - تعديل الطلب الأصلي. طلب العميل الأصلي ، بشكل عام ، غير صالح للنظام النهائي. تتمثل إحدى المهام في إضافة الأجزاء المفقودة إلى الطلب لجعلها صالحة. النقطة المهمة هي أن البيانات المفقودة مختلفة لكل عميل. نعلم أن العميل يأتي إلينا بشهادة يمكننا من خلالها أخذ بصمة واستخراج بيانات العميل الضرورية من قاعدة البيانات.
إذا كنت تحتاج في مرحلة ما إلى فصل العميل عن خدمتنا ، فستختفي بياناته من قاعدة البيانات ولن يتمكن من فعل أي شيء.
العمل مع بيانات العملاء
نحن بحاجة إلى ضمان توفر عالية للحل ، وخاصة كيفية الحصول على بيانات العملاء. تكمن الصعوبة في أن مصدر هذه البيانات هو خدمة تابعة لجهة خارجية لا تضمن سرعة عالية وغير منقطعة إلى حد ما.
لذلك ، نحتاج إلى ضمان توفر بيانات العملاء بشكل كبير. كأداة ، اخترنا
Hazelcast ، الذي يوفر لنا:
- الوصول السريع إلى البيانات
- القدرة على تنظيم مجموعة من عدة عقد مع بيانات منسوخة على عقد مختلفة.
لقد ذهبنا لأبسط استراتيجية لتسليم ذاكرة التخزين المؤقت:
يحدث العمل مع النظام النهائي في إطار الجلسات وهناك حد أقصى لعدد. إذا لم يغلق العميل الجلسة ، فسيتعين علينا القيام بذلك.
تأتي بيانات الجلسة المفتوحة من النظام المستهدف وتتم معالجتها في البداية على جانب Lua. قررنا استخدام Hazelcast لحفظ هذه البيانات مع كاتب .NET. ثم ، في بعض الفواصل الزمنية ، نتحقق من الحق في الحياة لجلسات مفتوحة ونغلق الخطأ.
الوصول إلى Hazelcast من Lua و .NET
لا يوجد عملاء على Lua للعمل مع Hazelcast ، ولكن Hazelcast لديه واجهة برمجة تطبيقات REST ، والتي قررنا استخدامها. بالنسبة إلى .NET ، يوجد
عميل نخطط من خلاله للوصول إلى بيانات Hazelcast على جانب .NET. ولكن كان هناك.
عند حفظ البيانات عبر REST والاسترداد من خلال عميل .NET ، يتم استخدام أدوات تسلسل / deserializers مختلفة. لذلك ، من المستحيل وضع البيانات من خلال REST ، ولكن من خلال الوصول إلى عميل .NET والعكس.
إذا كنت مهتمًا ، سنتحدث أكثر عن هذه المشكلة في مقالة منفصلة. المفسد - على shemka.
تسجيل ومراقبة
معيار الشركة الخاص بنا لتسجيل الدخول عبر .NET هو Serilog ، جميع السجلات تنتهي في Elasticsearch ، ونحن نحللها من خلال Kibana. كنت أرغب في القيام بشيء مماثل في هذه الحالة.
العميل الوحيد الذي يعمل مع Elastic on Lua الذي تم العثور عليه قد تم كسره عند الطلب الأول. واستخدمنا Fluentd.
Fluentd هو حل مفتوح المصدر لتوفير طبقة تسجيل تطبيق واحد. يسمح لك بجمع السجلات من طبقات مختلفة من التطبيق ، ومن ثم ترجمتها إلى مصدر واحد.
تعمل بوابة API في K8S ، لذلك قررنا إضافة الحاوية مع fluentd إلى نفس النوع الفرعي لكتابة سجلات إلى منفذ tcp open الحالي الموجود.
درسنا أيضًا كيف سيتصرف fluentd إذا لم يكن له أي صلة بـ Elasticsearch. لمدة يومين ، تم إرسال الطلبات بشكل مستمر إلى البوابة ، تم إرسال السجلات إلى fluentd ، ولكن تم حظر IP Elastic من fluentd. بعد إعادة الاتصال ، تجاوزت fluentd تماما جميع السجلات في مطاطا.
استنتاج
لقد سمح لنا النهج المختار للتنفيذ بتقديم منتج فعال حقًا إلى البيئة القتالية في 2.5 شهر فقط.
إذا صادفتك فعل مثل هذه الأشياء ، فننصحك أولاً أن تفهم بوضوح المشكلة التي تحلها وأي الموارد الموجودة لديك بالفعل. كن على دراية بتعقيدات التكامل مع أنظمة إدارة API الموجودة.
افهم بنفسك ما ستقوم بتطويره بالضبط - فقط منطق العمل الخاص بمعالجة الطلبات ، أو كما هو الحال في حالتنا ، الوكيل بالكامل. تذكر أن كل ما تفعله بنفسك يجب اختباره بدقة بعد ذلك.