API গেটওয়ে তৈরিতে আমাদের অভিজ্ঞতা

আমাদের গ্রাহক সহ কিছু কোম্পানি একটি অংশীদার নেটওয়ার্কের মাধ্যমে পণ্য বিকাশ করে। উদাহরণস্বরূপ, বড় অনলাইন স্টোরগুলি ডেলিভারি পরিষেবার সাথে একত্রিত হয় - আপনি একটি পণ্য অর্ডার করেন এবং শীঘ্রই প্যাকেজের জন্য একটি ট্র্যাকিং নম্বর পান। আরেকটি উদাহরণ হল যখন আপনি আপনার এয়ার টিকিটের সাথে বীমা বা Aeroexpress টিকেট কিনবেন।

এর জন্য, একটি API ব্যবহার করা হয়, যা অবশ্যই API গেটওয়ের মাধ্যমে অংশীদারদের কাছে জারি করতে হবে। আমরা এই সমস্যার সমাধান করেছি। এই নিবন্ধে আমরা আপনাকে বিস্তারিত বলব।

দেওয়া হয়েছে: একটি ইকোসিস্টেম এবং একটি ইন্টারফেস সহ একটি API পোর্টাল যেখানে ব্যবহারকারীরা নিবন্ধিত, তথ্য গ্রহণ করে ইত্যাদি। আমাদের একটি সুবিধাজনক এবং নির্ভরযোগ্য API গেটওয়ে তৈরি করতে হবে। প্রক্রিয়ায়, আমাদের সরবরাহ করতে হবে

• নিবন্ধন,
• API সংযোগ নিয়ন্ত্রণ,
• ব্যবহারকারীরা কীভাবে শেষ সিস্টেম ব্যবহার করে তা পর্যবেক্ষণ করা,
• ব্যবসা সূচক জন্য অ্যাকাউন্টিং.

নিবন্ধে আমরা API গেটওয়ে তৈরির আমাদের অভিজ্ঞতা সম্পর্কে কথা বলব, যার সময় আমরা নিম্নলিখিত কাজগুলি সমাধান করেছি:

• ব্যবহারকারী প্রমাণীকরণ,
• ব্যবহারকারীর অনুমোদন,
• মূল অনুরোধের পরিবর্তন,
• প্রক্সি করার অনুরোধ,
• প্রতিক্রিয়া পোস্টপ্রসেসিং।

এপিআই ব্যবস্থাপনা দুই ধরনের আছে:

1. স্ট্যান্ডার্ড, যা নিম্নরূপ কাজ করে। সংযোগ করার আগে, ব্যবহারকারী বৈশিষ্ট্য পরীক্ষা করে, তারপর অর্থ প্রদান করে এবং তার সাইটে এম্বেড করে। প্রায়শই এগুলি ছোট এবং মাঝারি আকারের ব্যবসায় ব্যবহৃত হয়।

2. বড় B2B API ম্যানেজমেন্ট, যখন কোম্পানী প্রথমে সংযোগ করার জন্য একটি ব্যবসায়িক সিদ্ধান্ত নেয়, তখন একটি চুক্তিভিত্তিক বাধ্যবাধকতা সহ কোম্পানির অংশীদার হয়, এবং তারপর API এর সাথে সংযোগ করে। এবং সমস্ত আনুষ্ঠানিকতা স্থির হওয়ার পরে, সংস্থাটি পরীক্ষার অ্যাক্সেস পায়, পরীক্ষায় উত্তীর্ণ হয় এবং উত্পাদনে যায়। কিন্তু এটি সংযোগ করার জন্য একটি ব্যবস্থাপনা সিদ্ধান্ত ছাড়া সম্ভব নয়.

আমাদের সমাধান

এই অংশে, আমরা একটি API গেটওয়ে তৈরি করার বিষয়ে কথা বলব।

