RO
Personajul-glob Eco², rafinat pentru acest portofoliu după cel mai recent personaj principal oficial: un glob albastru-deschis cu uscat verde, un mugur deasupra și o față maro zâmbitoare
Înapoi în sală

Eco²

Backend · Cloud infrastructure

Îndrumări de reciclare dintr-o fotografie și o conversație.

Un asistent AI complet, care înțelege cum funcționează reciclarea în Coreea.

2025.10.31 — 2026.02.10

Proiect de echipă · fundația de infrastructură și implementare → backend de domeniu → procesare asincronă, agent conversațional, verificare

2025 새싹 해커톤 (Saessak Hackathon)Premiul de excelență · 2 decembrie 2025

  • Aplicație webServiciu închis

Cum se conectează de fapt cele 24 de noduri, câte un flux pe rând.

Kubernetes autogestionat, construit cu kubeadm. Harta plasează cele 24 de noduri fizice și sarcinile de lucru de pe ele în cele cinci straturi din README și le leagă prin conexiunile lor reale. Alegeți un flux și doar acel traseu este evidențiat, cu pași numerotați.

Identifică deșeurile dintr-o fotografie și explică modul de eliminare, iar în conversație apelează instrumente pentru locuri, vreme, prețuri de reciclare și căutare web și generează imagini. În acest proiect de echipă am început cu fundația de cluster și implementare și mi-am extins domeniul la backendul de domeniu, procesarea asincronă, agentul conversațional și verificare.

De la dezvoltarea pentru competiție până la consolidarea backendului și a operării

Serviciul și-a încheiat activitatea; un demo înregistrat și raportul tehnic îl arată în funcțiune.

Harta conexiunilor clusterului · redesenată după manifestele și codul din commitul a072127
Harta conexiunilor clusterului Eco² · 24 de noduriO hartă a celor 24 de noduri fizice în cele cinci benzi de straturi din README. Browserul doar caută numele în Route 53; după ce TLS se încheie la ALB pe 443, Envoy-ul de ingress Istio de pe un NodePort trimite cererea către un API de domeniu. API-ul Scan pune lucrul în coada RabbitMQ și returnează imediat un job_id; scan-worker din pool-ul AI scrie cu XADD evenimente de progres în Redis Streams. Event Router le citește, actualizează State KV și publică în Pub/Sub, iar SSE Gateway le trimite browserului. checkpoint-syncer stochează punctele de control Chat, iar persistence consumer de pe nodul Chat stochează mesajele în PostgreSQL. Platform Layer nu este o cale de cerere; configurează, scalează și observă.BrowserHTTPS · SSEAWS ALB443 · TLS se încheie aiciRoute 53DNSGitHub Actions · Docker Hubimagine · revizie manifestLLM APIOpenAI · GoogleLangSmithurmărirea rulărilor LLMFluent BitDaemonSet · pe fiecare nodk8s-masterALB Controller · ExternalDNSArgo CD image updaterIstiodcontrol planek8s-ingress-gatewayIstio ingress Envoyk8s-api-scanScan APIk8s-api-chatChat APImessage consumerpersistence consumerk8s-api-authauth APIext-authzk8s-api-infoInfo APIinfo-workerk8s-api-charactercharacter APIk8s-api-imageimages APIk8s-api-usersusers APIk8s-api-locationlocation APIk8s-sse-gatewaySSE Gatewayk8s-event-routerEvent Routerk8s-rabbitmqRabbitMQk8s-worker-aik8s-worker-ai-2k8s-worker-storagek8s-worker-storage-2k8s-redis-pubsubPub/Subk8s-redis-streamsStreamsState KVk8s-redis-cacheCachek8s-postgresqlPostgreSQLk8s-redis-authblacklistk8s-monitoringKEDAPrometheusGrafanaAlertmanagerk8s-loggingElasticsearchKibanascan-workerchat-workercheckpoint-syncerauth-relayauth-workerusers-workercharacter-workercharacter-match-workerKialiJaeger · dev in-memoryCluster Kubernetes24 de noduri · kubeadmEdge Layer1 nodService Layer8 noduri · sidecar EnvoyIntegration Layer7 noduriPersistence Layer5 noduriPlatform Layer3 noduri · configurare · scalare · observareGestionat de AWSPool AIdomain: worker-aipool de stocaredomain: worker-storageFără nod fixat1Căutare DNS2 HTTPS 443 · Browser → AWS ALB23HTTP · NodePort4VirtualService5Sarcină Celery6 consume · RabbitMQ → scan-worker67 HTTPS · Pool AI → LLM API78XADD scan:events9XREADGROUP10SETEX state11PUBLISH12SUBSCRIBE13Flux SSE14Recuperare la reconectare1 HTTPS 443 · Browser → AWS ALB12HTTP · NodePort3VirtualService4Sarcină Taskiq5 consume · RabbitMQ → chat-worker56 HTTPS · Pool AI → LLM API67XADD chat:events8XREADGROUP9PUBLISH10SUBSCRIBE11Flux SSE12checkpoint13citirea punctului de control14sincronizare cu PostgreSQL15chat-persistence group16salvarea mesajelor1Căutare DNS2 HTTPS 443 · Browser → AWS ALB23HTTP · NodePort4ext-authz · gRPC 500515căutare în blacklist6VirtualService7gRPC8gRPC1outbox:blacklist2blacklist.events3 blacklist.events · RabbitMQ → auth-worker34stocarea blacklistului5 Celery batch · RabbitMQ → users-worker56UPSERT1imagine · revizie manifest2Ingress → ALB · înregistrări DNS3Configurație xDS4număr de pod-uri5 număr de pod-uri · KEDA → pool de stocare56jurnale7 urmărirea rulărilor LLM · Pool AI → LangSmith7

