Hogyan kezeli a Postman Engineering millió egyidejű kapcsolatot

A Postman Server Foundation csapata megosztja a Bifrost webaljzat átjáró történetét

(2020. december 22.)

A Marvel Cinematic Univerzumban a Bifrost annak a szivárványhídnak a neve, amely azonnali utazást tesz lehetővé a istenek és az emberiség. Hasonlóképpen és varázslatosan a Bifrost webhálózati átjárónk segítségével a Postman ügyfelek azonnal csatlakozhatnak a Postman szolgáltatásokhoz.

Fotó: Toni Reed a Unsplash

Amint arról korábban már beszámoltam (How Postman Engineering Does Microservices), az összes szoftverarchitektúra folyamatban lévő munka. A való világban való működés azt jelenti, hogy időnként átértékelik a régi gondolkodásmódokat, hogy alkalmazkodjanak az új körülményekhez. Ez a szoftvertervezés természetes fejlődése.

Íme a történet arról, hogy a Postman mérnökei hogyan fejlesztették ki a Bifrost websocket átjárót egy túl nagyra nőtt szolgáltatás aprításával.

Fejlesztői csapatok itt: Postman

A Postman legtöbb fejlesztői csapata többfunkciós csoportokban dolgozik, amelyek egyetlen magtartományra összpontosítanak, például dokumentációra vagy verziókezelésre . A tartományvezérelt tervezés elveitől vezérelve minden csapat belső mikroszolgáltatásokat és Postman szolgáltatásokat fejleszt a Postman felhasználók számára.

Míg a legtöbb mérnök a osztagok, egyesek funkcionális csapatokban dolgoznak, amelyek az egész mérnöki szervezetben megosztott összetevőket építenek. A Server Foundation csapata a Postman funkcionális csapatának példája. Ezek a mérnökök létrehozzák azokat a segédprogramokat, amelyeket más osztagok használnak saját jellemzőik építéséhez, szállításához és megfigyeléséhez. Ebben a csapatban laknak a rezidens AWS és az infrastruktúra szakértői is.

a Server Foundation A csapat a Postman funkcionális csapatának példája, amely létrehozza és kezeli az egész mérnöki szervezetben felhasznált anyagokat.

A Postman legtöbb mikroszolgáltatása összekapcsolva, így függetlenül fejlődhetnek a többi csapattól. Sajnos, egy szolgáltatás néha túl nagyra nőhet, és sok látszólag nem kapcsolódó szolgáltatást nyújt. Ezek a szolgáltatások lehetővé teszik a csapat számára, hogy gyorsan iteráljon, de elkezdhet inkább úgy viselkedni, mint egy duzzadt monolit, egy nagy sárgömb vagy bármi más, amit ezeknek a nehézkes lényeknek nevezni akarsz. A különböző csapatok végül hozzájárulnak a kódhoz, és minden csapatnál gondos koordinációt igényelnek minden egyes frissítéshez.

A monolitikus szinkronizálási szolgáltatás

Az egyik Postman szolgáltatás, amely túl nagyra nőtt ahhoz, hogy hatékony kezelése Sync. Ijesztő feladata, hogy a helyi gépen lévő Postman kliens összes tevékenységét szinkronizálja a Postman szerverekkel. A Postman minden felhasználói művelete egy sor webhívás-kapcsolaton keresztül végrehajtott API-hívást eredményez, közzététel-feliratkozás mintát követve , így az információk valós időben áramlanak a felhasználók és a csapatok között.

Például ez történik, ha bejelentkezik a Postman-be és frissít egy gyűjteményt:

  1. Paramétert ad a Postman-gyűjteményhez.
  2. A Postman nyilvántartást vezet a profiljában tárolt verziókezelő frissítésről.
  3. A Postman valós időben jeleníti meg a legfrissebb információkat a gyűjtemény nézői számára.

A szinkronizálást eredetileg adatbázis-tranzakciók kezelésére szánták, például egy gyűjtemény frissítésére. Tavaly ezúttal azonban a Sync további tevékenységeket is kezelt, például a legújabb verzió értesítését és megjelenítését mindenki számára, aki feliratkozott a gyűjteményre.

Nyomás alatti szinkronizálás

Amikor autót épít, a váz az a fő tartószerkezet, amelyhez az összes többi alkatrészek vannak csatlakoztatva. A keret apró repedése nem tűnhet nagy ügynek. Valószínűleg észrevétlen maradhat alacsony sebességgel való körbevezetés. Nagyobb sebességnél azonban van egy hullámzó hatás, amely fokozza az eltéréseket. A látszólag jelentéktelen repedés lehetővé teszi a rezgések felerősödését a jármű többi részén, amíg lángoló roncsokká nem nő.