তৈরি API গেটওয়ের শেষ ব্যবহারকারীরা আমাদের গ্রাহকের অংশীদার। আমরা ইতিমধ্যে তাদের প্রতিটি জন্য প্রয়োজনীয় চুক্তি আছে. আমাদের শুধুমাত্র গেটওয়েতে অনুমোদিত অ্যাক্সেস চিহ্নিত করে কার্যকারিতা প্রসারিত করতে হবে। তদনুসারে, একটি নিয়ন্ত্রিত সংযোগ এবং ব্যবস্থাপনা প্রক্রিয়া প্রয়োজন।

অবশ্যই, এপিআই ম্যানেজমেন্টের সমস্যা সমাধানের জন্য এবং বিশেষ করে একটি এপিআই গেটওয়ে তৈরির জন্য কিছু রেডিমেড সমাধান নেওয়া সম্ভব ছিল। উদাহরণস্বরূপ, এটি হতে পারে Azure API ব্যবস্থাপনা. এটি আমাদের জন্য উপযুক্ত ছিল না, কারণ আমাদের ক্ষেত্রে ইতিমধ্যেই একটি API পোর্টাল এবং এটির চারপাশে একটি বিশাল ইকোসিস্টেম তৈরি করা হয়েছে। সমস্ত ব্যবহারকারী ইতিমধ্যে নিবন্ধিত হয়েছে, তারা ইতিমধ্যে বুঝতে পেরেছে যে তারা কোথায় এবং কীভাবে প্রয়োজনীয় তথ্য পেতে পারে। প্রয়োজনীয় ইন্টারফেসগুলি ইতিমধ্যেই API পোর্টালে বিদ্যমান, আমাদের শুধুমাত্র API গেটওয়ে প্রয়োজন। আসলে, আমরা এর উন্নয়নে নিযুক্ত আছি।

আমরা যাকে API গেটওয়ে বলি তা হল এক ধরনের প্রক্সি। এখানে আমাদের আবার একটি পছন্দ ছিল - আপনি নিজের প্রক্সি লিখতে পারেন, বা আপনি তৈরি কিছু চয়ন করতে পারেন। এই ক্ষেত্রে, আমরা দ্বিতীয় উপায়ে গিয়েছি এবং nginx + Lua বান্ডিলটি বেছে নিয়েছি। কেন? আমাদের নির্ভরযোগ্য, পরীক্ষিত সফ্টওয়্যার প্রয়োজন যা স্কেলিং সমর্থন করে। বাস্তবায়নের পরে, আমরা ব্যবসায়িক যুক্তির সঠিকতা এবং প্রক্সির সঠিকতা উভয়ই পরীক্ষা করতে চাইনি।

প্রতিটি ওয়েব সার্ভারের একটি অনুরোধ প্রক্রিয়াকরণ পাইপলাইন আছে। Nginx এর ক্ষেত্রে, এটি এই মত দেখায়:

(থেকে চিত্র GitHub Lua Nginx)

আমাদের লক্ষ্য ছিল এই পাইপলাইনে এমন একটি স্থানে ফিট করা যেখানে আমরা মূল অনুরোধটি সংশোধন করতে পারি।

আমরা একটি স্বচ্ছ প্রক্সি তৈরি করতে চাই যাতে অনুরোধটি যেমনটি এসেছে তেমনই কার্যকরীভাবে থাকে। আমরা শুধুমাত্র চূড়ান্ত API-এ অ্যাক্সেস নিয়ন্ত্রণ করি, অনুরোধটিকে এটি পেতে সহায়তা করি। অনুরোধটি ভুল হলে, চূড়ান্ত API-এর ত্রুটি দেখাতে হবে, কিন্তু আমাদের নয়। আমরা একটি অনুরোধ অস্বীকার করতে পারি একমাত্র কারণ হল ক্লায়েন্টের অ্যাক্সেস নেই।

nginx এর জন্য ইতিমধ্যেই বিদ্যমান প্রসার উপর গ্রহণ করা. লুয়া একটি স্ক্রিপ্টিং ভাষা, এটি খুব হালকা এবং শেখা সহজ। এইভাবে, আমরা লুয়া ব্যবহার করে প্রয়োজনীয় যুক্তি প্রয়োগ করেছি।