Cerere Scan → livrare în timp real

O cerere de analiză a unei fotografii devine lucru pus în coadă, iar evenimentele ei de progres revin la același browser.

  1. BrowserCăutare DNSRoute 53

    Doar numele este rezolvat din înregistrările Route 53. Cererile nu trec prin DNS.

  2. BrowserHTTPS 443AWS ALB

    TLS se încheie la ALB.

  3. AWS ALBHTTP · NodePortIstio ingress Envoyk8s-ingress-gateway

    Transmis către Envoy-ul de ingress Istio prin NodePort-ul țintei de tip instanță EC2.

  4. Istio ingress Envoyk8s-ingress-gatewayVirtualServiceScan APIk8s-api-scan

    Rutat către API-ul Scan, care pune lucrul în coadă și returnează imediat un job_id; interogarea rezultatului răspunde cu 202 până când jobul este gata.

  5. Scan APIk8s-api-scanSarcină CeleryRabbitMQk8s-rabbitmq

    Sarcina Scan intră în RabbitMQ.

  6. RabbitMQk8s-rabbitmqconsumescan-workerk8s-worker-ai · k8s-worker-ai-2

    scan-worker (Celery · gevent) din pool-ul AI o preia și rulează Vision → Rule → Answer → Reward. Cele patru etape sunt sarcini Celery înlănțuite, nu noduri.

  7. Pool AIk8s-worker-ai · k8s-worker-ai-2HTTPSLLM API

    Workerii scan și chat apelează API-urile OpenAI și Google.

  8. scan-workerk8s-worker-ai · k8s-worker-ai-2XADD scan:eventsStreamsk8s-redis-streams

    Evenimentele de progres sunt scrise într-unul dintre cele patru sharduri Streams.

  9. Streamsk8s-redis-streamsXREADGROUPEvent Routerk8s-event-router

    Event Router le citește ca grup de consumatori și face XACK după procesare; pending și reclaim mențin livrarea at-least-once.

  10. Event Routerk8s-event-routerSETEX stateState KVk8s-redis-streams

    Scrie starea cea mai recentă și un marcaj de procesare duplicată în State KV, pe același nod Redis.

  11. Event Routerk8s-event-routerPUBLISHPub/Subk8s-redis-pubsub

    Livrate în timp real pe canalul jobului, în Pub/Sub pe sharduri.

  12. Pub/Subk8s-redis-pubsubSUBSCRIBESSE Gatewayk8s-sse-gateway

    SSE Gateway se abonează printr-un singur listener partajat per proces și le distribuie fiecărui browser conectat.

  13. SSE Gatewayk8s-sse-gatewayFlux SSEBrowser

    O conexiune deschisă pe aceeași cale ALB și ingress. Livrarea este at-least-once; duplicatele sunt tratate idempotent.

  14. State KVk8s-redis-streamsRecuperare la reconectareSSE Gatewayk8s-sse-gateway

    La reconectarea cu Last-Event-ID, State KV și Streams păstrate completează evenimentele pierdute.

