Guida alla topologia e alla distribuzione del sito ecommerce di grandi dimensioni

3

Problema

Sono un ingegnere capo per un sito eCommerce altamente trafficato (più di 1 milione di visualizzazioni all'ora). Per varie ragioni, abbiamo l'opportunità di ricostruire ampie porzioni della nostra infrastruttura. Ciò solleva una serie di problemi interessanti nel bilanciamento della flessibilità, della stabilità, della velocità di commercializzazione, ecc ... A un livello elevato sono interessato a come gli altri hanno gestito situazioni simili. In particolare, desidero sapere in che modo altri hanno architettato il loro sito per fornire distribuzioni stabili in ambienti in rapido movimento.

  • Uno dei principali compromessi che sto esaminando è la rottura del nostro sito area funzionale e fornendo a ciascuno il proprio sottodominio. Il il driver principale per questo è che stiamo ospitando su Azure e le distribuzioni sono tutte o niente.
  • Sono anche interessato a come gli altri hanno mantenuto l'architettura integrità in un ambiente in rapido movimento e team composto da diversi livelli di esperienza.

Tech

Siamo principalmente un negozio Microsoft: SQL Server, Windows Server 2008, .Net 4.0, Visual Studio 10, ecc.

Abbiamo anche preso la decisione di ospitare il nostro sito principale sulla piattaforma di Azure e stiamo facendo un uso massiccio dell'archiviazione di tabelle e blob e della cache di app. Stiamo prendendo in considerazione l'utilizzo di più data center di Azure ma non abbiamo ancora preso la decisione definitiva.

Tutti i contenuti statici tra cui JavaScript e CSS saranno miniati e ospitati sul nostro CDN.

Il nostro sito è realizzato utilizzando .Net MVC 3 ed è supportato da un'architettura in stile DDD. Le nostre librerie di accesso ai dati e le regole aziendali sono abbastanza ben incapsulate e separate dalla logica di visualizzazione effettiva.

Processo

Pur non essendo un vero negozio agile, iteriamo molto rapidamente con frequenti implementazioni, test multivariati, requisiti just in time, ecc ... Siamo generalmente molto imprenditoriali e abbiamo la necessità di rispondere rapidamente alle nuove opportunità che si presentano. (codice per "può diventare caotico")

Team

Il nostro team di sviluppo è composto da una decina di sviluppatori con vari livelli di competenza ed esperienza. Mentre alcuni degli sviluppatori possono operare in modo indipendente, altri devono fare delle revisioni molto accurate del codice.

Il team addetto al controllo qualità ha una procedura di revisione manuale molto approfondita. Stanno anche iniziando a costruire una suite di test QTP per automatizzare i test di regressione. Il team di sviluppo a sua volta utilizza i test unitari e BDD quando appropriato.

Non considerazioni

So che ci sono molte opinioni forti là fuori, quindi per prevenire le guerre di religione ecco un paio di risposte che non mi saranno di aiuto.

  • Basta usare Java, Oracle, PHP, Ruby, ecc ...
  • Usa solo EC2
  • Chiedi ai tuoi sviluppatori di fare più attenzione
  • Dì ai tuoi sviluppatori di programmare più velocemente
  • Dì semplicemente "al business" di rallentare
  • Usa Google Checkout

Chi sto cercando feedback da

So che ci sono molti ingegneri che, pur essendo molto abili, non hanno mai lavorato su sistemi che supportano più di poche centinaia di utenti simultanei. Le lezioni apprese da un sito che supporta 30.000 utenti simultanei sono molto diverse da quelle di un'app di supporto interna (ho lavorato su entrambi, btw, e non sto denigrando le app interne. Richiedono solo un approccio diverso).

Se hai esperienza in situazioni simili, mi piacerebbe sapere come ti sei avvicinato al problema e quali sono i vantaggi della tua soluzione.

    
posta William Edmondson 21.12.2011 - 17:42
fonte

1 risposta

1

I am want to know how others have architected their site to provide stable deploys in fast moving environment.

Abbiamo: 1) Architettura standard a 3 livelli, DB (My SQL), Business (Java, Struts like), livello di presentazione (Java, Html, Javascript, Css)

2) 1 server DB primario + server DB di failover

3) 3 server web con bilanciamento del carico (Il sito è veloce come un fulmine, ma otteniamo solo circa 250.000 hit all'ora. Potremmo farcela con il 2 ma ho capito perché il server di failover non fa del lavoro piuttosto che stare inattivo )

4) Il sito e-commerce gestisce tutte le interazioni con il cliente e conserva solo i dati necessari per questo. Tutte le operazioni amministrative, di elaborazione degli ordini e di pagamento avvengono localmente all'interno del sistema ERP. Con i dati degli ordini regolarmente scaricati dal sito.

5) Tutti i dati a livello di articolo sono gestiti all'interno del sistema ERP e pubblicati regolarmente sul DB Ecommerce. (C'è un po 'di avanti e indietro per quanto riguarda la quantità disponibile tra le altre cose)

6) Al momento della distribuzione pubblichiamo l'intera base di codice. È minuscolo, penso che con meno di 10mb. E lanciamo script mod DB. Ci vogliono meno 5 minuti di downtime, lo facciamo quando l'utilizzo è basso (2am o qualcosa)

One of the main tradeoffs I am looking at is breaking our site by functional area and providing them each their own sub domain. The primary driver for this is that we are hosting on Azure and deployments are all or nothing.

Penso che questo sia un errore; influisce sull'esperienza utente, quindi deve essere fatta sulla base di ragioni commerciali e non tecniche.

I am also interested in how others have maintained architectural integrity in a fast moving environment and team composed of varying levels of experience.

Abbiamo una posizione di architetti chiave che, insieme a me stesso, conosce l'architettura del sistema di inserimento da un livello elevato. Prendiamo tutte le decisioni più importanti sull'architettura e approviamo qualsiasi modifica alla struttura Db. Agiamo come un controllo centrale.

    
risposta data 21.12.2011 - 18:35
fonte