Hoi Habr!

Yn it ljocht fan aktuele barrens fanwegen it coronavirus binne in oantal ynternettsjinsten in ferhege lading begon te krijen. Bygelyks, Ien fan 'e Britske retailketens stoppe gewoan har online bestelside., omdat der net genôch kapasiteit wie. En it is net altyd mooglik om in server te fersnellen troch gewoan krêftiger apparatuer ta te foegjen, mar kliïntoanfragen moatte wurde ferwurke (as se sille nei konkurrinten gean).

Yn dit artikel sil ik koart prate oer populêre praktiken wêrmei jo in rappe en fouttolerante tsjinst kinne meitsje. Ut de mooglike ûntwikkelingsskema's haw ik lykwols allinich dejingen selektearre dy't op it stuit binne maklik te brûken. Foar elk item hawwe jo of klearmakke biblioteken, of jo hawwe de kâns om it probleem op te lossen mei in wolkplatfoarm.

Horizontale skaalfergrutting

De ienfâldichste en meast bekende punt. Konvinsjoneel binne de meast foarkommende twa loadferdielingsskema's horizontale en fertikale skaalfergrutting. Yn it earste gefal jo tastean tsjinsten te rinnen parallel, dêrmei fersprieden de lading tusken harren. Yn it twadde jo bestelle machtiger tsjinners of optimalisearje de koade.

Bygelyks, ik sil abstrakte wolkbestânsopslach nimme, dat is wat analoog fan OwnCloud, OneDrive, ensfh.

In standert ôfbylding fan sa'n sirkwy is hjirûnder, mar it toant allinich de kompleksiteit fan it systeem. Ommers, wy moatte ien of oare manier syngronisearje de tsjinsten. Wat bart der as de brûker in bestân fan 'e tablet opslaan en it dan fan' e tillefoan besjen wol?

It ferskil tusken de oanpak: yn fertikale skaalfergrutting binne wy ree om de krêft fan knopen te fergrutsjen, en yn horizontale skaalfergrutting binne wy ree om nije knopen ta te foegjen om de lading te fersprieden.

CQRS

Kommando Query Ferantwurdlikens Segregaasje In nochal wichtich patroan, om't it ferskate kliïnten mooglik makket om net allinich te ferbinen mei ferskate tsjinsten, mar ek deselde evenemintestreamen te ûntfangen. De foardielen binne net sa dúdlik foar in ienfâldige applikaasje, mar it is ekstreem wichtich (en ienfâldich) foar in drokke tsjinst. Syn essinsje: ynkommende en útgeande gegevensstreamen moatte net krúsje. Dat is, jo kinne gjin fersyk stjoere en in antwurd ferwachtsje; ynstee stjoere jo in fersyk nei tsjinst A, mar ûntfange in antwurd fan tsjinst B.

