Valitettavasti tällä termillä ei ole hyvää venäjänkielistä analogia. Wikipedia antaa "Monivuokraus, monivuokra". Tätä kutsutaan joskus "moniomistukseksi". Nämä termit voivat olla hieman hämmentäviä, koska aihe ei liity luonnostaan vuokraamiseen tai omistamiseen. Tässä on kysymys ohjelmistoarkkitehtuurista ja sen toiminnan organisoinnista. Ja jälkimmäinen ei ole vähemmän tärkeä.
Aloimme muotoilla ymmärrystämme monivuokrauksesta samaan aikaan, kun aloimme suunnitella lähestymistapaa 1C:Enterprisen pilvi (palvelu) -työmalliin. Tämä oli useita vuosia sitten. Ja sen jälkeen ymmärryksemme on laajentunut jatkuvasti. Löydämme jatkuvasti uusia ja uusia näkökohtia tästä aiheesta (edut, haitat, vaikeudet, ominaisuudet jne.).
Joskus kehittäjät ymmärtävät monivuokrauksen hyvin yksinkertaisena aiheena: "Jotta useiden organisaatioiden tiedot tallentuvat yhteen tietokantaan, sinun on lisättävä kaikkiin taulukoihin sarake organisaation tunnisteella ja asetettava siihen suodatin." Aloitimme tietysti myös aiheen tutkimuksen tästä hetkestä. Mutta he huomasivat nopeasti, että tämä oli vain yksi raivaus (sekä muuten, ei helppo). Yleensä tämä on "koko maa".
Monien asunnon perusidea voidaan kuvata jotenkin näin. Tyypillinen käyttökohde on mökki, joka on suunniteltu yhdelle perheelle, joka käyttää infrastruktuuriaan (seinät, katto, vesihuolto, lämmitys jne.). Monivuokrasovellus on kerrostalo. Siinä jokainen perhe käyttää samaa infrastruktuuria, mutta itse infrastruktuuri toteutetaan koko talolle.
Onko monivuokraus hyvä vai huono? Tästä voi löytää hyvin erilaisia mielipiteitä. Ei näytä olevan "hyvää tai huonoa" ollenkaan. Sinun on verrattava etuja ja haittoja tiettyjen ratkaistavien tehtävien yhteydessä. Mutta tämä on erillinen aihe...
Yksinkertaisimmassa mielessä monivuokrauksen tavoitteena on alentaa sovelluksen ylläpitokustannuksia "sosialisoimalla" infrastruktuurikustannukset. Tämä on sama liike kuin sovelluksen kustannusten alentaminen käyttämällä tuotantoratkaisua (mahdollisesti räätälöinnillä ja muokkauksilla) sen sijaan, että kirjoitettaisiin se "tilauksesta". Vain yhdessä tapauksessa kehitys sosialisoidaan ja toisessa - hyväksikäyttö.
Lisäksi toistamme, ettei myyntitapaan ole suoraa yhteyttä. Monivuokra-arkkitehtuuria voidaan käyttää myös yritysten tai osastojen IT-infrastruktuurissa useiden vastaavien sivukonttoreiden ja holdingyhtiöiden automatisoimiseen.
Voimme sanoa, että monivuokraus ei ole vain tiedon tallennuksen järjestämistä. Tämä on malli siitä, miten sovellus toimii kokonaisuutena (mukaan lukien merkittävä osa sen arkkitehtuurista, sen käyttöönottomalli ja sen ylläpito-organisaatio).
Vaikein ja mielenkiintoisin asia monivuokramallissa on mielestämme se, että sovelluksen olemus "kahtautuu". Osa toiminnallisuudesta toimii tiettyjen data-alueiden (asunnot) kanssa eikä ole kiinnostunut siitä, että muissa asunnoissa on asukkaita. Ja jotkut näkevät talon kokonaisuutena ja toimivat kaikille asukkaille kerralla. Samanaikaisesti jälkimmäinen ei voi sivuuttaa sitä tosiasiaa, että nämä ovat loppujen lopuksi erillisiä asuntoja, ja on tarpeen varmistaa tarvittava tarkkuus- ja turvallisuustaso.
1C:Enterprisessa monivuokrausmalli on toteutettu useiden teknologioiden tasolla. Nämä ovat 1C:Enterprise-alustan mekanismeja, mekanismeja"Ja"", mekanismeja (vakioalijärjestelmien kirjastot).
Jokainen näistä kohteista edistää kerrostalon yleisen infrastruktuurin rakentamista. Miksi tämä on toteutettu useissa teknologioissa, eikä yhdessä, esimerkiksi alustassa? Ensinnäkin siksi, että jotkin mekanismit ovat mielestämme aivan sopivia muutettaviksi tiettyä käyttöönottovaihtoehtoa varten. Mutta yleensä tämä on vaikea kysymys, ja olemme jatkuvasti valinnan edessä - millä tasolla on parempi toteuttaa tämä tai toinen monivuokrauksen näkökohta.
Ilmeisesti mekanismien perusosa piti toteuttaa alustassa. No, esimerkiksi varsinainen tietojen erottelu. Täällä ihmiset yleensä alkavat puhua monivuokrauksesta. Mutta lopulta monivuokrausmalli "matkasi" läpi merkittävän osan alustan mekanismeista ja vaati niiden jalostamista ja joissakin tapauksissa uudelleen miettimistä.
Alustatasolla toteutimme täsmälleen perusmekanismit. Niiden avulla voit luoda sovelluksia, jotka toimivat monivuokrausmallissa. Mutta jotta sovellukset voisivat "elätä ja työskennellä" tällaisessa mallissa, sinulla on oltava järjestelmä heidän "elämäntoimintojensa" hallintaan. Tästä ovat vastuussa 1cFresh-teknologiat ja yhtenäinen BSP-tason liiketoimintalogiikkakerros. Aivan kuten kerrostalossa infrastruktuuri tarjoaa asukkaille kaiken tarvitsemansa, niin 1cFresh-teknologiat tarjoavat kaiken, mitä he tarvitsevat monivuokramallissa toimiviin sovelluksiin. Ja jotta sovellukset voivat olla vuorovaikutuksessa tämän infrastruktuurin kanssa (ilman merkittäviä muutoksia), vastaavat "liittimet" sijoitetaan niihin BSP-alijärjestelmien muodossa.
Alustamekanismien näkökulmasta on helppo huomata, että kokemuksen kertyessä ja pilvikäyttötapausta ”1C:Enterprise” kehitettäessä laajennamme tähän arkkitehtuuriin liittyvien mekanismien koostumusta. Otetaan yksi esimerkki. Monivuokramallissa sovelluspalveluiden osallistujien roolit muuttuvat merkittävästi. Sovellusten käytöstä vastaavien rooli (vastuutaso) kasvaa merkittävästi. Heille tuli tarpeelliseksi saada tehokkaampia sovellustenhallintatyökaluja. Koska sovellusten käyttäjät (asukkaat) luottavat ennen kaikkea palveluntarjoajaan, jonka kanssa he työskentelevät. Tätä varten otimme käyttöön uuden . Tämän mekanismin avulla palveluntarjoajien järjestelmänvalvojat voivat rajoittaa sovellusten kehittäjien vapauden vaaditulle suojaustasolle - pohjimmiltaan eristää sovelluksen toiminnan kunkin vuokralaisen osalta tietyssä hiekkalaatikossa.
Yhtä kiinnostava on arkkitehtuuri monivuokraustilassa toimivien sovellusten hallintaan (mikä on toteutettu 1cFresh- ja BSP-tekniikoissa). Tässä perinteiseen käyttöönottomalliin verrattuna hallintaprosessien automatisoinnin vaatimukset lisääntyvät merkittävästi. Tällaisia prosesseja on kymmeniä: uusien tietoalueiden ("asuntojen") luominen, sovellusten päivittäminen, viranomaistietojen päivittäminen, varmuuskopiot jne. Ja tietysti vaatimukset luotettavuus- ja käytettävyystasolle kasvavat. Esimerkiksi varmistaaksemme luotettavan vuorovaikutuksen sovellusten ja ohjausjärjestelmän komponenttien välillä otimme käyttöön asynkronisen puhelujärjestelmän tekniikan taatulla toimituksella.
Hyvin hienovarainen kohta on tapa, jolla dataa ja prosesseja sosiaalistetaan. Se näyttää yksinkertaiselta (jos se näyttää jollekin) vain ensi silmäyksellä. Suurin haaste on tasapaino tiedon ja prosessien keskittämisen ja hajauttamisen välillä. Toisaalta keskittämisen avulla voit vähentää kustannuksia (levytila, prosessoriresurssit, järjestelmänvalvojan ponnistelut...). Toisaalta se rajoittaa "vuokralaisten" vapautta. Tämä on juuri yksi sovelluksen "hajauttamisen" hetkistä, jolloin kehittäjän täytyy ajatella samanaikaisesti sovellusta suppeassa merkityksessä (palvelee yhtä "huoneistoa") ja laajassa merkityksessä (palvelee kaikkia "vuokralaisia" kerralla) .
Esimerkkinä tällaisesta "dilemmasta" voidaan mainita sääntely- ja viitetiedot. Tietenkin on suuri kiusaus tehdä siitä yhteinen kaikille talon "vuokralaisille". Näin voit tallentaa sen yhtenä kopiona ja päivittää sen kaikille kerralla. Mutta tapahtuu, että jotkut asukkaat tarvitsevat erityisiä muutoksia. Kummallista kyllä, käytännössä näin tapahtuu, jopa sääntelijöiden (hallituksen elinten) määrittelemille tiedoille. Tämä osoittautuu vaikeaksi kysymykseksi: seurustella vai olla seurustelematta? On tietysti houkuttelevaa tehdä tiedoista yleisiä kaikille ja yksityisiä niille, jotka sitä haluavat. Ja tämä johtaa jo erittäin vaikeaan toteutukseen. Mutta me työskentelemme tämän asian parissa...
Toinen esimerkki on säännöllisten prosessien toteutuksen suunnittelu (suoritetaan aikataulussa, ohjausjärjestelmän käynnistämä jne.). Toisaalta ne voidaan toteuttaa kullekin tietoalueelle erikseen. Se on helpompaa ja kätevämpää. Mutta toisaalta tällainen hieno rakeisuus kuormittaa järjestelmää suurella tavalla. Kuorman vähentämiseksi sinun on otettava käyttöön sosiaalistettuja prosesseja. Mutta ne vaativat huolellisempaa tutkimista.
Tietenkin tämä herättää erittäin tärkeän kysymyksen. Miten sovelluskehittäjät voivat varmistaa monivuokrauksen? Mitä heidän pitää tehdä tämän eteen? Tietenkin pyrimme siihen, että teknologia- ja infrastruktuuriasioiden taakka laskeutuu mahdollisimman paljon toimitettavan teknologian harteille ja sovelluskehittäjä ajattelee vain liiketoimintalogiikkatehtävissä. Mutta kuten muidenkin tärkeiden arkkitehtonisten ongelmien kanssa, sovelluskehittäjillä on oltava jonkin verran ymmärrystä monivuokrausmallissa työskentelystä, ja sovellusten kehittäminen vaatii vaivaa. Miksi? Koska on kohtia, joita tekniikka ei voi tarjota automaattisesti ottamatta huomioon datan semantiikkaa. Esimerkiksi sama informaatiososialisaation rajojen määritelmä. Mutta yritämme pitää nämä vaikeudet pieninä. Tällaisten sovellusten toteutuksesta on jo esimerkkejä.
Tärkeä asia 1C:Enterprisen monivuokrauksen toteuttamisen yhteydessä on se, että olemme luomassa hybridimallia, jossa yksi sovellus voi toimia sekä monivuokraustilassa että normaalitilassa. Tämä on erittäin vaikea tehtävä ja erillisen keskustelun aihe.
Lähde: will.com