nginx কনফিগারেশন (অ্যাপ্লিকেশনের রুটের একটি সাদৃশ্য), যেখানে সমস্ত কাজ করা হয়, বেশ বোধগম্য। এখানে উল্লেখযোগ্য হল শেষ নির্দেশনা - পোস্ট_অ্যাকশন।

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;
}

এই কনফিগারেশনে কি ঘটবে তা বিবেচনা করুন:
আরও_ক্লিয়ার_ইনপুট_হেডার - নির্দেশের পরে নির্দিষ্ট শিরোনামগুলির মান পরিষ্কার করে।
lua_need_request_body - পুনঃলিখন/অ্যাক্সেস/অ্যাক্সেস_বাই_লুয়া নির্দেশাবলী কার্যকর করার আগে মূল অনুরোধের অংশটি পড়া উচিত কিনা তা নিয়ন্ত্রণ করে। ডিফল্টরূপে, nginx একটি ক্লায়েন্ট অনুরোধের মূল অংশটি পড়ে না এবং আপনার যদি এটি অ্যাক্সেস করার প্রয়োজন হয়, তাহলে এই নির্দেশটি চালু করা উচিত।
rewrite_by_lua_file - স্ক্রিপ্টের পথ, যা অনুরোধ সংশোধন করার যুক্তি বর্ণনা করে
অ্যাক্সেস_বাই_লুয়া_ফাইল — স্ক্রিপ্টের পথ, যা যুক্তির বর্ণনা দেয় যা সম্পদের অ্যাক্সেসের জন্য পরীক্ষা করে।
প্রক্সি_পাস — url যেখানে অনুরোধ প্রক্সি করা হবে।
body_filter_by_lua_file — স্ক্রিপ্টের পথ, যা ক্লায়েন্টকে ফেরত দেওয়ার আগে অনুরোধটি ফিল্টার করার যুক্তি বর্ণনা করে।
এবং অবশেষে পোস্ট_অ্যাকশন - একটি আনুষ্ঠানিকভাবে অনথিভুক্ত নির্দেশিকা যার সাহায্যে আপনি ক্লায়েন্টকে প্রতিক্রিয়া দেওয়ার পরে কিছু অন্যান্য ক্রিয়া সম্পাদন করতে পারেন।

এর পরে, আমরা কীভাবে আমাদের সমস্যাগুলি সমাধান করেছি তা বর্ণনা করব।

অনুমোদন/প্রমাণিকরণ এবং সংশোধনের অনুরোধ

অনুমোদন

আমরা শংসাপত্র অ্যাক্সেস ব্যবহার করে অনুমোদন এবং প্রমাণীকরণ তৈরি করেছি। একটি রুট সার্টিফিকেট আছে. গ্রাহকের প্রতিটি নতুন ক্লায়েন্টের জন্য, তার ব্যক্তিগত শংসাপত্র তৈরি করা হয়, যার সাহায্যে তিনি API অ্যাক্সেস করতে পারেন। এই শংসাপত্রটি 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;

অদলবদল

একটি ন্যায্য প্রশ্ন উঠতে পারে: একটি প্রত্যয়িত ক্লায়েন্টের সাথে কী করবেন যদি আমরা হঠাৎ সিস্টেম থেকে এটি সংযোগ বিচ্ছিন্ন করতে চাই? অন্য সব ক্লায়েন্টদের জন্য সার্টিফিকেট পুনরায় জারি করবেন না।

