Edo monolito batekin zorigaiztoko konpainia bakoitza bere erara dohakabea da.
Dodo IS sistemaren garapena berehala hasi zen, Dodo Pizza negozioa bezala, 2011n. Negozio-prozesuen erabateko eta erabateko digitalizazioaren ideian oinarritzen zen, eta , orduan ere 2011n galdera eta eszeptizismo asko eragin zituena. Baina 9 urte daramatzagu bide honetatik jarraitzen, gure garapenarekin, monolito batekin hasi zena.
Artikulu hau "Zergatik berridatzi arkitektura eta eskala handiko eta epe luzeko aldaketak egin?" galderei egindako "erantzuna" da. itzuli aurreko artikulura . Dodo IS-en garapena nola hasi zen, jatorrizko arkitektura nolakoa zen, modulu berriak nola agertu ziren eta eskala handiko aldaketak zer arazoren eraginez egin behar izan zuten hasiko naiz.
Artikulu sorta "Zer da Dodo IS?" buruz kontatzen du:
-
Dodo IS-en lehen monolitoa (2011-2015). (hemen zaude)
-
.
-
Bezeroaren alboko bidea: oinarriaren gaineko fatxada (2016-2017). (Abian...)
-
Egiazko mikrozerbitzuen historia. (2018-2019). (Abian...)
-
Monolitoaren zerraketa amaitu eta arkitektura egonkortzea. (Abian...)
Hasierako arkitektura
2011n, Dodo IS arkitekturak itxura hau zuen:
Arkitekturako lehen modulua eskaera onartzea da. Negozio-prozesua hau izan zen:
-
bezeroak pizzeria deitzen du;
-
arduradunak telefonoa hartzen du;
-
telefono bidez eskaera bat onartzen du;
-
paraleloan betetzen du eskaerak onartzeko interfazean: bezeroari buruzko informazioa, eskaeraren xehetasunak, entrega helbidea kontuan hartzen ditu.
Informazio sistemaren interfazeak horrelako zerbait zuen...
2011ko urriko lehen bertsioa:
Lehen eskaera hartzeko modulua garatzeko baliabideak mugatuak ziren. Asko egin behar izan genuen, azkar eta talde txiki batekin. Talde txiki bat etorkizuneko sistema osoaren oinarriak ezarri zituzten 2 garatzaile dira.
Haien lehen erabakiak teknologia pilaren patua zehaztu zuen:
-
Backend-a ASP.NET MVC-n, C# hizkuntzan. Garatzaileak dotnetchiki ziren, pila hau ezaguna eta atsegina zen haientzat.
-
Frontend Bootstrap eta JQuery-n: norberak idatzitako estilo eta script-en erabiltzaile-interfazeak.
-
MySQL datu-basea: lizentzia kosturik gabe, erabiltzeko erraza.
-
Windows Server-eko zerbitzariak, .NET orduan Windows-en soilik egon zitekeelako (ez dugu Mono eztabaidatuko).
Fisikoki, hori guztia βdedic at the hosterβ-ean adierazten zen.
Eskaerak hartzeko Aplikazioen Arkitektura
Orduan denek jada mikrozerbitzuei buruz hitz egiten zuten, eta SOA proiektu handietan erabili zen 5 urtez, adibidez, WCF 2006an kaleratu zen. Baina gero irtenbide fidagarria eta frogatua aukeratu zuten.
Hemen dago.
Asp.Net MVC Razor da, zeinak, inprimaki batek edo bezero batek eskatuta, HTML orri bat errendatzen du zerbitzariaren errendaketarekin. Bezeroan, CSS eta JS scriptek dagoeneko bistaratzen dute informazioa eta, behar izanez gero, AJAX eskaerak egiten dituzte JQuery bidez.
Zerbitzariko eskaerak *Controller klaseetan amaitzen dira, non metodoan azken HTML orria prozesatzea eta sortzea gertatzen den. Kontrolatzaileek *Zerbitzuak izeneko logika-geruza bati eskaerak egiten dizkiote. Zerbitzu bakoitza negozioaren alderdi bati zegokion:
-
Adibidez, DepartmentStructureService-k pizzeriei, sailei buruzko informazioa eman zuen. Saila frankiziadun bakar batek zuzentzen duen pizzeria talde bat da.
-
ReceivingOrdersService-k eskaeraren osaera onartu eta kalkulatu du.
-
Eta SmsService-k SMSak bidali zituen API zerbitzuetara SMSak bidaltzeko.
Zerbitzuek datu-baseko datuak prozesatzen dituzte, negozio-logika gordeta. Zerbitzu bakoitzak *Biltegi bat edo gehiago zituen, dagokion izenarekin. Dagoeneko datu-basean gordetako prozeduren kontsultak eta mapatzaileen geruza bat zeuden. Biltegietan negozio-logika zegoen, batez ere txosten-datuak igortzen zituztenetan asko. ORM ez zen erabili, denek eskuz idatzitako sql-an oinarritzen ziren.
Domeinu-ereduaren geruza bat eta laguntzaile-klase arruntak ere bazeuden, adibidez, eskaera gordetzen zuen Order klasea. Leku berean, geruzan, bistaratzeko testua aukeratutako monetaren arabera bihurtzeko laguntzaile bat zegoen.
Hori guztia eredu baten bidez irudikatu daiteke:
Ordena Bidea
Demagun hasierako modu sinplifikatu bat ordena hori sortzeko.
Hasieran, gunea estatikoa zen. Prezioak zituen gainean, eta gainean - telefono zenbaki bat eta "Pizza nahi baduzu, deitu zenbakira eta eskatu" inskripzioa. Ordenatzeko, fluxu sinple bat ezarri behar dugu:
-
Bezeroak prezioak dituen gune estatiko bat bisitatzen du, produktuak hautatzen ditu eta gunean ageri den zenbakira deitzen du.
-
Bezeroak eskaeran gehitu nahi dituen produktuak izendatzen ditu.
-
Bere helbidea eta izena ematen ditu.
-
Operadoreak eskaera onartzen du.
-
Eskaera onartutako eskaeren interfazean bistaratzen da.
Dena menua bistaratzen hasten da. Saioa hasita dagoen erabiltzaile-operadoreak eskaera bakarra onartzen du aldi berean. Hori dela eta, zirriborroa saskia bere saioan gorde daiteke (erabiltzailearen saioa memorian gordetzen da). Produktuak eta bezeroen informazioa dituen Saskia objektu bat dago.
Bezeroak produktuari izena ematen dio, operadoreak klik egiten du + produktuaren ondoan, eta eskaera bat bidaltzen zaio zerbitzariari. Produktuari buruzko informazioa datu-basetik ateratzen da eta produktuari buruzko informazioa saskira gehitzen da.
Kontuan izan. Bai, hemen ezin duzu produktua datu-basetik atera, baina frontend-etik transferitu. Baina argitasunerako, datu-baseko bidea zehatz-mehatz erakutsi nuen.
Ondoren, sartu bezeroaren helbidea eta izena.
"Sortu eskaera" sakatzen duzunean:
-
Eskaera OrderController.SaveOrder() helbidera bidaltzen da.
-
Saiotik Saskia lortzen dugu, behar dugun kantitatean daude produktuak.
-
Saskia bezeroari buruzko informazioarekin osatzen dugu eta ReceivingOrderService klaseko AddOrder metodora pasatzen dugu, non datu-basean gordetzen den.
-
Datu-baseak taulak ditu eskaera, eskaeraren osaera, bezeroa, eta guztiak konektatuta daude.
-
Eskaerak bistaratzeko interfazea joan eta azken eskaerak atera eta bistaratzen ditu.
Modulu berriak
Agindua hartzea garrantzitsua eta beharrezkoa zen. Ezin duzu pizza negoziorik egin saltzeko eskaerarik ez baduzu. Hori dela eta, sistema funtzionalitatea lortzen hasi zen - 2012tik 2015era gutxi gorabehera. Denbora horretan, sistemaren hainbat bloke agertu ziren, deituko ditudanak moduluak, zerbitzu edo produktu kontzeptuaren aldean.
Modulua negozio-helburu komun batzuek elkartzen duten funtzio multzoa da. Aldi berean, fisikoki aplikazio berean daude.
Moduluak sistema bloke dei daitezke. Adibidez, hau txostenak egiteko modulua, administratzaile interfazeak, , baimena. Hauek guztiak erabiltzailearen interfaze desberdinak dira, batzuek estilo bisual desberdinak dituzte. Aldi berean, dena aplikazio baten, exekutatzen ari den prozesu baten esparruan dago.
Teknikoki, moduluak Arlo gisa diseinatu ziren (halako ideia bat ere mantendu zen ). Fitxategi bereiziak zeuden frontend-erako, ereduetarako, baita beren kontroladore-klaseetarako ere. Ondorioz, sistema honetatik eraldatu zen ...
... honetan sartu:
Modulu batzuk gune ezberdinen bidez inplementatzen dira (proiektu exekutagarria), guztiz bereizitako funtzionaltasun baten ondorioz eta, neurri batean, garapen apur bat bereizi eta bideratuago baten ondorioz. Hau:
-
Web - gunea dodopizza.ru.
-
Esportatu: Dodo IS-en txostenak igotzen 1C-rako.
-
Personal - Langilearen kontu pertsonala. Bereiz garatu zen eta bere sarrera-puntu eta diseinu bereizia ditu.
-
fs β estatika ostatatzeko proiektua. Geroago urrundu ginen, estatiko guztiak Akamai CDNra eramanez.
Gainerako blokeak BackOffice aplikazioan zeuden.
Izenaren azalpena:
-
Kutxazaina - Jatetxeko kutxazaina.
-
ShiftManager - "Shift Manager" rolerako interfazeak: pizzerien salmentei buruzko estatistikak, produktuak gelditzeko zerrendan jartzeko gaitasuna, ordena aldatu.
-
OfficeManager - "Pizzeria kudeatzailea" eta "frankiziatua" roletarako interfazeak. Hona hemen pizzeria bat ezartzeko funtzioak, bere bonus promozioak, langileak jaso eta lan egiteko, txostenak.
-
PublicScreens - pizzerietan zintzilik dauden telebista eta tabletentzako interfazeak. Telebistetan menuak, publizitate-informazioa, eskaeraren egoera bidaltzean.
Zerbitzu geruza komun bat, Dodo.Core domeinu klase bloke komun bat eta oinarri komun bat erabili zituzten. Batzuetan, oraindik ere elkarren arteko trantsizioetan eraman dezakete. Banakako guneak barne, hala nola dodopizza.ru edo personal.dodopizza.ru, zerbitzu orokorretara joan ziren.
Modulu berriak agertu zirenean, lehendik sortutako zerbitzuen kodea, gordetako prozedurak eta datu-baseko taulak ahalik eta gehien berrerabiltzen saiatu ginen.
Sisteman egindako moduluen eskala hobeto ulertzeko, hona hemen 2012ko eskema bat garapen planekin:
2015erako, dena zegoen mapan eta are gehiago ekoizpenean.
-
Eskaeraren onarpena Harremanetarako Zentroko bloke bereizi batean hazi da, non eskaria operadoreak onartzen duen.
-
Pizzerietan zintzilik dauden menuak eta informazioa zeuden pantaila publikoak zeuden.
-
Sukaldeak eskaera berri bat iristen denean "Pizza berria" ahots-mezua automatikoki erreproduzitzen duen modulu bat du, eta mezulariaren faktura ere inprimatzen du. Horrek asko errazten ditu sukaldeko prozesuak, langileak eragiketa sinple ugarirekin distraitzea ahalbidetzen du.
-
Bidalketa-unitatea Bidalketa-ordainketa bereizi bihurtu zen, non eskaera aurretik txanda hartu zuen mezulariari igortzen zitzaion. Bere lanaldia kontuan hartu zen nominak kalkulatzeko.
Aldi berean, 2012tik 2015era, 10 garatzaile baino gehiago agertu ziren, 35 pizzeria ireki, sistema Errumaniara zabaldu eta Estatu Batuetan saltokiak irekitzeko prestatu ziren. Garatzaileek jada ez zituzten zeregin guztiak jorratzen, taldeetan banatuta zeuden. bakoitza bere sistemaren zatian espezializatua.
Problems
Arkitekturagatik barne (baina ez bakarrik).
Kaosa oinarrian
Oinarri bat erosoa da. Koherentzia lor daiteke bertan, eta datu-base erlazionaletan eraikitako tresnen kontura. Berarekin lan egitea ezaguna eta erosoa da, batez ere taula gutxi eta datu gutxi badaude.
Baina 4 urteko garapenean, datu-baseak 600 taula inguru, 1500 gordetako prozedura izan zituen, eta horietako askok logika ere bazuten. Ala ere, gordetako prozedurek ez dute abantaila handirik ekartzen MySQL-rekin lan egiten denean. Oinarriak ez ditu cachean gordetzen, eta haietan logika gordetzeak garapena eta arazketa zaildu egiten ditu. Kodea berrerabiltzea ere zaila da.
Taula askok ez zuten indize egokirik, nonbait, aitzitik, aurkibide asko zeuden, eta horrek txertatzea zailtzen zuen. 20 taula inguru aldatzea beharrezkoa zen - eskaera bat sortzeko transakzioak 3-5 segundo inguru iraun zezakeen.
Tauletako datuak ez ziren beti formarik egokienak izan. Nonbait desnormalizazioa egin behar zen. Aldian behin jasotako datuen zati bat XML egitura moduan zegoen zutabe batean, eta horrek exekuzio-denbora handitu zuen, kontsultak luzatu eta garapena zaildu zuen.
Mahai berdinetara oso ekoizten ziren eskaera heterogeneoak. Mahai herrikoiek bereziki sufritu zuten, goian aipatutako taulak bezala. aginduak edo mahaiak Pizza denda. Sukaldean interfaze operatiboak bistaratzeko erabiltzen ziren, analisiak. Beste gune bat haiekin harremanetan jarri zen (), non une bakoitzean eskaera asko etor zitezkeen bat-batean.
Datuak ez ziren batu eta kalkulu asko hegan egiten ziren oinarria erabiliz. Horrek alferrikako kalkuluak eta karga gehigarriak sortu zituen.
Askotan kodea datu-basera joaten zen ezin zuenean. Nonbait ez zegoen nahikoa ontziraturiko eragiketa, nonbait beharrezkoa izango litzateke eskaera bat hainbatetara zabaldu kodearen bidez, azkartu eta fidagarritasuna areagotzeko.
Kohesioa eta lausotzea kodean
Negozioaren partez arduratu behar ziren moduluek ez zuten zintzotasunez egin. Horietako batzuek eginkizunen bikoizketak zituzten roletarako. Adibidez, bere hirian sarearen marketin-jardueraz arduratzen den tokiko merkatari batek "Admin" interfazea (promozioak sortzeko) eta "Office Manager" interfazea (promozioak negozioan duten eragina ikusteko) erabili behar zituen. Jakina, bi modulu barruan bonus sustapenekin funtzionatzen zuen zerbitzu bera erabiltzen zuten.
Zerbitzuek (proiektu handi monolitiko baten barruan dauden klaseak) elkarri dei liezaiokete euren datuak aberasteko.
Datuak gordetzen dituzten eredu klaseekin, kodean lana ezberdin egin zen. Nonbait zeuden eraikitzaileak, zeinen bidez beharrezko eremuak zehaztea posible zen. Nonbait jabetza publikoen bidez egiten zen hori. Jakina, datu-basetik datuak lortzea eta eraldatzea askotarikoa zen.
Logika kontrolagailuetan edo zerbitzu klaseetan zegoen.
Badirudi arazo txikiak direla, baina garapena asko moteldu eta kalitatea murriztu zuten, ezegonkortasuna eta akatsak eraginez.
Garapen handi baten konplexutasuna
Garapenean bertan zailtasunak sortu ziren. Beharrezkoa zen sistemaren bloke desberdinak egitea, eta paraleloan. Osagai bakoitzaren beharrak kode bakarrean egokitzea gero eta zailagoa zen. Ez zen erraza izan ados jartzea eta osagai guztiak aldi berean atsegin izatea. Horri teknologiaren mugak gehitu zitzaizkion, batez ere oinarriari eta frontend-ari dagokionez. Beharrezkoa zen jQuery maila altuko esparruetara alde batera utzi, batez ere bezeroen zerbitzuei dagokienez (webgunea).
Sistemaren zati batzuetan, horretarako egokiagoak diren datu-baseak erabil litezke.. Esate baterako, geroago Redis-etik CosmosDB-ra pasatzearen erabilera kasua izan genuen eskaera-saski bat gordetzeko.
Beren eremuan parte hartzen duten talde eta garatzaileek argi eta garbi nahi zuten beren zerbitzuetarako autonomia gehiago, bai garapenari eta baita zabalkundeari dagokionez ere. Bateratu gatazkak, askatu arazoak. 5 garatzaileentzat arazo hau hutsala bada, 10ekin, eta are gehiago aurreikusitako hazkundearekin, dena larriagoa izango litzateke. Eta aurretik mugikorretarako aplikazio baten garapena izango zen (2017an hasi zen, eta 2018an ).
Sistemaren zati ezberdinek egonkortasun maila desberdinak behar zituzten, baina sistemaren konektibitate handia dela eta, ezin izan dugu hau eman. Admin panelean funtzio berri baten garapenean akats bat gertatu zitekeen webgunean eskaera bat onartzean, kodea ohikoa eta berrerabilgarria delako, datu-basea eta datuak ere berdinak direlako.
Seguruenik, akats eta arazo horiek saihestea posible izango litzateke halako arkitektura monolitiko-modular baten baitan: ardura banaketa egin, kodea zein datu-basea birfaktorea, geruzak elkarrengandik argi bereizi, kalitatea egunero kontrolatu. Baina aukeratutako arkitektura-irtenbideek eta sistemaren funtzionalitatearen hedapen azkarrean arreta jartzeak egonkortasun-arazoak ekarri zituen.
Power of the Mind blogak jatetxeetako kutxa erregistratzaileak nola jartzen dituen
Pizzeria sarearen (eta zamaren) hazkundeak erritmo berean jarraituko balu, pixka bat igaro ondoren, jaitsierak sistemak ez luke gora egingo. 2015erako aurre egiten hasi ginen arazoak ondo ilustratzen ditu, hona hemen halako istorio bat.
Blogean"β sare osoaren urteko diru-sarreren datuak erakusten zituen widget bat zen. Trepeta datu hauek eskaintzen dituen Dodo API publikora sartu da. Estatistika hau une honetan eskuragarri dago . Widgeta orri guztietan erakusten zen eta 20 segundoz behin tenporizadore batean eskaerak egiten zituen. Eskaera api.dodopizza.ru helbidera joan zen eta honako hau eskatu zuen:
-
sareko pizzeria kopurua;
-
sareko diru-sarrera osoa urte hasieratik;
-
gaurko diru-sarrerak.
Diru-sarreren estatistiken eskaera zuzenean datu-basera joan zen eta eskaerei buruzko datuak eskatzen hasi ziren, datuak joan-etorrian batzen eta zenbatekoa ematen.
Jatetxeetako kutxazainek eskaera-taula berera joan ziren, gaurko jasotako eskaeren zerrenda deskargatu zuten eta eskaera berriak gehitu zitzaizkion. Kutxa erregistratzaileek 5 segunduro edo orria freskatzen zuten eskaerak egiten zituzten.
Diagramak itxura hau zuen:
Udazken batean, Fiodor Ovtxinnikov-ek artikulu luze eta ezagun bat idatzi zuen bere blogean. Jende asko etorri zen blogera eta dena arretaz irakurtzen hasi zen. Etorritako pertsona bakoitzak artikulua irakurtzen zuen bitartean, diru-sarreren widgetak ondo funtzionatu zuen eta APIa eskatzen zuen 20 segundoro.
APIak biltegiratutako prozedura bat deitu zuen, urtea hasi zenetik sareko pizzeria guztien eskaera guztien batura kalkulatzeko. Agregazioa eskaerak taulan oinarritzen zen, oso ezaguna dena. Une horretan irekita dauden jatetxe guztietako kutxazain guztiak bertara joaten dira. Kutxazainek erantzuteari utzi zioten, eskaerak ez ziren onartu. Gunetik ere ez ziren onartu, ez ziren aztarnatzailean agertzen, txanda-zuzendariak ezin zituen bere interfazean ikusi.
Hau ez da istorio bakarra. 2015eko udazkenerako, ostiralero sistemaren karga kritikoa zen. Hainbat aldiz desaktibatu genuen API publikoa, eta behin, gunea ere itzali behar izan genuen, ezerk ez zuelako laguntzen. Zama astunetan itzaltzeko agindua zuten zerbitzuen zerrenda ere bazegoen.
Hemendik aurrera kargarekin eta sistema egonkortzearen aldeko gure borroka hasten da (2015eko udazkenetik 2018ko udazkenera arte). Orduan gertatu zen"". Gainera, batzuetan porrotak ere gertatu ziren, batzuk oso sentikorrak ziren, baina ezegonkortasun aldi orokorra gainditutzat jo daiteke.
Negozioaren hazkunde azkarra
Zergatik ezin izan da berehala egin? Ikusi besterik ez dago hurrengo taulak.
2014-2015ean ere Errumanian irekiera bat egon zen eta AEBetan irekiera bat prestatzen ari ziren.
Sarea oso azkar hazi zen, herrialde berriak ireki ziren, pizzerien formatu berriak agertu ziren, adibidez, pizzeria bat ireki zen janari-lekuan. Horrek guztiak arreta handia behar zuen bereziki Dodo IS funtzioen hedapenean. Funtzio guzti hauek gabe, sukaldean jarraipena egin gabe, sistemako produktuak eta galerak kontabilizatu gabe, elikadura-aretoan agindu baten igorpena bistaratu gabe, nekez hitz egingo ginateke arkitektura βzuzenaβ eta ikuspegi βzuzenaβ. garapena orain.
Arkitektura garaiz berrikusteko eta, oro har, arazo teknikoei arreta jartzeko beste oztopo bat 2014ko krisia izan zen. Horrelako gauzek gogor jotzen dute taldeek hazteko aukerak, batez ere Dodo Pizza bezalako negozio gazte batentzat.
Lagundu duten irtenbide azkarrak
Arazoak behar diren irtenbideak. Ohikoki, soluzioak 2 taldetan bana daitezke:
-
Sua itzali eta segurtasun tarte txiki bat ematen duten eta aldatzeko denbora irabazten diguten azkarrak.
-
Sistemikoa eta, beraz, luzea. Modulu batzuen biringeniaritza, arkitektura monolitiko baten zatiketa zerbitzu bereizietan (gehienak ez dira batere mikro zerbitzuak, makro zerbitzuak baizik, eta zerbait dago. ).
Aldaketa azkarren zerrenda lehorra honako hau da:
Eskalatu oinarrizko maisua
Noski, kargari aurre egiteko egiten den lehen gauza zerbitzariaren ahalmena handitzea da. Hau datu-base nagusirako eta web zerbitzarietarako egin zen. Ai, hau muga jakin batera bakarrik posible da, orduan garestiegia bihurtzen da.
2014az geroztik, Azurera joan gara, garai hartan gai honi buruz ere idatzi genuen artikuluan "". Baina oinarrirako zerbitzariaren igoera batzuen ondoren, kostuaren aurka egin zuten.
Irakurtzeko oinarrizko erreplikak
Oinarrirako bi erreplika egin ziren:
Irakurri Erreplika erreferentzia-eskaeretarako. Direktorioak, mota, hiria, kalea, pizzeria, produktuak (poliki-poliki aldatzen den domeinua) eta atzerapen txiki bat onargarria den interfazeetan irakurtzeko erabiltzen da. Erreplika hauetako 2 ziren, haien erabilgarritasuna bermatu genuen maisuen moduan.
Irakurri Erreplika Txosten-eskaeretarako. Datu-base honek erabilgarritasun txikiagoa zuen, baina txosten guztiak bertara joan ziren. Datuak birkalkulatzeko eskaera handiak izan ditzatela, baina ez diete datu-base nagusiei eta interfaze operatiboei eragiten.
Cacheak kodean
Kodean ez zegoen inon cacherik (inola ere). Horrek kargatutako datu-baserako eskaera gehigarriak ekarri zituen, ez beti beharrezkoak. Cacheak lehen bai memorian eta kanpoko cache zerbitzu batean zeuden, hau da, Redis. Dena baliogabetuta zegoen denboraren arabera, ezarpenak kodean zehaztu ziren.
Backend zerbitzari anitz
Aplikazioaren backend-a ere eskalatu behar zen lan-karga areagotu ahal izateko. Beharrezkoa zen iis-zerbitzari batetik kluster bat egitea. Berriz programatu dugu memoriatik RedisCache-ra, round robin-ekin karga-orekatzaile soil baten atzean hainbat zerbitzari egin ahal izateko. Hasieran, Redis bera erabiltzen zen cacheetarako, gero hainbatetan banatu zen.
Ondorioz, arkitektura zailagoa bihurtu da ...
β¦ baina tentsioaren zati bat kendu zen.
Eta orduan kargatutako osagaiak berregin behar izan ziren, eta hori egin genuen. Hurrengo zatian honetaz hitz egingo dugu.
Iturria: www.habr.com