La separazione del server API dal server HTTP vale davvero la pena?

Nella maggior parte dei casi, questo tipo di separazioni è probabilmente un'ottimizzazione prematura. Il tuo carico di utenti giornalieri da 2k a 3.5k suona come se fosse facilmente gestibile da un singolo server, quindi l'aggiunta della replica qui è probabilmente guidata più dalla ridondanza piuttosto che dai motivi di scalabilità.

Per ogni server che separi, aumenterai la complessità operativa / di implementazione. Anche quando si utilizza l'architettura dei microservizi, si desidera dividere i servizi in base a esigenze e problemi noti ( esempi ). Ogni servizio che è stato suddiviso dovrebbe essere fatto per risolvere un problema specifico che hai, piuttosto che naturalmente.

I'm currently developing a web community that might have 2k ~ 3.5k visiting users per day

Il numero complessivo di visite non è importante quanto il picco di concorrenza in un dato momento (o un lasso di tempo). Hai ragione ad essere preoccupato per la possibilità di sovraccaricare l'app NodeJS poiché NodeJS non brilla in scenari con alta concorrenza e chiamate sincrone (richieste web).

If API server and HTTP server is separated, Isn't it taking extra time to load web page since it does SSR (server-side rendering) which means fetching data from server to server?

Non necessariamente. I server HTTP sono implementati con uno scopo specifico: per inviare richieste HTTP il più rapidamente possibile . Ciò li rende adatti al bilanciamento del carico ed è per questo che sono presenti in molte topologie di rete, di solito davanti ai server delle applicazioni. Giusto come indovini nella tua domanda.

Ci sono alcuni ben noti per la loro efficienza e velocità. Nginx è uno di questi, ma ce ne sono altri ancora più veloci come HAProxy. L'ultimo non è un server Web allo stesso modo di Ngnix o Apache HTTPD. È proxy High Availability e viene implementato in molte delle più grandi società di software. La chiave di questi componenti è che sono stati creati per svolgere un solo lavoro e farlo nel modo più efficiente e veloce possibile. Anche il linguaggio di programmazione scelto per la loro implementazione ha caratteristiche che li rendono particolarmente adatti per il lavoro.

Parlando del linguaggio di programmazione, ho detto che NodeJS non è in grado di gestire la concorrenza web, ma è eccellente per inviare richieste up o down-stream. In altre parole, è bravo a fare fire-and-forget . Pettry molto quello che fa un proxy o un gateway.

in this scenario, HTTP server should process extra fetching logic like what I explained on 3 of the above scenario flow. and since HTTP server requests to API server, I think there are some problems:

Prendi prima alcune metriche, con e senza server HTTP. Le differenze di latenza dovrebbero essere intorno a pochi millisecondi. La latenza precisa dipenderà da diverse cose. I più importanti sono se la connessione tra server è crittografata o meno (implementa TLS) e se sono distribuiti vicini l'uno all'altro.

Solitamente, vengono distribuiti nella stessa rete (come commentato da @amon) o almeno nello stesso centro dati. In ambienti molto limitati, vengono distribuiti nella stessa macchina. Poiché il processo di intercomunicazione avviene all'interno di una DMZ "sicura", non è necessario crittografare la comunicazione da server a server. E come puoi immaginare, la comunicazione tra 2 processi in esecuzione nella stessa macchina è molto molto veloce. Le latenze sono trascurabili.

I think I misunderstood the benefits of separating API and HTTP server

Le prestazioni sono uno dei motivi per cui di solito mettiamo server HTTP dedicati come bilanciatori. Potrebbero essercene altri, come servire contenuti statici. Ma anche per sicurezza. Con questi equilibri, nascondiamo la topologia della rete e esponiamo solo un singolo punto di attacco che è abbastanza semplice da proteggere. Ad esempio, reindirizzare il carico a un foro di restringimento o semplicemente impostare soglie (limiti) di richieste per indirizzo. Idealmente, non esporrai mai il server dell'app perché è una finestra che consente l'accesso a sistemi più importanti e importanti. Ad esempio il database.

Ad ogni modo, non precipitarti in false premesse o conclusioni. Prendi alcuni parametri prima. Affrontare i compromessi (complessità della distribuzione) e poi decidere se i benefici fuori pesano i costi e i pericoli.

Al momento di ottenere le metriche, prestare particolare attenzione alle latenze che provengono dal server dell'app. I potenziali clienti del tempo sono connessioni al database e connessioni a servizi esterni. Nel complesso, quando queste connessioni mettono in risalto i protocolli sincroni e, come commentato, implementano TLS.