তাই আমরা মসৃণভাবে পরবর্তী টাস্কের কাছে চলে এসেছি - মূল অনুরোধটি পরিবর্তন করে। ক্লায়েন্টের প্রাথমিক অনুরোধ, সাধারণত বলতে গেলে, চূড়ান্ত সিস্টেমের জন্য বৈধ নয়। একটি কাজ হল অনুপস্থিত অংশগুলিকে বৈধ করার অনুরোধে যোগ করা। পয়েন্ট হল যে অনুপস্থিত ডেটা প্রতিটি ক্লায়েন্টের জন্য আলাদা। আমরা জানি যে একজন ক্লায়েন্ট আমাদের কাছে একটি শংসাপত্র নিয়ে আসে যেখান থেকে আমরা একটি আঙ্গুলের ছাপ নিতে পারি এবং ডেটাবেস থেকে প্রয়োজনীয় ক্লায়েন্ট ডেটা বের করতে পারি।

যদি কোনও সময়ে আপনার ক্লায়েন্টকে আমাদের পরিষেবা থেকে সংযোগ বিচ্ছিন্ন করতে হয়, তার ডেটা ডাটাবেস থেকে অদৃশ্য হয়ে যাবে এবং তিনি কিছুই করতে পারবেন না।

গ্রাহক ডেটা নিয়ে কাজ করা

আমাদের সমাধানটি অত্যন্ত উপলব্ধ করা দরকার, বিশেষ করে আমরা কীভাবে গ্রাহক ডেটা পাই। অসুবিধা হল এই ডেটার প্রাথমিক উৎস হল একটি তৃতীয় পক্ষের পরিষেবা যা নিরবচ্ছিন্ন এবং পর্যাপ্ত উচ্চ গতির গ্যারান্টি দেয় না।

অতএব, আমাদের গ্রাহক ডেটার উচ্চ প্রাপ্যতা নিশ্চিত করতে হবে। একটি হাতিয়ার হিসাবে, আমরা নির্বাচন করেছি হ্যাজেলকাস্টযা আমাদের প্রদান করে:

• ডেটাতে দ্রুত অ্যাক্সেস
• বিভিন্ন নোডের প্রতিলিপিকৃত ডেটা সহ বেশ কয়েকটি নোডের একটি ক্লাস্টার সংগঠিত করার ক্ষমতা।

আমরা ক্যাশে ডেটা সরবরাহের জন্য সবচেয়ে সহজ কৌশল নিয়ে গিয়েছিলাম:

শেষ সিস্টেমের সাথে কাজ সেশনের মধ্যে সঞ্চালিত হয় এবং সর্বাধিক সংখ্যার একটি সীমা রয়েছে। যদি ক্লায়েন্ট সেশন বন্ধ না করে থাকে তবে আমাদের এটি করতে হবে।

খোলা সেশনের ডেটা শেষ সিস্টেম থেকে আসে এবং প্রাথমিকভাবে লুয়ার দিকে প্রক্রিয়া করা হয়। আমরা একটি .NET কাজের সাথে এই ডেটা সংরক্ষণ করতে Hazelcast ব্যবহার করার সিদ্ধান্ত নিয়েছি। তারপর, কিছু ব্যবধানে, আমরা খোলা সেশনের জীবনের অধিকার পরীক্ষা করি এবং পচাগুলি বন্ধ করি।

Lua এবং .NET উভয় থেকে Hazelcast অ্যাক্সেস করা

Hazelcast এর সাথে কাজ করার জন্য কোন Lua ক্লায়েন্ট নেই, কিন্তু Hazelcast এর একটি REST API আছে, যা আমরা ব্যবহার করার সিদ্ধান্ত নিয়েছি। .NET এর জন্য আছে ক্লায়েন্ট, যার মাধ্যমে আমরা .NET সাইডে হ্যাজেলকাস্ট ডেটা অ্যাক্সেস করার পরিকল্পনা করেছি। কিন্তু সেখানে ছিল না।

REST এর মাধ্যমে ডেটা সংরক্ষণ করার সময় এবং .NET ক্লায়েন্টের মাধ্যমে ডেটা পুনরুদ্ধার করার সময়, বিভিন্ন সিরিয়ালাইজার এবং ডিসিরিয়ালাইজার ব্যবহার করা হয়। অতএব, REST-এর মাধ্যমে ডেটা রাখা অসম্ভব, কিন্তু .NET ক্লায়েন্টের মাধ্যমে এবং তদ্বিপরীত।