Chat · tokenuri și stocare

Tokenurile Chat urmează aceeași cale de evenimente ca Scan; punctele de control și mesajele sunt stocate de două sarcini de lucru diferite.

  1. BrowserHTTPS 443AWS ALB

    TLS se încheie la ALB.

  2. AWS ALBHTTP · NodePortIstio ingress Envoyk8s-ingress-gateway

    Transmis către Envoy-ul de ingress Istio prin NodePort-ul țintei de tip instanță EC2.

  3. Istio ingress Envoyk8s-ingress-gatewayVirtualServiceChat APIk8s-api-chat

    Rutat către API-ul Chat.

  4. Chat APIk8s-api-chatSarcină TaskiqRabbitMQk8s-rabbitmq

    Sarcina Chat intră în RabbitMQ.

  5. RabbitMQk8s-rabbitmqconsumechat-workerk8s-worker-ai · k8s-worker-ai-2

    chat-worker (Taskiq · asyncio) clasifică intenția cu LangGraph, apoi rulează vision dacă e nevoie, instrumentele selectate, agregatorul și un rezumat dacă e nevoie, apoi răspunde. Fiecare cerere rulează doar ramurile de care are nevoie.

  6. Pool AIk8s-worker-ai · k8s-worker-ai-2HTTPSLLM API

    Workerii scan și chat apelează API-urile OpenAI și Google.

  7. chat-workerk8s-worker-ai · k8s-worker-ai-2XADD chat:eventsStreamsk8s-redis-streams

    Tokenurile și evenimentele de etapă sunt scrise în patru sharduri Streams; de acolo, calea de livrare este aceeași ca la Scan.

  8. Streamsk8s-redis-streamsXREADGROUPEvent Routerk8s-event-router

    Event Router le citește ca grup de consumatori și face XACK după procesare; pending și reclaim mențin livrarea at-least-once.

  9. Event Routerk8s-event-routerPUBLISHPub/Subk8s-redis-pubsub

    Livrate în timp real pe canalul jobului, în Pub/Sub pe sharduri.

  10. Pub/Subk8s-redis-pubsubSUBSCRIBESSE Gatewayk8s-sse-gateway

    SSE Gateway se abonează printr-un singur listener partajat per proces și le distribuie fiecărui browser conectat.

  11. SSE Gatewayk8s-sse-gatewayFlux SSEBrowser

    O conexiune deschisă pe aceeași cale ALB și ingress. Livrarea este at-least-once; duplicatele sunt tratate idempotent.

  12. chat-workerk8s-worker-ai · k8s-worker-ai-2checkpointCachek8s-redis-cache

    Punctul de control LangGraph este păstrat în Redis Cache.

  13. Cachek8s-redis-cachecitirea punctului de controlcheckpoint-syncerk8s-worker-ai · k8s-worker-ai-2

    checkpoint-syncer citește punctul de control din Redis.

  14. checkpoint-syncerk8s-worker-ai · k8s-worker-ai-2sincronizare cu PostgreSQLPostgreSQLk8s-postgresql

    AsyncPostgresSaver îl stochează asincron în PostgreSQL.

  15. Streamsk8s-redis-streamschat-persistence grouppersistence consumerk8s-api-chat

    persistence consumer de pe nodul Chat citește evenimentele done ca grup de consumatori.

  16. persistence consumerk8s-api-chatsalvarea mesajelorPostgreSQLk8s-postgresql

    Mesajele Chat sunt salvate în PostgreSQL. Este o sarcină de lucru diferită de checkpoint-syncer.

Intrare · autentificare

Calea sincronă de la intrarea în cluster până la un API de domeniu. Doar căile protejate de politici verifică mai întâi autentificarea; traficul dintre pod-uri de pe noduri diferite rulează pe Calico VXLAN.

  1. BrowserCăutare DNSRoute 53

    Doar numele este rezolvat din înregistrările Route 53. Cererile nu trec prin DNS.

  2. BrowserHTTPS 443AWS ALB

    TLS se încheie la ALB.

  3. AWS ALBHTTP · NodePortIstio ingress Envoyk8s-ingress-gateway

    Transmis către Envoy-ul de ingress Istio prin NodePort-ul țintei de tip instanță EC2.

  4. Istio ingress Envoyk8s-ingress-gatewayext-authz · gRPC 50051ext-authzk8s-api-auth

    Doar căile aflate sub o politică CUSTOM întreabă mai întâi Go ext-authz (timeout 2 s, failOpen false). Căi precum login, health și docs sunt excluse.

  5. ext-authzk8s-api-authcăutare în blacklistblacklistk8s-redis-auth

    Tokenul este verificat în blacklistul Redis.

  6. Istio ingress Envoyk8s-ingress-gatewayVirtualServiceChat APIk8s-api-chat

    Rutat către API-ul Chat.

  7. Chat APIk8s-api-chatgRPCimages APIk8s-api-image

    Apelul sincron chat → images menționat în README.

  8. auth APIk8s-api-authgRPCusers APIk8s-api-users

    Apelul sincron auth → users menționat în README.

