Kas yra Kong ir kodėl jis reikalingas
Kai pradedi kurti aplikaciją su mikroservisų architektūra, greitai susiduri su iššūkiu – kaip visa tai valdyti? Turiu omenyje ne tik pačių servisų kūrimą, bet ir tai, kaip jie bendrauja tarpusavyje, kaip kontroliuoti prieigą, kaip sekti, kas vyksta, ir kaip užtikrinti, kad viskas veiktų sklandžiai. Čia ir ateina į pagalbą API gateway sprendimai, o Kong yra vienas populiariausių pasirinkimų šioje srityje.
Kong API Gateway – tai atvirojo kodo platforma, sukurta ant Nginx ir OpenResty pagrindo. Paprastai tariant, tai tarpininkas tarp kliento ir tavo mikroservisų. Visi užklausos pirmiausia patenka į Kong, o jis nusprendžia, ką su jomis daryti – ar perduoti toliau, ar blokuoti, ar transformuoti. Skamba paprasta, bet funkcionalumas yra tikrai platus.
Įsivaizduok situaciją: turi 15 skirtingų mikroservisų, kiekvienas turi savo autentifikaciją, rate limiting, logavimą. Tai būtų košmaras palaikyti. Su Kong visas šias funkcijas gali centralizuoti vienoje vietoje. Tai ne tik sutaupo laiko, bet ir sumažina klaidų tikimybę.
Pagrindiniai Kong privalumai mikroservisų ekosistemoje
Pirmiausia, Kong yra tikrai greitas. Kadangi jis pastatytas ant Nginx, gali tikėtis puikaus našumo net ir didelio krūvio metu. Testavau projektą, kur per sekundę buvo apdorojama apie 50,000 užklausų – Kong susidorojo be jokių problemų.
Antra, plėtinių ekosistema yra įspūdinga. Kong turi daugiau nei 50 oficialių plėtinių (jie vadina juos „plugins”), o bendruomenė yra sukūrusi dar šimtus papildomų. Nori JWT autentifikaciją? Yra plėtinys. Reikia rate limiting? Irgi yra. CORS, OAuth 2.0, request/response transformacijos – visa tai galima įjungti keliais paspaudimais.
Trečia, Kong puikiai integruojasi su Kubernetes. Jei naudoji K8s (o kas šiais laikais nenaudoja?), Kong Ingress Controller leidžia valdyti visą routing logiką tiesiog per Kubernetes manifests. Tai reiškia, kad tavo infrastructure-as-code workflow lieka nepažeistas.
Dar vienas dalykas, kurį vertinu – deklaratyvus konfigūravimas. Gali aprašyti visą savo API gateway konfigūraciją YAML ar JSON failuose ir versijuoti juos Git’e. Tai labai svarbu, kai dirbi komandoje ir nori turėti aiškų audit trail.
Kaip Kong veikia praktikoje
Kong architektūra susideda iš kelių pagrindinių komponentų. Pirma, yra pats Kong serveris, kuris apdoroja visas užklausas. Antra, duomenų bazė (PostgreSQL arba Cassandra), kur saugoma konfigūracija. Trečia, Admin API, per kurį valdai viską.
Kai užklausa patenka į Kong, vyksta keli etapai. Pirmiausia, Kong nustato, kuriam servisui ši užklausa skirta (tai vadinama „routing”). Tada vykdomi visi sukonfigūruoti plėtiniai tam servisui – autentifikacija, rate limiting, transformacijos ir t.t. Galiausiai, jei viskas gerai, užklausa perduodama tikrajam mikroservisui.
Štai paprastas pavyzdys. Tarkime, turi mikroservisą, veikiantį adresu http://internal-service:8000. Nori, kad jis būtų pasiekiamas per https://api.example.com/users. Su Kong tai atrodo maždaug taip:
curl -i -X POST http://localhost:8001/services/ \
--data name=user-service \
--data url='http://internal-service:8000'
curl -i -X POST http://localhost:8001/services/user-service/routes \
--data 'paths[]=/users' \
--data 'hosts[]=api.example.com'
Ir viskas. Dabar visi užklausos į https://api.example.com/users bus nukreiptos į tavo vidinį servisą. Bet tai tik pradžia.
Saugumo valdymas su Kong
Vienas iš svarbiausių API gateway uždavinių – saugumas. Kong čia tikrai neapvilia. Galiu pasidalinti keliais praktiniais pavyzdžiais iš realių projektų.
Autentifikacija yra pirmasis barjeras. Kong palaiko daugybę autentifikacijos metodų: API keys, JWT, OAuth 2.0, Basic Auth, LDAP ir kitus. Pavyzdžiui, JWT autentifikaciją įjungti labai paprasta:
curl -X POST http://localhost:8001/services/user-service/plugins \
--data "name=jwt"
Dabar visi užklausos į šį servisą turi turėti validų JWT token. Kong automatiškai validuos token’ą, patikrins signature ir expiration. Jei kas nors ne taip – užklausa bus atmesta dar nepasiekus tavo mikroserviso.
Rate limiting yra kitas kritinis aspektas. Nori apsaugoti savo API nuo piktnaudžiavimo ar DDoS atakų? Kong leidžia nustatyti limitus labai detaliai – pagal IP, pagal consumer, pagal credential. Pavyzdžiui, gali nustatyti, kad vienas vartotojas gali atlikti ne daugiau kaip 100 užklausų per minutę:
curl -X POST http://localhost:8001/services/user-service/plugins \
--data "name=rate-limiting" \
--data "config.minute=100" \
--data "config.policy=local"
ACL (Access Control Lists) leidžia dar labiau sudetinginti prieigos kontrolę. Gali sukurti grupes ir nurodyti, kurios grupės turi prieigą prie konkrečių servisų. Tai ypač naudinga, kai turi skirtingus klientų tipus – pavyzdžiui, premium ir free tier vartotojus.
Monitoring ir observability
Kai tavo aplikacija veikia production’e, žinoti, kas vyksta, yra kritiškai svarbu. Kong čia siūlo keletą sprendimų.
Logging plėtiniai leidžia siųsti visus logus į įvairias sistemas – Elasticsearch, Splunk, Datadog, arba paprasčiausiai į failą ar syslog. Aš paprastai naudoju kombinaciją: kritiniai eventai eina į Datadog, o visi kiti – į Elasticsearch.
curl -X POST http://localhost:8001/services/user-service/plugins \
--data "name=file-log" \
--data "config.path=/var/log/kong/service.log"
Prometheus plėtinys yra must-have, jei naudoji Prometheus + Grafana stack’ą monitoring’ui. Jis eksponuoja daugybę metrikų – request count, latency, bandwidth, error rates. Viską, ko reikia geram dashboard’ui.
Kong taip pat turi savo enterprise sprendimą su GUI – Kong Manager. Nors tai mokama versija, ji tikrai verta pinigų, jei valdai didelę infrastruktūrą. Ten gali matyti real-time metrikas, valdyti konfigūraciją per web interface, ir net nustatyti alerts.
Bet jei nori likti su open source versija, visiškai galima. Aš esu sukūręs custom Grafana dashboard’us, kurie rodo viską, ko man reikia. Kong Admin API suteikia prieigą prie visos informacijos, tad galimybės beveik neribotos.
Service mesh vs API gateway dilema
Dažnai kyla klausimas – ar reikia Kong, jei jau naudoji service mesh sprendimą kaip Istio ar Linkerd? Atsakymas: priklauso.
Service mesh ir API gateway sprendžia skirtingas problemas, nors funkcionalumas kartais persidengia. Service mesh daugiau orientuotas į service-to-service komunikaciją viduje klasterio – circuit breaking, retry logika, mutual TLS. API gateway daugiau orientuotas į išorinę komunikaciją – autentifikacija, rate limiting, API versioning.
Praktikoje dažnai matau kombinuotą sprendimą: Kong kaip edge gateway, o Istio viduje klasterio. Kong tvarko viską, kas susiję su išoriniais klientais, o Istio užtikrina patikimą komunikaciją tarp mikroservisų.
Tačiau jei tavo infrastruktūra nėra tokia didelė, Kong vieno gali užtekti. Jis turi circuit breaker plėtinį, proxy caching, load balancing – dauguma dalykų, kurių reikia viduje klasterio komunikacijai.
Svarbu suprasti, kad nėra vieno teisingo atsakymo. Reikia įvertinti savo specifinius poreikius. Jei turi 5 mikroservisus, tikriausiai service mesh yra overkill. Jei turi 50 – galbūt verta pagalvoti apie kombinuotą sprendimą.
Deployment strategijos ir best practices
Kai ruošiesi deplointi Kong production’e, yra keletas dalykų, kuriuos būtina žinoti.
Pirma, high availability. Niekada neturėtum turėti tik vienos Kong instancijos. Minimaliai – dvi, o geriau – tris ar daugiau, priklausomai nuo krūvio. Kong instancijos yra stateless (visa būsena saugoma duomenų bazėje), tad scale’inti horizontaliai labai paprasta.
Duomenų bazė yra kritinis komponentas. PostgreSQL paprastai yra geresnis pasirinkimas nei Cassandra, nebent tikrai reikia global distribution. Ir būtinai turėk duomenų bazės backup strategiją – praradus Kong konfigūraciją, visa tavo API infrastruktūra sustoja.
Yra ir DB-less režimas, kur visa konfigūracija saugoma YAML failuose. Tai puikus pasirinkimas Kubernetes aplinkoje, nes gali valdyti viską per GitOps. Tačiau yra apribojimų – kai kurie plėtiniai neveikia DB-less režime.
Versijų valdymas yra dar viena svarbi tema. Kai atnaujini Kong versiją, būtinai perskaityk changelog ir testuok staging aplinkoje. Kartais plėtinių API keičiasi, ir reikia atnaujinti konfigūraciją.
Štai keletas praktinių patarimų iš mano patirties:
- Naudok declarative configuration ir versijuok jį Git’e. Tai išgelbės tave ne kartą.
- Nustatyk health check endpoint’us ir monitoring’ą nuo pirmos dienos.
- Testuok rate limiting ir kitus security plėtinius staging aplinkoje su realistiniais duomenimis.
- Dokumentuok savo Kong konfigūraciją. Po metų niekas neprisiminės, kodėl tam tikras route sukonfigūruotas būtent taip.
- Naudok canary deployments, kai įdiegiate naujus plėtinius ar keičiate kritinę konfigūraciją.
Kai viskas susidėlioja į vietą
Kong nėra magiškas sprendimas, kuris išspręs visas tavo mikroservisų problemas. Bet jis tikrai gali labai palengvinti gyvenimą, jei teisingai jį naudosi. Svarbiausias dalykas – suprasti, kokias problemas nori išspręsti, ir nepersistengti su konfigūracija.
Pradėk paprastai. Įdiegk bazinį routing’ą, pridėk autentifikaciją, rate limiting. Kai tai veikia stabiliai, galėsi eksperimentuoti su sudėtingesniais dalykais – transformacijomis, custom plėtiniais, advanced monitoring.
Bendruomenė aplink Kong yra aktyvi ir draugiška. Jei užstrigtum, tikrai rasi pagalbos GitHub issues, forumuose ar Stack Overflow. Dokumentacija taip pat yra gana gera, nors kartais trūksta praktinių pavyzdžių – bet tai problema daugelio open source projektų.
Mikroservisų pasaulis yra sudėtingas, ir jis tik darosi sudėtingesnis. API gateway kaip Kong padeda suvaldyti tą chaosą ir suteikia tau kontrolę. Ar tai geriausias pasirinkimas? Priklauso nuo tavo situacijos. Bet tai tikrai vienas iš brandžiausių ir patikimiausių sprendimų rinkoje šiandien.