De earste bonus fan dizze oanpak is de mooglikheid om de ferbining te brekken (yn 'e brede sin fan it wurd) by it útfieren fan in lang fersyk. Litte wy bygelyks in min of mear standert folchoarder nimme:

De kliïnt stjoerde in fersyk nei de tsjinner.
De tsjinner begon in lange ferwurkingstiid.
De tsjinner reagearre op de klant mei it resultaat.

Lit ús yntinke dat yn punt 2 de ferbining waard ferbrutsen (of it netwurk opnij ferbûn, of de brûker gie nei in oare side, ferbrekke de ferbining). Yn dit gefal sil it lestich wêze foar de tsjinner om in antwurd nei de brûker te stjoeren mei ynformaasje oer wat krekt is ferwurke. Mei CQRS sil de folchoarder wat oars wêze:

De klant hat him abonnearre op updates.
De kliïnt stjoerde in fersyk nei de tsjinner.
De tsjinner antwurde "fersyk akseptearre."
De tsjinner antwurde mei it resultaat fia it kanaal fan punt "1".

Sa't jo sjen kinne, it skema is in bytsje komplekser. Boppedat ûntbrekt de yntuïtive oanpak fan fersyk-antwurd hjir. As jo lykwols sjen kinne, sil in ferbiningbreuk by it ferwurkjen fan in fersyk net liede ta in flater. Boppedat, as de brûker yn feite ferbûn is mei de tsjinst fan ferskate apparaten (bygelyks fan in mobile tillefoan en fan in tablet), kinne jo derfoar soargje dat it antwurd op beide apparaten komt.

Ynteressant wurdt de koade foar it ferwurkjen fan ynkommende berjochten itselde (net 100%) sawol foar eveneminten dy't beynfloede binne troch de kliïnt sels, en foar oare eveneminten, ynklusyf dy fan oare kliïnten.

Yn 'e realiteit krije wy lykwols in ekstra bonus fanwege it feit dat unidirectional stream kin wurde behannele yn in funksjonele styl (mei RX en ferlykber). En dit is al in serieuze plus, om't yn essinsje de applikaasje folslein reaktyf wurde kin, en ek mei in funksjonele oanpak. Foar fetprogramma's kin dit ûntwikkeling signifikant besparje en boarnen stypje.

As wy dizze oanpak kombinearje mei horizontale skaalfergrutting, dan krije wy as bonus de mooglikheid om oanfragen nei ien server te stjoeren en antwurden fan in oare te ûntfangen. Sa kin de klant de tsjinst kieze dy't him handich is, en it systeem fan binnen sil noch by steat wêze om eveneminten goed te ferwurkjen.

Event Sourcing

Lykas jo witte, is ien fan 'e wichtichste skaaimerken fan in ferspraat systeem it ûntbrekken fan in mienskiplike tiid, in mienskiplike krityske seksje. Foar ien proses kinne jo in syngronisaasje dwaan (op deselde mutexes), wêryn jo wis binne dat gjinien oars dizze koade útfiert. Dit is lykwols gefaarlik foar in ferdield systeem, om't it overhead sil fereaskje, en ek alle skientme fan skaalfergrutting sil deadzje - alle komponinten sille noch op ien wachtsje.

Hjirwei krije wy in wichtich feit - in fluch ferspraat systeem kin net syngronisearre wurde, want dan sille wy prestaasjes ferminderje. Oan 'e oare kant hawwe wy faak in bepaalde konsistinsje nedich tusken komponinten. En hjirfoar kinne jo de oanpak brûke mei úteinlike gearhing, wêr't it garandearre is dat as der gjin gegevensferoarings binne foar in perioade fan tiid nei de lêste fernijing ("úteinlik"), sille alle fragen de lêste bywurke wearde weromjaan.

It is wichtich om te begripen dat it foar klassike databases frij faak wurdt brûkt sterke gearhing, dêr't elke knooppunt hat deselde ynformaasje (dit wurdt faak berikt yn it gefal dêr't de transaksje wurdt beskôge fêststeld pas nei de twadde tsjinner reagearret). D'r binne hjir wat ûntspanningen fanwegen de isolaasjenivo's, mar it algemiene idee bliuwt itselde - jo kinne libje yn in folslein harmonisearre wrâld.

Litte wy lykwols weromgean nei de oarspronklike taak. As in part fan it systeem kin wurde boud mei úteinlike gearhing, dan kinne wy it folgjende diagram konstruearje.

Wichtige eigenskippen fan dizze oanpak:

Elk ynkommende fersyk wurdt pleatst yn ien wachtrige.
By it ferwurkjen fan in fersyk kin de tsjinst ek taken yn oare wachtrijen pleatse.
Elk ynkommende evenemint hat in identifier (dat is nedich foar deduplikaasje).
De wachtrige wurket ideologysk neffens it skema "allinne tafoegje". Jo kinne eleminten derfan net fuortsmite of opnij regelje.
De wachtrige wurket neffens it FIFO-skema (sorry foar de tautology). As jo moatte dwaan parallelle útfiering, dan op ien poadium moatte jo ferpleatse objekten nei ferskillende wachtrigen.

Lit my jo herinnerje dat wy it gefal beskôgje fan online bestân opslach. Yn dit gefal sil it systeem der sa útsjen:

It is wichtich dat de tsjinsten yn it diagram net needsaaklik in aparte tsjinner betsjutte. Sels it proses kin itselde wêze. In oar ding is wichtich: ideologysk binne dizze dingen sa skieden dat horizontale skaalfergrutting maklik tapast wurde kin.

En foar twa brûkers sil it diagram der sa útsjen (tsjinsten bedoeld foar ferskate brûkers wurde oanjûn yn ferskate kleuren):

Bonussen fan sa'n kombinaasje:

Tsjinsten foar ynformaasjeferwurking wurde skieden. De rigen wurde ek skieden. As wy de systeemtrochput moatte ferheegje, dan moatte wy gewoan mear tsjinsten op mear servers starte.
As wy ynformaasje krije fan in brûker, hoege wy net te wachtsjen oant de gegevens folslein bewarre binne. Krekt oarsom, wy moatte gewoan "ok" antwurdzje en dan stadichoan begjinne te wurkjen. Tagelyk glêdt de wachtrige peaks út, om't it tafoegjen fan in nij objekt fluch bart, en de brûker hoecht net te wachtsjen op in folsleine pass troch de heule syklus.
As foarbyld haw ik in deduplikaasjetsjinst tafoege dy't besiket identike bestannen te fusearjen. As it wurket foar in lange tiid yn 1% fan de gefallen, de klant sil amper merken it (sjoch hjirboppe), dat is in grut plus, sûnt wy binne net langer ferplichte te wêzen XNUMX% snelheid en betrouber.

De neidielen binne lykwols fuortendaliks sichtber:

Us systeem hat syn strikte konsistinsje ferlern. Dit betsjut dat as jo bygelyks abonnearje op ferskate tsjinsten, dan kinne jo teoretysk in oare steat krije (om't ien fan 'e tsjinsten miskien gjin tiid hat om in notifikaasje te ûntfangen fan' e ynterne wachtrige). As in oare konsekwinsje hat it systeem no gjin mienskiplike tiid. Dat is, it is bygelyks ûnmooglik om alle eveneminten gewoan op oankomsttiid te sortearjen, om't de klokken tusken tsjinners miskien net syngroan binne (en boppedat is deselde tiid op twa tsjinners in utopia).
Gjin eveneminten kinne no gewoan weromdraaid wurde (lykas kin dien wurde mei in database). Ynstee dêrfan moatte jo in nij barren tafoegje - kompensaasje evenemint, dy't de lêste steat feroarje sil nei de fereaske. As foarbyld út in ferlykber gebiet: sûnder skiednis te herskriuwen (wat yn guon gefallen min is), kinne jo gjin commit weromdraaie yn git, mar jo kinne in spesjale meitsje weromdraaie commit, dy't yn wêzen krekt de âlde steat werombringt. Sawol de ferkearde commit as de rollback sille lykwols yn 'e skiednis bliuwe.
It gegevensskema kin feroarje fan útjefte nei útjefte, mar âlde eveneminten kinne net mear bywurke wurde nei de nije standert (om't eveneminten yn prinsipe net feroare wurde kinne).

Sa't jo sjen kinne, wurket Event Sourcing goed mei CQRS. Boppedat is it útfieren fan in systeem mei effisjinte en handige wachtrigen, mar sûnder gegevensstreamen te skieden, op himsels al dreech, om't jo syngronisaasjepunten moatte tafoegje dy't it folsleine positive effekt fan 'e wachtrijen neutralisearje. Tapassen fan beide oanpakken tagelyk, is it nedich om in bytsje oanpasse it programma koade. Yn ús gefal, by it ferstjoeren fan in bestân nei de tsjinner, komt it antwurd allinich "ok", wat allinich betsjut dat "de operaasje fan it tafoegjen fan it bestân is bewarre." Formeel betsjut dit net dat de gegevens al beskikber binne op oare apparaten (bygelyks kin de deduplikaasjetsjinst de yndeks opnij opbouwe). Nei in skoft sil de kliïnt lykwols in notifikaasje krije yn 'e styl fan "bestân X is bewarre."

Dêrtroch:

It oantal ferstjoerstatussen fan bestân nimt ta: ynstee fan it klassike "bestân ferstjoerd", krije wy twa: "it bestân is tafoege oan de wachtrige op 'e tsjinner" en "it bestân is opslein yn opslach." Dat lêste betsjut dat oare apparaten al kinne begjinne mei it ûntfangen fan it bestân (oanpast foar it feit dat de wachtrijen op ferskate snelheden wurkje).
Fanwege it feit dat de ynstjoeringsynformaasje no fia ferskate kanalen komt, moatte wy oplossings komme om de ferwurkingsstatus fan it bestân te ûntfangen. As gefolch hjirfan: yn tsjinstelling ta de klassike fersyk-antwurd, kin de kliïnt opnij starte wurde by it ferwurkjen fan it bestân, mar de status fan dizze ferwurking sels sil korrekt wêze. Boppedat wurket dit item, yn essinsje, út 'e doaze. As gefolch: wy binne no toleranter foar mislearrings.

sharding

Lykas hjirboppe beskreaun, misse systeem foar boarnen foar eveneminten strikte konsistinsje. Dit betsjut dat wy ferskate opslach kinne brûke sûnder syngronisaasje tusken har. As wy ús probleem benaderje, kinne wy:

Skied triemmen troch type. Bygelyks, foto's / fideo's kinne wurde dekodearre en in effisjinter formaat kin selektearre wurde.
Skieden akkounts troch lân. Troch in protte wetten kin dit ferplicht wurde, mar dit arsjitektuerskema jout sa'n kâns automatysk

As jo wolle oerdrage gegevens fan de iene opslach nei de oare, dan standert middels binne net mear genôch. Spitigernôch moatte jo yn dit gefal de wachtrige stopje, de migraasje dwaan, en dan begjinne. Yn it algemiene gefal kinne gegevens net "on the fly" wurde oerdroegen, lykwols, as de barrenswachtrige folslein is opslein, en jo hawwe snapshots fan eardere opslachstaten, dan kinne wy de barrens as folgjend werhelje:

Yn Event Boarne hat elk evenemint in eigen identifier (ideaal, net-ôfnimmend). Dit betsjut dat wy in fjild kinne tafoegje oan 'e opslach - de id fan it lêste ferwurke elemint.
Wy duplisearje de wachtrige sadat alle eveneminten kinne wurde ferwurke foar ferskate ûnôfhinklike opslach (de earste is dejinge wêryn de gegevens al opslein binne, en de twadde is nij, mar noch leech). De twadde wachtrige wurdt fansels noch net ferwurke.
Wy lansearje de twadde wachtrige (dat is, wy begjinne mei it werheljen fan eveneminten).
As de nije wachtrige relatyf leech is (dat is, it gemiddelde tiidferskil tusken it tafoegjen fan in elemint en it opheljen is akseptabel), kinne jo begjinne mei it wikseljen fan lêzers nei de nije opslach.

Sa't jo sjen kinne, hawwe wy gjin strikte konsistinsje yn ús systeem, en hawwe noch altyd net. Der is allinnich úteinlike konsistinsje, dat is in garânsje dat eveneminten wurde ferwurke yn deselde folchoarder (mar mooglik mei ferskillende fertraging). En, mei help fan dit, kinne wy relatyf maklik gegevens oerdrage sûnder it systeem te stopjen nei de oare kant fan 'e wrâld.

Sa, trochgean mei ús foarbyld oer online opslach foar bestannen, sa'n arsjitektuer jout ús al in oantal bonussen:

Wy kinne objekten tichter by brûkers ferpleatse op in dynamyske manier. Op dizze manier kinne jo de kwaliteit fan 'e tsjinst ferbetterje.
Wy kinne guon gegevens binnen bedriuwen opslaan. Bygelyks, Enterprise-brûkers fereaskje faak dat har gegevens wurde opslein yn kontroleare datasintra (om gegevenslekken te foarkommen). Troch sharding kinne wy dit maklik stypje. En de taak is noch makliker as de klant in kompatibele wolk hat (bygelyks, Azure sels hosted).
En it wichtichste is dat wy dit net hoege te dwaan. Ommers, om te begjinnen, soene wy graach bliid wêze mei ien opslach foar alle akkounts (om fluch te begjinnen mei wurkjen). En it wichtichste skaaimerk fan dit systeem is dat hoewol it útwreidber is, yn 'e earste faze is it frij simpel. Jo moatte gewoan net fuortendaliks skriuwe koade dy't wurket mei in miljoen aparte ûnôfhinklike wachtrijen, ensfh. As it nedich is, kin dat yn de takomst.

Statyske ynhâldhosting

Dit punt kin lykje frij dúdlik, mar it is noch altyd nedich foar in mear of minder standert laden applikaasje. Syn essinsje is ienfâldich: alle statyske ynhâld wurdt ferspraat net fan deselde tsjinner dêr't de applikaasje leit, mar fan spesjale wijd spesifyk foar dizze taak. As resultaat wurde dizze operaasjes rapper útfierd (betingsten nginx tsjinnet bestannen rapper en minder djoer dan in Java-tsjinner). Plus CDN arsjitektuer (Netwurk foar levering fan ynhâld) lit ús ús bestannen tichter by einbrûkers lokalisearje, wat in posityf effekt hat op it gemak fan wurkjen mei de tsjinst.

It ienfâldichste en meast standert foarbyld fan statyske ynhâld is in set fan skripts en ôfbyldings foar in webside. Alles is ienfâldich mei har - se binne fan tefoaren bekend, dan wurdt it argyf opladen nei CDN-tsjinners, wêrfan se wurde ferspraat oan ein brûkers.

Yn werklikheid kinne jo lykwols foar statyske ynhâld in oanpak brûke dy't wat ferlykber is mei lambda-arsjitektuer. Litte wy weromgean nei ús taak (online bestân opslach), wêryn wy bestannen moatte fersprieden oan brûkers. De ienfâldichste oplossing is om in tsjinst te meitsjen dy't, foar elk fersyk fan brûkers, alle nedige kontrôles docht (autorisaasje, ensfh.), En dan it bestân direkt fan ús opslach downloadt. It wichtichste neidiel fan dizze oanpak is dat statyske ynhâld (en in bestân mei in bepaalde revyzje is yn feite statyske ynhâld) wurdt ferspraat troch deselde tsjinner dy't de saaklike logika befettet. Ynstee dêrfan kinne jo it folgjende diagram meitsje:

De tsjinner jout in download URL. It kin wêze fan de foarm file_id + kaai, dêr't kaai is in mini-digitale hantekening dy't jout it rjocht om tagong ta de boarne foar de folgjende XNUMX oeren.
It bestân wurdt ferspraat troch ienfâldige nginx mei de folgjende opsjes:
- Ynhâld caching. Sûnt dizze tsjinst kin lizze op in aparte server, hawwe wy ússels in reserve foar de takomst efterlitten mei de mooglikheid om alle lêste ynladen bestannen op skiif op te slaan.
- Kontrolearje de kaai op it momint fan oanmeitsjen fan ferbining
Opsjoneel: streaming ynhâld ferwurking. As wy bygelyks alle bestannen yn 'e tsjinst komprimearje, dan kinne wy direkt yn dizze module útpakke. As gefolch: IO operaasjes wurde dien wêr't se hearre. In argivator yn Java sil maklik in soad ekstra ûnthâld tawize, mar it oerskriuwen fan in tsjinst mei saaklike logika yn Rust / C ++ betingsten kin ek net effektyf wêze. Yn ús gefal wurde ferskate prosessen (as sels tsjinsten) brûkt, en dêrom kinne wy saaklike logika en IO-operaasjes frij effektyf skiede.

Dit skema is net heul gelyk oan it fersprieden fan statyske ynhâld (om't wy it heule statyske pakket net earne uploade), mar yn 'e realiteit is dizze oanpak krekt dwaande mei it fersprieden fan ûnferoarlike gegevens. Boppedat kin dit skema generalisearre wurde nei oare gefallen dêr't de ynhâld net gewoan statysk is, mar kin wurde fertsjintwurdige as in set fan ûnferoarlike en net-deletebere blokken (hoewol't se kinne wurde tafoege).

As in oar foarbyld (foar fersterking): as jo mei Jenkins/TeamCity wurke hawwe, dan witte jo dat beide oplossingen yn Java skreaun binne. Beide binne in Java-proses dat sawol build-orkestraasje as ynhâldbehear behannelet. Benammen se hawwe beide taken lykas "oerdracht fan in bestân / map fan 'e tsjinner." As foarbyld: it útjaan fan artefakten, it oerbringen fan boarnekoade (as de agint de koade net direkt fan 'e repository downloadt, mar de tsjinner it foar him docht), tagong ta logs. Al dizze taken ferskille yn har IO-lading. Dat is, it docht bliken dat de tsjinner dy't ferantwurdlik is foar komplekse saaklike logika tagelyk wêze moat om grutte streamen fan gegevens effektyf troch himsels te triuwe. En wat it meast nijsgjirrich is, is dat sa'n operaasje kin wurde delegearre oan deselde nginx neffens krekt itselde skema (útsein dat de gegevenskaai oan it fersyk tafoege wurde moat).

As wy lykwols weromgean nei ús systeem, krije wy in ferlykber diagram:

Sa't jo sjen kinne, is it systeem radikaal komplekser wurden. No is it net allinich in mini-proses dat bestannen lokaal opslaat. No wat fereaske is net de ienfâldichste stipe, API-ferzjekontrôle, ensfh. Dêrom, neidat alle diagrammen binne tekene, is it it bêste om yn detail te evaluearjen oft útwreidzjen de kosten wurdich is. As jo lykwols it systeem útwreidzje wolle (ynklusyf om mei in noch grutter oantal brûkers te wurkjen), dan moatte jo foar ferlykbere oplossings gean. Mar, as gefolch, it systeem is arsjitektoanysk klear foar ferhege load (hast elke komponint kin wurde cloned foar horizontale skaalfergrutting). It systeem kin bywurke wurde sûnder it te stopjen (gewoan guon operaasjes sille wat fertrage wurde).

Lykas ik oan it begjin sei, binne no in oantal ynternettsjinsten begon te krijen tanommen lading. En guon fan harren gewoan begûn te stopjen goed wurkjen. Yn feite, de systemen mislearre krekt op it momint dat it bedriuw soe meitsje jild. Dat is, ynstee fan útstelde levering, ynstee fan foarstelle oan klanten "plan jo levering foar de kommende moannen", sei it systeem gewoan "gean nei jo konkurrinten." Yn feite is dit de priis fan lege produktiviteit: ferliezen sille foarkomme krekt as winst soe wêze heechst.

konklúzje

Al dizze oanpak wiene earder bekend. Deselde VK hat al lang it idee fan Static Content Hosting brûkt om ôfbyldings wer te jaan. In protte online spultsjes brûke it Sharding-skema om spilers te dielen yn regio's of om spiellokaasjes te skieden (as de wrâld sels ien is). Event Sourcing-oanpak wurdt aktyf brûkt yn e-post. De measte hannelsapplikaasjes wêr't gegevens konstant wurde ûntfongen binne eins boud op in CQRS-oanpak om de ûntfongen gegevens te filterjen. No, horizontale skaalfergrutting is al in lange tiid brûkt yn in protte tsjinsten.

It wichtichste is lykwols dat al dizze patroanen heul maklik binne wurden te brûken yn moderne applikaasjes (as se fansels passend binne). Wolken biede Sharding en horizontale skaalfergrutting direkt oan, wat folle makliker is dan sels ferskate tawijde servers yn ferskate datasintra te bestellen. CQRS is folle makliker wurden, al is it mar troch de ûntwikkeling fan biblioteken lykas RX. Sa'n 10 jier lyn koe in seldsume webside dit stypje. Event Sourcing is ek ongelooflijk maklik yn te stellen, tank oan klearmakke konteners mei Apache Kafka. 10 jier lyn soe dit in ynnovaasje west hawwe, no is it gewoan. It is itselde mei Static Content Hosting: troch handiger technologyen (ynklusyf it feit dat d'r detaillearre dokumintaasje is en in grutte database fan antwurden), is dizze oanpak noch ienfâldiger wurden.

Dêrtroch is de ymplemintaasje fan in oantal frij komplekse arsjitektoanyske patroanen no folle ienfâldiger wurden, wat betsjut dat it better is om it fan tefoaren neier te besjen. As yn in tsien jier âlde applikaasje ien fan 'e oplossingen hjirboppe waard ferlitten fanwegen de hege kosten fan ymplemintaasje en eksploitaasje, no, yn in nije applikaasje, of nei refactoring, kinne jo in tsjinst meitsje dy't al arsjitektoanysk sawol útbreidber wêze sil ( yn termen fan prestaasjes) en klear makke foar nije oanfragen fan kliïnten (bygelyks om persoanlike gegevens te lokalisearjen).

En it wichtichste: brûk dizze oanpakken asjebleaft net as jo in ienfâldige applikaasje hawwe. Ja, se binne moai en nijsgjirrich, mar foar in side mei in pykbesite fan 100 minsken kinne jo faaks mei in klassike monolith komme (teminsten oan 'e bûtenkant kin alles binnen wurde ferdield yn modules, ensfh.).

Boarne: www.habr.com

Handige arsjitektoanyske patroanen