„Az ilyesmi kisebb rendszereknél észrevétlen marad, a bonyolultabb rendszerekben elkerülhetetlenné válik.”
Kunal Nagpal , a Postman mérnöki vezetője

A Sync a Postman egyik legkorábbi szolgáltatása volt, és monolit architektúrája lehetővé tette a csapat számára a Postman funkcióinak gyors szállítását. Idővel egyre több felelősséggel kezdett el foglalkozni. A Sync szolgáltatás mind a mai napig széles körű befolyással bír a mérnöki szervezetben, és sok mérnök érzi a fájdalmat, amikor a Sync váratlanul viselkedik, vagy ütemezett leállás van.

2019-ben a Sync mind a websocket kapcsolatokat, mind az adatbázisokat kezelte tranzakciók. Abban az időben 11 millió felhasználónk között egyre több együttműködés történt, a Postman egymással párhuzamos csatlakozáshoz közeledett csúcsterhelés mellett.

Mivel a Postman gyakorlatilag minden mikrohelyzetének alapja volt, a Sync megterhelése egyre nőtt.

  • Lépcsőzetes hiba az ellennyomás következtében: A szinkronizáláshoz történő minden egyes telepítés leválasztja a csatlakoztatott Postman klienseket webhálózatokon keresztül. Millió aljzat újracsatlakozásakor a kiszolgáló erőforrásai leromlottak, ami további szétkapcsolásokat eredményezhet, ami kiszámítható, de elkerülhetetlen túlfeszültségeket okozhat, amelyek helyreállítása 6–8 órát vehet igénybe. Befolyásolja a felhasználói élményt: Annak ellenére, hogy ez nem gyakran fordult elő, a megszakadt kapcsolatok alkalmanként késleltetést jelentettek a legfrissebb frissítések és tevékenységek megtekintéséhez a Csapat munkaterületén. >
  • Magasabb fenntartási költség : Mivel minden csapat a Syncre támaszkodott, a Postman gyakorlatilag minden mérnökének meg kellett tanulnia kezelje az eldobott kapcsolatokat, kezdeményezzen újakat, majd egyeztesse az esetleges konfliktusokat az adatokban.

A Server Foundation csapata tudta, hogy növelni kívánják a webaljzat-kapcsolatok hatékonyságát, és külön kezeli őket a Szinkronizálási szolgáltatás. A cél egyértelmű volt, de az eléréshez vezető út nem volt.

„Ez a szoftvertervezés természetes fejlődése. A mikroszolgáltatások fürgék, de felépülnek, és vissza kell bontani őket. Szeretnénk különválasztani a socket kezelését a Sync-től, mert sokkal több funkcionalitást terveztünk bevezetni. ”
Yashish Dua , szoftvermérnök a Postás

néhány belső szolgáltatás túl nagyra nő, és gondos koordinációt igényel a csapatok között

Íme, mi történt

1. lépés: Szervezeti felvásárlást kaptunk

Az első kihívás, amelyet meg kellett oldani, nem technikai volt. Nem ez volt a Postman első ambiciózus bevezetése. A mérnöki tudomány a múltbeli körülményektől kezdve az emberekkel kezdődött. 2019 októberétől a Server Foundation mérnökei sorozatosan áttekintették a cél kommunikálását a tágabb szervezet felé, és elmagyarázták az összes függő szolgáltatás előnyeit.

Ha ez az új rendszer sikeres volt, a leesett kapcsolatok kezelése és az utóhatások kezelése már nem lenne mindennapos. Ez valódi ösztönzést jelentett a többi mérnökcsapat számára, hogy támogassák és áttérjenek az új rendszerre. Ez a nyílt kommunikáció és koordináció a projekt egész időtartama alatt folytatódni fog.

2. lépés: Az ismeretlen ismeretleneket azonosítottuk.

A mérnökök tudták, milyen irányba haladnak. Ennek ellenére megtették egy kis idő az összes forgatókönyv átgondolására és az alapul szolgáló fogalmak jobb megértésére. A mérnökök felfedező foglalkozásokat szerveztek más érdekeltekkel az ismeretlen ismeretlenek, az előre nem látható körülmények azonosítása érdekében, amelyek nagyobb kockázatot jelenthetnek, mint az ismert ismertek.

Míg a Postman szervezet kutatni és tervezni szokott, a folyamat ezen része a változás kritikus jellege miatt a normálisnál sokkal tovább tartott. Különböző lehetőségeket kutattak, figyelembe vették a kiegészítő követelményeket, és két hónap alatt kidolgoztak egy tervet.

3. Lépés: Megépítettük a Bifrost websocket átjárót

