જેમ જેમ આપણે એકવિધ એપ્લિકેશનમાંથી માઇક્રોસર્વિસીસ આર્કિટેક્ચર તરફ આગળ વધીએ છીએ, તેમ આપણે નવા પડકારોનો સામનો કરીએ છીએ.

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

હું લાંબા સમયથી એક સાધન શોધી રહ્યો છું જે આવી સમસ્યાઓનો સામનો કરવામાં મદદ કરશે (મેં આ વિશે હેબ્રે પર લખ્યું છે: 1, 2), પરંતુ અંતે મેં મારું પોતાનું ઓપન સોર્સ સોલ્યુશન બનાવ્યું. આ લેખમાં હું સેવા મેશ અભિગમના ફાયદા વિશે વાત કરું છું અને તેના અમલીકરણ માટે એક નવું સાધન શેર કરું છું.

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

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

સેવા મેશ અભિગમ

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

ઉકેલો

આ અભિગમના ઘણા અમલીકરણો પહેલાથી જ છે: ઇસ્ટિઓ и linkerd2. તેઓ બોક્સની બહાર ઘણી બધી સુવિધાઓ પ્રદાન કરે છે. પરંતુ તે જ સમયે, સંસાધનો પર મોટી ઓવરહેડ આવે છે. તદુપરાંત, ક્લસ્ટર જેટલું મોટું છે જેમાં આવી સિસ્ટમ કાર્યરત છે, નવા ઇન્ફ્રાસ્ટ્રક્ચરને જાળવવા માટે વધુ સંસાધનોની જરૂર પડશે. એવિટોમાં, અમે કુબરનેટ્સ ક્લસ્ટર ચલાવીએ છીએ જેમાં હજારો સેવાના દાખલાઓ હોય છે (અને તેમની સંખ્યા ઝડપથી વધતી જાય છે). તેના વર્તમાન અમલીકરણમાં, Istio સેવાના દાખલા દીઠ ~300Mb RAM વાપરે છે. મોટી સંખ્યામાં શક્યતાઓને લીધે, પારદર્શક સંતુલન સેવાઓના એકંદર પ્રતિભાવ સમયને પણ અસર કરે છે (10ms સુધી).

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

પરિણામે, અમે અમારા નિર્ણય પર આવ્યા:  નેત્રમેશ.

નેત્રમેશ

નેત્રમેશ સિસ્ટમમાં સેવાઓની સંખ્યાને ધ્યાનમાં લીધા વિના, અનંત રીતે સ્કેલ કરવાની ક્ષમતા સાથે લાઇટવેઇટ સર્વિસ મેશ સોલ્યુશન છે.

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

આજે, મોટાભાગના ક્લાઉડ સોલ્યુશન્સ ગોલાંગમાં લાગુ કરવામાં આવે છે. અને, અલબત્ત, આના કારણો છે. ગોલાંગમાં નેટવર્ક એપ્લિકેશન લખવી જે I/O સાથે અસુમેળ રીતે કામ કરે છે અને જરૂરિયાત મુજબ કોરો પર સ્કેલ કરે છે તે અનુકૂળ અને એકદમ સરળ છે. અને, શું પણ ખૂબ જ મહત્વપૂર્ણ છે, આ સમસ્યાને હલ કરવા માટે કામગીરી પૂરતી છે. એટલા માટે અમે પણ ગોલાંગ પસંદ કર્યું.

ઉત્પાદકતા

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

ચાલો જોઈએ કે અમને શું પરિણામ મળ્યું.

રામ

નેત્રમેશ ટ્રાફિક વિના ~10Mb અને ઉદાહરણ દીઠ 50 RPS સુધીના લોડ સાથે મહત્તમ 10000Mb વાપરે છે.

Istio envoy proxy હંમેશા હજારો ઉદાહરણો સાથે અમારા ક્લસ્ટરોમાં ~300Mb વાપરે છે. આ તેને સમગ્ર ક્લસ્ટરમાં માપવાની મંજૂરી આપતું નથી.

નેત્રમેશ સાથે અમને મેમરી વપરાશમાં ~10xનો ઘટાડો મળ્યો.

સી.પી.યુ

CPU વપરાશ લોડ હેઠળ પ્રમાણમાં સમાન છે. તે સાઇડકારને સમયના એકમ દીઠ વિનંતીઓની સંખ્યા પર આધાર રાખે છે. ટોચ પર પ્રતિ સેકન્ડ 3000 વિનંતીઓ પર મૂલ્યો:

ત્યાં એક વધુ મહત્વનો મુદ્દો છે: નેત્રમેશ - કંટ્રોલ પ્લેન વિના અને લોડ વિનાનું સોલ્યુશન CPU સમયનો ઉપયોગ કરતું નથી. Istio સાથે, સાઇડકાર હંમેશા સેવાના અંતિમ બિંદુઓને અપડેટ કરે છે. પરિણામે, અમે આ ચિત્રને લોડ વિના જોઈ શકીએ છીએ:

અમે સેવાઓ વચ્ચે સંચાર માટે HTTP/1 નો ઉપયોગ કરીએ છીએ. દૂત દ્વારા પ્રોક્સી કરતી વખતે Istio માટે પ્રતિભાવ સમયમાં વધારો 5-10ms જેટલો હતો, જે મિલીસેકન્ડમાં પ્રતિસાદ આપવા માટે તૈયાર હોય તેવી સેવાઓ માટે ઘણો મોટો છે. નેત્રમેશ સાથે આ સમય ઘટીને 0.5-2ms થયો છે.

માપનીયતા

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

સેવા શોધ

નેત્રમેશ સેવાની શોધ માટે કોઈ વધારાની મિકેનિઝમ ઉમેરતું નથી. તમામ ટ્રાફિક નેત્રા સાઇડકાર દ્વારા પારદર્શક રીતે પ્રોક્સી કરવામાં આવે છે.

નેત્રમેશ HTTP/1 એપ્લિકેશન પ્રોટોકોલને સપોર્ટ કરે છે. તેને વ્યાખ્યાયિત કરવા માટે, બંદરોની રૂપરેખાંકિત સૂચિનો ઉપયોગ થાય છે. સામાન્ય રીતે, સિસ્ટમમાં કેટલાક પોર્ટ હોય છે જેના દ્વારા HTTP સંચાર થાય છે. ઉદાહરણ તરીકે, અમે સેવાઓ અને બાહ્ય વિનંતીઓ વચ્ચેની ક્રિયાપ્રતિક્રિયા માટે 80, 8890, 8080 નો ઉપયોગ કરીએ છીએ. આ કિસ્સામાં, તેઓ પર્યાવરણ ચલનો ઉપયોગ કરીને સેટ કરી શકાય છે. NETRA_HTTP_PORTS.

જો તમે કુબરનેટ્સનો ઉપયોગ ઓર્કેસ્ટ્રેટર તરીકે કરો છો અને સેવાઓ વચ્ચેના આંતર-ક્લસ્ટર સંચાર માટે તેની સેવા એન્ટિટી મિકેનિઝમનો ઉપયોગ કરો છો, તો પદ્ધતિ બરાબર એ જ રહે છે. પ્રથમ, માઇક્રોસર્વિસ kube-dns નો ઉપયોગ કરીને સેવા IP સરનામું મેળવે છે અને તેની સાથે નવું કનેક્શન ખોલે છે. આ જોડાણ સૌપ્રથમ સ્થાનિક નેટ્રા-સાઇડકાર સાથે સ્થાપિત કરવામાં આવે છે અને તમામ TCP પેકેટ શરૂઆતમાં નેત્રામાં આવે છે. આગળ, નેટ્રા-સાઇડકાર મૂળ ગંતવ્ય સાથે જોડાણ સ્થાપિત કરે છે. નોડ પર પોડ આઈપી પર NAT નેટ્રા વિના બરાબર એ જ રહે છે.

વિતરિત ટ્રેસિંગ અને સંદર્ભ ફોરવર્ડિંગ

નેત્રમેશ HTTP ક્રિયાપ્રતિક્રિયાઓ વિશે ટ્રેસિંગ સ્પાન્સ મોકલવા માટે જરૂરી કાર્યક્ષમતા પ્રદાન કરે છે. નેટ્રા-સાઇડકાર HTTP પ્રોટોકોલનું વિશ્લેષણ કરે છે, વિનંતી વિલંબને માપે છે અને HTTP હેડરોમાંથી જરૂરી માહિતી કાઢે છે. આખરે, અમે એક જ જેગર સિસ્ટમમાં તમામ નિશાનો મેળવીએ છીએ. સરસ રૂપરેખાંકન માટે, તમે અધિકૃત પુસ્તકાલય દ્વારા પ્રદાન કરવામાં આવેલ પર્યાવરણ ચલોનો પણ ઉપયોગ કરી શકો છો. jaeger જાઓ પુસ્તકાલય.

પરંતુ એક સમસ્યા છે. જ્યાં સુધી સેવાઓ સ્પેશિયલ ઉબેર હેડર જનરેટ અને મોકલે નહીં, ત્યાં સુધી અમે સિસ્ટમમાં કનેક્ટેડ ટ્રેસિંગ સ્પાન્સ જોઈશું નહીં. અને આ તે છે જે આપણે સમસ્યાઓનું કારણ ઝડપથી શોધવાની જરૂર છે. અહીં ફરી નેત્રમેશ પાસે ઉકેલ છે. પ્રોક્સીઓ HTTP હેડરો વાંચે છે અને, જો તેમાં uber ટ્રેસ આઈડી ન હોય તો, એક જનરેટ કરે છે. નેત્રમેશ સાઇડકારમાં ઇનકમિંગ અને આઉટગોઇંગ રિક્વેસ્ટ વિશેની માહિતી પણ સ્ટોર કરે છે અને જરૂરી આઉટગોઇંગ રિક્વેસ્ટ હેડરો સાથે તેમને સમૃદ્ધ બનાવીને મેચ કરે છે. તમારે સેવાઓમાં માત્ર એક હેડર મોકલવાની જરૂર છે X-Request-Id, જે પર્યાવરણ ચલનો ઉપયોગ કરીને ગોઠવી શકાય છે NETRA_HTTP_REQUEST_ID_HEADER_NAME. નેત્રમેશમાં સંદર્ભના કદને નિયંત્રિત કરવા માટે, તમે નીચેના પર્યાવરણ ચલો સેટ કરી શકો છો: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (સંદર્ભ સંગ્રહિત કરવામાં આવશે તે સમય) અને NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (સંદર્ભ સફાઈની આવર્તન).

તમારી સિસ્ટમ પર બહુવિધ પાથને વિશિષ્ટ સત્ર ટોકન સાથે ચિહ્નિત કરીને જોડવાનું પણ શક્ય છે. નેત્રા તમને ઇન્સ્ટોલ કરવાની પરવાનગી આપે છે HTTP_HEADER_TAG_MAP HTTP હેડરોને અનુરૂપ ટ્રેસિંગ સ્પાન ટૅગ્સમાં ફેરવવા માટે. આ ખાસ કરીને પરીક્ષણ માટે ઉપયોગી થઈ શકે છે. કાર્યાત્મક પરીક્ષણ પાસ કર્યા પછી, તમે જોઈ શકો છો કે અનુરૂપ સત્ર કી દ્વારા ફિલ્ટર કરવાથી સિસ્ટમનો કયો ભાગ પ્રભાવિત થયો હતો.

વિનંતી સ્ત્રોત નક્કી

વિનંતી ક્યાંથી આવી છે તે નિર્ધારિત કરવા માટે, તમે સ્ત્રોત સાથે આપમેળે હેડર ઉમેરવાની કાર્યક્ષમતાનો ઉપયોગ કરી શકો છો. પર્યાવરણ ચલનો ઉપયોગ કરીને NETRA_HTTP_X_SOURCE_HEADER_NAME તમે હેડર નામનો ઉલ્લેખ કરી શકો છો જે આપમેળે ઇન્સ્ટોલ થઈ જશે. ઉપયોગ કરીને NETRA_HTTP_X_SOURCE_VALUE તમે વેલ્યુ સેટ કરી શકો છો કે જેના પર એક્સ-સોર્સ હેડર તમામ આઉટગોઇંગ વિનંતીઓ માટે સેટ કરવામાં આવશે.

આ ઉપયોગી હેડરના વિતરણને સમગ્ર નેટવર્કમાં સમાનરૂપે વિતરિત કરવાની મંજૂરી આપે છે. પછી તમે તેનો ઉપયોગ સેવાઓમાં કરી શકો છો અને તેને લોગ અને મેટ્રિક્સમાં ઉમેરી શકો છો.

ટ્રાફિક રૂટીંગ અને નેત્રમેશ ઇન્ટરનલ

નેત્રમેશ બે મુખ્ય ઘટકો ધરાવે છે. પ્રથમ, નેટ્રા-ઇનિટ, ટ્રાફિકને અટકાવવા માટે નેટવર્ક નિયમો સેટ કરે છે. તે વાપરે છે iptables રીડાયરેક્ટ નિયમો સાઇડકાર પરના તમામ અથવા અમુક ટ્રાફિકને અટકાવવા માટે, જે નેત્રમેશનું બીજું મુખ્ય ઘટક છે. ઇનકમિંગ અને આઉટગોઇંગ TCP સત્રો માટે કયા પોર્ટ્સને અટકાવવાની જરૂર છે તે તમે ગોઠવી શકો છો: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

સાધનમાં એક રસપ્રદ સુવિધા પણ છે - સંભવિત રૂટીંગ. જો તમે નેત્રમેશનો ઉપયોગ ફક્ત ટ્રેસિંગ સ્પાન્સ એકત્રિત કરવા માટે કરો છો, તો પછી ઉત્પાદન વાતાવરણમાં તમે સંસાધનો બચાવી શકો છો અને વેરિયેબલ્સનો ઉપયોગ કરીને સંભવિત રૂટીંગને સક્ષમ કરી શકો છો. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 થી 1 સુધી). ડિફૉલ્ટ મૂલ્ય 1 છે (બધો ટ્રાફિક અટકાવાયેલ છે).

સફળ વિક્ષેપ પછી, નેત્રા સાઇડકાર નવા જોડાણને સ્વીકારે છે અને તેનો ઉપયોગ કરે છે SO_ORIGINAL_DST મૂળ ગંતવ્ય મેળવવા માટે સોકેટ વિકલ્પ. નેત્રા ત્યારપછી મૂળ આઈપી એડ્રેસ પર નવું કનેક્શન ખોલે છે અને ત્યાંથી પસાર થતા તમામ ટ્રાફિકને સાંભળીને પક્ષકારો વચ્ચે દ્વિ-માર્ગી TCP સંચાર સ્થાપિત કરે છે. જો પોર્ટને HTTP તરીકે વ્યાખ્યાયિત કરવામાં આવે છે, તો નેત્રા તેને પાર્સ અને ટ્રેસ કરવાનો પ્રયાસ કરે છે. જો HTTP પાર્સિંગ નિષ્ફળ જાય, તો નેત્રા TCP પર પાછું આવે છે અને પારદર્શક રીતે બાઈટ્સને પ્રોક્સી કરે છે.

નિર્ભરતા ગ્રાફ બનાવવો

જેગરમાં મોટી માત્રામાં ટ્રેસિંગ માહિતી પ્રાપ્ત કર્યા પછી, હું સિસ્ટમમાં ક્રિયાપ્રતિક્રિયાઓનો સંપૂર્ણ ગ્રાફ મેળવવા માંગુ છું. પરંતુ જો તમારી સિસ્ટમ એકદમ લોડ થયેલ છે અને દરરોજ અબજો ટ્રેસીંગ સ્પાન્સ એકઠા થાય છે, તો તેમને એકત્ર કરવું એટલું સરળ કાર્ય નથી. આ કરવાની એક સત્તાવાર રીત છે: સ્પાર્ક-નિર્ભરતા. જો કે, સંપૂર્ણ ગ્રાફ બનાવવામાં કલાકો લાગશે અને તમને છેલ્લા 24 કલાકથી જેગરમાંથી સમગ્ર ડેટાસેટ ડાઉનલોડ કરવા દબાણ કરશે.

જો તમે ટ્રેસિંગ સ્પાન્સ સ્ટોર કરવા માટે Elasticsearch નો ઉપયોગ કરી રહ્યાં છો, તો તમે ઉપયોગ કરી શકો છો એક સરળ ગોલાંગ ઉપયોગિતા, જે Elasticsearch ની સુવિધાઓ અને ક્ષમતાઓનો ઉપયોગ કરીને મિનિટોમાં સમાન ગ્રાફ બનાવશે.

નેત્રમેશ નો ઉપયોગ કેવી રીતે કરવો

નેત્રા કોઈપણ ઓર્કેસ્ટ્રેટરને ચલાવતી કોઈપણ સેવામાં સરળતાથી ઉમેરી શકાય છે. તમે એક ઉદાહરણ જોઈ શકો છો અહીં.

આ ક્ષણે, નેત્રા પાસે સેવાઓમાં સાઇડકાર્સને આપમેળે લાગુ કરવાની ક્ષમતા નથી, પરંતુ અમલીકરણ માટેની યોજનાઓ છે.

નેત્રમેશનું ભવિષ્ય

મુખ્ય ધ્યેય નેત્રમેશ ન્યૂનતમ સંસાધન ખર્ચ અને ઉચ્ચ પ્રદર્શન હાંસલ કરવા માટે છે, અવલોકનક્ષમતા અને આંતર-સેવા સંચારના નિયંત્રણ માટે મૂળભૂત ક્ષમતાઓ પૂરી પાડે છે.

ભવિષ્યમાં, નેત્રમેશ HTTP ઉપરાંત અન્ય એપ્લિકેશન લેયર પ્રોટોકોલ્સને સપોર્ટ કરશે. L7 રૂટીંગ નજીકના ભવિષ્યમાં ઉપલબ્ધ થશે.

જો તમને સમાન સમસ્યાઓનો સામનો કરવો પડે તો નેત્રમેશનો ઉપયોગ કરો અને પ્રશ્નો અને સૂચનો સાથે અમને લખો.

સોર્સ: www.habr.com