API ગેટવે બનાવવાનો અમારો અનુભવ

અમારા ગ્રાહક સહિત કેટલીક કંપનીઓ ભાગીદાર નેટવર્ક દ્વારા ઉત્પાદન વિકસાવે છે. ઉદાહરણ તરીકે, મોટા ઑનલાઇન સ્ટોર્સ ડિલિવરી સેવા સાથે સંકલિત છે - તમે ઉત્પાદનનો ઓર્ડર આપો છો અને ટૂંક સમયમાં પેકેજ માટે ટ્રેકિંગ નંબર પ્રાપ્ત કરો છો. બીજું ઉદાહરણ એ છે કે જ્યારે તમે તમારી એર ટિકિટ સાથે વીમો અથવા Aeroexpress ટિકિટ ખરીદો છો.

આ માટે, એક API નો ઉપયોગ કરવામાં આવે છે, જે API ગેટવે દ્વારા ભાગીદારોને જારી કરવી આવશ્યક છે. અમે આ સમસ્યા હલ કરી છે. આ લેખમાં અમે તમને વિગતો જણાવીશું.

આપેલ: એક ઇકોસિસ્ટમ અને ઇન્ટરફેસ સાથેનું API પોર્ટલ જ્યાં વપરાશકર્તાઓ નોંધાયેલા છે, માહિતી મેળવે છે, વગેરે. અમારે અનુકૂળ અને વિશ્વસનીય API ગેટવે બનાવવાની જરૂર છે. પ્રક્રિયામાં, અમારે પ્રદાન કરવાની જરૂર હતી

• નોંધણી,
• API કનેક્શન નિયંત્રણ,
• વપરાશકર્તાઓ અંતિમ સિસ્ટમનો ઉપયોગ કેવી રીતે કરે છે તેનું નિરીક્ષણ કરવું,
• વ્યવસાય સૂચકાંકો માટે એકાઉન્ટિંગ.

લેખમાં આપણે API ગેટવે બનાવવાના અમારા અનુભવ વિશે વાત કરીશું, જે દરમિયાન અમે નીચેના કાર્યોને હલ કર્યા:

• વપરાશકર્તા પ્રમાણીકરણ,
• વપરાશકર્તા અધિકૃતતા,
• મૂળ વિનંતીમાં ફેરફાર,
• પ્રોક્સી કરવાની વિનંતી કરો,
• પ્રતિભાવ પોસ્ટપ્રોસેસિંગ.

API મેનેજમેન્ટના બે પ્રકાર છે:

1. ધોરણ, જે નીચે મુજબ કાર્ય કરે છે. કનેક્ટ કરતા પહેલા, વપરાશકર્તા સુવિધાઓનું પરીક્ષણ કરે છે, પછી ચૂકવણી કરે છે અને તેની સાઇટ પર એમ્બેડ કરે છે. મોટેભાગે તેઓ નાના અને મધ્યમ કદના વ્યવસાયોમાં ઉપયોગમાં લેવાય છે.

2. લાર્જ B2B API મેનેજમેન્ટ, જ્યારે કંપની પ્રથમવાર કનેક્ટ થવાનો વ્યવસાયિક નિર્ણય લે છે, ત્યારે કરારની જવાબદારી સાથે કંપનીની ભાગીદાર બને છે અને પછી API સાથે જોડાય છે. અને તમામ ઔપચારિકતાઓ પતાવટ કર્યા પછી, કંપની પરીક્ષણ ઍક્સેસ મેળવે છે, પરીક્ષણ પાસ કરે છે અને ઉત્પાદનમાં જાય છે. પરંતુ કનેક્ટ કરવાના મેનેજમેન્ટના નિર્ણય વિના આ શક્ય નથી.

અમારો ઉકેલ

આ ભાગમાં, આપણે 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;
}

આ ગોઠવણીમાં શું થાય છે તે ધ્યાનમાં લો:
more_clear_input_headers - નિર્દેશન પછી ઉલ્લેખિત હેડરોની કિંમત સાફ કરે છે.
lua_need_request_body - પુનઃલેખન/એક્સેસ/એક્સેસ_બાય_લુઆ નિર્દેશોને અમલમાં મૂકતા પહેલા મૂળ વિનંતીનો મુખ્ય ભાગ વાંચવો જોઈએ કે નહીં તે નિયંત્રિત કરે છે. ડિફૉલ્ટ રૂપે, nginx ક્લાયંટ વિનંતીના મુખ્ય ભાગને વાંચતું નથી, અને જો તમારે તેને ઍક્સેસ કરવાની જરૂર હોય, તો આ નિર્દેશન ચાલુ પર સેટ કરવું જોઈએ.
lua_file દ્વારા ફરીથી લખો - સ્ક્રિપ્ટનો માર્ગ, જે વિનંતીને સંશોધિત કરવા માટેના તર્કનું વર્ણન કરે છે
access_by_lua_file — સ્ક્રિપ્ટનો પાથ, જે તર્કનું વર્ણન કરે છે જે સંસાધનની ઍક્સેસ માટે તપાસે છે.
proxy_pass — 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 જોબ સાથે આ ડેટા સ્ટોર કરવા માટે હેઝલકાસ્ટનો ઉપયોગ કરવાનું નક્કી કર્યું. પછી, અમુક સમયાંતરે, અમે ખુલ્લા સત્રોના જીવનનો અધિકાર તપાસીએ છીએ અને સડેલાને બંધ કરીએ છીએ.

