Immagina di avere un sito web happy-cooking-together.com. (L'ho inventato quindi se diventa disponibile all'improvviso non lo prendo per davvero.) Sta diventando molto traffico e molti team ci stanno lavorando. Il codebase è diventato enorme e per lo più non mantenibile, quindi ciascuna delle squadre lotta a modo suo. Alcuni non hanno una tecnologia di front-end moderna per potenziare incredibili nuove esperienze utente mentre gli altri hanno problemi con le prestazioni e le interruzioni. L'azienda cresce così le parti interessate vogliono avere un sacco di nuove pagine, così come alcune modifiche a quelle esistenti e tutto ciò in una volta, il che porta a una collisione di priorità. Nessuno possiede più l'intera codebase e la pipeline di rilascio insieme ai test è diventata un enorme collo di bottiglia.
Quindi il team di sviluppo presenta una soluzione: rompere il monolite in micro servizi. Dopo aver analizzato i possibili modi per farlo, decidono di suddividerli in pagine diverse, quindi ciascuno dei nuovi servizi più piccoli renderà una porzione di URL esistenti. Vogliono disporre di un sistema gestibile, scalabile e gestibile in grado di adattarsi alle esigenze aziendali, consentire loro di lanciare esperimenti diversi, guidare l'innovazione in modo sicuro ea basso rischio.
Ecco il grande schema di cose che vogliono provare e vedere se funziona.
- Il proxy URL decide dove indirizzare ogni richiesta. Ad esempio,
/blog/cooking-potatoesandrà su Blog mentre tutta la/recipes/*sarà gestita dal servizio micro ricette. - Ogni servizio diventa rilevabile e invia al proxy URL e al generatore di Sitemap l'elenco di URL che serve. Ad esempio, la home page riporta solo il servizio
/URL. - Sitemap Builder funge da consumatore di quegli eventi (o segnali in una terminologia agnostica di implementazione) e di un emettitore, che mostra
/sitemap.xml. - Ogni servizio è totalmente autonomo, con il proprio database, se necessario, magari con il livello di memorizzazione nella cache, ad esempio, Sitemap Builder memorizzerà nella cache gli URL rilevati per 5 minuti per non sovraccaricare.
In superficie, tutto sembra essere logico e promettente. Il team pensa di poter iniziare implementando il componente Proxy URL insieme a Sitemap Builder e rendendo il resto degli URL serviti da un monolite esistente. Quindi procedono ad estrarre i servizi uno a uno e vedere come funzionano le cose.
Ci sono anche alcuni dettagli su cui hanno pensato:
- Tutte le intestazioni delle richieste devono essere inoltrate per i servizi corrispondenti per assicurarsi che Utente-Agente, cookie, Referente e qualsiasi altra cosa non vadano persi.
- Per mantenere la coerenza visiva per l'intero sito Web, estraggono una libreria di componenti dell'interfaccia utente che riutilizzano in modo che il menu sia sempre lo stesso e il loro bel logo.
Anche se sembra bello in superficie, sono ancora incerto su quanto segue:
- La descrizione sopra descritta ha senso?
- Quali sono i difetti e gli svantaggi di questa architettura?
- Quali sono i modi per rendere i servizi rilevabili dagli altri?
- C'è qualcosa che manca per far funzionare questo?