A Bifrost két rész:

  • Nyilvános átjáró : Az átjáró a Fastify web keretrendszert és az Amazon AWS-t használja ElastiCache for Redis, mint központi üzenetközvetítő az összes webhálózati kapcsolat kezeléséhez.
  • Privát API : Az API emellett a Fastify-t alacsony rezsi webes keretrendszerként használja a belső Postman-szolgáltatások forgalmának proxy-ához.
A Bifrost két részből áll: egy nyilvános átjáróból és egy privát API

4. lépés: Kipróbáltuk az új átjárót

Amikor a Postman mérnökei készen állnak egy szolgáltatás szállítására, elvárják, hogy teszteljék a funkciót és a kapcsolódó szolgáltatásokat. Mivel a Postman szinte minden szolgáltatása webhálózatokra támaszkodik, ez azt jelentette, hogy minden egyes funkciót tesztelni kellett a kiadáshoz. Ezenkívül a webaljzatok automatizált tesztelésének keretrendszerét még nem állították be még a Postman, így az összes tesztet manuálisan fejezték be a Bifrost előtt felhasználható volt a gyártásban.

Ez egy nehéz út volt, de 2020 januárjának végére a mérnöki munka bizonyítéka volt a koncepciónak.

5. lépés: Áttértünk az új átjáró

Minden Postman kliens, például az Electron alkalmazás vagy a Web, egy kezdeti indítóhívásra támaszkodik egy másik, a Godserver nevű alapszolgáltatáshoz. Ez a kiszolgáló határozza meg az ügyfelek hozzáférését és konfigurációját, és hogyan irányítja a tervezés a termék növekményes bevezetését. Mivel mindezt előre meghatározta és irányította a Godserver, a Bifrost átjáróhoz való áttéréshez nincs szükség egyetlen Postman kliens kód frissítésre.

A Server Foundation csapata felvázolta a csapatok migrációs lépéseit, a szükséges kódváltozásokat és konfigurációt. alkalmazni. Néhány hét alatt a függő szolgáltatások megkezdték a Sync-re való támaszkodásról a Bifrost-alapú webkapcsolat-kapcsolatok kezelésére való áttérést. A Godserver egyre nagyobb forgalmat terelt az új webaljzat-átjáróra, hogy lássa, hogyan kezelte a Bifrost a terhelést és hogyan reagált az éles esetekre.

„Olyan, mintha egy repülőgép közepén repülés. ”
Numaan Ashraf , a Postman mérnöki igazgatója

6. lépés: Mi átméretezte a szolgáltatást

A Bifrost átjáró működött!

De a Postman további vagy több felhasználót szerzett, miközben az átjáró a tervezés és a fejlesztés alatt állt. És a többi mérnökcsapat ez idő alatt nem szüneteltette saját munkáját. Új együttműködési funkciók, például a verzióvezérlés és a szerepalapú hozzáférés-vezérlés (RBAC) támaszkodtak erősen a webhálózatokon, hogy az információk valós időben frissüljenek. A közelgő termékkiadások özönében voltak, amelyek valóban tesztelni fogják az új átjárót.

A Bifrost készen állt a megnövekedett igények támogatására és a webhálózat-kezelés nagyságrendű kezelésére.

  • Vízszintes méretezés : Legtöbbször a Postman szolgáltatások kezelik a megnövekedett felhasználást vagy méretezéssel nagyobb kapacitású példányokra, vagy több számítási példány hozzáadásával a flottához. Tehát a Postman mérnökei általában up szolgáltatást méreteznek az AWS EC2 méretének és számítási teljesítményének növelésével. például az AWS Elastic Beanstalk használatával. De a Bifrost esetében a webhálózat-kezelési skála out a további gépek. Az optimális hatékonyság akkor érhető el, ha kisebb méretű példányokat használnak nagy számban. Ez a fajta hiper vízszintes méretezés jól működik a Bifrost esetében, mert az ügyfelek nem igényelnek nagy hálózati átvitelt, és az egyes gépek kevesebb kapcsolatra való korlátozása korlátozza a hibák robbanássugarát.
  • A CPU és a memória új terhelési tényezője : A legtöbb Postman szolgáltatás hatékonyan képes skálázni a skálázási mutató egyetlen dimenziójával, például CPU, memória vagy késés. A Bifrost esetében azonban a dolgok némileg árnyaltabbá válnak, mivel mind a memória, mind a CPU használat különböző hatással van a különböző átviteli szinteken végzett műveletekre. Ennek elszámolásához a Bifrost a terhelési tényező alapján egyéni méretezési mutatót használ. A terhelési tényező egy többdimenziós számítás, amely egyedi, nem lineáris méretezési profilt ad át.

