Moje prawdziwe pytanie brzmi, czy powyższy stos technologii może skalować 1 000 000 wiadomości na sekundę (tekst, obrazy, filmy)?
Jasne, że może. Z odpowiednim projektem i wystarczającą ilością sprzętu. Pytanie, które powinien zadać klient, tak naprawdę nie brzmi, czy można to zrobić, aby osiągnąć tak duże rozmiary, ale jakim kosztem i praktycznością można to zrobić i czy to najlepszy wybór.
Przyjrzyjmy się każdemu wymienionemu fragmentowi:
node.js - W przypadku aplikacji zorientowanej na operacje we/wy jest to doskonały wybór w przypadku dużej skali i można ją skalować, wdrażając wiele procesorów w klastrze (zarówno wieloprocesowych na serwer, jak i wieloserwerowych). To, jak praktyczna jest tego typu skala, zależy w dużej mierze od tego, do jakiego rodzaju współdzielonych danych wszystkie te procesy serwerowe potrzebują dostępu. Zwykle magazyn danych ostatecznie staje się trudniejszym wąskim gardłem w skalowaniu, ponieważ łatwo jest rzucić więcej serwerów podczas przetwarzania żądania. Nie jest łatwo wrzucić więcej sprzętu do scentralizowanego magazynu danych. Są na to sposoby, ale zależy to w dużej mierze od wymagań aplikacji dotyczących tego, jak to robisz i jak jest to trudne.
socket.io - Jeśli potrzebujesz wydajnego wypychania niewielkich wiadomości przez serwer, prawdopodobnie najlepszym rozwiązaniem jest socket.io, ponieważ jest to najbardziej wydajne wypychanie do klienta. Nie jest to jednak świetne we wszystkich rodzajach transportu. Na przykład nie przenosiłbym dużych obrazów lub filmów przez socket.io, ponieważ istnieje więcej sposobów na to, aby to zrobić. Tak więc użycie socket.io zależy w dużej mierze od tego, do czego dokładnie aplikacja chce go używać. Jeśli chcesz przesłać film do klienta, możesz również przesłać tylko adres URL, a klient odwróci się i zażąda filmu za pośrednictwem zwykłego adresu URL http przy użyciu dobrze znanej technologii wysokiej skali.
Ponownie - Znowu świetny do niektórych rzeczy, nie do wszystkiego. Tak więc to naprawdę zależy od tego, co próbujesz zrobić. To, co wyjaśniłem wcześniej, to fakt, że projekt twojego magazynu danych i liczba transakcji za jego pośrednictwem jest prawdopodobnie miejscem, w którym tkwią twoje prawdziwe problemy ze skalą. Gdybym zaczynał tę pracę, zacząłbym od zrozumienia potrzeb serwera w zakresie przechowywania danych, transakcji na sekundę różnych typów, strategii buforowania, redundancji, przełączania awaryjnego, trwałości danych itp. i zaprojektowania wysokiego najpierw skaluj dostęp do danych. Nie byłbym do końca pewien, czy redis był preferowanym wyborem. Prawdopodobnie sugerowałbym, że potrzebujesz specjalisty od baz danych na dużą skalę jako konsultanta na początku projektu.
Nginx - Wiele witryn na dużą skalę używających nginx, więc jest to z pewnością dobre narzędzie. To, czy jest to właściwe narzędzie dla Ciebie, zależy od Twojego projektu. Prawdopodobnie pracowałbym nad tą częścią jako ostatni, ponieważ wydaje się ona mniej centralna dla projektu, a po ułożeniu reszty systemu możesz rozważyć, czego tutaj potrzebujesz.
Amazonka EC2 - Jedna z kilku możliwych opcji. Te wybory są trudne do porównania bezpośrednio w porównaniu jabłek do jabłek. Systemy na dużą skalę zostały zbudowane z EC2, więc istnieje dowód koncepcji, a ogólna architektura wydaje się pasować. Jeśli chcesz wiedzieć, gdzie są prawdziwe gremliny, potrzebujesz konsultanta, który robił rzeczy na dużą skalę w EC2.
Amazon S3 - Osobiście znam kilka witryn o bardzo dużej pamięci masowej i przepustowości, które używają S3 zarówno do wideo, jak i obrazów. To działa.
Tak więc… są to na ogół dobre narzędzia do użycia, jeśli są używane we właściwy sposób. Redis byłby znakiem zapytania w zależności od potrzeb pamięci masowej rzeczywistej aplikacji (podałeś zerowe wymagania i nie można wybrać bazy danych z zerowymi wymaganiami). Bardziej uzasadniona odpowiedź byłaby oparta na zestawieniu wysokopoziomowego zestawu wymagań, które analizują, co system musi być w stanie zrobić, aby obsłużyć 1 000 000 czegokolwiek. Te wymagania można porównać ze znanymi możliwościami niektórych z tych elementów, aby rozpocząć pole manewru przy skalowaniu systemu. Następnie musiałbyś zebrać kilka testów porównawczych, aby uruchomić kilka testów na niektórych elementach systemu. Powodzenie niepowodzenia w dużej mierze zależałoby od tego, jak zbudowano aplikację i jak wykorzystano narzędzia, tak samo jak od wybranych narzędzi. Prawdopodobnie możesz stworzyć udaną skalę za pomocą wielu różnych rodzajów narzędzi. Heck, Facebook działa na PHP (cóż, wysoce zmodyfikowanym, dostosowanym PHP, który nie jest tak naprawdę typowym PHP w czasie wykonywania).
