Mikropalvelusuunnitteluopas

On vuosi 2018, kaikki ovat kuulleet Microservicesistä. Mutta osaatko suunnitella sellaisen?

Mikropalvelut on trendi aihe ohjelmistoinsinöörien keskuudessa. Ymmärretään kuinka pystymme rakentamaan todella modulaarisia, ketterästi toimivia IT-järjestelmiä Microservices-arkkitehtonisella tyylillä.

Mikropalvelukonsepti

Mikropalvelutarkkitehtuuri koostuu kokoelmista kevyitä, löysästi kytkettyjä palveluita. Jokainen palvelu toteuttaa yhden liiketoimintamahdollisuuden. Ihannetapauksessa näiden palvelujen tulisi olla riittävän yhtenäisiä kehittää, testata, vapauttaa, ottaa käyttöön, skaalata, integroida ja ylläpitää itsenäisesti.

Muodollinen määritelmä
”Microservice-arkkitehtoninen tyyli on lähestymistapa yhden sovelluksen kehittämiseen pienten palveluiden sarjaksi, jokainen toimii omassa prosessissaan ja kommunikoi kevyiden mekanismien, usein HTTP-resurssipiirin, kanssa. Nämä palvelut on rakennettu liiketoimintamahdollisuuksien ympärille, ja ne voidaan ottaa itsenäisesti käyttöön täysin automatisoitujen käyttöönottokoneiden avulla. Näiden palvelujen keskitetty hallinta on vain minimaalista, ja ne voidaan kirjoittaa eri ohjelmointikielissä ja käyttää erilaisia ​​tiedontallennustekniikoita. "
- James Lewis ja Martin Fowler

Mikropalvelujen ominaisuuksien määritteleminen

  • Jokainen palvelu on kevyt, itsenäinen ja löysästi kytketty liiketoimintayksikkö.
  • Jokaisella palvelulla on oma kooditietokanta, jota pieni joukkue hallinnoi ja kehittää (lähinnä ketterässä ympäristössä).
  • Jokainen palvelu on vastuussa toiminnallisuuden yhdestä osasta (liiketoimintakyky) ja tekee sen hyvin.
  • Jokainen palvelu voi valita parhaan tekniikkapinon käyttötapauksiinsa (ei tarvitse pysyä yhtenä kehyksenä koko sovelluksen ajan).
  • Jokaisella palvelulla on oma DevOp-suunnitelma (testata, vapauttaa, ottaa käyttöön, skaalata, integroida ja ylläpitää itsenäisesti).
  • Jokainen palvelu otetaan käyttöön itsenäisessä ympäristössä.
  • Palvelut kommunikoivat keskenään käyttämällä hyvin määriteltyjä sovellusliittymiä (älykkäitä päätepisteitä) ja yksinkertaisia ​​protokollia, kuten REST HTTP: n kautta (tyhmä putket).
  • Jokainen palvelu on vastuussa oman datansa säilyttämisestä ja ulkoisen tilan pitämisestä (Ainoa, jos useat palvelut käyttävät samaa dataa, tällaiset tilanteet käsitellään yhdessä tietokerroksessa).

Mikropalveluiden edut

Mikropalvelut tehdään suurten järjestelmien mittakaavaan. Ne ovat myös erinomainen mahdollistaja jatkuvalle integroinnille ja toimitukselle.

