අපගේ පාරිභෝගිකයා ඇතුළු සමහර සමාගම් අනුබද්ධ ජාලයක් හරහා නිෂ්පාදනය දියුණු කරයි. උදාහරණයක් ලෙස, විශාල අන්තර්ජාල වෙළඳසැල් බෙදා හැරීමේ සේවාවක් සමඟ ඒකාබද්ධ කර ඇත - ඔබ නිෂ්පාදනයක් ඇණවුම් කර ඉක්මනින් පාර්සලය ලුහුබැඳීමේ අංකයක් ලබා ගනී. තවත් උදාහරණයක් නම් ඔබ ගුවන් ටිකට් පතක් සමඟ රක්ෂණයක් හෝ Aeroexpress ටිකට් පතක් මිලදී ගැනීමයි.
මෙය සිදු කිරීම සඳහා, එක් API භාවිතා කරනු ලැබේ, එය API Gateway හරහා හවුල්කරුවන්ට නිකුත් කළ යුතුය. අපි මේ ගැටලුව විසඳුවා. මෙම ලිපියෙන් අපි ඔබට විස්තර කියන්නෙමු.
ලබා දී ඇත: පරිසර පද්ධතියක් සහ පරිශීලකයින් ලියාපදිංචි වන, තොරතුරු ලබා ගන්නා අතුරු මුහුණතක් සහිත API ද්වාරයක්. අපට පහසු සහ විශ්වාසදායක API ද්වාරයක් සෑදිය යුතුය. ක්රියාවලිය තුළ අපි සහතික කිරීමට අවශ්ය විය
- ලියාපදිංචි කිරීම,
- API සම්බන්ධතා පාලනය,
- පරිශීලකයන් අවසාන පද්ධතිය භාවිතා කරන ආකාරය නිරීක්ෂණය කිරීම,
- ව්යාපාර දර්ශක ගිණුම්කරණය.
මෙම ලිපියෙන් අපි API Gateway නිර්මාණය කිරීමේ අපගේ අත්දැකීම් ගැන කතා කරමු, එම කාලය තුළ අපි පහත සඳහන් ගැටළු විසඳා ඇත:
- පරිශීලක සත්යාපනය,
- පරිශීලක අවසරය,
- මුල් ඉල්ලීම වෙනස් කිරීම,
- ඉල්ලීම ප්රොක්සි කිරීම,
- ප්රතිචාරය පසු සැකසීම.
API කළමනාකරණය වර්ග දෙකක් තිබේ:
1. පහත පරිදි ක්රියා කරන සම්මතය. සම්බන්ධ වීමට පෙර, පරිශීලකයා හැකියාවන් පරීක්ෂා කරයි, පසුව එය ගෙවා ඔහුගේ වෙබ් අඩවියේ තැන්පත් කරයි. බොහෝ විට එය කුඩා හා මධ්යම ප්රමාණයේ ව්යාපාරවල භාවිතා වේ.
2. විශාල B2B API කළමනාකරණය, සමාගම මුලින්ම සම්බන්ධ වීමට ව්යාපාරික තීරණයක් ගන්නා විට, ගිවිසුම්ගත බැඳීමක් ඇති සමාගමේ හවුල්කරුවෙකු බවට පත් වන අතර, පසුව API වෙත සම්බන්ධ වේ. සියලුම විධිවිධාන නිරාකරණය කිරීමෙන් පසුව, සමාගමට පරීක්ෂණ ප්රවේශය ලැබේ, පරීක්ෂණ වලට භාජනය වී නිෂ්පාදනයට යයි. නමුත් සම්බන්ධතාවය පිළිබඳ කළමනාකරණ තීරණයකින් තොරව මෙය කළ නොහැකිය.
අපගේ විසඳුම
මෙම කොටසින් අපි API Gateway එකක් නිර්මාණය කිරීම ගැන කතා කරමු.
නිර්මාණය වෙමින් පවතින API ද්වාරයෙහි අවසාන පරිශීලකයින් අපගේ පාරිභෝගිකයාගේ හවුල්කරුවන් වේ. ඔවුන් එක් එක් සඳහා, අපි දැනටමත් අවශ්ය ගිවිසුම් ගබඩා කර ඇත. අපට අවශ්ය වනුයේ ගේට්වේ වෙත ලබා දී ඇති ප්රවේශය සලකුණු කිරීමෙන් පමණක් ක්රියාකාරීත්වය දීර්ඝ කිරීමයි. ඒ අනුව, පාලිත සම්බන්ධතාවයක් සහ කළමනාකරණ ක්රියාවලියක් අවශ්ය වේ.
ඇත්ත වශයෙන්ම, API කළමනාකරණය පිළිබඳ ගැටළුව විසඳීමට සහ විශේෂයෙන් API Gateway එකක් නිර්මාණය කිරීමට සූදානම් කළ විසඳුමක් ලබා ගැනීමට හැකි විය. උදාහරණයක් ලෙස, මෙය විය හැකිය. එය අපට ගැලපෙන්නේ නැත, මන්ද අපගේ නඩුවේ දැනටමත් API ද්වාරයක් සහ එය වටා විශාල පරිසර පද්ධතියක් ගොඩනගා ඇත. සියලුම පරිශීලකයින් දැනටමත් ලියාපදිංචි වී ඇත, ඔවුන් දැනටමත් අවශ්ය තොරතුරු ලබා ගත හැක්කේ කොහෙන්ද සහ කෙසේද යන්න තේරුම් ගෙන ඇත. අවශ්ය අතුරුමුහුණත් දැනටමත් API ද්වාරයෙහි පවතී; අපට අවශ්ය වූයේ API ද්වාරයක් පමණි. ඇත්ත වශයෙන්ම, අපි එය සංවර්ධනය කිරීමට පටන් ගත්තා.
අපි API Gateway ලෙස හඳුන්වන්නේ ප්රොක්සි වර්ගයකි. මෙන්න නැවතත් අපට තේරීමක් තිබුණි - ඔබට ඔබේම ප්රොක්සියක් ලිවිය හැකිය, නැතහොත් ඔබට සූදානම් කළ දෙයක් තෝරා ගත හැකිය. මෙම අවස්ථාවේදී, අපි දෙවන මාර්ගය ගෙන nginx + Lua සංයෝජනය තෝරා ගත්තෙමු. ඇයි? අපට පරිමාණය කළ හැකි විශ්වාසදායක, පරීක්ෂා කළ මෘදුකාංග අවශ්ය විය. ක්රියාත්මක කිරීමෙන් පසු ව්යාපාර තර්කනයේ නිවැරදිභාවය සහ ප්රොක්සියේ නිවැරදි ක්රියාකාරිත්වය යන දෙකම පරීක්ෂා කිරීමට අපට අවශ්ය නොවීය.
ඕනෑම වෙබ් සේවාදායකයකට ඉල්ලීම් සැකසීමේ නල මාර්ගයක් ඇත. nginx සම්බන්ධයෙන් ගත් කල, එය මේ ආකාරයෙන් පෙනේ:
(රූප සටහන )
අපගේ ඉලක්කය වූයේ අපට මුල් ඉල්ලීම වෙනස් කළ හැකි ස්ථානයක මෙම නල මාර්ගයට ඇතුල් වීමයි.
ක්රියාකාරීව ඉල්ලීම පැමිණි ආකාරයටම පවතින පරිදි විනිවිද පෙනෙන ප්රොක්සියක් සෑදීමට අපට අවශ්යය. අපි අවසාන API වෙත ප්රවේශය පමණක් පාලනය කරන අතර ඉල්ලීමට එය ලබා ගැනීමට උදවු කරන්නෙමු. ඉල්ලීම වැරදි නම්, අවසාන API දෝෂය පෙන්විය යුතුය, නමුත් අප නොවේ. අපට ඉල්ලීමක් ප්රතික්ෂේප කළ හැකි එකම හේතුව සේවාදායකයාට ප්රවේශය නොමැති වීමයි.
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;
}
මෙම වින්යාසය තුළ සිදුවන්නේ කුමක්දැයි බලමු:
තවත්_පැහැදිලි_ආදාන_ශීර්ෂක - නියෝගයෙන් පසුව සඳහන් කර ඇති ශීර්ෂවල අගය හිස් කරයි.
lua_deed_request_body - rewrite/access/access_by_lua විධානයන් ක්රියාත්මක කිරීමට පෙර මුල් ඉල්ලීම් අන්තර්ගතය කියවිය යුතුද නැද්ද යන්න පාලනය කරයි. පෙරනිමියෙන්, nginx සේවාලාභී ඉල්ලීම් ශරීරය කියවන්නේ නැත, ඔබට එයට ප්රවේශ වීමට අවශ්ය නම්, මෙම විධානය ක්රියාත්මක කළ යුතුය.
නැවත ලියන්න_lua_file - ඉල්ලීම වෙනස් කිරීම සඳහා තර්කනය විස්තර කරන ස්ක්රිප්ට් වෙත මාර්ගය
ප්රවේශ_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 හි ලියා ඇති කාර්යයක් සමඟ මෙම දත්ත සුරැකීමට Hazelcast භාවිතා කිරීමට අපි තීරණය කළෙමු. ඉන්පසුව, යම් සංඛ්යාතයකින්, අපි විවෘත සැසිවල ජීවත්වීමේ අයිතිය පරීක්ෂා කර කුණු වූ ඒවා වසා දමමු.
Lua සහ .NET දෙකෙන්ම Hazelcast වෙත පිවිසෙන්න
Hazelcast සමඟ වැඩ කිරීමට Lua සේවාදායකයින් නැත, නමුත් Hazelcast සතුව REST API එකක් ඇත, එය අප භාවිතා කිරීමට තීරණය කර ඇත. .NET සඳහා ඇත , ඒ හරහා අපි .NET පැත්තේ Hazelcast දත්ත වෙත ප්රවේශ වීමට සැලසුම් කළා. නමුත් එය එහි නොවීය.
REST හරහා දත්ත ගබඩා කිරීමේදී සහ .NET සේවාලාභියෙකු හරහා එය ලබා ගැනීමේදී, විවිධ serializers සහ deserializers භාවිතා වේ. එබැවින්, REST හරහා දත්ත දමා .NET සේවාලාභියා හරහා සහ අනෙක් අතට දත්ත ලබා ගැනීම කළ නොහැක.
යමෙකු උනන්දුවක් දක්වන්නේ නම්, අපි මෙම ගැටළුව ගැන වැඩි විස්තර වෙනම ලිපියකින් ඔබට කියන්නෙමු. ස්පොයිලර් - රූප සටහනේ.
ලොග් කිරීම සහ අධීක්ෂණය
.NET හරහා ලොග් වීම සඳහා අපගේ ආයතනික ප්රමිතිය Serilog වේ, සියලුම ලොග අවසානයේ Elasticsearch වලින් අවසන් වන අතර අපි ඒවා Kibana හරහා විශ්ලේෂණය කරමු. මට මේ නඩුවේදී ඒ හා සමාන දෙයක් කිරීමට අවශ්ය විය. එකම එක ලුවා හි ඉලාස්ටික් සමඟ වැඩ කිරීම සඳහා, සොයා ගන්නා ලද, පළමු අවශ්යතාවයේදීම කැඩී ගියේය. ඒ වගේම අපි Fluentd පාවිච්චි කළා.
- යෙදුම් ලොග් කිරීමේ තනි ස්ථරයක් සැපයීම සඳහා විවෘත මූලාශ්ර විසඳුමක්. යෙදුමේ විවිධ ස්ථර වලින් ලඝු-සටහන් එකතු කිරීමට ඔබට ඉඩ සලසයි, ඉන්පසු ඒවා තනි මූලාශ්රයකට විකාශනය කරන්න.
API Gateway K8S හි ක්රියාත්මක වේ, එබැවින් අපි fluentd හි දැනට පවතින විවෘත tcp port වෙත ලඝු-සටහන් ලිවීම සඳහා එම පොඩ් එකටම fluentd සහිත බහාලුමක් එක් කිරීමට තීරණය කළෙමු.
ප්රත්යාස්ථ සෙවීමට සම්බන්ධයක් නොමැති නම් චතුර ලෙස හැසිරෙන ආකාරය ද අපි ගවේෂණය කළෙමු. දින දෙකක්, ඉල්ලීම් ගේට්වේ වෙත නොකඩවා යවන ලදී, ලඝු-සටහන් fluentd වෙත යවන ලදී, නමුත් fluentd ගේ IP Elastic තහනම් කරන ලදී. සම්බන්ධතාවය ප්රතිසාධනය කිරීමෙන් පසුව, fluentd පරිපූර්ණ ලෙස සියලුම ලොග් ඉලාස්ටික් වෙත මාරු කළේය.
නිගමනය
ක්රියාත්මක කිරීම සඳහා තෝරාගත් ප්රවේශය මාස 2.5 ක් තුළ සැබවින්ම වැඩ කරන නිෂ්පාදනයක් සටන් පරිසරයකට ලබා දීමට අපට ඉඩ සලසයි.
ඔබ කවදා හෝ මෙවැනි දෙයක් කරන්නේ නම්, ඔබ විසඳන ගැටලුව කුමක්ද සහ ඔබට දැනටමත් ඇති සම්පත් මොනවාද යන්න පැහැදිලිව තේරුම් ගැනීමට අපි ඔබට උපදෙස් දෙමු. පවතින API කළමනාකරණ පද්ධති සමඟ ඒකාබද්ධ වීමේ සංකීර්ණතා පිළිබඳව දැනුවත් වන්න.
ඔබ හරියටම සංවර්ධනය කිරීමට යන්නේ කුමක් දැයි ඔබම තේරුම් ගන්න - ඉල්ලීම් සැකසීම සඳහා ව්යාපාරික තර්කනය පමණක් හෝ, අපගේ නඩුවේ සිදු විය හැකි පරිදි, සම්පූර්ණ ප්රොක්සිය. ඔබ විසින්ම කරන සෑම දෙයක්ම පසුව හොඳින් පරීක්ෂා කළ යුතු බව අමතක නොකරන්න.
මූලාශ්රය: www.habr.com
