Kontrolni popis za arhitekturu softvera: Kako izraditi proizvod od nule

Jednog se jutra probudite da popijete kavu i zakusite voće, trenutak Eureke je stigao Napokon ste shvatili svoj poslovni model i sve dolazi na svoje mjesto. Znate da će se investitorima svidjeti i jednostavno ne možete dočekati da počnete graditi proizvod. Prva prednost vašeg pokretača je vaša.

Ti su trenuci rijetki, ali kad se dogode, trebate krenuti u pravo vrijeme. Sve što vam treba je pravi vodič koji će vam pomoći da shvatite što biste trebali, a što ne biste trebali učiniti. Nije vrijeme za eksperimentiranje, vrijeme za izvršenje. Sad je TVOJE vrijeme!

NAPOMENA - Sljedeće se odnosi na izgradnju softverskih arhitektura od nule. Dakle, ako ste zainteresirani za saznavanje groznosti uključenih tehnologija, nastavite. Inače, molim vas podijelite s onima koji će ovo definitivno voljeti: P

Odakle je došao ovaj vodič

I sam sam radio na pregršt proizvoda u ranoj fazi, i da budem iskren, griješio sam. Uvijek sam želio da postoji kontrolni popis koji treba slijediti dok sam proizvodio proizvod od temelja.

Toliko je stvari uključeno u izgradnju arhitekture od nule da ćete potpuno zaboraviti određene dijelove. I vratit će se da vas ugrize u kasnijim fazama ciklusa proizvoda.

Napokon sam odlučio stvoriti ovaj popis stvari koje biste trebali uzeti u obzir prije nego što prvi put pritisnete taj gumb za postavljanje.

Dakle, bez daljnje nadogradnje, evo kontrolnog popisa koji biste trebali proći dok gradite Backend arhitekturu za proizvod od nule.

Odaberite PRAVILNI jezik i okvir (za svoj projekt)

Odabir ispravnog jezika i okvira za vaš proizvod je nezgodan i za to nema posebnog srebrnog metka. Moj je savjet da odaberete jezik koji vam najviše odgovara i poznajete zamršenost ulaska i izlaska.

Rekavši to, rijetko je, jer vrlo je malo ljudi koji su Javascript ninje, ili Python Panthers, ili bilo koja zabavna imena koja su vani.

Stoga odaberite jezik koji ima dobru dobru podršku u industriji, poput Javascripta, Pythona, Jave ili samo nekoliko imena. Možete odabrati bilo koji jezik, samo odaberite koji vam je najudobniji.

I ne zaboravite - gradite MVP (minimalno održivi proizvod) i bit ćete u procesu stvaranja POC-a (dokaz o konceptu). Stoga izvadite svoj proizvod što je prije moguće. Ne trebate zapinjati oko problema koji bi mogli doći iz novog jezika u gradu. Da biste izbjegli te probleme, odaberite jezik koji se više koristi, dobro dokumentiran.

Na kraju, možete skalirati i kasnije. Ako ste u fazi izrade POC-a, samo izgradite i obavite to. Ali ako gradite nešto stvarno specifično, a postoji jezik i okvir koji se posebno gradi za to, onda biste definitivno trebali odabrati tu tehnologiju.

No, većinu vremena problemi koje pokušavamo riješiti mogu se lako riješiti bilo kojim od gore spomenutih jezika i njihovim odgovarajućim okvirima. Zato samo odaberite jedan i pokrenite svoj proizvod.

Dobar resurs koji će vam pomoći da odlučite -

//content.techgig.com/top-5-programming-languages-for-backend-web-development/articleshow/67337449.cms

Provesti mikroservise za provjeru autentičnosti i autorizacije

Postoji puno načina za autentifikaciju i autorizaciju korisnika. Možete isprobati Session Tokens, JWT (JSON Web Tokens) ili OAuth, da nabrojimo samo neke. Svaka opcija ima svoje prednosti i nedostatke. Pa pogledajmo neke od njih pobliže.

JSON web žetoni

