Šīs, pēc ekspertu domām, ir visefektīvākās mikropakalpojumu testēšanas stratēģijas

Pārbaudīt mikropakalpojumus ir grūti. Konkrētāk, pārbaude no gala līdz galam ir sarežģīta, un to mēs sīkāk apspriedīsim šajā rakstā.

Bet vispirms īss stāsts.

Es uzzināju, cik smaga varētu būt mikropakalpojumu pārbaude, kad es pirmo reizi iegāju tehnikas kaudzē ar septiņiem atsevišķiem mikropakalpojumiem. Katram no tiem bija sava kodu bāze, atkarības pārvaldība, funkciju filiāles un datu bāzes shēma - kurai arī bija unikāls migrāciju kopums.

Runā par drudžainu.

Mēs izvēlējāmies visu vadīt vietējā līmenī. Tātad tas nozīmēja, ka jebkurā brīdī, kad es vēlos veikt pilnas pārbaudes, man būs jāveic šādi pieci soļi katram no septiņiem mikropakalpojumiem:

  1. Pārliecinieties, vai es atradu pareizo koda atzaru (vai nu galveno, vai feature_xyz)
  2. Izvelciet jaunāko šīs filiāles kodu
  3. Pārliecinieties, vai visas atkarības bija atjauninātas
  4. Palaidiet visas jaunās datubāzes migrācijas
  5. Sāciet pakalpojumu

Tā bija tikai pamatprasība, lai varētu veikt testus. Bieži vien es aizmirsu veikt kādu no šīm darbībām pakalpojumam un 10–15 minūtes pavadīt problēmas atkļūdošanā. Kad beidzot visi pakalpojumi bija priecīgi un darbojas, es varētu sākt testēšanas komplektu. Šī pieredze noteikti lika man garām dienas, kad es testēju vienu lielu monolītu.

Tātad, jā, es atklāju, ka mikropakalpojumu pārbaude no gala līdz galam ir sarežģīta - un ar katru jaunu pakalpojumu, kuru jūs ieviešat, kļūst eksponenciāli grūtāk. Bet nebaidieties, jo ir veidi, kā atvieglot mikroservisu testēšanu. Esmu runājis ar vairākiem CTO par to, kā viņi izdomāja savus radošos veidus, kā risināt šo sarežģīto problēmu.

Parastās mikroservisu testēšanas metodes

Vienības pārbaude

Mikropakalpojums pēc definīcijas var būt mazāks, taču, pārbaudot vienību, jūs varat veikt vēl sīkāku informāciju. Vienības pārbaude koncentrējas uz pārbaudāmās programmatūras mazāko daļu, lai pārliecinātos, vai šī sastāvdaļa darbojas tā, kā vajadzētu. Slavenais programmatūras inženieris, autors un starptautiskais runātājs Martins Faulers sadala ierīces testēšanu divās kategorijās:

  1. Sabiedrisko vienību testēšana: Šī vienības testēšanas metode pārbauda moduļu darbību, novērojot izmaiņas to stāvoklī.
  2. Atsevišķas vienības pārbaude: Šī metode ir vērsta uz objekta un tā atkarību mijiedarbību un sadarbību, kuras aizstāj ar testa dubultošanos.

Lai gan šīs vienības testēšanas stratēģijas ir atšķirīgas, Faulers norāda, ka tās nekonkurē - tās var izmantot kopā, lai atrisinātu dažādas testēšanas problēmas.

Sarunā ar Panteona CTO Deividu Štrausu Deivids man teica, ka "iespēja ir tāda, ka mikropakalpojumi ir ļoti vienkārši, lai faktiski veiktu vienību testēšanu."

Integrācijas testēšana

Izmantojot integrācijas testus, jūs darāt to, kas izklausās pēc tā: pārbauda sakaru ceļus un komponentu mijiedarbību, lai atklātu problēmas. Saskaņā ar Faulera teikto, integrācijas tests “izmanto apakšsistēmas saziņas ceļus, lai pārbaudītu, vai katram modulim ir nepareizi pieņēmumi par mijiedarbību ar vienaudžiem”.

Integrācijas tests parasti pārbauda mijiedarbību starp mikropakalpojumu un ārējiem pakalpojumiem, piemēram, citu mikropakalpojumu vai datu krātuvi.

Pawel Ledwoń, platformas vadītājs uzņēmumā Pusher, man paziņoja, ka viņa komanda “sliecas uz integrācijas testēšanu”. Vienības testi joprojām ir noderīgi dažām abstrakcijām, taču lietotājiem paredzētām funkcijām ir grūti izsmiet vai izlaist svarīgas sistēmas daļas. ”