Scale Cube: 3-ulotteinen malli skaalautuvuudelle (Kuva: Nginx Blog)
  • Itsenäinen skaalaaminen - Microservices-arkkitehtuuri tukee Scale Cube -konseptia, joka on kuvattu erinomaisessa The Scalability Art -kirjassa. Kun kehitetään mikropalveluita toiminnallisen hajoamisen aikaansaamiseksi, sovellus skaalautuu automaattisesti Y-akselin kautta. Kun kulutus on suuri, mikropalvelut voivat skaalata X-akselin kautta kloonaamalla enemmän CPU: ta ja muistia. Tietoja voidaan jakaa useille koneille suuret tietokannat voidaan jakaa (varjostus) pienempiin, nopeampiin, helpommin hallittaviin osiin, jotka mahdollistavat Z-akselin skaalauksen.
  • Itsenäiset julkaisut ja käyttöönotot - Virhekorjaukset ja ominaisuuksien julkaisut ovat hallittavissa ja vähemmän riskialttiita, mikropalvelujen avulla. Voit päivittää palvelun uudelleen ottamatta uudelleen käyttöön koko sovellusta, ja palata päivitys tai jatkaa sitä, jos jokin menee pieleen.
  • Itsenäinen kehittäminen - Jokaisella palvelulla on oma kooditietokanta, jonka pieni keskittynyt joukkue kehittää, testaa ja ottaa käyttöön. Kehittäjät voivat keskittyä vain yhteen palveluun ja vain suhteellisen pieneen laajuuteen. Tämä johtaa parantuneeseen tuottavuuteen, projektinopeuteen, jatkuvaan innovaatioon ja laatuun lähteellä.
  • Suojallinen huonontuminen - Jos palvelu laskee, sen vaikutus ei leviä muihin sovelluksiin ja johtaa järjestelmän katastrofaaliseen vikaantukseen, joka antaa mahdollisuuden ilmetä tietyssä asteessa epävakautta.
  • Hajautettu hallinto - Kehittäjät voivat vapaasti valita teknologiapinoja ja tehdä suunnittelustandardeja ja täytäntöönpanopäätöksiä, jotka parhaiten sopivat heidän palveluunsa. Joukkueiden ei tarvitse joutua rankaisemaan aikaisempien teknologiapäätösten takia.

Operatiiviset huolet

Itsenäiset palvelut eivät yksin pysty muodostamaan järjestelmää. Mikropalveluarkkitehtuurin todellinen menestys edellyttää merkittäviä investointeja järjestelmien välisten huolenaiheiden hoitamiseksi, kuten:

  • Palvelun replikointi - mekanismi, jolla palvelut voivat helposti skaalata metatietojen perusteella
  • Palvelun rekisteröinti ja löytäminen - mekanismi, joka mahdollistaa palvelun etsinnän ja löytää kunkin palvelun päätepisteen
  • Palveluseuranta ja -loki - mekanismi yhdistää lokit erilaisista mikropalveluista ja tarjota yhdenmukainen raportointi
  • Joustavuus - mekanismi palveluille, jotka suorittavat korjaavat toimenpiteet automaattisesti vikojen aikana
  • DevOps - mekanismi jatkuvaan integrointiin ja käyttöönottoon (CI ja CD)
  • API-yhdyskäytävä - mekanismi asiakaspisteen tarjoamiseksi

Väliohjelmisto ja suunnittelumallit

API-yhdyskäytävä (yksi pääsypiste kaikille asiakkaille)

API-yhdyskäytävän tyylin mikropalveluarkkitehtuuri (Kuva: Microsoft Azure Docs) - tämä on yleisin mikropalveluissa käytetty suunnittelumalli. API-yhdyskäytävä on välittäjä, jolla on minimaaliset reititysmahdollisuudet ja joka toimii vain

API-yhdyskäytävä toimii yhtenä pääsypisteenä kaikille asiakkaille ja reunapalveluna paljastamalla mikropalvelut ulkomaailmaan hallittuina sovellusliittyminä. Se kuulostaa käänteiseltä välityspalvelimelta, mutta sillä on myös muita vastuita, kuten yksinkertainen kuormituksen tasapainotus, todennus ja valtuutus, vikojen käsittely, tarkastus, protokollan käännökset ja reititys. Kehitysryhmä voi valita yhden seuraavista lähestymistavoista API-yhdyskäytävän toteuttamiseksi.

  • Rakenna se ohjelmallisesti - jotta sinulla olisi parempia mukautuksia ja hallintaa
  • Asenna olemassa oleva API-yhdyskäytävätuote - säästää alkukehitysaikaa ja käyttää edistyneitä sisäänrakennettuja ominaisuuksia (Miinukset: Tällaiset tuotteet ovat valmistajariippuvaisia ​​eivätkä ole täysin ilmaisia. Kokoonpanot ja ylläpito voivat usein olla työlästä ja aikaa vievää)