JWT-ovi su brzi i jednostavni za primjenu. To je zato što se tokeni nikad ne pohranjuju nigdje u vašem sustavu. Oni su samo kodirani, šifrirani i poslani korisniku. Dakle, provjera valjanosti JWT-a je brža od bilo koje druge metode.

Ali tada, budući da nisu pohranjeni u sustavu, zapravo ne možete učiniti da žeton istječe prije stvarnog vremena isteka, a to u određenim slučajevima može predstavljati problem.

Stoga shvatite prednosti i nedostatke svakog sustava za provjeru autentičnosti i odaberite onaj koji najbolje odgovara vašim zahtjevima. Osobno preferiram JWT-ove (ali to je moj vlastiti izbor).

Odobrenje

Nikada ne zaboravite primijeniti autorizaciju korisnika. Ne želite da prijavljeni korisnik1 promijeni detalje o korisniku2. To može uzrokovati čisti kaos u vašem sustavu.

Utvrdite krajnje točke za koje je potrebno odobrenje i odmah ih primijenite. Ne želite da stanje vaše baze podataka bude ovako oštećeno. Sjetite se razlike između 401 i 403.

Slijede određene krajnje točke koje biste svakako trebali uzeti u obzir prilikom izrade vašeg autentifikacijskog sustava (jedan sam stvorio u Djangu koristeći JWT). Mogu postojati određeni dodaci / brisanja za vaš slučaj upotrebe, ali to su oni koje biste trebali razmotriti.

Mnogo ih okvira nudi izvan okvira, ali razmotrite ih prije nego što ih napravite sami. Provjerite autentifikacijske_razrede i dozvoljene_razrede u Django Rest Framework-u za daljnju referencu.

Pogledajte ovaj resurs Django REST Framework -

//www.django-rest-framework.org/tutorial/4-authentication-and-permissions/

Stvorite apstraktni osnovni model koji će naslijediti svaki drugi model u vašoj bazi podataka

Sjetite se SUHOG principa - Ne ponavljajte se? To bi trebalo slijediti do srži u softverskom inženjerstvu.

Nadovezujući se na gornji proces razmišljanja, u vašoj će bazi podataka biti određeni stupci koji će biti prisutni u svakoj tablici. Stoga je bolje stvoriti apstraktnu klasu za njih kako bi ih druge klase modela mogle naslijediti.

Prođimo kroz ovaj kod i što on znači:

  • id - Iako ovdje nije napisan, automatski ga stvara Django okvir. Ali ako ga nema u vašem, zapišite ga u ovaj razred. To je samo automatski uvećano polje koje se može koristiti kao primarni ključ u vašoj relaciji baze podataka.
  • created_at - To podrazumijeva kada je polje / redak umetnuto u vašu tablicu i ispunjava ga sam okvir. Ne trebate to eksplicitno postaviti.
  • updated_at - To implicira kada je polje / redak zadnji put izmijenjen / ažuriran u vašoj tablici, a opet ga ispunjava sam okvir.
  • delete_at + is_deleted - Dakle, ovo je kontroverzno polje. Nemam točan odgovor treba li to biti tamo ili ne - jer da budem iskren, ništa se s interneta nikad ne briše. Ako se popuni, ovo polje prikazuje da se redak briše iz sustava (iako podaci ostaju u sustavu za buduće reference i mogu se ukloniti iz baze podataka i pohraniti u sigurnosne kopije)
  • uuid - Ovisi želite li ovo staviti u svoj stol ili ne. Ako primarni ključ svoje tablice trebate izložiti vanjskom sustavu, bolje je izložiti ovaj, a ne automatski uvećano cijelo polje. Možda se pitate zašto ...? Pa, zašto biste vanjskom sustavu htjeli reći da u tablici imate 10378 narudžbi? Ali opet je to osobni izbor.

Postavite mikroservis za obavijesti

Svaki proizvod treba poslati podsjetnike i obavijesti korisniku u svrhe angažmana i transakcije. Dakle, svaki će proizvod trebati ovo.

Svakako biste trebali razmotriti izgradnju mikroservisa koji krajnjim korisnicima pruža usluge obavijesti (poput push obavijesti, e-pošte i SMS-a).

