Örökölt PHP-webhelyek migrálása az üzleti működés megszakítása nélkül

A DigiForge-nél túl sok olyan örökölt PHP-migrációs projektet láttunk, amely félresiklott – nem azért, mert a technológia nehéz lett volna, hanem mert az üzlet folyamatosan működött a költözés alatt. A „migráció” szó maga a latin „helyváltoztatás” szóból származik, és a számítástechnikában kifejezetten azt jelenti, hogy „új számítógépes rendszert kezdünk használni, vagy információt helyezünk át egyik rendszertípusból a másikba” [1]. Ez egyszerűnek hangzik, de amikor egy olyan PHP monolitot migrálsz, amely rendeléseket, felhasználói munkameneteket és fizetési integrációkat kezel, a valódi kihívás az, hogy az ügyfelek soha ne vegyenek észre semmit.

Felmérés, mielőtt egyetlen kódsort is megváltoztatnál

Mielőtt még csak gondolnánk új útvonalak írására vagy egy modern keretrendszer telepítésére, auditáljuk a meglévő alkalmazást – nemcsak a kódját, hanem a futásidejű viselkedését is. Kezdd az összes belépési pont alapos leltárával: minden útvonal, minden cron feladat, minden sorba állított feladat. Az örökölt PHP-alkalmazások gyakran rejtett végpontokkal rendelkeznek – lehet, hogy egy cron.php minden vasárnap futtatja a bérszámfejtést, vagy egy egyedi API-végpont, amelyet egy harmadik féltől származó szállítási szolgáltatás használ. Ha kihagysz egyet, a migráció el fog törni valamit.

Az audit során dokumentáld az adatfolyamot is: hogyan csatlakozik a régi alkalmazás az adatbázishoz? Vannak tárolt eljárások? Létezik megosztott fájlrendszer a feltöltött képek vagy munkamenetfájlok számára? Sok örökölt PHP-alkalmazás fájlalapú munkamenetekre támaszkodik, amelyek nem skálázhatók vízszintesen. Ez egy piros zászló, amit korán kezelünk, gyakran a munkamenetek Redisbe vagy adatbázisba történő migrálásával.

Válasszon olyan migrációs stratégiát, amely megfelel a kockázattűrő képességének

A DigiForge-nál általában három stratégia közül ajánlunk, attól függően, hogy a vállalkozás mekkora kockázatot vállal.

A nagy durranás: teljes újraírás

Ez a legdrámaibb: a semmiből felépíti az új rendszert, majd egyetlen lépésben átvált. Ez a legkockázatosabb is. Láttuk, hogy csak akkor működik, ha a régi alkalmazás kicsi (mondjuk néhány tucat oldal), vagy ha a vállalkozás elvisel egy tervezett karbantartási ablakot. Bármi, ami valós idejű tranzakciókat vagy éjjel-nappali ügyfeleket érint, kerülje ezt a megközelítést.

A strangler fig minta

A trópusi növényről elnevezett minta, amely lassan körbefonja gazdatestét, lehetővé teszi az örökölt alkalmazás darabonkénti lecserélését. Meghatározott URL-eket vagy API-végpontokat irányítasz az új kódhoz, míg a többi továbbra is a régi PHP-n fut. Egy terheléselosztó vagy fordított proxy (például Nginx vagy HAProxy) a kérés útvonala alapján irányíthatja a forgalmat. Minden lecserélt darab csökkenti a kockázatot, mert egyszerre csak egy kis felületet változtatsz. Ezt a mintát szinte minden nagyobb migrációnál használjuk.

Feature Flag-ek mindenhol

Még a strangler fig mellett is a feature flag-ek biztosítanak egy vészleállító kapcsolót. Ha az új fizetési végpont hibákat dob, átbillentesz egy jelzőt, és a forgalom visszakerül a régi kódhoz – mindezt telepítés nélkül. Az olyan eszközök, mint a LaunchDarkly, vagy egy egyszerű adatbázis-vezérelt kapcsoló jól működnek. Mindent egy jelző mögé teszünk, még az adatbázis-kapcsolatot is. Így élesben tesztelhetünk egy új lekérdezést néhány felhasználóval, mielőtt mindenkire kiterjesztenénk.

A migráció végrehajtása nulla állásidővel

A nulla állásidő nem nulla kockázatot jelent – azt jelenti, hogy a felhasználó soha nem lát hibaoldalt. A kulcs a kettős írás: amikor új adatbázis-sémára vagy más tárolórendszerre váltasz, egyidejűleg írj adatokat a régi és az új rendszerbe is. Kezdd azzal, hogy mindkettőbe írsz, de a régi rendszerből olvasol. Miután az új rendszer felzárkózott, és ellenőrizted az adatok integritását, válts át az olvasásra az új rendszerre. Végül állítsd le az írást a régi rendszerbe. Ez működik adatbázisoknál, üzenetsoroknál, fájltárolásnál és API-integrációknál is.

<?php
// Example: dual-write to old and new databases
$legacyDb = getLegacyConnection();
$newDb = getNewConnection();

