Pro-architectuur
Uw Adobe Commerce on cloud Infrastructure Pro-architectuur ondersteunt meerdere omgevingen die u kunt gebruiken om uw winkel te ontwikkelen, te testen en te starten.
- Meester - verstrekt a
mastertak die aan Platform als de dienstcontainers (PaaS) wordt opgesteld. - Integratie - verstrekt één enkele
integrationtak voor ontwikkeling, hoewel u één extra tak kunt tot stand brengen. Dit staat voor maximaal twee actieve takken toe die aan Platform als de dienstcontainers (PaaS) worden opgesteld. - het Opvoeren - verstrekt één enkele
stagingtak die aan specifieke Infrastructuur als de dienstcontainers (IaaS) wordt opgesteld. - Productie - verstrekt één enkele
productiontak die aan specifieke Infrastructuur als de dienstcontainers (IaaS) wordt opgesteld.
De volgende tabel geeft een overzicht van de verschillen tussen omgevingen:
Omgevingsarchitectuur
Uw project is één Git-opslagplaats met drie belangrijke omgevingsvertakkingen: integration, staging en production . Het volgende diagram toont de hiërarchische verhouding van Pro milieu's:
Hoofdomgeving
Bij Pro-projecten biedt de master -vertakking een actieve PaaS-omgeving met uw productieomgeving. Duw altijd een exemplaar van de productiecode aan het master milieu zodat u het productiemilieu kunt zuiveren zonder de diensten te onderbreken.
beveats:
-
Creëer geen tak die op de
mastertak wordt gebaseerd. Gebruik de integratieomgeving om actieve vertakkingen voor ontwikkeling te maken. -
Gebruik de
master-omgeving niet voor ontwikkelings-, UAT- of prestatietests
Integratieomgeving
De integratieomgeving wordt uitgevoerd in een Linux-container (LXC) op een raster met servers die PaaS wordt genoemd. Elke omgeving bevat een webserver en database waarmee u uw site kunt testen. Zie Regionale IP Adressenvoor een lijst van AWS en Azure IP adressen.
Aanbevolen gebruiksgevallen:
De milieu's van de integratie worden ontworpen voor beperkte test en ontwikkeling alvorens veranderingen in het opvoeren en productiemilieu's te bewegen. U kunt bijvoorbeeld de integratieomgeving gebruiken om de volgende taken uit te voeren:
-
Ervoor zorgen dat wijzigingen in processen voor continue integratie (CI) compatibel zijn met de cloud
-
Kritieke workflows testen op sleutelpagina's zoals Home, Categorie, pagina met productdetails (PDP), Afhandeling en Beheer
Voor de beste prestaties in de integratieomgeving volgt u de volgende aanbevolen procedures:
-
Beperk de catalogusgrootte - Ter referentie bevat de voorbeeldgegevens ongeveer 2.048 producten. Verklein uw catalogus tot ongeveer 4.000-5.000 producten.
Om het aantal producten in de catalogus te controleren, stel de volgende vraag MySQL in werking:code language-sql select distinct count(entity_id) from catalog_product_entity; -
Verminder het aantal klantengroepen - Het hebben van teveel klantengroepen kan de indexerende prestaties en algemene prestaties beïnvloeden.
-
Gebruik beperken tot een of twee gelijktijdige gebruikers
-
Snijtaken uitschakelen en indien nodig handmatig uitvoeren
beveats:
-
Snelle CDN- en New Relic-services zijn niet toegankelijk in een integratieomgeving
-
De architectuur van het integratiemilieu past niet de Staging en architectuur van de Productie aan
-
Gebruik de
integration-omgeving niet voor het testen van de ontwikkeling, het testen van de prestaties of het testen van de gebruikersacceptatie (UAT) -
Gebruik de
integration-omgeving niet om B2B voor Adobe Commerce-functionaliteit te testen -
U kunt de database niet terugzetten in de integratieomgeving vanuit de databaseproductie of -staging
Stationele omgeving
De testomgeving biedt een omgeving voor bijna-productie om uw site te testen. Deze omgeving, die wordt gehost op toegewezen IaaS-hardware, omvat alle services, zoals Fastly CDN, New Relic APM en zoeken.
Aanbevolen gebruiksgevallen:
De omgeving komt overeen met de productiearchitectuur en is ontworpen voor UAT, inhoudstaging en definitieve revisie voordat de functies naar de production -omgeving worden verplaatst. U kunt bijvoorbeeld de staging -omgeving gebruiken om de volgende taken uit te voeren:
-
Regressietest aan de hand van productiegegevens
-
Prestaties testen met snelle caching ingeschakeld
-
Nieuwe builds testen in plaats van patching in Production
-
UAT testen voor nieuwe builds
-
Test B2B voor Adobe Commerce
-
De configuratie van de uitsnede aanpassen en de taken voor uitsnijden testen
Zie het werkschema van de Plaatsingen plaatsing van de Test.
beveats:
-
Na het lanceren van de productielocatie, gebruik het het opvoeren milieu hoofdzakelijk om flarden voor productie-kritieke insectenmoeilijke situaties te testen.
-
U kunt geen vertakking maken van de
staging-vertakking. In plaats daarvan verandert de code van deintegration-vertakking in destaging-vertakking.
Productieomgeving
De productieomgeving voert uw openbare, naar wens enkelvoudige en multisite winkels uit. Deze omgeving wordt uitgevoerd op toegewezen IaaS-hardware met redundante knooppunten met hoge beschikbaarheid voor continue toegang en failover-beveiliging voor uw klanten. Het productiemilieu omvat alle diensten in het opvoeren milieu, plus de dienst van de Infrastructuur van New Relic (NRI), die automatisch met de toepassingsgegevens en prestatiesanalyses verbindt om dynamische servercontrole te verstrekken.
Beveat:
U kunt geen vertakking maken van de production -vertakking. In plaats daarvan verandert de code van de staging -vertakking in de production -vertakking.
Stapel productietechnologie
De productieomgeving heeft drie virtuele machines (VM's) achter een Elastic Load Balancer die wordt beheerd door een HAProxy per VM. Elke VM bevat de volgende technologieën:
-
snel CDN - HTTP caching en CDN
-
NGINX - Webserver die PHP-FPM gebruikt, één instantie met veelvoudige arbeiders
-
GlusterFS - dossierserver voor het beheren van alle statische dossierplaatsingen en synchronisatie met vier foldersteunen:
varpub/mediapub/staticapp/etc
-
herstelt - één server per VM met slechts één actief en andere twee als replica's
-
Elasticsearch - onderzoek naar Adobe Commerce op wolkeninfrastructuur 2.2 aan 2.4.3-p2
-
OpenSearch - onderzoek naar Adobe Commerce op wolkeninfrastructuur 2.3.7-p3, 2.4.3-p2, 2.4.4 en later
-
Galera - gegevensbestandcluster met één gegevensbestand MariaDB MySQL per knoop met auto-verhogen het plaatsen van drie voor unieke identiteitskaarts over elk gegevensbestand
De volgende afbeelding toont de technologieën die in de productieomgeving worden gebruikt:
Redundante hardware
Eerder dan het in werking stellen van een traditioneel, actief-passief master of een primair-secundaire opstelling, stelt Adobe Commerce op wolkeninfrastructuur a overtollige architectuur in werking waar alle drie instanties lezen en schrijven goedkeuren. Deze architectuur biedt geen onderbreking wanneer het schrapen aan en verstrekt gewaarborgde transactionele integriteit.
Vanwege de unieke, redundante hardware kan Adobe drie gatewayservers leveren. De meeste externe diensten laten u toe om veelvoudige IP adressen aan een lijst van gewenste personen toe te voegen, zodat heeft meer dan één vast IP adres geen probleem is. De drie gateways wijzen aan de drie servers in uw cluster van het productiemilieu toe en behouden statische IP adressen. Het is volledig overtollig en hoogst beschikbaar op elk niveau:
- DNS
- Content Delivery Network (CDN)
- Elastic Load balancer (ELB)
- Drieservercluster bestaande uit alle Adobe Commerce-services, inclusief de database en webserver
Back-up en noodherstel
Adobe Commerce op cloudinfrastructuur maakt gebruik van een architectuur met hoge beschikbaarheid die elk Pro-project repliceert op drie aparte AWS- of Azure-beschikbaarheidszones, elke zone met een afzonderlijk datacenter. Naast deze overtolligheid, ontvangen de Pro het opvoeren en productiemilieu's regelmatige, levende steunen die voor gebruik in gevallen van catastrofale mislukking worden ontworpen.
Automatische steunen omvatten blijvende gegevens van alle lopende diensten, zoals het gegevensbestand MySQL en dossiers die op de opgezette volumes worden opgeslagen. De back-ups worden opgeslagen in gecodeerde EBS (Elastic Block Storage) in hetzelfde gebied als de productieomgeving. De automatische steunen zijn niet openbaar toegankelijk omdat zij in een afzonderlijk systeem worden opgeslagen.
app/ folder omvatten. Zoals voor de andere dossiers, worden zij gecreeerd/geproduceerd door bouwt en plaatsingsproces, en u zult ook uw bewaarplaats van het Git voor resterende dossiers moeten controleren.U kunt a handsteun van het gegevensbestand voor uw het Opvoeren en milieu's van de Productie tot stand brengen gebruikend bevelen CLI. Zie file het gegevensbestand. Voor integration -omgevingen raadt de Adobe aan een back-up te maken als eerste stap nadat ze uw Adobe Commerce hebben benaderd voor een cloud-infrastructuurproject en voordat ze belangrijke wijzigingen aanbrengen. Zie Reservekopiebeheer.
Doelstelling herstelpunt
RPO is zes uren maximumtijd aan laatste steun (bijvoorbeeld bij 06:00, toen 12:00, toen 18:00). De frequentie van back-ups is afhankelijk van het back-upschema van uw abonnement en het volume van de wijzigingen dat naar de opslagservice moet worden geschreven.
Retentiebeleid
Met Adobe blijven automatische back-ups behouden volgens het volgende beleid voor gegevensopslag:
Dit beleid kan afhankelijk van uw plan van de wolkeninfrastructuur variëren.
Doelstelling hersteltijd
RTO is afhankelijk van de grootte van de opslag. Grote EBS-volumes hebben meer tijd nodig om te herstellen. De hersteltijden kunnen variëren afhankelijk van de grootte van uw database:
- Een grote database (200+ GB) kan 5 uur duren
- Een middelgrote database (150 GB) kan 2 1/2 uur in beslag nemen
- Een kleine database (60 GB) kan 1 uur duren
Schalen in Pro-clusters
Het Pro cluster rangschikken en verwerkt configuraties afhankelijk van de gekozen wolkenleverancier (AWS, Azure), gebied, en de dienstgebiedsdelen. De de wolkeninfrastructuur van de Adobe kan Pro clusters schrapen om verkeersverwachtingen en de dienstvereisten aan te passen aangezien de vraag verandert.
De overtollige architectuur laat de Adobe wolkeninfrastructuur toe om zonder onderbreking te verhogen. Bij upscaling roteert elk van de drie instanties om de capaciteit te upgraden zonder dat dit invloed heeft op de sitebewerking. U kunt bijvoorbeeld extra webservers toevoegen aan een bestaande cluster als de beperking zich op PHP-niveau bevindt in plaats van op databaseniveau. Dit verstrekt horizontaal schrapen om het verticale schrapen aan te vullen die door extra CPUs op het gegevensbestandniveau wordt verstrekt. Zie Schaalde architectuur.
Als u een significante toename van verkeer voor een gebeurtenis of een andere reden verwacht, kunt u om een tijdelijke verhoging van capaciteit verzoeken. Zie hoe te om een tijdelijke upsizein het Centrum van de Hulp van Commerce te verzoeken.