Ovo bi uopće trebalo biti zasebna mikro usluga. Ne ugrađujte ovo u svoju mikroservis za provjeru autentičnosti ili uslugu aplikacija (stvarna poslovna logika).

Postoji mnogo biblioteka / usluga trećih strana koje se mogu koristiti za izradu za vašu aplikaciju. Iskoristite ih i izgradite to povrh toga.

Ne zaboravite izgraditi sve 3 funkcionalnosti:

  • Push obavijesti (APNS + FCM),
  • E-adrese (samo za početak integrirajte SMTP klijenta)
  • i SMS

NAPOMENA - Imajte dva kanala za slanje SMS-a, transakcijski i promotivni. Nikada nemojte slati promotivni SMS na transakcijski kanal, jer postoje šanse da će vas tužiti dobro informirani i motivirani korisnik.

Jednostavan način konfiguriranja SMTP klijenta u aplikaciji je korištenje ovog u vašim postavkama:

To sam učinio u Djangu, ali vi to možete učiniti na odabranom jeziku i u okviru.

Postavite evidentiranje pogrešaka

Koristite posrednički softver za bilježenje pogrešaka koje se javljaju u vašem proizvodnom sustavu. Ljudi koji sjede tamo neće nadgledati vaš proizvodni sustav kako bi vidjeli zapise aplikacija 24/7. Dakle, trebat će vam sustav koji će te interne pogreške poslužitelja evidentirati na središnjem mjestu. Tada ih možete svakodnevno provjeravati ili stvoriti web kuku kako biste mogli biti upozoreni u pravo vrijeme i brinuti se o njima.

Na tržištu postoji puno alata za evidentiranje pogrešaka treće strane. Samo odaberite bilo koji koji odgovara vašim zahtjevima. Uglavnom koristim Sentry / Airbrake.

Razmislite o konfiguriranju webhooksa, kao što sam gore spomenuo. Oni će obavijestiti vaše korisnike o pogreškama i, na primjer, možete ih objaviti kad i kada se pojave na određenim opuštenim kanalima. Tada te kanale možete redovito provjeravati i ispravljati na temelju njihove ozbiljnosti.

Službena početna stranica Airbrakea - //airbrake.io/

Službena početna stranica Sentryja - //sentry.io/welcome/

Zahtjev za implementacijom - odgovor i zapisivanje aplikacija

Scenarij - korisnik dolazi na vašu podršku i kaže da nije primio transakcijski račun za kupnju koju je izvršio na vašoj web stranici. Što ćeš učiniti?

Ako ste u svoj sustav stavili prijavu aplikacija, onda ne brinite. Što sad pod tim mislim? Uvijek je bolje pokazati primjer nego pokušavati objasniti riječima. Pa evo:

Zabilježio sam da ću poslati e-poštu na spomenuti email_id. Mogu provjeriti u zapisnicima aplikacija da vidim je li e-pošta stvarno poslana klijentu provjerom postoji li takav zapisnik u sustavu. Obavezno stavite sveobuhvatne zapisnike u svoj sustav kako biste mogli pratiti put zahtjeva.

Uz to, dobra je ideja postaviti asinkroni sustav koji će odabrati takve zapisnike zahtjeva i odgovora i aplikacije iz vašeg sustava te ih odložiti na centralno mjesto. Tamo se mogu obraditi kako bi ih bilo lakše razumjeti.

ELK stog je dobra opcija za ovo: ElasticSearch - Logstash - Kibana.

Više o ELK stogu - //www.elastic.co/what-is/elk-stack

NAPOMENA - Tijekom bilježenja zahtjeva i odgovora vodite računa o sljedećem:

  • Ne prijavljujte lozinke.
  • Ne zapisujte tokene (pristupni tokeni koji se koriste za provjeru autentičnosti)
  • Ne prijavljujte OTP-ove

Uvedite throttling u svoje API-je i ograničenje brzine na vašim poslužiteljima aplikacija

Scenarij - Upravo ste pokrenuli svoju uslugu i plasirali ste proizvod na platforme društvenih medija. Otkrio je haker crnog šešira i samo se htio poigrati vašim sustavom. Stoga su planirali DOS (uskraćivanje usluge) napad na vaš sustav.

