Paras vastaus
Skaalautuva tarkoittaa, että järjestelmä voidaan suhteellisen helposti mukauttaa laajemmalle käyttäjäkunnalle kuin alun perin tai alun perin oli tarkoitettu . Tekijöitä, jotka määrittävät sovelluksen skaalautuvuuden, ovat:
- hyvä ohjelmarakenne (kuinka helppoa ohjelma on ymmärtää ja laajentaa tukemaan uusia rooleja)
- huolto useita käyttäjiä ja samanaikainen tietokannan käyttö ja muokkaus (jotta vältetään tietokannan lukitseminen, pääsyn estäminen, vioittuminen tai tietojen menetys)
- sekä käyttäjien pääsyä että tietokannan eheyttä koskevat turvaominaisuudet
- kyky toimia hajautettu sovellus useilla palvelimilla ja tietokannoissa useilla aikavyöhykkeillä
- tietokannan varmuuskopiointi, korjaaminen ja palauttaminen
- kieli- ja kulttuuriset säännökset
- säännös vuorovaikutuksesta kolmansien osapuolten kanssa sovellukset joko paljastamalla hyvin hallittu ohjelmaliittymä tai tilaamalla alan standardit
- resurssien käyttö ja laitteisto- / käyttöjärjestelmäriippuvuudet
- reaaliaikainen suorituskyky
On olemassa muita tekijöitä, jotka riippuvat tietyistä liiketoiminta-alueista, mutta näistä tekijöistä näemme rutiininomaisesti olevan i jatka, kun yritys yrittää ”skaalata” tai ”laajentaa” sovelluksiaan.
Skaalautuvuus kärsii yleensä, kun jompikumpi / tai:
- ohjelman on suunnitellut ja kirjoittanut joku muu ammattitaitoinen sovelluskehityksen aloilla
- vastuu ohjelman kirjoittamisesta on sovittu määrittelyllä, jossa ei tutkita kaikkia asiakkaiden tuleviin tarpeisiin sopivia tekijöitä (heikko määrittely johtaa usein skaalautumattomiin ratkaisuihin) )
- ammattitaitoinen ohjelmistoinsinööri, joka ymmärtää liiketoiminta-alueen, ei valvo
Yksinkertainen esimerkki mittakaavassa epäonnistumisesta on varasto-ohjelma, jonka parissa työskentelin vuonna 1990 (ish).
Alkuperäinen ohjelma kirjoitettiin yhdelle käyttäjälle, yhdelle palvelimelle ja yökopioille (jonka aikana järjestelmä ei ollut käytettävissä). Peräkkäisessä järjestyksessä asiakas halusi:
- lisätä käyttäjien määrää yhdestä yli 50: een ja säätää kullekin käyttäjälle erilaisia rooleja ja käyttöoikeuksia.
- laajenna sovellusta tukemaan useita varastoja samassa maassa
- laajenna sovellusta ottamaan huomioon uudet offshore-varastot, jotka merkitsivät tukea useille aikavyöhykkeille, kielille, laillisille standardeille ja toimintamenetelmille
Alkuperäistä ohjelmaa ei ollut koskaan rakennettu niin kovalle skaalausvaatimukselle. Tietokanta kärsi usein tapahtuvista ”tappavan omaksumisen” lukitsemisista, tietojen menetyksestä ja kohtuuttomasta seisokista tietokannan varmuuskopiointimenettelyjen vuoksi. Sovelluksessa ei ollut säännöksiä ”offline” -tietojen syöttämisestä, eikä sitä tietenkään kirjoitettu vikasietoisiksi viestintäongelmiin. Ohjelman päivittäminen osoittautui myös painajaiseksi – pohjimmiltaan heidän koko järjestelmänsä pysähtyi useiden tuntien ajaksi, joka kului globaalin päivityksen asentamiseen.
Ennen kuin meidät kutsuttiin konsultteiksi, ohjelma alkuperäisen kooderin (paikallinen) ”korjasi”, joka oli myöhemmin lopettanut ja kadonnut hankalasti.
Korjaus hämmensi koodin rakennetta ja toiminnallisuutta – epäilen kuitenkin, että ohjelmaa olisi koskaan rakennettu tai dokumentoitu oikein – kukaan ei ollut tiennyt tarpeeksi ymmärtääkseen riskin, jota tämä yhtiölle aiheutti! Koodi kirjoitettiin C ++: lla, ja sitä käytettiin tavutaulukkoina teollisuuden standardien, monitavuisten merkistöjen (MBCS) merkkijonojen sijaan … saat yleisen idean!
Meitä kutsuttiin korjaamaan ongelmia. Totuus on, että olisi ollut yksinkertaisempaa ja halvempaa vaihtaa asiakas kaupalliseen varastonhallintatuotteeseen, mutta heillä oli syvällisesti upotettu taloudellinen mallinnus järjestelmään, eikä kukaan ymmärtänyt tarpeeksi kuinka se toimi näiden ominaisuuksien siirtämiseksi kaupalliseen käyttöön Ohjelma (ainakaan ilman merkittävää riskiä).
Loppujen lopuksi joudumme huomauttamaan kustannustehokkaammista ratkaisuista, joudumme kuitenkin suunnittelemaan tuotteen uudelleen ja kirjoittamaan sovelluksen kokonaan uudelleen. Tuotteen uudelleenkirjoittaminen kesti 2 järjestelmäsuunnittelijaa, 4 johtavaa insinööriä, 20 ohjelmistoinsinööriä, 5 validointia ja 2 työkalu / metodologian insinööriä – ja melkein 2 vuotta kului aikaa saada sovellus yleiseen julkaisuun.
Joten miten saavutat skaalautuvuuden?
- Aloita varmistamalla, että olet kirjoittanut skaalautuvuusvaatimuksesi tuotespesifikaatioihin. Yleensä aikapaine ja edullisimmat kustannukset aiheuttavat uhrauksia alueilla, joita ei ole määritelty asianmukaisesti spesifikaatiossa.
- Tee yhteistyötä alan asiantuntijoiden kanssa, jotka voivat auttaa sinua rakentamaan rakenteen, joka vastaa (todennäköisesti) tulevaisuuden tarpeita.
- Käytä suunnittelumalleja, kirjastoja, 4GL / AI-sovelluksia ja arkkitehtuureja, jotka on muotoiltu alusta alkaen skaalautuvuuden välttämiseksi (joista monet on kehitetty katkera kokemus).
- Lue kaikki keskeiset alueet, kuten hajautetut, vikasietoiset tietokannat erittäin samanaikaisille sovelluksille, sulautetut turvallisuusarkkitehtuurit, tietokannan replikointi, pilviprosessointi jne.
- Varmista, että käytät kokeneet, kokeneet insinöörit avainasemissa. Sanoisin, että melkein 50\% toteuttamistamme pelastusprojekteista oli seurausta kokemattomista johtavista insinööreistä ja järjestelmäsuunnittelijoista. Loput johtuivat hallintavirheistä tai virheellisestä viestinnästä suunnittelun ja asiakkaan välillä.
Joten sinulla on se. Nykyään skaalautuvuuskysymyksille ei todellakaan ole mitään tekosyytä keskisuurissa ja suurissa yrityksissä, mutta monet yritykset aloittavat vain muutamalla ihmisellä, jotka hakkeroivat ratkaisuja parhaalla mahdollisella tavalla. Sitten yritys kasvaa ja skaalautuvuudesta tulee painajainen sen sijaan, että sen pitäisi olla järjestyksessä!
Vastaus
Ohjelmistotuotannon skaalautuvuus viittaa normaalisti ohjelmistojärjestelmien suunnitteluun siten, että , kun järjestelmän käyttäjien määrä kasvaa (jopa kertoimilla 100x tai enemmän), ohjelmisto toimii edelleen vastaavilla vasteaikoilla. Seuraava kysymys on ”miten tämä saavutetaan?”
Erillinen työpöytäohjelmisto (esim. Pelit) on aina 100\% skaalautuva, koska jokainen käyttäjä saa koko oman tietokoneensa. Tämä on vähäinen skaalattavuuden muoto.
Asiakaspalvelin- ja verkkopohjaiset ohjelmistojärjestelmät riippuvat kuitenkin -palvelimista , jotka ovat tietokoneita. jotka tarjoavat palveluja useille käyttäjille. Pitäisi olla ilmeistä, että mikä tahansa palvelin pystyy käsittelemään vain rajoitettua määrää samanaikaisia käyttäjiä.
On olemassa kaksi yleistä tekniikkaa, joiden avulla järjestelmä voi skaalata pidemmälle kuin mitä yksi palvelin pystyy käsittelemään. Hyvin skaalautuvat järjestelmät yhdistävät molemmat tekniikat.
Ensimmäinen on toiminnallisuuden jakaminen eri osiin. Yksi yleinen jako on saada erillinen palvelin järjestelmän tukeman tietokannan isännöimiseksi (pysyvien tietojen säilyttämiseksi on melkein aina jonkinlainen tietokanta). Tietokantapalvelimelle annetaan paljon muistia ja erittäin nopeita levyjä tai RAID-matriiseja, kun taas toisen tyyppinen palvelin tarvitsee vähemmän muistia ja suhteellisen vähän levytilaa.
Tämä voidaan laajentaa n-tason arkkitehtuuriin, jossa yhä useampi toiminnallisuus (ja data, tietokannoille) jaetaan eri prosessien kesken. Kun kuorma kasvaa, prosessit siirretään erillisiin palvelimiin suorituskyvyn ylläpitämiseksi. Huomaa, että kaikki nämä palvelimet ovat fyysisesti samassa palvelintilassa ja ne on yhdistetty erittäin nopeilla verkkoyhteyksillä.
Toinen skaalattavaksi käytetty tekniikka on replikointi . Tämä tarkoittaa, että käytetään esimerkiksi useita verkkopalvelimia ja jokainen käyttäjä on yhteydessä vain yhteen niistä. Tukemaan useampia käyttäjiä järjestelmä tarvitsee vain enemmän laitteistoja (tässä esimerkissä verkkopalvelinjärjestelmät). Tietokannat pystyvät myös replikoitumaan, joten useat tietokantapalvelimet voivat tukea tietokannan klooneja (joskus on hankalaa pitää tietokannan eri kopiot ajan tasalla, mutta dba: t ovat hoitaneet tätä ongelmaa jo vuosia). Suuremmille järjestelmille on olemassa skaalattavia tietokantoja, jotka jakavat tietonsa useille palvelimille.
A2A: ”Mitä tarkoitetaan” skaalautuvuudella ”ohjelmistotuotannossa?”