BG
Персонажът глобус на Eco², доработен за това портфолио по най-новия официален главен персонаж: светлосин глобус със зелена суша, кълн отгоре и кафяво усмихнато лице
Обратно в залата

Eco²

Backend · Cloud infrastructure

Указания за рециклиране от една снимка и разговор.

Всеобхватен AI асистент, който разбира как работи рециклирането в Корея.

2025.10.31 — 2026.02.10

Екипен проект · основа за инфраструктура и внедряване → бекенд на домейна → асинхронна обработка, разговорен агент, проверка

2025 새싹 해커톤 (Saessak Hackathon)Награда за отлично представяне · 2 декември 2025 г.

  • Уеб приложениеУслугата е спряна

Как реално се свързват 24-те възела, поток по поток.

Самостоятелно управляван Kubernetes, изграден с kubeadm. Картата поставя 24-те физически възела и работните натоварвания върху тях в петте слоя от README и ги свързва с реалните им връзки. Изберете поток и се откроява само неговият път, с номерирани стъпки.

Разпознава отпадъка от снимка и обяснява как да се изхвърли, а в разговор извиква инструменти за места, времето, цени при рециклиране и уеб търсене и генерира изображения. В този екипен проект започнах с основата за клъстера и внедряването и разширих обхвата си към бекенда на домейна, асинхронната обработка, разговорния агент и проверката.

От разработката за състезанието до укрепването на бекенда и експлоатацията

Услугата е приключила работа; записано демо и техническият доклад я показват в действие.

Карта на връзките в клъстера · начертана наново по манифестите и кода при къмит a072127
Карта на връзките в клъстера на Eco² · 24 възелаКарта на 24-те физически възела в петте ленти на слоевете от README. Браузърът само търси името в Route 53; след като TLS приключи в ALB на порт 443, Istio ingress Envoy на NodePort изпраща заявката към API на домейна. Scan API поставя работата в RabbitMQ и веднага връща job_id; scan-worker в AI пула записва с XADD събития за напредъка в Redis Streams. Event Router ги прочита, обновява State KV и публикува в Pub/Sub, а SSE Gateway ги изпраща на браузъра. checkpoint-syncer съхранява контролните точки на Chat, а persistence consumer на възела Chat съхранява съобщенията в PostgreSQL. Platform Layer не е път на заявките; той конфигурира, мащабира и наблюдава.БраузърHTTPS · SSEAWS ALB443 · тук приключва TLSRoute 53DNSGitHub Actions · Docker Hubобраз · ревизия на манифестаLLM APIOpenAI · GoogleLangSmithпроследяване на изпълненията на LLMFluent BitDaemonSet · на всеки възелk8s-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-memoryКлъстер Kubernetes24 възела · kubeadmEdge Layer1 възелService Layer8 възела · Envoy sidecarIntegration Layer7 възелаPersistence Layer5 възелаPlatform Layer3 възела · конфигуриране · мащабиране · наблюдениеУправлявано от AWSAI пулdomain: worker-aiпул за съхранениеdomain: worker-storageБез фиксиран възел1DNS търсене2 HTTPS 443 · Браузър → AWS ALB23HTTP · NodePort4VirtualService5Задача Celery6 consume · RabbitMQ → scan-worker67 HTTPS · AI пул → LLM API78XADD scan:events9XREADGROUP10SETEX state11PUBLISH12SUBSCRIBE13SSE поток14Възстановяване при повторно свързване1 HTTPS 443 · Браузър → AWS ALB12HTTP · NodePort3VirtualService4Задача Taskiq5 consume · RabbitMQ → chat-worker56 HTTPS · AI пул → LLM API67XADD chat:events8XREADGROUP9PUBLISH10SUBSCRIBE11SSE поток12checkpoint13четене на контролната точка14синхронизиране с PostgreSQL15chat-persistence group16запис на съобщенията1DNS търсене2 HTTPS 443 · Браузър → AWS ALB23HTTP · NodePort4ext-authz · gRPC 500515проверка в черния списък6VirtualService7gRPC8gRPC1outbox:blacklist2blacklist.events3 blacklist.events · RabbitMQ → auth-worker34запис в черния списък5 Celery batch · RabbitMQ → users-worker56UPSERT1образ · ревизия на манифеста2Ingress → ALB · DNS записи3xDS конфигурация4брой подове5 брой подове · KEDA → пул за съхранение56логове7 проследяване на изпълненията на LLM · AI пул → LangSmith7