Ne visi, ar kuriem es runāju, nebija šī procesa cienītāji. Piemēram, ir vērts atzīmēt, ka Mosquera uzņemas integrācijas testēšanas tēmu.

Integrācijas testēšana ir ļoti pakļauta kļūdām un dārga, ņemot vērā cilvēka stundas. IA vienkārši nav. Katrs individuālais integrācijas tests nodrošina nelielu lietojuma gadījumu nelielu pārklājumu.

Testēšana no gala līdz galam

Pēdējais, bet ne mazāk svarīgais ir end-to-end testēšana, kas - kā jau iepriekš minēts - var būt grūts uzdevums. Tas ir tāpēc, ka tas ietver visu mikropakalpojuma kustīgo daļu pārbaudi, nodrošinot, ka tā var sasniegt mērķus, kuriem esat to izveidojis.

Faulers uzrakstīja sekojošo:

end-to-end testos var būt jāņem vērā arī asinhronitāte sistēmā GUI vai asinhrono aizmugures procesu starp pakalpojumiem dēļ.

Viņš turpina paskaidrot, kā šie faktori var izraisīt “pārslas, pārmērīgu testa izpildes laiku un papildu testu komplekta uzturēšanas izmaksas”.

Labākais padoms, ko es varu sniegt, veicot pilnīgu testēšanu, ir ierobežot to, cik reizes jūs mēģināt to veikt vienā pakalpojumā. Veselīgs līdzsvars starp pārējām minētajām mikropakalpojumu testēšanas stratēģijām - piemēram, vienības testēšana un integrācijas testēšana - palīdzēs jums atsijāt mazākus jautājumus.

"End-to-end" tests pēc definīcijas ir lielāks, prasa vairāk laika, un to var daudz vieglāk kļūdīties. Lai saglabātu zemas izmaksas un izvairītos no laika samazināšanas, ievērojiet gala pārbaudi, kad visi pārējie testēšanas līdzekļi ir iztērēti, un kā galīgo kvalitātes nodrošināšanas zīmogu.

Mikroservisu testēšanas izaicinājumi

Mikroservisiem (salīdzinot ar monolītu) nepieciešamas papildu darbības, piemēram, vairāku krātuvju un filiāļu pārvaldīšana, katrai no tām ir savas datu bāzes shēmas. Bet izaicinājumi var būt dziļāki.

Šeit ir daži galvenie izaicinājumi, kas saistīti ar mikropakalpojumu testēšanu:

  • Pieejamība: Tā kā dažādas komandas, iespējams, pārvalda savus mikropakalpojumus, nodrošina mikropakalpojumu pieejamību (vai, vēl trakāk, mēģinot atrast laiku, kad visi mikropakalpojumi ir pieejami vienlaikus), ir grūts.
  • Sadrumstalota un holistiska pārbaude: mikropakalpojumi ir veidoti tā, lai tie darbotos atsevišķi un kopā ar citiem brīvi saistītiem pakalpojumiem. Tas nozīmē, ka izstrādātājiem jāpārbauda katrs komponents atsevišķi, kā arī jāpārbauda viss kopā.
  • Zināšanu trūkumi: it īpaši ar integrācijas testēšanu (par to mēs runāsim vēlāk šajā rakstā), ikvienam, kurš veic testus, būs nepieciešama laba izpratne par katru pakalpojumu, lai efektīvi rakstītu testa gadījumus.

Saskaņā ar Oleksiy Kovyrin, Elastic Swiftype SRE vadītāju,

Viens svarīgs jautājums, kas mums jāpatur prātā, strādājot ar mikropakalpojumiem, ir API stabilitāte un API versijas. Lai izvairītos no lietojumprogrammu sadalīšanas atkarībā no pakalpojuma, mums jāpārliecinās, vai mums ir stabils mikroservisa API integrācijas testu kopums, un, ja izmaiņas notiek pārrāvuma gadījumā, mums jānodrošina atpakaļ savietojams veids, kā klienti var pāriet uz jaunu versiju savā tempā, lai izvairītos no liela starppakalpojumu API izmaiņu ieviešanas.

Arī Sumo Logic galvenais arhitekts Stefans Zjē man atkārtoja, ka mikroservisu testēšana patiešām ir “ļoti, ļoti sarežģīta”.

“It īpaši, ja dodaties uz nepārtrauktāku izvietošanu. Mēs esam ieguldījuši un turpinām diezgan daudz ieguldīt integrācijas testēšanā, vienību testēšanā un darītu daudz vairāk, ja mums būtu cilvēki, kas to darītu, ”Zier man teica.

To sakot, viņš atzina, ka noteiktos posmos, kad Sumo Logic vēlas pārbaudīt viņu pakalpojumus visaptveroši, “vairāk vai mazāk [viss] uzņēmums savā ziņā kļūst par kvalitātes nodrošināšanas komandu”.

Risinājums: Piecas mikropakalpojumu testēšanas stratēģijas jaunajiem uzņēmumiem

Jā, mikropakalpojumu pārbaude var būt sarežģīta, taču, ņemot vērā visas mikropakalpojumu priekšrocības, atteikšanās no tām testēšanas problēmu dēļ nav pareizais ceļš. Lai risinātu šīs problēmas, es guvu ieskatu no vairākām CTO un pārtraucu piecas stratēģijas, kuras viņi izmantoja, lai veiksmīgi tuvotos mikroservisu testēšanai.

1. Dokumentācija - pirmā stratēģija

Inženierzinātņu Sparkpost viceprezidents Kriss Makfadens mūsu diskusijas laikā diezgan labi apkopoja dokumentācijas pirmo stratēģiju:

Mēs vispirms ievērojam dokumentācijas pieeju, tāpēc visa mūsu dokumentācija ir atzīmēta GitHub. Mūsu API dokumenti ir atvērta pirmkoda, tāpēc tas viss ir publisks. Tad mēs darīsim, pirms kāds raksta jebkādas API izmaiņas, vai nu jaunu API, vai izmaiņas API, vispirms atjauninās dokumentāciju, pārskatīs šīs izmaiņas, lai pārliecinātos, ka tā atbilst mūsu API konvencijām un standartiem, kas ir visi dokumentēti, un pārliecinieties, ka šeit nav ieviestas nekādas izmaiņas. Pārliecinieties, ka tas atbilst mūsu nosaukšanas konvencijām un tamlīdzīgi.

Ja esat gatavs iet vēl vienu soli tālāk, jūs varētu ķerties pie API līgumu testēšanas, kas, kā jau iepriekš minēts, ietver testu rakstīšanu un izpildi, kas nodrošina skaidru un netiešu mikropakalpojuma līgumu, kā tam vajadzētu darboties.

2. Pilna kaudzes in-a-box stratēģija

Pilna skursteņa kastē stratēģija ietver mākoņa vides kopēšanu lokāli un visa pārbaudīšanu vienā klaiņojošā instancē (“$ vagrant up”). Problēma? Tas ir ārkārtīgi grūts, kā emuāra ziņā paskaidroja programmatūras inženieris Sindija Sridharana no Imgix:

Man ir bijusi tieša pieredze ar šo kļūdu iepriekšējā uzņēmumā, kurā es strādāju, kur mēs mēģinājām visu savu kaudzi savērt [vietējā] klaidoņu kastē. Ideja, kā jūs varētu iedomāties, bija tāda, ka vienkāršam klaiņotājam vajadzētu ļaut jebkuram uzņēmuma inženierim (pat frontend un mobilo ierīču izstrādātājiem) spēt pilnībā izveidot savu klēpjdatoru.

Sridharans turpina sīkāk izklāstīt, kā uzņēmumam bija tikai divi mikropakalpojumi, uz Gevent balstīts API serveris un daži asinhronie Python fona darbinieki. Visādā ziņā samērā vienkārša iestatīšana.

"Es atceros, kā pavadīju visu savu pirmo nedēļu šajā uzņēmumā, cenšoties veiksmīgi apgūt VM lokāli, lai saskartos ar daudzām kļūdām. Visbeidzot, ap pulksten 16:00 pirmās nedēļas piektdienā, man bija veiksmīgi izdevies panākt, lai Vagrant iestatīšana darbotos, un visi testi nokārtoja lokāli. Es atceros, ka jutos neticami izsmelts, ”viņa stāstīja.

Turklāt Sumo Logic galvenais arhitekts Stefans Zjē man paskaidroja, ka papildus lokālajai testēšanas stratēģijai nav grūti izvilkt:

“[Izmantojot] lokālu izvietojumu, mēs tur apkalpojam lielāko daļu pakalpojumu, lai jūs iegūtu pilnībā darbināmu sistēmu, un tā tagad pat ļoti iestiepj pat 16 GB RAM. Tātad tas nav īsti mērogs, ”viņš teica.

3. AWS testēšanas stratēģija

Šī trešā stratēģija ietver Amazon Web Services (AWS) infrastruktūras izveidi katram inženierim, lai izvietotu un veiktu testus. Šī ir mērogojamāka pieeja iepriekš aprakstītajai pilnās kaudzes in-a-box stratēģijai.

Zier to nosauca par “personisko izvietošanu [stratēģiju], kur ikvienam šeit ir savs AWS konts”.