Jotkut suunnittelumallit, jotka selittävät API-yhdyskäytävän käyttäytymistä, ovat seuraavat (Lue mikropalvelujen suunnittelumallit).

  • Yhdyskäytävän yhdistäminen - yhdistää useita asiakaspyyntöjä (yleensä HTTP-pyyntöjä), jotka kohdistuvat useisiin sisäisiin mikropalveluihin yhdeksi asiakaspyynnöksi, vähentämällä chattiinisuutta ja viivettä kuluttajien ja palveluiden välillä.
  • Yhdyskäytävän poisto - sallii yksittäisten mikropalvelujen lataamaan jaetun palvelutoiminnon API-yhdyskäytävätasolle. Tällaisia ​​monialaisia ​​toimintoja ovat todennus, valtuutus, palvelun etsintä, vikasietoisuuden mekanismit, QoS, kuorman tasapainotus, lokitiedot, analytiikka jne.
  • Yhdyskäytäväreititys (kerroksen 7 reititys, yleensä HTTP-pyynnöt) - reitittää pyynnöt sisäisten mikropalvelujen päätepisteisiin käyttämällä yhtä päätepistettä, jotta kuluttajien ei tarvitse hallita monia erillisiä päätepisteitä

Huomaa, että API-yhdyskäytävän tulisi aina olla erittäin saatavissa oleva ja suorittava komponentti, koska se on koko järjestelmän lähtökohta.

Tapahtumaväylä (pub / sub-sovittelukanava asynkroniselle tapahtumavetoiselle viestinnälle)

Mahdollisuus johdonmukaisuuteen mikropalvelujen välillä, joka perustuu tapahtumavetoiseen async-viestintään (Kuva: microsoft.com)

Jotta sovelluksen eri osat voivat kommunikoida keskenään riippumatta viestisarjasta (asynkroninen) tai siitä, mitä kieltä he käyttävät (kielen agnostiikka), voidaan käyttää tapahtumaväylää. Suurin osa tapahtumaväylistä tukee julkaisua / tilaamista, jakelua, pisteestä pisteeseen ja pyyntö-vastaus -viestejä. Jotkut tapahtumaväylät (kuten Vert.x: ssä) sallivat asiakaspuolen kommunikoida vastaavien palvelinsolmujen kanssa käyttämällä samaa tapahtumaväylää, mikä on hieno ominaisuus, jota täydet pinojoukkueet rakastavat.

Service Mesh (sivuvaunu palvelujen väliseen viestintään)

Palvelujen välinen viestintä Service Mesh -tyylillä (Kuva: Microservices in Practice)Palvelusilmien käyttö sovelluksessa (Kuva: christianposta.com)

Service Mesh toteuttaa sivuvaunumallin tarjoamalla auttajainfrastruktuurin palveluiden väliseen viestintään. Se sisältää ominaisuuksia, kuten joustavuus (vikasietoisuus, kuorman tasapainotus), palvelun löytäminen, reititys, havaittavuus, turvallisuus, kulunvalvonta, tietoliikenneprotokollan tuki jne.

Kuinka palveluverkot mahtuvat verkkopinoon (Kuva: christianposta.com)

Käytännössä Sidecar-esimerkki otetaan käyttöön jokaisen palvelun rinnalla (mieluiten samassa säilytysastiassa). He voivat kommunikoida palvelun primitiivisten verkkotoimintojen kautta. Service Mesh -ohjaustaso on erikseen otettu käyttöön keskitettyjen ominaisuuksien, kuten palvelun löytämisen, pääsynhallinnan ja havaittavuuden (seuranta, hajautettu lokitieto) tarjoamiseksi. Tärkeintä on, että Service Mesh -tyylin avulla kehittäjät voivat irrottaa verkkoviestinnän toiminnot mikropalvelukoodista ja pitää palvelut keskittyneinä vain liiketoimintamahdollisuuksiin. (Lue: Netflix Prana, Microsoftin palveluverkko)

Vaikka yllä olevat kuvat osoittavat suorien yhteyksien palveluiden välillä, hieno tapa käsitellä palveluiden välistä viestintää olisi käyttää yksinkertaista tapahtumaväylää välittäjänä pitämään kytkentä minimitasolla.

Taustaohjelmat etusivulle (BFF)

Taustaohjelmien käyttöönotto etuosa- ja aggregaattorimalleille API-yhdyskäytävän tasolla (Kuva: microsoft.com)