যদি আগ্রহী হন, আমরা আপনাকে একটি পৃথক নিবন্ধে এই সমস্যা সম্পর্কে আরও বলব। স্পয়লার - পরিকল্পিত উপর।

লগিং এবং পর্যবেক্ষণ

.NET-এর মাধ্যমে লগিং করার জন্য আমাদের কর্পোরেট স্ট্যান্ডার্ড হল Serilog, সমস্ত লগ ইলাস্টিকসার্চে শেষ হয় এবং আমরা কিবানার মাধ্যমে সেগুলি বিশ্লেষণ করি। আমি এই ক্ষেত্রে অনুরূপ কিছু করতে চাই. একমাত্র ক্লায়েন্ট লুয়াতে ইলাস্টিকের সাথে কাজ করার জন্য, যা পাওয়া গেছে, প্রথম প্রয়োজনে ভেঙে গেছে। এবং আমরা Fluentd ব্যবহার করেছি।

সাবলীল - অ্যাপ্লিকেশন লগিংয়ের একক স্তর প্রদানের জন্য ওপেন সোর্স সমাধান। আপনাকে অ্যাপ্লিকেশানের বিভিন্ন স্তর থেকে লগ সংগ্রহ করতে এবং তারপর একটি একক উত্সে সম্প্রচার করতে দেয়৷

API গেটওয়ে K8S-এ কাজ করে, তাই আমরা বিদ্যমান খোলা tcp পোর্ট fluentd-এ লগ লেখার জন্য একই পডিতে fluentd সহ একটি কন্টেইনার যোগ করার সিদ্ধান্ত নিয়েছি।

ইলাস্টিকসার্চের সাথে কোন সংযোগ না থাকলে কীভাবে সাবলীল আচরণ করবে তাও আমরা অনুসন্ধান করেছি। দুই দিনের জন্য, গেটওয়েতে ক্রমাগত অনুরোধ পাঠানো হয়েছিল, লগগুলি সাবলীলভাবে পাঠানো হয়েছিল, কিন্তু ইলাস্টিক আইপিকে সাবলীল থেকে নিষিদ্ধ করা হয়েছিল। সংযোগ পুনরুদ্ধার করার পরে, fluentd পুরোপুরি ইলাস্টিকের সমস্ত লগকে ছাড়িয়ে গেছে।

উপসংহার

বাস্তবায়নের জন্য নির্বাচিত পদ্ধতিটি আমাদেরকে মাত্র 2.5 মাসে যুদ্ধের পরিবেশে একটি সত্যিকারের কার্যকর পণ্য সরবরাহ করতে দেয়।

যদি কোনো দিন আপনি এই ধরনের কাজ করে থাকেন, আমরা আপনাকে প্রথমেই পরিষ্কারভাবে বুঝতে পরামর্শ দিই যে আপনি কোন সমস্যাটি সমাধান করছেন এবং আপনার কাছে ইতিমধ্যেই কোন সম্পদ রয়েছে। বিদ্যমান API ম্যানেজমেন্ট সিস্টেমের সাথে একীভূত হওয়ার জটিলতা সম্পর্কে সচেতন হন।

আপনি ঠিক কী বিকাশ করতে যাচ্ছেন তা নিজের জন্য বুঝুন - অনুরোধগুলি প্রক্রিয়া করার জন্য শুধুমাত্র ব্যবসায়িক যুক্তি, বা, যেমনটি আমাদের ক্ষেত্রে হতে পারে, সম্পূর্ণ প্রক্সি। ভুলে যাবেন না যে আপনি নিজে যা কিছু করেন তার পরে অবশ্যই পুঙ্খানুপুঙ্খভাবে পরীক্ষা করতে হবে।

উত্স: www.habr.com