Vessünk egy pillantást a Postman mérnöki döntéseire.

A Bifrost architektúrája és technológiai vereme

A Bifrost rendszer két fő összetevője van: egy átjáró és egy API. Ez a kétrészes architektúra a rendszer stabilitásának és skálázhatóságának titkos eleme.

A Gateway az összes webhálózati kapcsolat végpontjaként működik. Annak ellenére, hogy a kereskedelmi átjárók megvásárolhatók, fontos volt megőrizni az optimalizálás évek alatt felhalmozott örökölt üzleti logikáját. A postás mérnökök azt is teljes mértékben szabályozni akarták, hogy miként kezelik a webaljzatot, például ha be akarják használni a protokoll kézfogását. A Bifrost átjáróhoz az Amazon ElastiCache alkalmazást használták a Redis számára, amely lehetővé tette számukra a Redis gyorsítótár lekérdezését olvasó és író csomópontok segítségével.A forgalom két csomópontra történő felosztása az írási és olvasási műveletekhez tovább lehetővé teszi a csapat számára a teljesítmény optimalizálását. Ez minden Postman-ügyfél proxyja, és felelős a belső Postman-szolgáltatások alacsony szintű socket-műveleteinek kezeléséért. ”
Mudit Mehta , szoftvermérnök a Postmannál

A Postman legtöbb más szolgáltatása a Sails szolgáltatást használja valós idejű MVC keretrendszerként a Node.js számára. . A Bifrost átjáróhoz azonban a mérnököknek olyan előadó háttérrendszerre volt szükségük, amely képes nagy mennyiségek gyors és optimális memóriafelhasználású kezelésére. Ismét mélyebbre akartak menni a foglalat rétegében, a Sails által biztosított magasabb szintű absztrakciók alatt. Ezért a Fastify oldalra fordultak, és az socketio-adapter köztes szoftvert elrakták, hogy optimalizálják saját használatukra. esetek.

a Bifrost átjáró AWS-t, Redis-t és Fastify-t használt a webhálózatok kezeléséhez

Az átjáró mellett a Bifrost másik összetevője az a privát API, amely megterheli a forgalmat más Postman szolgáltatások felé. Rugalmas üzleti szabályokon alapul, ezért folyamatosan újraértékelik, hogyan és hová továbbítsa a bejövő forgalmat.

„Egyszerű összetevők. Komplex logika. ”
Kunal Nagpal , a Postman mérnöki vezetője

Mindkét alkatrész esetében a mérnökcsapat úgy döntött, hogy tekeri a sajátját. Bár a Bifrost átjáró része nem frissül gyakran, a csapat teljes mértékben ellenőrzi, mi történik a webhálózat-kezelés mélyebb rétegeiben. A Bifrost API része a művelet agya, és konvertálja a beérkező valós idejű üzeneteket szokásos HTTP hívásokká. Gyorsabban frissíthető a Sync és a Bifrost átjáró független összetevőjeként is.

Emlékszel arra a titkos szószra? A Bifrost leválasztása e két diszkrét rendszerre lehetővé teszi, hogy mindkét rész optimalizálja a saját céljait.

Az utazás még korántsem ért véget

Mint minden zamatos mérnöki történetnél, ez még nem a vége . Hagyok önöknek néhány apróságot arról, hogy mi következik a Postman mérnöki munkáival kapcsolatban.

  • További redundancia létrehozása : A Redis gyorsítótár központi üzenetközvetítő . A webhálózat kezelése továbbra is egyetlen hibapontra támaszkodik, tehát mi történik, ha a gyorsítótár valaha is lemegy?
  • Növelje a sávszélességet és az áteresztőképességet : Az átjáró jelenleg képes a tízszeres párhuzamosság kezelésére, de a Postás közösség gyorsan növekszik, és a mérnöki munka további együttműködési funkciókat épít ki. Gyorsan felmerül a nagyobb webhálózati forgalom kezelése.
  • Folytassa a monolit lebontását: A szinkronizálási szolgáltatás a kódbázisában összefonódott egyéb szolgáltatásokat tartalmaz. A konnektorkezelés leválasztása a Sync-ről lazábbá teszi a szolgáltatásokat, így az egyéb szolgáltatások már könnyebben leválaszthatók.

Ez a kulisszák mögötti újabb pillantás volt a Postman mérnöki működésére. Maradjon velünk az árkok további történeteiről.

🙏🏼 Kunal Nagpal, Yashish Dua, Mudit Mehta és Shamasis Bhattacharya műszaki áttekintése.

Eredetileg a https://blog.postman.com címen jelent meg / em> 2020. december 22-én.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük