Bioyino - વિતરિત, સ્કેલેબલ મેટ્રિક્સ એગ્રીગેટર

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

અમારા અગાઉના લેખોમાંથી (1, 2) તમે શોધી શકો છો કે થોડા સમય સુધી અમે ટૅગ્સનો ઉપયોગ કરીને એકત્રિત કર્યા બ્રુબેક. તે C માં લખાયેલું છે. કોડના દૃષ્ટિકોણથી, તે પ્લગ જેટલું સરળ છે (જ્યારે તમે યોગદાન આપવા માંગતા હો ત્યારે આ મહત્વપૂર્ણ છે) અને, સૌથી અગત્યનું, તે અમારા 2 મિલિયન મેટ્રિક્સ પ્રતિ સેકન્ડ (MPS) ના વોલ્યુમને ટોચ પર હેન્ડલ કરે છે. કોઈપણ સમસ્યા વિના. દસ્તાવેજીકરણ એસ્ટરિસ્ક સાથે 4 મિલિયન MPS માટે સમર્થન જણાવે છે. આનો અર્થ એ છે કે જો તમે Linux પર નેટવર્કને યોગ્ય રીતે ગોઠવશો તો તમને જણાવેલ આકૃતિ મળશે. (અમે જાણતા નથી કે જો તમે નેટવર્ક જેમ છે તેમ છોડી દો તો તમને કેટલા MPS મળી શકે છે). આ ફાયદાઓ હોવા છતાં, અમારી પાસે બ્રુબેક વિશે ઘણી ગંભીર ફરિયાદો હતી.

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

દાવો 2. ગણતરીઓની ચોકસાઈ. બ્રુબેક એકત્રીકરણ માટે કુલ 65536 મૂલ્યો એકત્રિત કરે છે. અમારા કિસ્સામાં, કેટલાક મેટ્રિક્સ માટે, એકત્રીકરણ સમયગાળા દરમિયાન (30 સેકન્ડ), ઘણા વધુ મૂલ્યો આવી શકે છે (1 ટોચ પર). આ નમૂનાના પરિણામે, મહત્તમ અને લઘુત્તમ મૂલ્યો નકામી દેખાય છે. ઉદાહરણ તરીકે, આની જેમ:

જેવું હતું તેવું

તે કેવી રીતે હોવું જોઈએ

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

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

પ્રથમ, દોષ સહનશીલતા, જેથી સર્વર પર અચાનક સમસ્યા ઓફિસમાં માનસિક ઝોમ્બી એપોકેલિપ્સનું કારણ ન બને. બીજું, લિનક્સ નેટવર્ક સ્ટેકમાં ઊંડે સુધી ખોદ્યા વિના અને શાંતિથી જરૂરી કદમાં “પહોળાઈમાં” વધ્યા વિના, 4 મિલિયનથી વધુ MPS સ્વીકારવામાં સમર્થ થવા માટે સ્કેલિંગ.

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

જો તમે સમસ્યા વિશે થોડું વિચારશો અને તે જ સમયે પાવડો વડે બરફ ખોદશો, તો નીચેનો સ્પષ્ટ વિચાર મનમાં આવી શકે છે: તમારે એક સ્ટેટ્સડીની જરૂર છે જે વિતરિત મોડમાં કાર્ય કરી શકે. એટલે કે, જે સમય અને મેટ્રિક્સમાં નોડ્સ વચ્ચે સિંક્રનાઇઝેશન લાગુ કરે છે. "અલબત્ત, આવા ઉકેલ કદાચ પહેલાથી જ અસ્તિત્વમાં છે," અમે કહ્યું અને Google પર ગયા…. અને તેઓને કંઈ મળ્યું નહીં. વિવિધ આંકડાઓ માટેના દસ્તાવેજીકરણમાંથી પસાર થયા પછી (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 ડિસેમ્બર, XNUMX સુધી), અમને બિલકુલ કંઈ મળ્યું નથી. દેખીતી રીતે, ન તો વિકાસકર્તાઓ અને ન તો આ ઉકેલોના વપરાશકર્તાઓએ હજુ સુધી ઘણા બધા મેટ્રિક્સનો સામનો કર્યો છે, અન્યથા તેઓ ચોક્કસપણે કંઈક સાથે આવશે.

અને પછી અમને “ટોય” સ્ટેટ્સડી - બાયોયિનો વિશે યાદ આવ્યું, જે જસ્ટ ફોર ફન હેકાથોન પર લખવામાં આવ્યું હતું (હેકાથોનની શરૂઆત પહેલાં સ્ક્રિપ્ટ દ્વારા પ્રોજેક્ટનું નામ બનાવવામાં આવ્યું હતું) અને અમને સમજાયું કે અમને તાકીદે અમારા પોતાના આંકડાઓની જરૂર છે. શેના માટે?

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

શું લખવું? અલબત્ત, રસ્ટમાં. શા માટે?