Заявка Scan → доставка в реално време

Заявка за анализ на снимка става работа в опашка, а събитията за напредъка ѝ се връщат в същия браузър.

  1. БраузърDNS търсенеRoute 53

    От записите в Route 53 се разрешава само името. Заявките не минават през DNS.

  2. БраузърHTTPS 443AWS ALB

    TLS приключва в ALB.

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

    Предава се на Istio ingress Envoy през NodePort на целта от тип EC2 инстанция.

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

    Маршрутизира се към Scan API, който поставя работата в опашката и веднага връща job_id; проверката на резултата отговаря с 202, докато задачата не е готова.

  5. Scan APIk8s-api-scanЗадача CeleryRabbitMQk8s-rabbitmq

    Задачата Scan отива в RabbitMQ.

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

    scan-worker (Celery · gevent) в AI пула я поема и изпълнява Vision → Rule → Answer → Reward. Четирите етапа са свързани във верига задачи Celery, а не възли.

  7. AI пулk8s-worker-ai · k8s-worker-ai-2HTTPSLLM API

    Работните процеси scan и chat извикват API на OpenAI и Google.

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

    Събитията за напредъка се записват в един от четирите шарда на Streams.

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

    Event Router ги чете като група потребители и прави XACK след обработката; pending и reclaim запазват доставката at-least-once.

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

    Записва последното състояние и маркер за дублирана обработка в State KV на същия възел на Redis.

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

    Доставят се в реално време по канала на задачата в Pub/Sub по шардове.

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

    SSE Gateway се абонира чрез един споделен listener за процес и ги разпраща към всеки свързан браузър.

  13. SSE Gatewayk8s-sse-gatewaySSE потокБраузър

    Връзка, отворена по същия път през ALB и ingress. Доставката е at-least-once; дубликатите се обработват идемпотентно.

  14. State KVk8s-redis-streamsВъзстановяване при повторно свързванеSSE Gatewayk8s-sse-gateway

    При повторно свързване с Last-Event-ID State KV и запазените Streams допълват пропуснатите събития.

Chat · токени и съхранение

Токените на Chat минават по същия път за събития като Scan; контролните точки и съобщенията се съхраняват от две различни работни натоварвания.

  1. БраузърHTTPS 443AWS ALB

    TLS приключва в ALB.

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

    Предава се на Istio ingress Envoy през NodePort на целта от тип EC2 инстанция.

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

    Маршрутизира се към Chat API.

  4. Chat APIk8s-api-chatЗадача TaskiqRabbitMQk8s-rabbitmq

    Задачата Chat отива в RabbitMQ.

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

    chat-worker (Taskiq · asyncio) класифицира намерението с LangGraph, след което изпълнява vision при нужда, избраните инструменти, агрегатора и обобщение при нужда и отговаря. Всяка заявка изпълнява само нужните ѝ клонове.

  6. AI пулk8s-worker-ai · k8s-worker-ai-2HTTPSLLM API

    Работните процеси scan и chat извикват API на OpenAI и Google.

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

    Токените и събитията за етапите се записват в четири шарда на Streams; оттам пътят на доставка е същият като при Scan.

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

    Event Router ги чете като група потребители и прави XACK след обработката; pending и reclaim запазват доставката at-least-once.

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

    Доставят се в реално време по канала на задачата в Pub/Sub по шардове.

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

    SSE Gateway се абонира чрез един споделен listener за процес и ги разпраща към всеки свързан браузър.

  11. SSE Gatewayk8s-sse-gatewaySSE потокБраузър

    Връзка, отворена по същия път през ALB и ingress. Доставката е at-least-once; дубликатите се обработват идемпотентно.

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

    Контролната точка на LangGraph се пази в Redis Cache.

  13. Cachek8s-redis-cacheчетене на контролната точкаcheckpoint-syncerk8s-worker-ai · k8s-worker-ai-2

    checkpoint-syncer прочита контролната точка от Redis.

  14. checkpoint-syncerk8s-worker-ai · k8s-worker-ai-2синхронизиране с PostgreSQLPostgreSQLk8s-postgresql

    AsyncPostgresSaver я съхранява асинхронно в PostgreSQL.

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

    persistence consumer на възела Chat чете събитията done като група потребители.

  16. persistence consumerk8s-api-chatзапис на съобщениятаPostgreSQLk8s-postgresql

    Съобщенията от Chat се записват в PostgreSQL. Това е различно работно натоварване от checkpoint-syncer.

