Najlepsza odpowiedź
Skalowalność oznacza, że system może być stosunkowo łatwo dostosowany do szerszej bazy użytkowników niż początkowo lub pierwotnie planowano . Czynniki, które określają, jak skalowalna jest aplikacja, obejmują:
- dobrą strukturę programu (jak łatwy jest program do zrozumienia i rozszerzenia w celu obsługi nowych ról)
- zapewnienie wielu użytkowników i jednoczesny dostęp do bazy danych i jej edycja (aby uniknąć zablokowania bazy danych, odmowy dostępu, uszkodzenia lub utraty danych)
- postanowienia dotyczące bezpieczeństwa dostępu użytkowników i integralności bazy danych
- możliwość działania jako aplikacja rozproszona na wielu serwerach i bazach danych w wielu strefach czasowych
- tworzenie kopii zapasowych, poprawianie i przywracanie bazy danych
- przepisy językowe i kulturowe
- zapewnienie komunikacji wewnętrznej z zewnętrznymi podmiotami aplikacje, udostępniając dobrze zarządzany interfejs programu lub subskrybując standardy branżowe.
- wykorzystanie zasobów i zależności sprzętu / systemu operacyjnego
- wydajność w czasie rzeczywistym
Istnieją inne czynniki, zależne od konkretnych dziedzin biznesowych, ale są to czynniki, które zwykle stają się i problem, gdy firma próbuje „skalować” lub „rozszerzać” swoje aplikacje.
Skalowalność zwykle cierpi, gdy:
- program został wymyślony i napisany przez kogoś innego wykwalifikowany w dyscyplinach tworzenia aplikacji
- odpowiedzialność za napisanie programu jest zlecana specyfikacją, która nie obejmuje wszystkich czynników odpowiednich dla przyszłych potrzeb klienta (słaba specyfikacja często prowadzi do nieskalowalnych rozwiązań )
- nie ma nadzoru ze strony wykwalifikowanego inżyniera oprogramowania, który rozumie dziedzinę biznesową
Prostym przykładem niepowodzenia w skalowaniu jest program inwentaryzacji magazynu, nad którym pracowałem w 1990 roku (ish).
Oryginalny program został napisany dla jednego użytkownika, jednego serwera i nocnych kopii zapasowych (w tym czasie system był niedostępny). Klient chciał kolejno:
- zwiększyć liczbę użytkowników z 1 do 50+ oraz nadać każdemu użytkownikowi różne role i uprawnienia dostępu.
- rozszerzyć aplikację o obsługę wielu magazynów w tym samym kraju
- rozszerzyć aplikację o nowe magazyny typu offshore, co wiązało się z obsługą wielu stref czasowych, języków, norm prawnych i procedur operacyjnych
Pierwotny program nigdy nie był tak skonstruowany, aby sprostać tak dużym wymaganiom skalowania. Baza danych cierpiała z powodu częstych „śmiertelnych blokad”, utraty danych i niedopuszczalnych przestojów z powodu procedur tworzenia kopii zapasowych bazy danych. Aplikacja nie miała możliwości wprowadzania danych w trybie „offline” i oczywiście nie została napisana tak, aby była odporna na błędy w komunikacji. Próba aktualizacji programu również okazała się koszmarem – w zasadzie cały ich system zatrzymał się na kilka godzin, które zajęło zainstalowanie globalnej aktualizacji.
Zanim zostaliśmy wezwani jako konsultanci, program został „załatany” przez oryginalnego programistę (w liczbie pojedynczej), który następnie zakończył pracę i niewygodnie zniknął.
Poprawki zaciemniły strukturę i funkcjonalność kodu – jednak wątpię, czy program kiedykolwiek został odpowiednio skonstruowany lub udokumentowany – nikt nie wiedział wystarczająco dużo, aby zdać sobie sprawę z ryzyka, jakie stanowiło to dla firmy! Kod został napisany w C ++ i używał tablic bajtowych zamiast standardowych, wielobajtowych ciągów znaków zestawu znaków (MBCS)… masz ogólny pomysł!
Zostaliśmy wezwani, aby „naprawić” problemy. Prawda jest taka, że przejście klienta na komercyjny produkt do zarządzania zapasami byłoby prostsze i tańsze, jednak mieli oni głęboko osadzone modelowanie finansowe w systemie i nikt nie do końca rozumiał, jak działało przeniesienie tych funkcji do komercyjnego (przynajmniej bez znaczącego ryzyka).
Ostatecznie, mimo wskazania bardziej efektywnych kosztowo rozwiązań, musieliśmy przeprowadzić inżynierię wsteczną produktu i całkowicie przepisać aplikację. Przepisanie produktu wymagało 2 projektantów systemów, 4 głównych inżynierów, 20 inżynierów oprogramowania, 5 specjalistów ds. Walidacji i 2 inżynierów ds. Narzędzi / metodologii – i prawie 2 lata upłynęły, zanim aplikacja została udostępniona do ogólnej wersji.
A więc jak osiągnąć skalowalność?
- Zacznij od wpisania wymagań dotyczących skalowalności w specyfikacji produktu. Generalnie presja czasu i najniższe koszty spowodują poświęcenia w obszarach, które nie zostały odpowiednio określone w specyfikacji.
- Współpracuj z ekspertami dziedzinowymi, którzy pomogą Ci opracować strukturę, która spełni (prawdopodobne) przyszłe potrzeby.
- Skorzystaj z wzorców projektowych, bibliotek, aplikacji i architektur 4GL / AI, które zostały sformułowane od podstaw, aby uniknąć problemów związanych ze skalowalnością (wiele z nich zostało opracowanych na podstawie gorzkich doświadczeń).
- Zapoznaj się ze wszystkimi kluczowymi obszarami, takimi jak rozproszone, odporne na błędy bazy danych dla wysoce współbieżnych aplikacji, wbudowane architektury zabezpieczeń, replikacja baz danych, przetwarzanie w chmurze itp.
- Upewnij się, że używasz doświadczeni inżynierowie na kluczowych stanowiskach. Powiedziałbym, że prawie 50\% projektów ratunkowych, które podjęliśmy, było konsekwencją niedoświadczonych głównych inżynierów i projektantów systemów. Reszta była spowodowana błędami w zarządzaniu lub niewłaściwą komunikacją między inżynierem a klientem.
Więc to wszystko. W dzisiejszych czasach naprawdę nie ma usprawiedliwienia dla problemów ze skalowalnością w średnich i dużych firmach, jednak wiele firm zaczyna od zaledwie kilku osób, które hakują rozwiązania najlepiej, jak potrafią. Wtedy firma rośnie, a skalowalność staje się koszmarem, a nie uporządkowanym postępem, jakim powinien być!
Odpowiedź
Skalowalność w inżynierii oprogramowania odnosi się zwykle do projektowania systemów oprogramowania w taki sposób, że wraz ze wzrostem liczby użytkowników systemu (nawet o współczynnik 100x lub więcej) oprogramowanie będzie nadal działać z porównywalnymi czasami odpowiedzi. Teraz następne pytanie brzmi: „Jak to się robi?”
Samodzielne oprogramowanie komputerowe (np. Gry) jest zawsze w 100\% skalowalne, ponieważ każdy użytkownik otrzymuje własny komputer. To trywialna forma skalowalności.
Systemy typu klient-serwer i oprogramowanie internetowe zależą jednak od serwerów , którymi są komputery które świadczą usługi dla wielu użytkowników. Powinno być oczywiste, że każdy serwer może obsłużyć tylko pewną ograniczoną liczbę jednoczesnych użytkowników.
Istnieją dwie ogólne techniki, które umożliwiają skalowanie systemu poza to, co może obsłużyć pojedynczy serwer. Wysoce skalowalne systemy będą łączyć obie techniki.
Pierwsza polega na podzieleniu funkcjonalności na różne części. Typowym podziałem jest posiadanie oddzielnego serwera do hostowania bazy danych, na której opiera się system (prawie zawsze istnieje jakaś baza danych do przechowywania trwałych informacji). Serwer bazy danych ma dużą ilość pamięci i bardzo szybkie dyski lub macierze RAID, podczas gdy inny typ serwera wymaga mniej pamięci i stosunkowo mało miejsca na dysku.
Można to rozszerzyć do architektury n-warstwowej, gdzie coraz więcej funkcji (i danych w przypadku baz danych) jest rozdzielanych między różne procesy. Gdy obciążenie wzrasta, procesy są migrowane na oddzielne serwery w celu utrzymania wydajności. Zwróć uwagę, że wszystkie te serwery znajdują się fizycznie w tej samej farmie serwerów i są połączone bardzo szybkimi połączeniami sieciowymi.
Inną techniką skalowalności jest replikacja . Oznacza to, że np. Używanych jest wiele serwerów WWW, a każdy użytkownik jest połączony tylko z jednym z nich. Aby obsłużyć więcej użytkowników, system potrzebuje po prostu więcej sprzętu (w tym przykładzie systemy serwerów WWW). Bazy danych są również zdolne do replikacji, więc wiele serwerów baz danych może obsługiwać klony bazy danych (czasami trudno jest aktualizować różne kopie bazy danych, ale dba radzi sobie z tym problemem od lat). W przypadku większych systemów istnieją bazy danych, które są zaprojektowane tak, aby były skalowalne i dystrybuują swoje dane na wielu serwerach.
A2A: „Co oznacza„ skalowalność ”w inżynierii oprogramowania?”