Lua અને .NET બંનેમાંથી હેઝલકાસ્ટને એક્સેસ કરવું

Hazelcast સાથે કામ કરવા માટે કોઈ લુઆ ક્લાયંટ નથી, પરંતુ Hazelcast પાસે REST API છે, જેનો અમે ઉપયોગ કરવાનું નક્કી કર્યું છે. .NET માટે ત્યાં છે ગ્રાહક, જેના દ્વારા અમે .NET બાજુ પર હેઝલકાસ્ટ ડેટાને ઍક્સેસ કરવાની યોજના બનાવી છે. પરંતુ તે ત્યાં ન હતો.

REST દ્વારા ડેટા સ્ટોર કરતી વખતે અને .NET ક્લાયંટ દ્વારા ડેટા પુનઃપ્રાપ્ત કરતી વખતે, વિવિધ સીરીયલાઇઝર્સ અને ડીસીરીયલાઇઝર્સનો ઉપયોગ કરવામાં આવે છે. તેથી, REST દ્વારા ડેટા મૂકવો અશક્ય છે, પરંતુ તેને .NET ક્લાયંટ દ્વારા મેળવો અને તેનાથી વિપરીત.

જો ત્યાં રસ હોય, તો અમે તમને એક અલગ લેખમાં આ સમસ્યા વિશે વધુ જણાવીશું. સ્પોઇલર - યોજનાકીય પર.

લોગીંગ અને મોનીટરીંગ

.NET દ્વારા લોગીંગ કરવા માટેનું અમારું કોર્પોરેટ સ્ટાન્ડર્ડ સેરીલોગ છે, બધા લોગ્સ Elasticsearch માં સમાપ્ત થાય છે, અને અમે કિબાના દ્વારા તેનું વિશ્લેષણ કરીએ છીએ. હું આ કિસ્સામાં કંઈક આવું જ કરવા માંગુ છું. બસ એકજ ગ્રાહક લુઆ પર સ્થિતિસ્થાપક સાથે કામ કરવા માટે, જે મળી આવ્યું હતું, તે ખૂબ જ પ્રથમ જરૂરિયાત પર તૂટી ગયું હતું. અને અમે Fluentd નો ઉપયોગ કર્યો.

અસ્ખલિત - એપ્લીકેશન લોગીંગનું એક સ્તર પૂરું પાડવા માટે ઓપન સોર્સ સોલ્યુશન. તમને એપ્લિકેશનના વિવિધ સ્તરોમાંથી લોગ એકત્રિત કરવાની અને પછી તેમને એક સ્રોતમાં પ્રસારિત કરવાની મંજૂરી આપે છે.

API ગેટવે K8S માં કામ કરે છે, તેથી અમે હાલના ઓપન tcp પોર્ટ fluentd પર લોગ લખવા માટે સમાન પોડીમાં fluentd સાથે કન્ટેનર ઉમેરવાનું નક્કી કર્યું છે.

અમે એ પણ અન્વેષણ કર્યું કે જો તે Elasticsearch સાથે કોઈ જોડાણ ન હોય તો તે કેવી રીતે અસ્ખલિત વર્તન કરશે. બે દિવસ સુધી, ગેટવે પર વિનંતીઓ સતત મોકલવામાં આવી હતી, લોગ ફ્લુએન્ટને મોકલવામાં આવ્યા હતા, પરંતુ આઈપી ઈલાસ્ટિક દ્વારા ફ્લુએન્ટ પર પ્રતિબંધ મૂકવામાં આવ્યો હતો. કનેક્શન પુનઃસ્થાપિત થયા પછી, fluentd સંપૂર્ણપણે ઇલાસ્ટિકમાંના તમામ લોગને પાછળ છોડી દીધું.

નિષ્કર્ષ

અમલીકરણ માટે પસંદ કરેલ અભિગમ અમને માત્ર 2.5 મહિનામાં લડાઇના વાતાવરણમાં ખરેખર કાર્યકારી ઉત્પાદન પહોંચાડવાની મંજૂરી આપે છે.

જો તમે ક્યારેય આવી વસ્તુઓ કરો છો, તો અમે તમને સૌ પ્રથમ સ્પષ્ટપણે સમજવાની સલાહ આપીએ છીએ કે તમે કઈ સમસ્યા હલ કરી રહ્યા છો અને તમારી પાસે પહેલાથી જ કયા સંસાધનો છે. હાલની API મેનેજમેન્ટ સિસ્ટમ્સ સાથે એકીકૃત થવાની જટિલતાઓથી વાકેફ રહો.

તમારા માટે સમજો કે તમે બરાબર શું વિકસાવવા જઈ રહ્યા છો - વિનંતીઓ પર પ્રક્રિયા કરવા માટે ફક્ત વ્યવસાયિક તર્ક, અથવા, અમારા કિસ્સામાં, સમગ્ર પ્રોક્સી. ભૂલશો નહીં કે તમે જાતે કરો છો તે બધું પછીથી સંપૂર્ણ રીતે પરીક્ષણ કરવું આવશ્યક છે.

સોર્સ: www.habr.com