අපි මොනොලිතික් යෙදුමක සිට ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයකට මාරු වන විට, අපට නව අභියෝගවලට මුහුණ දීමට සිදුවේ.

මොනොලිතික් යෙදුමකදී, දෝෂය සිදුවූයේ පද්ධතියේ කුමන කොටසෙහිද යන්න තීරණය කිරීම සාමාන්‍යයෙන් තරමක් පහසුය. බොහෝ දුරට, ගැටළුව ඇත්තේ මොනොලිත් කේතයේ හෝ දත්ත ගබඩාවේ ය. නමුත් අපි ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයක ගැටලුවක් සෙවීමට පටන් ගත් විට, සියල්ල තවදුරටත් එතරම් පැහැදිලි නැත. අපි ඉල්ලීම ආරම්භයේ සිට අවසානය දක්වා ගෙන ගිය සම්පූර්ණ මාර්ගය සොයා ගැනීමට සහ ක්ෂුද්ර සේවා සිය ගණනකින් එය තෝරාගත යුතුය. එපමණක් නොව, ඔවුන්ගෙන් බොහෝ දෙනෙකුට තමන්ගේම ගබඩා පහසුකම් ද ඇති අතර, එය තාර්කික දෝෂ මෙන්ම කාර්ය සාධනය සහ වැරදි ඉවසීමේ ගැටළු ද ඇති කළ හැකිය.

එවැනි ගැටළු සමඟ සාර්ථකව කටයුතු කිරීමට උපකාරී වන මෙවලමක් සඳහා මම දිගු කලක් තිස්සේ සොයමින් සිටිමි (මම මේ ගැන Habé හි ලිව්වෙමි: 1, 2), නමුත් අවසානයේ මම මගේම විවෘත මූලාශ්‍ර විසඳුමක් සාදා ගත්තෙමි. මෙම ලිපියෙන් මම සේවා දැල් ප්‍රවේශයේ ප්‍රතිලාභ ගැන කතා කරන අතර එය ක්‍රියාත්මක කිරීම සඳහා නව මෙවලමක් බෙදා ගන්නෙමි.

බෙදා හරින ලද ලුහුබැඳීම බෙදා හරින ලද පද්ධතිවල දෝෂ සෙවීමේ ගැටලුවට පොදු විසඳුමකි. නමුත් ජාල අන්තර්ක්‍රියා පිළිබඳ තොරතුරු රැස් කිරීමේ මෙම ප්‍රවේශය තවමත් පද්ධතිය තුළ ක්‍රියාත්මක කර නොමැති නම්, නැතහොත්, වඩාත් නරක ලෙස, පද්ධතියේ කොටසක එය දැනටමත් නිසි ලෙස ක්‍රියා කරයි, නමුත් අර්ධ වශයෙන් එය පැරණි සේවාවන්ට එකතු කර නොමැති බැවින් කුමක් කළ යුතුද? ? ගැටලුවක මූල හේතුව නිවැරදිව තීරණය කිරීම සඳහා, පද්ධතියේ සිදුවන්නේ කුමක්ද යන්න පිළිබඳ සම්පූර්ණ චිත්රයක් තිබීම අවශ්ය වේ. ප්‍රධාන ව්‍යාපාර-විවේචනාත්මක මාර්ගවලට සම්බන්ධ වන ක්ෂුද්‍ර සේවා මොනවාද යන්න තේරුම් ගැනීම විශේෂයෙන් වැදගත් වේ.

මෙහිදී සේවා දැල් ප්‍රවේශය අපගේ ආධාරයට පැමිණිය හැකි අතර, එය සේවා විසින්ම ක්‍රියාත්මක වන මට්ටමට වඩා අඩු මට්ටමක ජාල තොරතුරු රැස් කිරීම සඳහා සියලුම යන්ත්‍ර සූත්‍ර සමඟ කටයුතු කරනු ඇත. මෙම ප්‍රවේශය අපට සියලු ගමනාගමනයට බාධා කිරීමට සහ පියාසර කිරීමේදී එය විශ්ලේෂණය කිරීමට ඉඩ සලසයි. එපමණක් නොව, යෙදුම් ඒ ගැන කිසිවක් දැන සිටිය යුතු නැත.

සේවා දැල් ප්රවේශය

සේවා දැල් ප්‍රවේශයේ ප්‍රධාන අදහස වන්නේ ජාලය හරහා තවත් යටිතල පහසුකම් තට්ටුවක් එක් කිරීමයි, එමඟින් අන්තර් සේවා අන්තර්ක්‍රියා සමඟ ඕනෑම දෙයක් කිරීමට අපට ඉඩ සලසයි. බොහෝ ක්‍රියාත්මක කිරීම් පහත පරිදි ක්‍රියා කරයි: විනිවිද පෙනෙන ප්‍රොක්සියක් සහිත අමතර පැති කාර් කන්ටේනරයක් සෑම ක්ෂුද්‍ර සේවාවකටම එකතු කරනු ලැබේ, එමඟින් සේවාවේ එන සහ පිටතට යන ගමනාගමනය සම්මත වේ. අපට සේවාදායක සමතුලිත කිරීම, ආරක්ෂක ප්‍රතිපත්ති යෙදීම, ඉල්ලීම් ගණනට සීමා පැනවීම සහ නිෂ්පාදනයේ සේවාවන්හි අන්තර් ක්‍රියාකාරිත්වය පිළිබඳ වැදගත් තොරතුරු රැස් කිරීම කළ හැකි ස්ථානය මෙයයි.

විසඳුම්

මෙම ප්‍රවේශයේ ක්‍රියාත්මක කිරීම් කිහිපයක් දැනටමත් තිබේ: ඉස්ටියෝ и linkerd2. ඔවුන් කොටුවෙන් පිටත බොහෝ විශේෂාංග සපයයි. නමුත් ඒ සමගම, සම්පත් මත විශාල පිරිවැයක් ද ඇත. එපමනක් නොව, එවැනි පද්ධතියක් ක්රියාත්මක වන පොකුර විශාල වන තරමට, නව යටිතල පහසුකම් නඩත්තු කිරීම සඳහා වැඩි සම්පත් අවශ්ය වනු ඇත. Avito හි, අපි සේවා අවස්ථා දහස් ගණනක් අඩංගු kubernetes පොකුරු ක්‍රියාත්මක කරන්නෙමු (සහ ඒවායේ සංඛ්‍යාව වේගයෙන් වර්ධනය වේ). එහි වත්මන් ක්‍රියාත්මක කිරීමේදී, Istio එක් සේවා අවස්ථාවක RAM ~300Mb පරිභෝජනය කරයි. විශාල ඉඩ ප්‍රමාණයක් නිසා, විනිවිද පෙනෙන සමතුලිතතාවය සේවාවල සමස්ත ප්‍රතිචාර කාලයට (මි. 10 දක්වා) ද බලපායි.

එහි ප්‍රතිඵලයක් වශයෙන්, අපි මේ මොහොතේ අපට අවශ්‍ය හැකියාවන් මොනවාදැයි හරියටම සොයා බැලූ අතර, අපි එවැනි විසඳුම් ක්‍රියාත්මක කිරීමට පටන් ගැනීමට ප්‍රධාන හේතුව සමස්ත පද්ධතියෙන්ම ලුහුබැඳීමේ තොරතුරු විනිවිදභාවයෙන් එකතු කිරීමේ හැකියාව බව තීරණය කළෙමු. අපට සේවාවල අන්තර්ක්‍රියා පාලනය කිරීමට සහ සේවා අතර මාරු කරන ශීර්ෂයන් සමඟ විවිධ හැසිරවීම් කිරීමටද අවශ්‍ය විය.

එහි ප්‍රතිඵලයක් වශයෙන්, අපි අපගේ තීරණයට පැමිණියෙමු:  නේත්‍රමේෂ්.

නේත්‍රමේෂ්

නේත්‍රමේෂ් පද්ධතියේ ඇති සේවා සංඛ්‍යාව කුමක් වුවත්, අසීමිත ලෙස පරිමාණය කිරීමේ හැකියාව සහිත සැහැල්ලු සේවා දැල් විසඳුමකි.

නව විසඳුමේ ප්‍රධාන අරමුණු වූයේ අඩු සම්පත් පොදු කාර්ය සහ ඉහළ කාර්ය සාධනයයි. ප්‍රධාන විශේෂාංග අතර, අපගේ ජේගර් පද්ධතියට ලුහුබැඳීමේ පරාසයන් විනිවිද පෙනෙන ලෙස යැවීමට අපට වහාම අවශ්‍ය විය.