Вход · удостоверяване

Синхронният път от входа на клъстера до API на домейн. Само пътищата, защитени с политика, първо проверяват удостоверяването; трафикът между подове на различни възли минава по Calico VXLAN.

  1. БраузърDNS търсенеRoute 53

    От записите в Route 53 се разрешава само името. Заявките не минават през DNS.

  2. БраузърHTTPS 443AWS ALB

    TLS приключва в ALB.

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

    Предава се на Istio ingress Envoy през NodePort на целта от тип EC2 инстанция.

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

    Само пътищата под политика CUSTOM първо питат Go ext-authz (timeout 2 s, failOpen false). Пътища като login, health и docs са изключени.

  5. ext-authzk8s-api-authпроверка в черния списъкblacklistk8s-redis-auth

    Токенът се проверява в черния списък в Redis.

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

    Маршрутизира се към Chat API.

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

    Синхронното извикване chat → images, посочено в README.

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

    Синхронното извикване auth → users, посочено в README.

Пул за съхранение · асинхронни записи

Черният списък за удостоверяване и собствеността на персонажите се съхраняват от работните процеси в пула за съхранение, които получават работата си от RabbitMQ.

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

    auth-relay (auth-Bus в README) чете outbox в Redis.

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

    Публикува отново в RabbitMQ, с повторни опити и DLQ.

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

    auth-worker получава събитията за черния списък.

  4. auth-workerk8s-worker-storage · k8s-worker-storage-2запис в черния списъкblacklistk8s-redis-auth

    Те се съхраняват в черния списък в Redis.

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

    users-worker получава на партиди работа по собствеността на персонажите.

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

    Тя се прилага в PostgreSQL.

Конфигуриране · мащабиране · наблюдение

Platform Layer не е стъпка, през която минават заявките; той внедрява, конфигурира, мащабира и наблюдава останалите слоеве. Възлите са EC2 инстанции, създадени с Terraform, с kubeadm и Calico, инсталирани чрез Ansible; CI само валидира Terraform и никога не го прилага автоматично.

  1. GitHub Actions · Docker Hubобраз · ревизия на манифестаArgo CD image updaterk8s-master

    Argo CD привежда конфигурацията на клъстера в съответствие чрез App-of-Apps и Sync Waves. Разположението в control-plane е потвърдено само за image updater.

  2. ALB Controller · ExternalDNSk8s-masterIngress → ALB · DNS записиУправлявано от AWS

    ALB Controller и ExternalDNS конфигурират ресурсите от страна на AWS. Това не е път, по който минават заявките.

  3. Istiodk8s-masterxDS конфигурацияIstio ingress Envoyk8s-ingress-gateway

    Istiod изпраща чрез xDS конфигурацията на Gateway, VirtualService и EnvoyFilter към ingress Envoy и към Envoy sidecar на всеки API.

  4. KEDAk8s-monitoringброй подовеAI пулk8s-worker-ai · k8s-worker-ai-2

    KEDA регулира броя на подовете на работните процеси. Броят на възлите не се променя.

  5. KEDAk8s-monitoringброй подовепул за съхранениеk8s-worker-storage · k8s-worker-storage-2

    Подовете на работните процеси в пула за съхранение се мащабират по същия начин.

  6. Fluent BitлоговеElasticsearchk8s-logging

    Fluent Bit е DaemonSet на всеки възел и изпраща логовете към Elasticsearch.

  7. AI пулk8s-worker-ai · k8s-worker-ai-2проследяване на изпълненията на LLMLangSmith

    Следите от извикванията на LLM отиват в LangSmith, външен SaaS.