• કારણ કે ત્યાં પહેલેથી જ પ્રોટોટાઇપ સોલ્યુશન હતું,
• કારણ કે લેખના લેખક તે સમયે રસ્ટને પહેલેથી જ જાણતા હતા અને તેને ઓપન-સોર્સમાં મૂકવાની તક સાથે ઉત્પાદન માટે તેમાં કંઈક લખવા આતુર હતા,
• કારણ કે પ્રાપ્ત થયેલા ટ્રાફિક (લગભગ રીયલટાઇમ)ની પ્રકૃતિને કારણે GC સાથેની ભાષાઓ આપણા માટે યોગ્ય નથી અને GC વિરામ વ્યવહારીક રીતે અસ્વીકાર્ય છે,
• કારણ કે તમારે C સાથે તુલનાત્મક મહત્તમ પ્રદર્શનની જરૂર છે
• કારણ કે રસ્ટ અમને નિર્ભીક સંમતિ પ્રદાન કરે છે, અને જો અમે તેને C/C++ માં લખવાનું શરૂ કર્યું હોત, તો અમે બ્રુબેક કરતાં પણ વધુ નબળાઈઓ, બફર ઓવરફ્લો, રેસની સ્થિતિ અને અન્ય ડરામણા શબ્દોમાં વધારો કર્યો હોત.

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

સમય પસાર થયો...

છેવટે, ઘણા નિષ્ફળ પ્રયાસો પછી, પ્રથમ કાર્યકારી સંસ્કરણ તૈયાર હતું. શું થયું? આવું જ થયું.

દરેક નોડ તેના પોતાના મેટ્રિક્સનો સેટ મેળવે છે અને તેને એકઠા કરે છે, અને તે પ્રકારો માટે મેટ્રિક્સને એકીકૃત કરતું નથી જ્યાં અંતિમ એકત્રીકરણ માટે તેનો સંપૂર્ણ સેટ જરૂરી છે. નોડ્સ અમુક પ્રકારના વિતરિત લોક પ્રોટોકોલ દ્વારા એકબીજા સાથે જોડાયેલા હોય છે, જે તમને તેમાંથી એક જ પસંદ કરવાની મંજૂરી આપે છે (અહીં અમે રડ્યા હતા) જે મહાન વ્યક્તિને મેટ્રિક્સ મોકલવા માટે યોગ્ય છે. દ્વારા હાલમાં આ સમસ્યાનું નિરાકરણ કરવામાં આવી રહ્યું છે કોન્સ્યુલ, પરંતુ ભવિષ્યમાં લેખકની મહત્વાકાંક્ષાઓ વિસ્તરે છે પોતાના અમલીકરણ રાફ્ટ, જ્યાં સૌથી લાયક વ્યક્તિ, અલબત્ત, સર્વસંમતિ નેતા નોડ હશે. સર્વસંમતિ ઉપરાંત, નોડ્સ ઘણી વાર (ડિફૉલ્ટ રૂપે પ્રતિ સેકન્ડમાં એકવાર) તેમના પડોશીઓને પૂર્વ-એગ્રિગેટેડ મેટ્રિક્સના તે ભાગો મોકલે છે જે તેઓ તે સેકન્ડમાં એકત્રિત કરવામાં વ્યવસ્થાપિત હતા. તે તારણ આપે છે કે સ્કેલિંગ અને ફોલ્ટ સહિષ્ણુતા સચવાયેલી છે - દરેક નોડ હજુ પણ મેટ્રિક્સનો સંપૂર્ણ સેટ ધરાવે છે, પરંતુ મેટ્રિક્સ પહેલેથી જ એકીકૃત, TCP દ્વારા મોકલવામાં આવે છે અને દ્વિસંગી પ્રોટોકોલમાં એન્કોડ કરવામાં આવે છે, તેથી ડુપ્લિકેશન ખર્ચ UDP ની તુલનામાં નોંધપાત્ર રીતે ઘટાડે છે. ઇનકમિંગ મેટ્રિક્સની એકદમ મોટી સંખ્યા હોવા છતાં, સંચય માટે ખૂબ ઓછી મેમરી અને ઓછા CPUની જરૂર પડે છે. અમારા અત્યંત સંકુચિત મેરિટિક્સ માટે, આ માત્ર થોડાક દસ મેગાબાઇટ્સ ડેટા છે. વધારાના બોનસ તરીકે, અમને ગ્રેફાઈટમાં કોઈ બિનજરૂરી ડેટા ફરીથી લખવામાં આવતો નથી, જેમ કે બરબેકનો કેસ હતો.

