Zerbitzariaren suntsipenarekin gure laser bilaketa nola antolatu zen kontatzen jarraitzen dugu. Hasi aurrekoan .
Guztira, jokoaren backendak 6 unitate arkitektoniko zituen, artikulu honetan aztertuko ditugunak:
- Joko-mekanismoez arduratzen ziren joko-entitateen backend-a
- Backend eta guneko datuak trukatzeko autobusa VPS-n
- Backend eskaeren (jokoaren elementuak) itzultzailea Arduinora eta tokiko hardwarera
- Arduino, erreleak kontrolatzeko ardura zuena, itzultzailearen aginduak jaso eta benetako lana egin zuen
- Benetako gailuak: haizagailua, girlandak, solairuko lanparak, etab.
- Frontend - Falcon webgunea bera, non jokalariek gailuak kontrolatzen zituzten
Goazen horietako bakoitza.
Joko-entitateen backend-a
Backend-a udaberriko abioko aplikazio gisa inplementatu zen: hainbat atseden kontrolagailu, websocket amaierako puntu bat eta joko logika duten zerbitzuak zituen.
Hiru kontrolagailu baino ez zeuden:
- Megatron. Egungo Megatron orria GET eskaeren bidez bidali zen: boterea piztu aurretik eta ondoren. Laserra POST eskaeraren bidez jaurti da.
- Orrialde tildeak mapatzea, orriaren izenaren arabera hornitzeko. Tildek esportatzeko orriak ekoizten ditu jatorrizko izenekin, baina barneko IDarekin eta betetze-informazioarekin.
- Captcha kontroladore sasi-karga handiko zerbitzariaren captcha zerbitzatzeko.
Websocket amaierako puntua tramankuluak kontrolatzeko erabiltzen zen: lanparak, girlandak eta letrak. Jokalari guztiei gailuaren uneko egoera sinkronikoki bistaratzeko aukeratu zen: piztuta edo itzalita dagoen, aktibo edo ez, letren zein kolore dagoen horman argituta dagoen une honetan. Laserra pizteko zeregina apur bat zailagoa izan dadin, baimena gehitu genion girlandari eta laserra, login eta pasahitz berdinarekin admin/admin.
Jokalariek proba egin dezakete girlanda piztuz eta gauza bera errepikatu laserrarekin.
Saio-hasiera-pasahitz bikote hutsala aukeratu genuen jokalariak alferrikako hautapenarekin ez oinazetzeko.
Zeregin apur bat interesgarriagoa izan dadin, mongodb-ko objektuen IDak gailuen identifikatzaile gisa erabili ziren gelan.
ObjectId-ek denbora-zigilu bat dauka: ausazko bi balio, horietako bat gailuaren identifikatzailean oinarrituta hartzen da, eta bigarrena hura sortzen duen prozesuaren pid eta kontagailuaren balioan oinarrituta. Aldizka eta pid prozesu ezberdinekin sortutako identifikatzaileak egin nahi nituen, baina kontagailu komun batekin, laser gailuen identifikatzailearen hautaketa interesgarriagoa izan zedin. Hala ere, azkenean, denak kontagailuaren balioan soilik desberdinak ziren identifikatzaileekin hasi ziren. Honek urratsa sinpleegia bihurtu izana eta objectId egituraren azterketa behar ez izatea.
Backend eskaeren itzultzailea
, tenporizadoreak landu eta jokoen abstrakzioetatik eredu fisiko batera itzuli zituena. Adibidez, "piztu zoruko lanpara" β "piztu N2 errelea".
Scripta RabbitMQ ilarara konektatu eta eskaerak ilaratik Arduinora transferitu zituen. Argi paraleloen aldatzearen logika ere ezarri zuen: gailu batzuekin batera, haietako argia pizten zen, adibidez, hasiera batean Megatroni energia ematen zitzaionean, eszenatokiko argiarekin argitzen zen. Eszena osoaren zinemagintzarako argiztapen-diseinua Ilya Serov gure proiektuko ekoizle eta ekoizle-diseinatzailearen lan bikainari buruzko istorio bereizia da, eta aparteko argitalpen batean kontatuko dugu.
Itzultzailea ere arduratzen zen birringailua abiarazteko tenporizadorea erabiliz eta irudia telebistara helarazteko logikaz: birringailua abiarazteko tenporizadorea, kapibara garrasi bat, jokoaren amaierako iragarkia.
Megatron tokena sortzeko logika nola egituratu zen
Proba jaurtiketa
25 segundoro token berri bat sortzen zen eta laserra 10 segundoz pizteko erabil zitekeen 10/255 potentzian. Esteka .
Ondoren, laserra minutu 1 hoztu zen; denbora horretan ez zegoen erabilgarri eta ez zuen jaurtiketa eskaera berririk onartu.
Botere hori ez zen nahikoa sokatik erretzeko, baina edozein jokalarik Megatron jaurti zezakeen eta laser izpia martxan ikusi.
Tokena sortzeko MD5 hashing algoritmoa erabili da. Eta eskema ondo atera zen MD5etik MD5 + kontagailua + sekretua Borroka-token batentzat eta sekreturik gabe proba-token batentzat.
MD5 Pavelek, gure backender-ak, egin zuen proiektu komertzial baten erreferentzia da. Duela urte pare bat proiektu honek MD5 erabiltzen zuen, eta proiektuaren arkitektoari zifratze algoritmo zaharkitua zela esan zionean, MD5etik MD5 erabiltzen hasi ziren. Ahalik eta proiektu noobena egitea erabaki genuenez, dena gogoratu zuen eta erreferentzia txiki bat egitea erabaki zuen.
Borrokako jaurtiketa
Megatron-en borroka modua %100eko laser potentzia da 3 watt-tan. Hau nahikoa da 2 minutuz pisuari eusten zion sokatik erretzeko, akuarioa apurtzeko eta zerbitzaria urez gainezkatzeko.
Proiektuaren Github-i buruzko argibide batzuk utzi genituen: hots, tokenak sortzeko kodea, bertatik uler zitekeen proba eta borroka tokenak kontagailuaren adierazle berean oinarrituta sortzen direla. Borroka token baten kasuan, kontagailuaren balioaz gain, gatz bat ere erabiltzen da, mamia hau aldatzearen historian ia guztiz geratu dena, azken bi karaktereak izan ezik.
Datu hauek ezagututa, gatzaren azken 2 sinboloak ordenatu eta, egia esan, Lost-eko zenbakiak, sistema hamaseimalera bihurtuta, erabili zirela jakin zen.
Ondoren, jokalariek kontagailuaren balioa harrapatu (probaren tokena aztertuz) eta borroka token bat sortu behar zuten hurrengo kontagailuaren balioa eta aurreko urratsean hautatutako gatza erabiliz.
Kontagailua probako jaurtiketa bakoitzean eta 25 segundoz behin handitzen da. Ez genuen honi buruz inon idatzi, joko txikiko sorpresa bat izan behar zen.
Captcha interakzio zerbitzua
Jokoen munduan, haizagailua pizteko eta iradokizun batekin flipchart irekitzeko kargatu behar zen captcha bera zen. Kameraren ondoan ordenagailu eramangarri bat zegoen karga kontrolatzeko.
Uneko karga gisa monitorizazioan bistaratu behar dena kalkulatu nuen: tenperatura eta CPU Fan. Metrikoak denbora-basearen datu-basera transferitu eta grafana-k marraztu zituen.
Azken 5 segundoetan captcha bistaratzeko 50 eskaera baino gehiago egon baziren, orduan karga pauso kopuru finko + ausaz handitu zen. Kalkulua zen %100eko karga bi minututan lor zitekeela.
Izan ere, azken jokoan bistaratzen zena baino logika gehiago zegoen zerbitzuan: monitorea PUZaren haizagailuaren biraketa soilik ikusten zen moduan jarri genuen.
Bilaketa hasieran Grafan Falcon webgunetik eskuragarri utzi nahi zuten. Baina backend aplikazioaren txosteneko springboot metrikoak ere jasotzen zituen, ez genuen garbitzeko astirik izan, beraz, sarbidea blokeatzea erabaki genuen. Eta arrazoiz - bilaketaren hasieran ere, jokalari batzuek aplikazioa springboot esparruan idatzita zegoela asmatu zuten eta zerbitzu batzuen izenak zulatu ere egin zituzten.
Hosting eta datu-busa
Backend-etik webgunera informazioa transferitzeko tresna, RabbitMQ exekutatzen ari zen VPS zerbitzaria.
Backend-a eta datu-busa piztuta mantendu ziren . Bere potentzia pantailan ikusten zenuen ordenagailuaren parekoa zen: 2 nukleoko VPS bat, bi gigabyte RAM dituena. Tarifa baliabideengatik kobratu zen, karga gailurra egun batzuetarako bakarrik aurreikusi baitzen - hau da gure bezeroek denbora laburrean VPS kargatzeko asmoa dutena. Orduan, karga espero genuena baino handiagoa zela eta tarifa finko bat errentagarriagoa izango litzateke. Bilaketa bat egiten baduzu, aukeratu lineako tarifak .
Zerbitzaria DDoSatik babesteko, Cloudflare erabili dugu.
Esan beharra dago VPSak ohore handiz jasan zuela dena.
Arduino, erreleak kontrolatzeko ardura zuena, itzultzailearen aginduak jaso eta benetako lana egin zuen
Hau da proiektuaren hardware zatiari buruzko hurrengo artikuluaren gaia gehiago: backend-ak errele zehatz bat pizteko eskaerak bidali besterik ez du egin. Gertatu zen backend-ak ia entitate guztiak ezagutzen zituela eta haren eskaerak "aktibatu entitate hau" zirudien. Gunearen hasierako probak egiteko egin genuen (oraindik ez genituen Arduino eta errele guztiak muntatu), azkenean dena horrela utzi genuen.
Frontend
Azkar sortu genuen gunea tildean, lanegun bat behar izan genuen eta gure aurrekontuan 30 mila aurreztu genituen.
Hasieran, gunea esportatzea eta falta zitzaigun logika gehitzea besterik ez genuen pentsatu, baina hori egitea debekatzen ziguten erabilera-baldintzak topatu genituen.
Ez geunden prest lizentzia urratzeko, beraz, bi aukera zeuden: dena geuk ezartzea edo zuzenean Tildarekin harremanetan jartzea, proiektuaz hitz egin eta kodea aldatzeko baimena eskatzea.
Bigarren aukera aukeratu genuen eta erdibidean ezagutu gintuzten ez ezik, urtebeteko doako negozio kontua ere eman ziguten, eta horregatik asko eskertzen diegu. Oso deserosoa izan zen Sokol-en webgunearen diseinua erakustea.
Ondorioz, oinarrizko gailuetara eskaerak bidaltzeko js logika erantsi dugu frontend-era, eta jokoaren elementuak aktibatzeko eta desaktibatzeko botoien estiloak apur bat aldatu ditugu.
Webguneen diseinua
Bilaketen historia, aparteko kapitulu bat merezi duena.
Garai bateko gune bat ez ezik, diseinuaren oinarrizko arau guztiak urratzen dituen guztiz nazkagarria sortu nahi genuen. Aldi berean, garrantzitsua zen sinesgarritasuna mantentzea: ez zuen ENT istorioa hautsi behar, egilearen pretentsioa frogatu, eta jokalariek gune hori egon zitekeela sinetsi beharko lukete eta bezeroak ere ekarri. Eta ekarri zuen! Jokoa zihoan bitartean, bi aldiz jarri ginen harremanetan webguneak sortzeko.
Hasieran nik neuk egin nuen diseinua, gif eta elementu distiratsu gehiago sartu nahian. Baina 10 urteko nire diseinatzaile senarrak sorbaldatik begiratu zuen eta "ongi"tzat jo zuen. Diseinu arauak hausteko, ezagutu behar dituzu.
Nazka sentimendu iraunkorra sorrarazten duten hainbat kolore-konbinazio daude: aberastasun berdineko berdea eta gorria, grisa eta arrosa, urdina gehi marroia. Azkenean, oinarrizko kolore gisa gorria eta berdea konbinazioa hartu genuen, katu batekin gifak gehitu eta Sokolov beraren 3-4 argazki hautatu genituen stock-argazki batetik. Baldintza batzuk baino ez nituen: adin ertaineko gizona, pare bat tamaina handiegia den traje desegokia jantzita eta "estudio profesionaleko argazki-saioa" posean. Proba egiteko, lagunei erakutsi eta "nola gustatzen zaizu?" galdetu zieten.
Diseinua garatzeko prozesuan, nire senarra ordu erdiro etzanda joan behar izan zen; helikopteroa hegan egiten hasi zen. Pasha garatzaileen kontsola pantailaren gehiengoan irekitzen saiatu zen frontend-a amaitzen zuen bitartean, begiak babesteko.
Benetako gailuak
Haizagailuak eta argiak egoera solidoko erreleen bidez muntatzen ziren, potentzia betean berehala piztu ez zitezen, potentzia monitorizazioarekin paraleloan handitu zedin.
Baina hurrengo postan honetaz hitz egingo dugu, jokoaren hardware zatiari eta gunearen benetako eraikuntzari buruz.
Stay tuned!
Zerbitzaria suntsitzeko bilaketari buruzko beste artikulu batzuk
Iturria: www.habr.com