Всички връзки с еднаква дебелина. Изберете поток, за да се откроят само неговият път и номерираните стъпки.

  • Плътна · посоката, в която текат заявките, работата, събитията и записите
  • Пунктирна · DNS търсене; заявките не минават през него
  • Прекъсната · конфигуриране или мащабиране; не е път на данните
  • Дълга щрих-пунктирна · логове и проследяване на изпълненията
  • Дебела черна линия · избраният поток; числата показват реда
  • Кутия · физически възел, с името на хоста в заглавието
  • Вътрешен етикет · работно натоварване на този възел
  • Прекъсната рамка · пул за планиране с два възела
  • Прекъсната кутия · извън клъстера, не се брои за възел
  • Оранжев контур · където решава модел
  • Control plane1 възел
  • Domain API8 възела
  • AI пул2 възела
  • пул за съхранение2 възела
  • Data5 възела
  • Platform6 възела

Петте слоя от README (лентите) и физическите групи (нюансът на заглавието на всеки възел) групират едни и същи 24 възела по различен начин. State KV споделя възела на Streams и не е броен отделно; Route 53, ALB и услугите извън клъстера не са възли. Пулът е обхват за планиране, а не твърдение, че всеки под работи и на двата възела.

Разположение на 24 възела · по списъка на възлите в таблото от 21 януари 2026 г.

24възела

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

  1. 1Control plane

    role: control-plane

    kube-apiserver · scheduler · controller-manager · etcd, както и контролерите на платформата.

    1. k8s-master

  2. 8Domain API

    domain: <услуга>

    По един възел за всеки домейн. Вътрешните извиквания използват 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

    Два пула за планиране с по два възела. KEDA променя броя на подовете; броят на възлите остава същият.

    пул за съхранениеdomain: worker-storage
    1. k8s-worker-storage
    2. k8s-worker-storage-2
    AI пулdomain: worker-ai
    1. k8s-worker-ai
    2. k8s-worker-ai-2

  4. 5Data

    Redis е разделен на четири възела със специално предназначение. Хранилището на PostgreSQL е EBS CSI · gp3.

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

  5. 6Platform

    Съобщенията, наблюдаемостта, входящият трафик и доставката в реално време имат всеки свой възел.

    1. k8s-rabbitmq
    2. k8s-monitoring
    3. k8s-logging
    4. k8s-ingress-gateway
    5. k8s-sse-gateway
    6. k8s-event-router
Всеки възел
  • Fluent Bit · DaemonSet
  • Calico

Конфигурирани модели · по доставчици

Услугата е спряна, затова това са моделите, конфигурирани в хранилището, а не възможности за избор днес. Всяка роля е посочена отделно; това не е списък с проверени изпълнения.

  • OpenAI

    Доставчик по подразбиране за Chat

    Chat

    • openai/gpt-5.2по подразбиране

    Моделът по подразбиране е gpt-5.2; ако заявката посочи модел, се използва той.

    Scan

    • gpt-5.2по подразбиране
    • gpt-5.2-pro
    • gpt-5.1
    • gpt-5
    • gpt-5-pro
    • gpt-5-mini

    Модели извън съпоставянето от 13 модела се отхвърлят.

    Съпоставяне за изображения

    • gpt-image-1.5

    Отделно от gpt-5.2, модела за оркестрация на Responses. Генерирането на изображения е изключено по подразбиране.

    Оценяване

    • gpt-4o-miniпо подразбиране

    LLM оценителят за оценяване на разговорите, отделен от модела на Chat.

  • Google

    Когато Chat избере Google

    Chat

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

    При избран Google gemini-3-flash-preview е по подразбиране.

    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

    Съпоставяне за изображения

    • gemini-3-pro-image-preview

Източникbackend main d8840c7Публичен къмит 29 септември 2026 г. · проверено 8 октомври 2026 г.