function saveOrder($orderData) {
    global $legacyDb, $newDb;
    // Write to both
    $legacyDb->insert('orders', $orderData);
    $newDb->insert('orders', $orderData);
}

// Read from legacy until we verify new data
function getOrder($orderId) {
    global $legacyDb;
    return $legacyDb->fetchOne('SELECT * FROM orders WHERE id = ?', [$orderId]);
}

A kettős írás fázisában néhány percenként egyeztető szkripteket futtatunk a két adattár összehasonlítására. Az esetleges eltéréseket gyorsan észleljük. Miután az új rendszer egy teljes üzleti cikluson (általában 48 órán) keresztül megegyezik, átkapcsoljuk az olvasásokat. A következő órában szorosan figyeljük a hibanaplókat – ha bármi szokatlan történik, azonnal visszaállítjuk az előző állapotot.

Munkamenet-állapot kezelése

A régi PHP gyakran fájlokban tárolt $_SESSION-t használ. Egy új Laravel vagy Symfony alkalmazás valószínűleg adatbázis- vagy Redis-munkameneteket vár. A felhasználók bejelentkezve tartásához az átállás során egy munkamenethidat valósítunk meg: a régi alkalmazás mind fájlokba, mind egy megosztott Redis-tárolóba írja a munkameneteket; az új alkalmazás a Redis-ből olvas. Az átállás befejeztével kikapcsoljuk a fájlírást és eltávolítjuk a régi munkamenet-kezelőt.

Migráció utáni érvényesítés és visszaállítási tervezés

Még a legaprólékosabb tervezés mellett is elromlik valami. Ez nem pesszimizmus, hanem mérnöki realizmus. Mielőtt megnyomod a végső kapcsolót, írj egy visszaállítási tervet, amely tartalmazza a DNS-rekordok helyreállítását, az adatbázisséma-változtatások visszavonását és a régi alkalmazás elindítását egy pillanatképből. Legalább egyszer gyakorold a visszaállítást a tesztkörnyezetben.

A DigiForge-nál a régi éles környezetet mindig legalább két hétig futtatjuk egy nagyobb migráció után. Néhány plusz szerver költsége elhanyagolható egy olyan sikertelen visszaállításhoz képest, amely órákig tart.

Az érvényesítés túlmutat azon, hogy ellenőrizzük, betöltődnek-e az oldalak. Automatizált üzleti tranzakciós teszteket futtatunk: rendelés leadása, profil frissítése, visszatérítés feldolgozása. Összehasonlítjuk a kritikus API-végpontok kimenetét a régi és az új rendszer között. Ha olyan megfigyelőeszközt használsz, mint a New Relic vagy a Sentry, állíts be egyéni riasztásokat bármilyen 5xx-es hibára vagy lassú lekérdezésre. Végül vond be az üzleti csapatot – végezzék el a napi munkafolyamataikat az új rendszeren egy tesztkörnyezetben, mielőtt élesbe kerül.

Gyakori buktatók és hogyan kerüljük el őket

• Feltételezni, hogy a régi kód helyes. Az örökölt PHP gyakran tartalmaz csendes hibákat, amelyek „funkciókká” váltak. Minden viselkedést reprodukálni? Néha biztonságosabb kijavítani a hibát az új verzióban, ha az üzleti oldal egyetért.
• Megfeledkezni a cron feladatokról és az ütemezett feladatokról. Azok a régi curl hívások egy egyedi szkripthez? Helyet kell kapniuk az új rendszerben. A cron feladatokat áttelepítjük egy feladatütemezőbe, például a Laravel ütemezőjébe vagy egy dedikált feldolgozóba.
• Elhanyagolni a harmadik féltől származó integrációkat. A fizetési átjárók, szállítási API-k és partnerek webhookjai meghatározott formátumban küldenek adatokat. Teszteld az integrációs végpontokat korán – nem szeretnéd felfedezni a formátumeltérést a Black Friday-en.

Egy másik tanulság: ne bízz a régi dokumentációban. A kód az igazság forrása. Mindig alapos kódmélymerítést végzünk az eredeti fejlesztővel (ha elérhető) vagy egy olyan csapattaggal, aki évek óta karbantartja az alkalmazást. Az ő mentális modelljük az alkalmazás furcsaságairól felbecsülhetetlen értékű.

Következtetés

Egy örökölt PHP webhely migrálása olyan, mintha nyílt szívműtétet végeznénk egy maratont futó páciensen. A kockázat valós, de a jutalom – modern teljesítmény, biztonság és fejlesztői termelékenység – hatalmas. A DigiForge csapatával több tucat vállalkozást vezettünk végig ezen a folyamaton. A kulcs a kis, visszafordítható lépésekben való haladás, a régi rendszer folyamatos üzemben tartása, és a szüntelen monitorozás, amíg meg nem bizonyosodunk az új rendszer stabilitásáról.

Ne feledd: a migráció nem csak a technológiáról szól – arról is, hogy a vállalkozásod működőképes maradjon, miközben menet közben cseréled a motort. Tervezz gondosan, tesztelj kérlelhetetlenül, és mindig legyen készenlétben egy visszaállítási terv. A felhasználóid soha nem fogják észrevenni, hogy bármi is változott.