Jos sovelluksen on räätälöitävä jokainen sovellusliittymä sopimaan asiakassovellustyyppiin (verkko, mobiili, erilaiset alustat), erilaiset säännöt (kokoonpanot) voidaan panna täytäntöön julkisivun kautta tai palvella erillisiä rakennuksia asiakasominaisuuksien perusteella. Tämä voidaan toteuttaa itse API-yhdyskäytävätasolla tai samanaikaisesti palvelutason kanssa. Tämä malli on hyödyllinen tarjottaessa erityisiä käyttökokemuksia. Kehitysryhmän tulisi kuitenkin olla riittävän varovainen pitämään BFF: it hallittavissa olevan rajan yläpuolella.

Parhaat käytännöt

Verkkotunnusohjattu suunnittelu - Mallipalvelut liiketoiminta-alueen ympärillä.

Suurten mallien ja ryhmien käsittelemiseksi voidaan soveltaa Domain Driven Design (DDD) -toimintoa. Se käsittelee suuria malleja jakamalla ne erilaisiin rajoitettuihin konteksteihin ja selkeästi suhteista toisiinsa ja ala-alueeseen. Nämä rajatut kontekstit voidaan muuntaa erillisiksi mikropalveluiksi sovellussuunnittelutasolla (Lue: Rajattu konteksti toimialueohjatussa suunnittelussa).

Hajautettu tiedonhallinta (Vältä jaettuja tietokantoja). Kun useat palvelut käyttävät jaettua datakaavaa, se voi luoda tiukan kytkennän tietokerrokseen. Sen välttämiseksi jokaisella palvelulla tulisi olla oma tiedonsaantilogiikka ja erillinen tietovarasto. Kehitysryhmä voi vapaasti valita datankestävyysmenetelmän, joka sopii parhaiten kullekin palvelulle ja tiedon luonteelle.

Vältä jaettuja tietovarastoja ja tiedonsiirtomekanismeja (Kuva: christianposta.com)

Älykkäät päätepisteet ja tyhmät putket - Jokainen palvelu omistaa hyvin määritellyn sovellusliittymän ulkoiselle viestinnälle. Vältä vuotamasta käyttötietoja. Käytä kommunikoinnissa aina yksinkertaisia ​​protokollia, kuten REST yli HTTP.

Asynkroninen viestintä - Kun asynkronista viestintää käytetään palveluiden välillä, datavirta ei estä muita palveluita.

Synkroninen vs. asynkroninen viestintä (Kuva: microsoft.com)

Vältä palveluiden välistä kytkemistä - Palveluissa tulisi olla löysä kytkentä ja korkea toiminnallinen koheesio. Kytkemisen tärkeimpiä syitä ovat jaetut tietokantakaaviot ja jäykät viestintäprotokollat.

Development Hajauttaminen kehitystyöhön - Vältä koodekkien, dataskeemien tai kehitysryhmän jäsenten jakamista useiden palvelujen / projektien kesken. Anna kehittäjien keskittyä innovaatioihin ja laatuun lähteellä.

Pidä verkkotunnustiedot poistossa. Anna yhdyskäytävän käsitellä reititys- ja monialaisia ​​huolenaiheita (todennus, SSL-päättäminen).

Token-pohjainen todennus - Sen sijaan, että toteuttaa tietoturvakomponentit jokaisella mikropalvelutasolla, joka puhuu keskitetylle / jaetulle käyttäjän arkistolle ja hakea todennustiedot, harkitse todentamisen toteuttamista API Gateway -tasolla laajasti käytettyjen API-suojausstandardien, kuten OAuth2 ja OpenID, kanssa. Kytkeä. Saatuaan autentunnuksen autentarjoajalta, sitä voidaan käyttää kommunikointiin muiden mikropalvelujen kanssa.

Microsoftin tietoturva OAuth2: n ja OpenID Connect -sovelluksen avulla (Kuva: Kasunin blogi)

Tapahtumavetoinen luonto - Ihmiset ovat itsenäisiä tekijöitä, jotka voivat reagoida tapahtumiin. Eivätkö järjestelmäämme voi olla sellaisia? (Lue: Miksi mikropalvelujen tulisi olla tapahtumalähtöisiä: Itsenäisyys vs. auktoriteetti)

Lopullinen johdonmukaisuus - Koska mikropalveluissa on suuri koheesio, on vaikea saavuttaa vahvaa johdonmukaisuutta koko järjestelmässä. Kehitysryhmän on käsiteltävä lopullista johdonmukaisuutta.