Pool de stocare · scrieri asincrone

Blacklistul de autentificare și proprietatea asupra personajelor sunt stocate de workerii din pool-ul de stocare, care își primesc lucrul din RabbitMQ.

  1. blacklistk8s-redis-authoutbox:blacklistauth-relayk8s-worker-storage · k8s-worker-storage-2

    auth-relay (auth-Bus din README) citește outboxul Redis.

  2. auth-relayk8s-worker-storage · k8s-worker-storage-2blacklist.eventsRabbitMQk8s-rabbitmq

    Republică în RabbitMQ, cu reîncercări și un DLQ.

  3. RabbitMQk8s-rabbitmqblacklist.eventsauth-workerk8s-worker-storage · k8s-worker-storage-2

    auth-worker primește evenimentele de blacklist.

  4. auth-workerk8s-worker-storage · k8s-worker-storage-2stocarea blacklistuluiblacklistk8s-redis-auth

    Sunt stocate în blacklistul Redis.

  5. RabbitMQk8s-rabbitmqCelery batchusers-workerk8s-worker-storage · k8s-worker-storage-2

    users-worker primește în loturi lucrul privind proprietatea asupra personajelor.

  6. users-workerk8s-worker-storage · k8s-worker-storage-2UPSERTPostgreSQLk8s-postgresql

    Este aplicat în PostgreSQL.

Configurare · scalare · observare

Platform Layer nu este o etapă prin care trec cererile; implementează, configurează, scalează și observă celelalte straturi. Nodurile sunt instanțe EC2 create cu Terraform, cu kubeadm și Calico instalate prin Ansible; CI doar validează Terraform și nu face niciodată apply automat.

  1. GitHub Actions · Docker Hubimagine · revizie manifestArgo CD image updaterk8s-master

    Argo CD aliniază configurația clusterului prin App-of-Apps și Sync Waves. Plasarea pe control-plane a fost confirmată doar pentru image updater.

  2. ALB Controller · ExternalDNSk8s-masterIngress → ALB · înregistrări DNSGestionat de AWS

    ALB Controller și ExternalDNS configurează resursele din partea AWS. Nu este o cale pe care o urmează cererile.

  3. Istiodk8s-masterConfigurație xDSIstio ingress Envoyk8s-ingress-gateway

    Istiod trimite prin xDS configurația Gateway, VirtualService și EnvoyFilter către Envoy-ul de ingress și către sidecarul Envoy al fiecărui API.

  4. KEDAk8s-monitoringnumăr de pod-uriPool AIk8s-worker-ai · k8s-worker-ai-2

    KEDA ajustează numărul de pod-uri ale workerilor. Numărul de noduri nu se schimbă.

  5. KEDAk8s-monitoringnumăr de pod-uripool de stocarek8s-worker-storage · k8s-worker-storage-2

    Pod-urile workerilor din pool-ul de stocare sunt scalate la fel.

  6. Fluent BitjurnaleElasticsearchk8s-logging

    Fluent Bit este un DaemonSet pe fiecare nod și trimite jurnalele către Elasticsearch.

  7. Pool AIk8s-worker-ai · k8s-worker-ai-2urmărirea rulărilor LLMLangSmith

    Urmele apelurilor LLM merg la LangSmith, un SaaS extern.