අද බොහෝ වලාකුළු විසඳුම් Golang හි ක්රියාත්මක වේ. තවද, ඇත්ත වශයෙන්ම, මේ සඳහා හේතු තිබේ. I/O සමඟ අසමමුහුර්තව ක්‍රියා කරන Golang හි ජාල යෙදුම් ලිවීම සහ අවශ්‍ය පරිදි හර හරහා පරිමාණය කිරීම පහසු සහ සරල ය. තවද, ඉතා වැදගත් වන්නේ, මෙම ගැටළුව විසඳීම සඳහා කාර්ය සාධනය ප්රමාණවත්ය. ඒකයි අපිත් ගොලං තෝරගත්තේ.

ඵලදායිතාව

අපි උපරිම ඵලදායිතාවයක් ලබා ගැනීම සඳහා අපගේ උත්සාහයන් යොමු කර ඇත. සේවාවේ එක් එක් අවස්ථාවට යාබදව යොදවා ඇති විසඳුමක් සඳහා, RAM සහ CPU කාලය කුඩා පරිභෝජනයක් අවශ්‍ය වේ. තවද, ඇත්ත වශයෙන්ම, ප්රතිචාර ප්රමාදය ද කුඩා විය යුතුය.

අපි බලමු අපිට ලැබුණු ප්‍රතිඵල මොනවද කියලා.

RAM

Netramesh ගමනාගමනය නොමැතිව ~10Mb පරිභෝජනය කරන අතර එක් අවස්ථාවක RPS 50 දක්වා බරක් සමඟ උපරිම 10000Mb පරිභෝජනය කරයි.

Istio එන්වෝයි ප්‍රොක්සි සෑම විටම දහස් ගණනක් අවස්ථා සමඟ අපගේ පොකුරු තුළ ~300Mb පරිභෝජනය කරයි. මෙය සම්පූර්ණ පොකුරට පරිමාණය කිරීමට ඉඩ නොදේ.

Netramesh සමඟින් අපට මතක පරිභෝජනයෙහි ~10x අඩුවීමක් ලැබුණි.

CPU

පැටවීම යටතේ CPU භාවිතය සාපේක්ෂව සමාන වේ. එය සයිඩ් කාර් එකට කාල ඒකකයකට ලැබෙන ඉල්ලීම් ගණන මත රඳා පවතී. උපරිම තත්පරයට ඉල්ලීම් 3000ක අගයන්:

තවත් වැදගත් කරුණක් තිබේ: Netramesh - පාලන තලයක් නොමැතිව සහ බරක් නොමැතිව විසඳුමක් CPU කාලය පරිභෝජනය නොකරයි. Istio සමඟින්, සයිඩ්කාර් සෑම විටම සේවා අන්ත ලක්ෂ්‍ය යාවත්කාලීන කරයි. එහි ප්‍රතිඵලයක් වශයෙන්, බරක් නොමැතිව අපට මෙම පින්තූරය දැකිය හැකිය:

සේවා අතර සන්නිවේදනය සඳහා අපි HTTP/1 භාවිතා කරමු. එන්වෝයි හරහා ප්‍රොක්සි කිරීමේදී Istio සඳහා ප්‍රතිචාර දැක්වීමේ කාලය 5-10ms දක්වා වැඩි විය, එය මිලි තත්පරයකින් ප්‍රතිචාර දැක්වීමට සූදානම් සේවාවන් සඳහා බෙහෙවින් වැඩි වේ. Netramesh සමඟ මෙම කාලය 0.5-2ms දක්වා අඩු වී ඇත.

පරිමාණය

එක් එක් ප්‍රොක්සි විසින් පරිභෝජනය කරන කුඩා සම්පත් ප්‍රමාණය එය එක් එක් සේවාව අසල තැබීමට හැකි වේ. Netramesh චේතනාන්විතව නිර්මාණය කර ඇත්තේ එක් එක් පැති රථය සැහැල්ලුවෙන් තබා ගැනීම සඳහා පාලන තල සංරචකයක් නොමැතිවය. බොහෝ විට සේවා දැල් විසඳුම් වලදී, පාලක තලය එක් එක් පැති කාර් වෙත සේවා සොයාගැනීම් තොරතුරු බෙදා හරිනු ලැබේ. එය සමඟ කල් ඉකුත්වීම් සහ සමතුලිත සැකසුම් පිළිබඳ තොරතුරු පැමිණේ. මේ සියල්ල ඔබට ප්රයෝජනවත් දේවල් ගොඩක් කිරීමට ඉඩ සලසයි, නමුත්, අවාසනාවකට මෙන්, එය ප්රමාණයෙන් සයිඩ්කාර් පුම්බා ඇත.

සේවා සොයා ගැනීම

Netramesh සේවා සොයා ගැනීම සඳහා කිසිදු අමතර යාන්ත්‍රණයක් එකතු නොකරයි. නෙත්‍රා සයිඩ්කාර් හරහා සියලුම ගමනාගමනය විනිවිද පෙනෙන ලෙස ප්‍රොක්සි කෙරේ.

Netramesh HTTP/1 යෙදුම් ප්‍රොටෝකෝලය සඳහා සහය දක්වයි. එය නිර්වචනය කිරීම සඳහා, වින්යාසගත කළ හැකි වරායන් ලැයිස්තුවක් භාවිතා වේ. සාමාන්‍යයෙන්, පද්ධතියට HTTP සන්නිවේදනය සිදු වන වරායන් කිහිපයක් ඇත. උදාහරණයක් ලෙස, අපි සේවා සහ බාහිර ඉල්ලීම් අතර අන්තර්ක්‍රියා සඳහා 80, 8890, 8080 භාවිතා කරමු. මෙම අවස්ථාවේදී, පරිසර විචල්‍යයක් භාවිතයෙන් ඒවා සැකසිය හැක. NETRA_HTTP_PORTS.

ඔබ වාදකයෙකු ලෙස Kubernetes සහ සේවා අතර අන්තර්-පොකුරු සන්නිවේදනය සඳහා එහි සේවා ආයතන යාන්ත්‍රණය භාවිතා කරන්නේ නම්, යාන්ත්‍රණය හරියටම එලෙසම පවතී. පළමුව, microservice kube-dns භාවිතයෙන් සේවා IP ලිපිනයක් ලබාගෙන එයට නව සම්බන්ධතාවයක් විවෘත කරයි. මෙම සම්බන්ධතාවය මුලින්ම දේශීය netra-sidecar සමඟ ස්ථාපිත කර ඇති අතර සියලුම TCP පැකට් මුලින් netra වෙත පැමිණේ. ඊළඟට, netra-sidecar මුල් ගමනාන්තය සමඟ සම්බන්ධතාවයක් ඇති කරයි. නෝඩයේ පොඩ් IP මත NAT හරියටම netra නොමැතිව පවතී.

බෙදා හරින ලද ලුහුබැඳීම සහ සන්දර්භය යොමු කිරීම

Netramesh HTTP අන්තර්ක්‍රියා පිළිබඳ ලුහුබැඳීමේ පරාසය යැවීමට අවශ්‍ය ක්‍රියාකාරීත්වය සපයයි. Netra-sidecar HTTP ප්‍රොටෝකෝලය විග්‍රහ කරයි, ඉල්ලීම් ප්‍රමාදයන් මනින අතර HTTP ශීර්ෂයෙන් අවශ්‍ය තොරතුරු උපුටා ගනී. අවසාන වශයෙන්, අපි සියලු හෝඩුවාවන් තනි ජේගර් පද්ධතියකින් ලබා ගනිමු. සියුම් වින්‍යාසය සඳහා, ඔබට නිල පුස්තකාලයෙන් සපයන පරිසර විචල්‍යයන් ද භාවිතා කළ හැකිය. jaeger go පුස්තකාලය.

නමුත් ගැටලුවක් තිබේ. සේවාවන් විශේෂ uber ශීර්ෂයක් ජනනය කර එවන තුරු, අපි පද්ධතිය තුළ සම්බන්ධිත ලුහුබැඳීමේ පරාසයන් නොදකිමු. ඒ වගේම අපි ඉක්මනින්ම ගැටළු වලට හේතුව සොයා ගැනීමට අවශ්ය වන්නේ මෙයයි. ඔන්න ආයෙත් නේත්‍රමේෂ්ට විසදුමක් තියෙනවා. ප්‍රොක්සි විසින් HTTP ශීර්ෂ කියවන අතර, ඒවායේ uber ට්‍රේස් හැඳුනුම්පත නොමැති නම්, එකක් උත්පාදනය කරන්න. Netramesh පැමිණෙන සහ පිටතට යන ඉල්ලීම් පිළිබඳ තොරතුරු පැති රථයක ගබඩා කරන අතර අවශ්‍ය පිටතට යන ඉල්ලීම් ශීර්ෂයන් සමඟ ඒවා පොහොසත් කිරීමෙන් ඒවා ගැලපේ. සේවාවන්හි ඔබ කළ යුත්තේ එක් ශීර්ෂයක් යැවීම පමණි X-Request-Id, පරිසර විචල්‍යයක් භාවිතයෙන් වින්‍යාසගත කළ හැක NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh හි සන්දර්භයේ ප්‍රමාණය පාලනය කිරීමට, ඔබට පහත පරිසර විචල්‍යයන් සැකසිය හැක: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (සන්දර්භය ගබඩා කරනු ලබන කාලය) සහ NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (සන්දර්භය පිරිසිදු කිරීමේ වාර ගණන).

විශේෂ සැසි ටෝකනයකින් සලකුණු කිරීමෙන් ඔබේ පද්ධතියේ බහු මාර්ග ඒකාබද්ධ කිරීමටද හැකිය. Netra ඔබට ස්ථාපනය කිරීමට ඉඩ සලසයි HTTP_HEADER_TAG_MAP HTTP ශීර්ෂයන් අනුරූප ලුහුබැඳීමේ පරතරය ටැග් බවට පත් කිරීමට. මෙය පරීක්ෂා කිරීම සඳහා විශේෂයෙන් ප්රයෝජනවත් විය හැකිය. ක්‍රියාකාරී පරීක්ෂණයෙන් සමත් වූ පසු, අනුරූප සැසි යතුර මඟින් පෙරීම මඟින් පද්ධතියේ කුමන කොටස බලපෑවේදැයි ඔබට දැක ගත හැකිය.

ඉල්ලීම් මූලාශ්රය තීරණය කිරීම

ඉල්ලීම පැමිණියේ කොහෙන්ද යන්න තීරණය කිරීම සඳහා, ඔබට මූලාශ්‍රය සමඟ ස්වයංක්‍රීයව ශීර්ෂයක් එක් කිරීමේ ක්‍රියාකාරීත්වය භාවිතා කළ හැක. පරිසර විචල්‍යයක් භාවිතා කිරීම NETRA_HTTP_X_SOURCE_HEADER_NAME ඔබට ස්වයංක්‍රීයව ස්ථාපනය වන ශීර්ෂ නාමයක් සඳහන් කළ හැක. භාවිතා කිරීම මගින් NETRA_HTTP_X_SOURCE_VALUE සියලුම පිටතට යන ඉල්ලීම් සඳහා X-මූලාශ්‍ර ශීර්ෂය සකසන අගය ඔබට සැකසිය හැක.

මෙම ප්රයෝජනවත් ශීර්ෂය බෙදා හැරීම ජාලය පුරා ඒකාකාරව බෙදා හැරීමට ඉඩ සලසයි. එවිට ඔබට එය සේවාවන්හි භාවිතා කළ හැකි අතර එය ලඝු-සටහන් සහ ප්‍රමිතික වෙත එක් කළ හැක.

රථවාහන මාර්ගගත කිරීම සහ Netramesh අභ්යන්තර

Netramesh ප්රධාන සංරචක දෙකකින් සමන්විත වේ. පළමු, netra-init, ගමනාගමනයට බාධා කිරීමට ජාල රීති සකසයි. ඔහු භාවිතා කරයි iptables යළි-යොමුවීම් නීති Netramesh හි දෙවන ප්‍රධාන අංගය වන පැති කාර් රථයේ ගමනාගමනයේ සම්පූර්ණ හෝ කොටසක් බාධා කිරීමට. ඔබට පැමිණෙන සහ පිටතට යන TCP සැසි සඳහා බාධා කළ යුතු වරායන් වින්‍යාසගත කළ හැක: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

මෙවලමෙහි සිත්ගන්නා අංගයක් ද ඇත - සම්භාවිතා මාර්ගගත කිරීම. ඔබ Netramesh ලුහුබැඳීමේ පරතරය එකතු කිරීම සඳහා පමණක් භාවිතා කරන්නේ නම්, නිෂ්පාදන පරිසරයකදී ඔබට සම්පත් ඉතිරි කර ගත හැකි අතර විචල්‍යයන් භාවිතයෙන් සම්භාවිතා මාර්ගගත කිරීම සක්‍රීය කළ හැකිය. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 සිට 1 දක්වා). පෙරනිමි අගය 1 වේ (සියලු ගමනාගමනය බාධා වේ).

සාර්ථක බාධාවකින් පසුව, netra sidecar නව සම්බන්ධතාවය පිළිගෙන භාවිතා කරයි SO_ORIGINAL_DST මුල් ගමනාන්තය ලබා ගැනීමට සොකට් විකල්පය. Netra පසුව මුල් IP ලිපිනයට නව සම්බන්ධතාවයක් විවෘත කර පාර්ශ්ව අතර ද්වි-මාර්ග TCP සන්නිවේදනය ස්ථාපිත කරයි, හරහා ගමන් කරන සියලුම මාර්ග තදබදයට සවන් දෙයි. වරාය HTTP ලෙස අර්ථ දක්වා තිබේ නම්, Netra එය විග්‍රහ කර සොයා ගැනීමට උත්සාහ කරයි. HTTP විග්‍රහ කිරීම අසාර්ථක වුවහොත්, Netra නැවත TCP වෙත වැටී බයිට් විනිවිද පෙනෙන ලෙස ප්‍රොක්සි කරයි.

පරායත්ත ප්‍රස්තාරයක් ගොඩනැගීම

Jaeger හි ලුහුබැඳීමේ තොරතුරු විශාල ප්‍රමාණයක් ලැබීමෙන් පසු, මට පද්ධතියේ අන්තර්ක්‍රියා පිළිබඳ සම්පූර්ණ ප්‍රස්ථාරයක් ලබා ගැනීමට අවශ්‍යය. නමුත් ඔබේ පද්ධතිය තරමක් පටවා තිබේ නම් සහ දිනකට ලුහුබැඳීමේ පරාසය බිලියන ගණනක් එකතු වේ නම්, ඒවා එකතු කිරීම එතරම් පහසු කාර්යයක් නොවේ. මෙය කිරීමට නිල ක්රමයක් තිබේ: ගිනි පුපුර- යැපීම්. කෙසේ වෙතත්, සම්පූර්ණ ප්‍රස්ථාරයක් තැනීමට පැය ගණනක් ගතවනු ඇති අතර පසුගිය පැය XNUMX සඳහා Jaeger වෙතින් සම්පූර්ණ දත්ත කට්ටලය බාගත කිරීමට ඔබට බල කරනු ඇත.

ඔබ ලුහුබැඳීමේ පරතරය ගබඩා කිරීමට Elasticsearch භාවිතා කරන්නේ නම්, ඔබට භාවිතා කළ හැක සරල Golang උපයෝගීතාවයක්, Elasticsearch හි විශේෂාංග සහ හැකියාවන් භාවිතයෙන් මිනිත්තු කිහිපයකින් එකම ප්‍රස්ථාරය ගොඩනඟයි.

Netramesh භාවිතා කරන්නේ කෙසේද?

ඕනෑම වාද්‍ය වෘන්දයක් පවත්වාගෙන යන ඕනෑම සේවාවකට නේත්‍රා පහසුවෙන් එකතු කළ හැක. ඔබට උදාහරණයක් දැකිය හැකිය මෙහි.

මේ මොහොතේ, නේත්‍රාට සේවා සඳහා අතුරු කාර් ස්වයංක්‍රීයව ක්‍රියාත්මක කිරීමේ හැකියාවක් නැත, නමුත් ක්‍රියාත්මක කිරීම සඳහා සැලසුම් තිබේ.

නෙත්‍රමේෂ්ගේ අනාගතය

ප්රධාන ඉලක්කය නේත්‍රමේෂ් අන්තර් සේවා සන්නිවේදනය නිරීක්ෂණය කිරීම සහ පාලනය කිරීම සඳහා මූලික හැකියාවන් සැපයීම, අවම සම්පත් පිරිවැය සහ ඉහළ කාර්යසාධනය සාක්ෂාත් කර ගැනීමයි.

අනාගතයේදී, Netramesh HTTP හැර අනෙකුත් යෙදුම් ස්ථර ප්‍රොටෝකෝල සඳහා සහය දක්වයි. L7 මාර්ගගත කිරීම නුදුරු අනාගතයේ දී ලබා ගත හැකි වනු ඇත.

ඔබට සමාන ගැටළු ඇති වුවහොත් Netramesh භාවිතා කර ප්‍රශ්න සහ යෝජනා සමඟ අපට ලියන්න.

මූලාශ්රය: www.habr.com