"Jūs varat nospiest jūsu klēpjdatorā esošo kodu AWS apmēram desmit minūtēs un vienkārši palaist to kā īstu sistēmu," viņš teica.

4. Dalītās testēšanas gadījumu stratēģija

Man patīk domāt par šo ceturto stratēģiju kā hibrīdu starp pilnas kaudzes kastē un AWS testēšanu. Tas ir tāpēc, ka tas ietver izstrādātājus, kas strādā no savas, vietējās stacijas, vienlaikus izmantojot atsevišķu, kopīgu mikropakalpojuma gadījumu, lai testēšanas laikā norādītu uz vietējo vidi.

Steven Czerwinski, Scaylr inženierzinātņu vadītājs, paskaidroja, kā tas var darboties praksē:

Daži [mūsu] izstrādātāji palaiž atsevišķu mikropakalpojuma gadījumu, lai to izmantotu tikai vietējo būvējumu pārbaudei. Tāpēc iedomājieties, ka esat izstrādātājs, attīstāties savā vietējā darbstacijā un jums nav vienkāršs veids, kā palaist attēlu parsētāju. Tomēr jūsu vietējais veidotājs vienkārši norāda uz testa attēlu parsētāju, kas darbojas Google infrastruktūrā.

5. Izturīgo pakalpojumu stratēģija

Un visbeidzot, mums ir iestrēgušo pakalpojumu testēšanas stratēģija.

Zjērs izklāstīja SumoLogic pieeju stumbra pakalpojumu pārbaudei, man sakot, kā: “Pieņemsim, ka jūs rakstāt šīs mikropakalpojumu zīmes vai“ stabus ”, kas rīkojas tā, it kā viņi būtu īstais dienests, un viņi mūsu pakalpojuma atklājumā reklamējas tā, it kā tie būtu reāli pakalpojumi. , bet tie ir tikai fiktīvi atdarinājumi, ”viņš paskaidroja.

Piemēram, pakalpojuma pārbaudei var būt nepieciešams, lai pakalpojums uzzinātu, ka lietotājs veic uzdevumu kopumu. Izmantojot nelokāmos pakalpojumus, varat izlikties, ka lietotājs (un viņa uzdevumi) ir notikuši bez parastajām sarežģītībām, kas ar to saistītas. Šī pieeja ir daudz vieglāka, salīdzinot ar pakalpojumu sniegšanu kopumā.

Rīki, kas palīdzēs pārbaudīt mikropakalpojumus

Šeit ir saraksts ar rīkiem, kas man ir guvuši labumu manā paša veikto mikropakalpojumu testēšanas pieredzē, un to papildina daži CTO un vecāko izstrādātāju kopas ieteikumi:

  • Hoverfly: simulē API latentumu un kļūmes.
  • Vagrant: izveidojiet un uzturiet portatīvās virtuālās programmatūras izstrādes vides
  • VCR: vienības testēšanas rīks
  • Pakts: izveido uz patērētāju balstītu līgumu testēšanu.
  • Drava: API dokumentācijas rīks
  • API Blueprint: API izstrāde un prototips
  • Swagger: API izstrāde un prototips

Mikroservisu testēšana: grūti, bet tā vērts

Jūsu mikropakalpojumu pārbaude nebūs pastaiga parkā, taču papildu darbs ir mikropakalpojumu arhitektūras priekšrocību vērts.

Turklāt mikroservisu testēšanas stratēģijām, kuras pieņēmušas tādas personas kā SumoLogic un Scaylr, vajadzētu palīdzēt izlīdzināt procesu. Šeit ir īss šo stratēģiju kopsavilkums:

  1. Dokumentācija - vispirms stratēģija
  2. Pilna skursteņa stratēģija
  3. AWS testēšanas stratēģija
  4. Koplietojamo testēšanas gadījumu stratēģija
  5. Stingra apkalpošanas stratēģija

Protams, jums, iespējams, būs jāpielāgo katra stratēģija, lai tā atbilstu jūsu unikālajiem apstākļiem, taču, izmantojot dažus vecmodīgus labus izmēģinājumus un kļūdas, jūsu mikropakalpojumu testēšanas stratēģijai vajadzētu būt savai.

Ja jums patika šis raksts, lūdzu, palīdziet tam izplatīties, aplaudējot zemāk! Lai iegūtu vairāk šāda veida satura, sekojiet mums Twitter un abonējiet mūsu emuāru.

Džeiks Lumeta ir ButterCMS izpilddirektors un publicē Microservices for Startups.

Un, ja vēlaties savai vietnei pievienot emuāru vai CMS, nejaucoties ar WordPress, jums vajadzētu izmēģināt Butter CMS.