Fiecare conexiune cu aceeași grosime. Alegeți un flux pentru a evidenția doar traseul lui, cu pași numerotați.

  • Continuă · direcția în care circulă cererile, lucrul, evenimentele și scrierile
  • Punctată · căutare DNS; cererile nu trec prin ea
  • Întreruptă · configurare sau scalare; nu este o cale de date
  • Linie-punct lungă · jurnale și urmărirea rulărilor
  • Linie neagră groasă · fluxul selectat; numerele dau ordinea
  • Casetă · un nod fizic, cu numele gazdei în antet
  • Etichetă interioară · o sarcină de lucru care rulează pe acel nod
  • Cadru întrerupt · un pool de planificare cu două noduri
  • Casetă întreruptă · în afara clusterului, nenumărată ca nod
  • Contur portocaliu · locul în care decide un model
  • Control plane1 nod
  • Domain API8 noduri
  • Pool AI2 noduri
  • pool de stocare2 noduri
  • Data5 noduri
  • Platform6 noduri

Cele cinci straturi din README (benzile) și grupurile fizice (nuanța antetului fiecărui nod) grupează diferit aceleași 24 de noduri. State KV împarte nodul Streams și nu este numărat separat; Route 53, ALB și serviciile din afara clusterului nu sunt noduri. Un pool este un domeniu de planificare, nu o afirmație că fiecare pod rulează pe ambele noduri.

Configurația cu 24 de noduri · după lista de noduri din dashboardul din 21 ianuarie 2026

24noduri

24 = 1 control plane + 8 API + 4 worker + 5 data + 6 platform

  1. 1Control plane

    role: control-plane

    kube-apiserver · scheduler · controller-manager · etcd, plus controlerele de platformă.

    1. k8s-master

  2. 8Domain API

    domain: <serviciu>

    Un nod pentru fiecare domeniu. Apelurile interne folosesc gRPC.

    1. k8s-api-auth
    2. k8s-api-users
    3. k8s-api-scan
    4. k8s-api-character
    5. k8s-api-location
    6. k8s-api-image
    7. k8s-api-chat
    8. k8s-api-info

  3. 4Execution worker

    Două pool-uri de planificare, cu câte două noduri fiecare. KEDA schimbă numărul de pod-uri; numărul de noduri rămâne același.

    pool de stocaredomain: worker-storage
    1. k8s-worker-storage
    2. k8s-worker-storage-2
    Pool AIdomain: worker-ai
    1. k8s-worker-ai
    2. k8s-worker-ai-2

  4. 5Data

    Redis este împărțit pe patru noduri dedicate. Stocarea PostgreSQL este EBS CSI · gp3.

    1. k8s-postgresql
    2. k8s-redis-auth
    3. k8s-redis-streams
    4. k8s-redis-cache
    5. k8s-redis-pubsub

  5. 6Platform

    Mesageria, observabilitatea, ingress-ul și livrarea în timp real au fiecare propriul nod.

    1. k8s-rabbitmq
    2. k8s-monitoring
    3. k8s-logging
    4. k8s-ingress-gateway
    5. k8s-sse-gateway
    6. k8s-event-router
Fiecare nod
  • Fluent Bit · DaemonSet
  • Calico

Modele configurate · pe furnizori

Serviciul a fost închis, așa că acestea sunt modelele configurate în depozit, nu opțiuni disponibile astăzi. Fiecare rol este listat separat; nu este o listă de rulări verificate.

  • OpenAI

    Furnizorul implicit pentru Chat

    Chat

    • openai/gpt-5.2implicit

    Modelul implicit este gpt-5.2; un model numit în cerere este folosit în locul lui.

    Scan

    • gpt-5.2implicit
    • gpt-5.2-pro
    • gpt-5.1
    • gpt-5
    • gpt-5-pro
    • gpt-5-mini

    Modelele din afara mapării de 13 modele sunt respinse.

    Maparea imaginilor

    • gpt-image-1.5

    Separat de gpt-5.2, modelul de orchestrare Responses. Generarea de imagini este dezactivată implicit.

    Evaluare

    • gpt-4o-miniimplicit

    Evaluatorul LLM pentru evaluarea conversațiilor, separat de modelul Chat.

  • Google

    Când Chat alege Google

    Chat

    • google/gemini-3-pro-preview
    • google/gemini-3-flash-preview

    Cu Google selectat, gemini-3-flash-preview este implicit.

    Scan

    • gemini-3-pro-preview
    • gemini-3-flash-preview
    • gemini-2.5-pro
    • gemini-2.5-flash
    • gemini-2.5-flash-lite
    • gemini-2.0-flash
    • gemini-2.0-flash-lite

    Maparea imaginilor

    • gemini-3-pro-image-preview

Sursăbackend main d8840c7Commit public 29 septembrie 2026 · verificat 8 octombrie 2026