મેટ્રિક્સ સાથેના UDP પેકેટો એક સરળ રાઉન્ડ રોબિન દ્વારા નેટવર્ક સાધનો પર નોડ્સ વચ્ચે અસંતુલિત છે. અલબત્ત, નેટવર્ક હાર્ડવેર પેકેટોના સમાવિષ્ટોનું વિશ્લેષિત કરતું નથી અને તેથી પ્રતિ સેકન્ડ 4M પેકેટો કરતાં વધુ ખેંચી શકે છે, મેટ્રિક્સનો ઉલ્લેખ ન કરવો કે જેના વિશે તે બિલકુલ જાણતું નથી. જો આપણે ધ્યાનમાં લઈએ કે દરેક પેકેટમાં એક સમયે મેટ્રિક્સ આવતા નથી, તો અમે આ સ્થાન પર કોઈ પણ કાર્યપ્રદર્શન સમસ્યાઓની આગાહી કરતા નથી. જો સર્વર ક્રેશ થાય છે, તો નેટવર્ક ઉપકરણ ઝડપથી (1-2 સેકન્ડમાં) આ હકીકતને શોધી કાઢે છે અને ક્રેશ થયેલા સર્વરને રોટેશનમાંથી દૂર કરે છે. આના પરિણામે, નિષ્ક્રિય (એટલે ​​​​કે, બિન-નેતા) નોડ્સ ચાર્ટ પરના ડ્રોડાઉનને ધ્યાનમાં લીધા વિના વ્યવહારીક રીતે ચાલુ અને બંધ કરી શકાય છે. અમે જે મહત્તમ ગુમાવીએ છીએ તે મેટ્રિક્સનો ભાગ છે જે છેલ્લી સેકન્ડમાં આવ્યા હતા. લીડરની અચાનક ખોટ/શટડાઉન/સ્વિચ હજુ પણ નાની વિસંગતતા પેદા કરશે (30 સેકન્ડનો અંતરાલ હજુ સુમેળ નથી), પરંતુ જો નોડ્સ વચ્ચે સંચાર હોય, તો આ સમસ્યાઓ ઘટાડી શકાય છે, ઉદાહરણ તરીકે, સિંક્રોનાઇઝેશન પેકેટો મોકલીને .

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

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

વિકાસ દરમિયાન ઘણી વધુ સમસ્યાઓ મેટ્રિક્સ પ્રાપ્ત કરવા માટે જવાબદાર નેટવર્ક ભાગને કારણે થઈ હતી. નેટવર્ક ફ્લોને અલગ-અલગ એન્ટિટીમાં વિભાજિત કરવાનો મુખ્ય ધ્યેય પ્રવાહ દ્વારા વિતાવેલા સમયને ઘટાડવાની ઇચ્છા હતી. નથી સોકેટમાંથી ડેટા વાંચવા માટે. અસુમેળ UDP અને નિયમિત recvmsg નો ઉપયોગ કરતા વિકલ્પો ઝડપથી અદૃશ્ય થઈ ગયા: પ્રથમ ઇવેન્ટ પ્રોસેસિંગ માટે ખૂબ જ વપરાશકર્તા-જગ્યા CPU વાપરે છે, બીજાને ઘણા બધા સંદર્ભ સ્વીચોની જરૂર છે. તેથી હવે તેનો ઉપયોગ થાય છે recvmmsg મોટા બફર્સ સાથે (અને બફર્સ, સજ્જન અધિકારીઓ, તમારા માટે કંઈ નથી!). રેગ્યુલર UDP માટે સપોર્ટ પ્રકાશ કેસો માટે આરક્ષિત છે જ્યાં recvmmsg ની જરૂર નથી. મલ્ટિમેસેજ મોડમાં, મુખ્ય વસ્તુ હાંસલ કરવી શક્ય છે: મોટાભાગનો સમય, નેટવર્ક થ્રેડ OS કતારને રેક કરે છે - સોકેટમાંથી ડેટા વાંચે છે અને તેને યુઝરસ્પેસ બફરમાં સ્થાનાંતરિત કરે છે, ફક્ત ક્યારેક ક્યારેક ભરેલા બફરને આપવા માટે સ્વિચ કરે છે. એગ્રીગેટર્સ સોકેટમાં કતાર વ્યવહારીક રીતે એકઠી થતી નથી, ડ્રોપ કરેલા પેકેટોની સંખ્યા વ્યવહારીક રીતે વધતી નથી.

નોંધણી

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

છેલ્લે, ચાર્ટ પ્રેમીઓ માટે કેટલાક ચાર્ટ્સ.

દરેક સર્વર માટે ઇનકમિંગ મેટ્રિક્સની સંખ્યા પરના આંકડા: 2 મિલિયનથી વધુ MPS.

નોડ્સમાંથી એકને અક્ષમ કરવું અને ઇનકમિંગ મેટ્રિક્સનું ફરીથી વિતરણ કરવું.

આઉટગોઇંગ મેટ્રિક્સ પરના આંકડા: ફક્ત એક નોડ હંમેશા મોકલે છે - ધાડ બોસ.

વિવિધ સિસ્ટમ મોડ્યુલોમાં ભૂલોને ધ્યાનમાં લેતા, દરેક નોડની કામગીરીના આંકડા.

ઇનકમિંગ મેટ્રિક્સની વિગતો (મેટ્રિક નામો છુપાયેલા છે).

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

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

આટલું જ કહેવાતું હતું, લોકો, અમારા હાથી ખરીદો!

સોર્સ: www.habr.com