Vikasietoisuus - Koska järjestelmä koostuu useista palveluista ja väliohjelmiston komponenteista, viat voivat tapahtua jossain erittäin helposti. Täytäntöönpanomallit, kuten piirin katkaisu, laipio, uudelleenyritykset, aikakatkaisut, epäonnistuminen nopeasti, häiriöiden välimuisti, nopeudenrajoitimet, kuormanerottimet sellaisissa haavoittuvissa komponenteissa voivat minimoida suurten vikojen riskit. (Lue: Mikropalveluarkkitehtuurin suunnittelu epäonnistumiseen)

Tuotesuunnittelu - Mikropalvelut toimivat hyvin, kunhan ne on suunniteltu tuotteeksi, ei projektiksi. Kyse ei ole siitä, että se toimisi jollakin tavalla ja toimittaisi ennen määräaikoja, vaan pitkäaikaisesta sitoutumisesta tekniikan huippuosaamiseen.

Mikropalvelut käytännössä

Milloin käyttää Microservices-palveluita

Microservices-arkkitehtuuri sopii parhaiten:

  • Sovellukset, joilla on suuri skaalautuvuus
  • Projektit, joilla on suuri vapautumisnopeus
  • Liiketoimintatapaukset, joissa on rikkaita verkkotunnuksia tai monia aliverkkotunnuksia
  • Ketterä ympäristö, jossa pienet, monitoiminnalliset kehitysryhmät kehittävät suuria tuotteita yhteistyössä (Lue: Microservices-arkkitehtuurien todellinen menestystarina)

Jotkut siirtymiskehykset mikropalvelujen toteuttamiseksi

  • Vert.x - kevyt, helppo ymmärtää / toteuttaa / ylläpitää, polyglotti (tukee monia kieliä), tapahtumapohjainen, estämätön, toistaiseksi paras suorituskyky ja skaalautuvuus käsiteltäessä korkean samanaikaisuuden tarpeita pienellä laitteistolla, käyttämättömät ( tarjoaa vain hyödyllisiä tiiliä, kehittäjillä on vapaus olla innovatiivisia ja rakentaa sovelluksiaan huolellisesti, ei kuten perinteisiä rajoittavia kehyksiä)
  • Akka - tyydyttävä suorituskyky, toteuttaa näyttelijämalli, hyvä reaktiivisiin ja tapahtumavetoisiin mikropalveluihin
  • SpringBoot / Cloud - helppo aloittaa (tutut paradigmat) perustuen vanhaan hyvään kevään kehykseen, vähän raskas kehys, monia integraatioita käytettävissä, suuri yhteisön tuki
  • Dropwizard - hyvä RESTful-verkkopalveluiden nopeaan kehittämiseen, mukana on hienoja Java-työkaluja ja -kirjastoja, kuten Google Guava, Jetty-palvelin, Logback, Hibernate Validator, Joda Time, Jersey ja Jackson.

Käyttöönottoasetukset

  • Kontit - hyvät DevOp-tavoitteiden toteuttamiseksi (nopea kehitys, markkinoille saattamisen vähentäminen, saumaton skaalaus)
  • Pilvi - hyvä luotettavan ja skaalautuvan infrastruktuurin rakentamiseen palvellakseen maantieteellisesti hajallaan olevia käyttäjiä
  • Palvelimeton - hyvä erittäin haihtuvien kauppojen käsittelyyn
  • Ylläpidä omaa IT-infrastruktuuria - hyvä niille, joilla on korkea kapasiteetti ja resurssit rakentaa koko infrastruktuuri

Kehitetään konsepteja mikropalvelujen ympärillä

  • Itsevarustetut järjestelmät - koota ohjelmisto riippumattomista järjestelmistä (kuten pystysuunnat mikropalveluissa)
  • Micro Frontends - jaa monoliittiset web-käyttöliittymät itsenäisiksi ominaisuuksiksi, joita voidaan kehittää itsenäisiksi käyttöliittymäkomponenteiksi ja kommunikoida suoraan mikropalvelujen kanssa

Avainsanat googleen (ja opiskele!)

Verkkotunnusohjattu suunnittelu (DDD) | Rajoitettu konteksti (BC) | Polyglotin pysyvyys (PP) | Komento- ja kyselyvastuusegmentit (CQRS) | Komentokyselyn erottelu (CQS) Tapahtumien hankinta (ES) | CAP-lause Lopullinen johdonmukaisuus 12 tekijän sovellus | Kiinteät periaatteet |

Arkkitehtuuriehdotukset

Microservices-arkkitehtuuri verkkokaupoissa tapahtuvalle sovellukselle (Kuva: microsoft.com) - Tämän arkkitehtuurin ehdottavat Microsoftin kehittäjät, jotka käyttävät Microsoftin tekniikoita. Täällä API-yhdyskäytävä on räätälöity käsittelemään verkko- ja mobiilikäyttäjiä eri tavalla. Tietokerrosta varten tietotallennustekniikat valitaan huolellisesti liiketoimintamahdollisuuksien mukaan (relaatiotietokannat jäsennellylle tiedolle, Redis väliaikaiselle tietojen välimuistille, MongoDB ja CosmosDB rakenteettomalle tiedolle). Tapahtumaväylän hoitama palveluiden välinen viestintä. Pitämällä tekniikat syrjään, tämä on yleisin integrointimalli, jota käytetään mikropalvelupohjaisissa sovelluksissa.Mikropalveluarkkitehtuuri sovellukselle, joka näyttää reaaliaikaiset päivitykset loppukäyttäjille käyttämällä suuria määriä eri tietolähteistä tulevia syöttötietovirtoja (esim. Liikennetiedot, säälukemat, osakemarkkinasyötteet, sosiaalisen median viestit, anturilähdöt). Nämä syöttötietovirrat kerätään aluksi tapahtumalokilla, joka toteutetaan Kafkan avulla. Se säilyttää levyllä olevan tiedon, joten sitä voidaan käyttää hajautettuihin kulutustarkoituksiin (analytiikka, raportointi, tietotiede, varmuuskopiointi, auditointi) tai lähettää tosiaikaiseen kulutustarkoitukseen (operatiivinen analytiikka, CEP, järjestelmänhallintapaneelit, hälytyssovellukset). Tämän kaavion mukaan jatkuva saapuva virta jaetaan kuitenkin mikro-eriin tietyin väliajoin Sparkin avulla ja syötetään WSO2 Siddhi CEP -moottoriin. Sitten se tunnistaa tapahtumat ja jatkaa niitä rakenteettomina muodoina MongoDB-tietovarastojen avulla. Mikropalvelut kuluttavat nämä tiedot ja näytetään loppukäyttäjille. Jos tarkastelet suunnittelua huolellisesti, koska Vert.x-tapahtumaväylällä on kyky luoda yhteyksiä käyttöliittymän käyttöliittymäkomponenteihin, tätä ominaisuutta on käytetty päivittämään tehokkaasti vain käyttöliittymän asianmukaiset osat. Pitämällä tekniikat syrjään, tämä on loistava arkkitehtuuri tapahtumapohjaiselle ei-estopalvelulle mikropalvelupohjaisille sovelluksille.Pilvien ominaiskanavien mikropalveluarkkitehtuuri tilauksenhallintasovellukselle (Kuva: ibm.com) - Yksi tämän suunnittelun tärkeimmistä erikoisuuksista on API Gateway -sovelluksen sijasta, IBM-arkkitehdit ovat ehdottaneet reunakerroksen erillisillä taustalla jokaiselle asiakaskanavalle ( mobiilisovellukset, verkkosovellukset, IOT-laitteet, API-kuluttajat). Toinen erikoisuus on, että mikropalvelutaso on jaettu kahteen alakerrokseen, joita kutsutaan Business Logic -kerrokseksi ja Foundational-kerrokseksi. Foundational Layer (a.k.a. Core Services Layer) käsittelee pysyvyys- ja integrointitehtäviä käyttämällä erilaisia ​​pilvipalveluita (pilvidatavarastot, Elasticsearch-moottorit, jotka integroivat ja indeksoivat Watson-keskustelun). Business Logic -kerros integroi tiedot Foundational-kerroksesta ja tarjoaa merkittävät liiketoimintamahdollisuudet. Tämä olisi loistava arkkitehtuuri palvelemaan erittäin suurta määrää maantieteellisesti hajaantuneita käyttäjäkuntia ja pääsyä sovelluksiin eri alustojen kautta.
Nautitko siitä toistaiseksi? Älä unohda suositella