Da biste se borili protiv toga, možete postaviti ograničenje brzine na temelju različitih čimbenika povrh svojih uravnoteživača opterećenja za vaše aplikacijske poslužitelje. Ovo će se pobrinuti za DOS napade i spriječiti zlonamjernog korisnika da napada vaše poslužitelje.

Scenarij - API krajnja točka / otp / validate koja uzima 4 znamenkaste OTP-ove za autentifikaciju korisnika i vraća tokene koji će se koristiti za autentificirane API-je. Zlonamjerni korisnik dobiva mobile_number za jednog od vaših klijenata i započinje udaranje krajnje točke API-ja grubim napadom mijenjajući IP-ove, DDOS (Distributed Denial of Service) napad. Ograničivač brzine ne može zaustaviti korisnika, jer se IP neprestano mijenja sa svakim upućenim zahtjevom.

Da biste to zaustavili, API-je možete staviti na regulaciju i na temelju korisnika. Možete konfigurirati koliko zahtjeva određeni korisnik može uputiti na krajnju točku API-ja. Za OTP provjeru valjanosti je 5 zahtjeva u 10 minuta. To će spriječiti zlonamjernog korisnika da izvrši DDOS napad grubom silom na gore navedeni API.

Ubacivanje u Djangov REST Framework -

//www.django-rest-framework.org/api-guide/throttling/

Uspostavite i konfigurirajte asinkronu komunikaciju od prvog dana

Scenarij - Korisniku morate poslati e-poruku dobrodošlice kada se registrira u vašoj aplikaciji. Prednji klijent pogađa API za registraciju, vi stvarate korisnika u pozadini nakon provjera valjanosti, a to započinje postupak slanja e-pošte dobrodošlice.

Slanje ove poruke dobrodošlice potrajat će, možda nekoliko sekundi. Ali zašto biste željeli da mobilni klijent zaglavi za takav postupak? To se može dogoditi u pozadini, a da korisnik bez posebnog razloga zaglavi na stranici Registriraj se. Svaka je sekunda dragocjena i ne želite da korisnik izgubi te dragocjene sekunde.

Dakle, samo pošaljite e-poštu putem asinkronog zadatka. Za to koristite radnike, zadatke, posrednike poruka i povratne rezultate.

Dobar primjer za to iz svijeta Pythona je radnik celera. Samo stavite zadatak koji treba izvršiti u posrednik poruka (Rabbit MQ / SQS, itd.). Celera će to poslušati i zadatak će poslati naznačenom radniku. Taj će radnik zatim obraditi zahtjev i rezultat staviti u pozadinu rezultata koja može biti sustav predmemorije / sustav baze podataka. (Redis / PostgreSQL na primjer).

Te zadatke i redove možete pratiti s puno biblioteka trećih strana. Dobar primjer za to je Cvijet celera koji sve to nadgleda.

Više o RabbitMQ možete pročitati ovdje - //www.rabbitmq.com/

I celer - //docs.celeryproject.org/en/stable/django/first-steps-with-django.html

I na kraju, Cvijet celera - //flower.readthedocs.io/en/latest/

Postavite cron poslove

Scenarij - Upravo ste pokrenuli svoj proizvod i svojim korisnicima morate poslati preporuke o novim proizvodima na vašoj platformi. Slati ćete ih na temelju povijesti kupovine svakog vikenda.

Gore navedeni zadatak može se jednostavno izvršiti pomoću cron zadatka. Lako ga je podesiti u svakom okviru. Važno je imati na umu da cron zadatke ne biste trebali stavljati izravno u crontab datoteku vašeg poslužitelja. Trebali biste pustiti da okvir to obrađuje.

To je zato što bi inženjer implementacije / inženjer Devops trebao biti jedina osoba koja ima pristup ovakvom sustavu iz sigurnosnih razloga. Iako to ne morate provoditi na ovaj način, dobro je imati stvar od početka.

U svijetu Django možete pomoću celerybeat-a konfigurirati krune pomoću radnika celera.

Ovdje saznajte više o Celery Beat - // docs.celeryproject.org/en/latest/userguide/periodic-tasks.html

Ispravno upravljajte svojim tajnama (datoteka parametara)

Postoji puno načina za upravljanje tajnama parametara na vašim proizvodnim poslužiteljima. Neki od njih su:

  • Stvaranje datoteke s tajnama i pohranjivanje u privatnu s3 kantu te izvlačenje iste tijekom postavljanja vaše aplikacije.
  • Postavljanje parametara u varijablama okoline tijekom implementacije vaše aplikacije (ponovno ih sprema u s3)
  • Stavljanje tajni u neku uslugu upravljanja tajnama (npr. //Aws.amazon.com/secrets-manager/) i njihovo korištenje za dobivanje tajni u vašoj aplikaciji.

Možete odabrati bilo koju od ovih metoda prema svojoj udobnosti i slučaju upotrebe. (Možete odabrati zadržavanje različitih tajnih datoteka za lokalno, scensko i produkcijsko okruženje.)

Izvršite verzije API-ja od prvog dana

To je nešto o čemu biste svakako trebali razmisliti od 1. dana. Nikada nećete znati koliko često se vaši poslovni modeli mogu mijenjati, a u aplikaciji morate imati kompatibilnost s naprijed-nazad. Stoga biste trebali verzijati svoje API-je kako biste osigurali da sve funkcionira glatko za sve.

Možete imati različite aplikacije za različite verzije i dopustiti da ih nginx obrađuje za vašu aplikaciju. Ili možete imati inačicu verzija u samoj aplikaciji i dopustiti rutama na vašem poslužitelju aplikacija da to obrađuju. Možete odabrati bilo koju metodu za njezinu implementaciju - glavna je stvar omogućiti verziranje od početka.

Odlučite se za provjere verzije tvrdog i mekog ažuriranja za vaše klijente

Dakle, koja je razlika između tvrdih i mekih ažuriranja?

Tvrda ažuriranja odnose se na to kada je korisnik prisiljen ažurirati verziju klijenta na veći broj verzije od onoga što je instalirano na njegovom mobitelu.

Meka ažuriranja odnose se na to kada se korisniku prikaže upit da je dostupna nova verzija i ako svoju aplikaciju može ažurirati na novu verziju.

Tvrda ažuriranja se ne potiču, ali postoje trenuci kada ih trebate primijeniti. Bez obzira na slučaj, svakako biste trebali razmotriti kako ćete to primijeniti u svojim aplikacijama.

To možete učiniti implementacijom ili konfiguracijom u Trgovini Play ili App Store. Drugi je način stvoriti API u pozadinskoj aplikaciji koji će biti pogođen svaki put kada se pokrene mobilna aplikacija. Ovo će poslati dvije tipke: hard_update -> true / false i soft_update -> true / false, ovisno o verziji korisnika i verziji tvrdog i mekog ažuriranja postavljenoj u vašem pozadinskom sustavu.

Dobro mjesto za pohranu ovih verzija nalazi se u vašoj predmemoriji (Redis / Memcache), koju možete promijeniti u hodu, bez potrebe za postavljanjem aplikacije.

Uvedite kontinuiranu integraciju (CI) od prvog dana

Scenarij - jedan od pripravnika koji rade u vašem projektu nije dovoljno vješt da napiše kôd produkcijske razine. Možda su promijenili nešto što bi moglo razbiti neku kritičnu komponentu u vašem projektu. Kako možete osigurati da je sve u redu u takvim slučajevima?

Uvesti kontinuiranu integraciju. Pokrenut će lintere i test slučajeve na svakom urezivanju i prekršit će se ako se prekrše bilo koja pravila. To će zauzvrat blokirati spajanje zahtjeva za povlačenjem dok ne prođu sva pravila povezivanja i testovi. Lijepo je imati stvar, a zapravo pomaže i dugoročno, pa imajte na umu.

Na tržištu je dostupno puno opcija. Možete odabrati da sami implementirate jedan (Jenkins CI / CD), ili za to možete koristiti TravisCI, CircleCI itd.

Pročitajte ovdje o TravisCI - //travis-ci.org/

I CircleCI - //circleci.com/

Omogućite Docker podršku (osobne preferencije)

Stvorite Dockerfile i docker-compose.yml za svoju aplikaciju tako da svi pokreću aplikaciju pomoću Dockera od početka. Jedan od glavnih razloga za korištenje takvog pristupa je postojanje dosljednosti u vašem lokalnom / scenskom / produkcijskom okruženju, tako da niti jedan programer to više nikada ne može reći:

Ali radilo je na mom stroju.

Nije ga teško zaposliti od 1. dana. U početku samo koristite Docker za svoje lokalno okruženje kako bi postavljanje vaše aplikacije moglo biti stvarno glatko. Ali imajte na umu kako ga možete pokretati s Dockerom i bez njega u proizvodnji.

Evo više informacija o Docker Hubu - //hub.docker.com/

Koristite APM alat

Alat za nadzor aplikacija mora imati ako želite nadgledati API-je aplikacije, transakcije, veze s bazom podataka i tako dalje.

Scenarij - tvrdi disk vašeg cron poslužitelja gotovo je pun i ne može pokretati cron poslove. Budući da ne može pronaći prostor na disku, vaši krunovi se ne izvode. Pa kako možete dobiti obavijest kad se to dogodi?

Postoji puno APM alata pomoću kojih možete to nadgledati. Možete ih konfigurirati prema tome kada trebate biti obaviješteni. Dobit ćete obavijesti na mediju po vašem izboru kad se takav kaos dogodi na vašem sustavu - i vjerujte mi da se to događa cijelo vrijeme. Zato se bolje pripremite za to. New Relic je dobra opcija.

Pročitajte više o Novoj relikviji ovdje - //newrelic.com/

Upotrijebite ElasticSearch za pokretanje pretraživanja u aplikacijama klijenta u cijeloj aplikaciji

Prema wikipediji,

Elasticsearch je pretraživač zasnovan na knjižnici Lucene. Pruža distribuiranu tražilicu za puni tekst s mogućnostima multitenanata s HTTP web sučeljem i JSON dokumentima bez sheme. Elasticsearch je razvijen na Javi.

Na početku ćete biti u iskušenju da koristite tradicionalne upite baze podataka da biste dobili rezultate na toj traci za pretragu klijentske aplikacije. Zašto? Jer je lako.

No tradicionalne baze podataka nisu namijenjene takvim izvedbenim upitima. Smislite dobro vrijeme za migraciju pretraživanja na ElasticSearch i uvođenje podatkovnog cjevovoda u vaš sustav. Elastično pretraživanje hrani podacima, a zatim povezuje pretraživanje s ElasticSearch-a na poslužitelj aplikacija.

Evo dobrog pregleda Elasticsearch-a za početak.

I dokumenti ElasticSearch - //www.elastic.co/guide/index.html

Stavite vatrozid u svoj proizvodni poslužitelj

To biste definitivno trebali učiniti - to morate imati. Stavite vatrozid u svoj proizvodni poslužitelj i zatvorite sve priključke osim onih koji će se koristiti za API-je (https veze). Usmjerite krajnje točke API-ja koristeći obrnuti proxy web poslužitelj, poput NGiNX ili Apache. Nijedna luka ne smije biti dostupna vanjskom svijetu osim onih koje dopušta NGiNX.

Zašto biste trebali koristiti NGiNX:

  • //www.nginx.com/resources/wiki/community/why_use_it/
  • //blog.serverdensity.com/why-we-use-nginx/
  • //www.freecodecamp.org/news/an-introduction-to-nginx-for-developers-62179b6a458f/

Završavati

Gore spomenute točke temelje se na mojim vlastitim preferencijama i razvijao sam ih tijekom godina. Tu i tamo bit će male razlike, ali koncepti ostaju isti.

I na kraju sve to radimo da bi se glatki sustav izgrađen od nule pokrenuo u proizvodnji što je prije moguće nakon što smislite ideju.

Pokušao sam pišući dolje sve svoje znanje koje sam stekao tijekom godina, i ja mogu biti u krivu se u nekoliko mjesta .Ja f mislite da možete ponuditi bolje informacije , slobodno komentirati. Kao i uvijek, molim vas podijelite ako mislite da je to korisno.