Невидливиот мотор зад современите SaaS Кога корисникот кликнува на "Пријавете се" на SaaS производ или бара некои специфични податоци, тие очекуваат реактивност и веродостојност во реално време. Зад оваа едноставна интеракција работи софистициран backend, архитектиран за скалирање, само-лекување и дистрибуирање на товарот низ констелацијата на микро-услуги. Но, како што повеќе стартапи ги прифаќаат дизајните од облакот и контејнеризираните услуги стануваат 'рбетот', еден предизвик постојано се појавува: како можеме интелигентно да го балансираме сообраќајот така што не е само рамномерно распределен, туку и насочен кон најздравите, најбрзите и најсигурните сервисни крајни точки? Ова е многу покомплексно од класичното рутирање со круг-робин. Како што секој кој работи со системи за производство научи, наивното дистрибуција на сообраќајот доведува до каскадни неуспеси кога една услуга оди нездрава, или пречки кога новите верзии не се подготвени за производство. Балансирање на товарот за Dockerized Python микро-услуги – со користење на Cloud Load Balancing, GKE/Cloud Run, управуван VPC, силен IAM и природни карактеристики за набљудување. Интелигентно Контекст на проблемот: Зошто наивното балансирање на товарот не успева во производството Новата верзија на Billing pod распоредува која трае 30 секунди за да го загрее својот базен за поврзување со базата на податоци. Или можеби pod е заглавен за справување со задачата за експорт на партија, зголемување на латенцијата до 5x нормално. Можеби постои латенција на меморијата која полека ги деградира перформансите во текот на часовите. Класичните балансери за оптоварување ќе продолжат да ги насочуваат корисниците кон овие тешки pods бидејќи, технички, тие сè уште реагираат на основните здравствени проверки. Дури и со вградените сонди за готовност на Kubernetes, стандардниот GCP управуван балансер за оптоварување не секогаш има доволно гранулирани здравствени податоци за да се избегнат бавни или неуспешни крајни точки веднаш. Сондата може да се провери на секои 10 секунди, но под може да пропадне спектакуларно во интервентното време. Она што ни е потребно е интелигентно балансирање на оптоварувањето управувано со детални здравствени сигнали, порти за готовност, метрики во реално време и брзо откривање на неуспеси. Дефинирање на интелигентно балансирање на товарот Пред да напишам еден ред код или да обезбедам каква било инфраструктура, научив дека е критично да се биде прецизен за тоа што всушност значи "интелигентно" во овој контекст. Премногу често, тимовите скокаат право на имплементација без да ги дефинираат критериумите за успех, само за да откријат месеци подоцна дека нивната стратегија за балансирање на товарот има суптилни, но критични празнини. Интелигентното балансирање на оптоварувањето значи дека системот само испраќа сообраќај до pods кои се здрави, живи и навистина одговорни – не само pods кои сè уште не се срушиле. Тоа значи да се направи разлика помеѓу контејнери кои технички работат и оние кои всушност се подготвени да се справат со производствениот сообраќај. Покрај едноставно здравје, интелигентното рутирање мора да ги разгледа карактеристиките на перформансите во реално време. Подот може да биде здрав, но во моментов доживува висока латентност поради собирање на ѓубре или континуирано собирање на ресурси. Балансерот на товарот треба да ги преферира крајните точки со пониски, постабилни времиња на одговор. Кога подот почнува да покажува зголемени стапки на грешка или забавувања, системот има потреба од линк за повратна информација за привремено да се рутира околу него, дури и ако традиционалните здравствени проверки сè уште го покажуваат како оперативен. Архитектурата, исто така, треба да игра убаво со еластично скалирање. Како што подните се врти нагоре и надолу во одговор на моделите на сообраќај, балансерот на товарот мора да го интегрира новиот капацитет, додека исцедува сообраќајот од подните закажани за прекинување. И критично, сето ова бара набљудуваност вградена од првиот ден. Без логови, траги и метрики кои се враќаат во одлуките за рутирање, летате слепи. Ова е местото каде интегрираното алатирање на GCP станува непроценливо, обезбедувајќи ја темелот за телеметрија што ги прави интелигентните одлуки можни. Дизајн на Cloud-Native Backend архитектура 3.1 Дизајн на микро-услуги (Python, Docker) Основата на интелигентното балансирање на оптоварувањето започнува со услугите кои правилно ја комуницираат нивната состојба. Открив дека премногу микро-услуги ги третираат здравствените проверки како послемисла, имплементирајќи ги со едноставен "враќање 200 ОК" кој му кажува на балансерот на оптоварувањето ништо корисно. Еве услуга за фактурирање базирана на Python која го демонстрира шемата што ја користам во производството. Забележете како го одделува здравјето ( дали процесот е жив?) од подготвеноста ( дали е подготвен да служи за сообраќај?): # billing_service.py from flask import Flask, jsonify import random import time app = Flask(__name__) @app.route("/healthz") def health(): # Report healthy 95% of the time, failure 5% if random.random() < 0.95: return "OK", 200 else: return "Unhealthy", 500 @app.route("/readyz") def ready(): # Simulate readiness delay on startup if time.time() - START_TIME < 10: return "Not Ready", 503 return "Ready", 200 @app.route("/pay", methods=["POST"]) def pay(): # Simulate payment processing latency latency = random.uniform(0.05, 1.5) time.sleep(latency) return jsonify({"status": "success", "latency": latency}) if __name__ == "__main__": global START_TIME START_TIME = time.time() app.run(host='0.0.0.0', port=8080) Оваа поделба меѓу и Огледало на она што го имплементирав во десетици услуги за производство. Крајната точка за здравјето му кажува на Kubernetes дали процесот треба да се рестартира – можеби е заглавен или има исцрпени дескриптори на датотеки. Крајната точка за подготвеност кажува дали подот добива сообраќај за производство. За време на тие критични првите секунди по стартувањето, додека услугата воспоставува врски со базата на податоци, кеши за загревање или конфигурација за полнење од Secret Manager, подготвеноста се враќа 503. /healthz /readyz Во вистинскиот производствен код, вашата проверка за подготвеност ќе ги провери вистинските зависности. Можете ли да пинг на базата на податоци? Дали Redis одговара? Дали сте го вчитале вашиот ML модел во меморија? За услугата за фактурирање конкретно, може да проверите дали е завршена иницијализацијата на Stripe SDK или дали правилата за откривање на измама се вчитаат успешно. Случајноста во здравствената проверка тука симулира прекинувачки неуспеси со кои ќе се соочите во производството – мрежни пречки, транзициона исцрпеност на ресурсите или надворешни зависности. 3.2 Контејнеризација: Пример за Dockerfile Откако вашата услуга правилно ја открива својата состојба, пакувањето за облак-национално распоредување станува едноставно. # Dockerfile FROM python:3.11-slim WORKDIR /app COPY billing_service.py . RUN pip install flask EXPOSE 8080 CMD ["python", "billing_service.py"] Во производството, би сакале да го зајакнете ова со повеќестепени градежи за да го минимизирате големината на сликата, да работите како корисник без корен за безбедност и потенцијално да користите requirements.txt за управување со зависноста. Но, основниот модел останува: тенка база слика, минимални слоеви, јасна влезна точка. Открив дека оптимизирањето на времето за стартување на контејнерите е едно од највисоките подобрувања на леверот што можете да го направите за интелигентно балансирање на оптоварувањето, бидејќи побрзите стартапи значат помалку време во состојба "не е подготвена" и полесно скалирање. 3.3 GCP Resource Provisioning: Изградба и распоредување Со вашата услуга контејнеризирана, следниот чекор е да го внесете во регистарот на артефактите на GCP и на вашиот кластер. Типично го структурирам ова како повторувачки цев, но тука е рачниот работен тек за да разберете што се случува под капакот: # Build, tag, and push Docker image to GCP Artifact Registry gcloud artifacts repositories create python-services --repository-format=docker --location=us-central1 docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/python-services/billing-service:v1 . gcloud auth configure-docker us-central1-docker.pkg.dev docker push us-central1-docker.pkg.dev/${PROJECT_ID}/python-services/billing-service:v1 Она што е важно е дека користите регистар на артефакти наместо регистар на контејнери. Регистар на артефакти ви дава ранливост за скенирање надвор од кутијата, подобра интеграција на IAM и опции за регионална репликација кои стануваат критични кога користите мултирегионални услуги. Сега доаѓа конфигурацијата за распоредување, каде што интелигентното балансирање на товарот навистина почнува да добива облик: # k8s/billing-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: billing-service spec: replicas: 3 selector: matchLabels: app: billing-service template: metadata: labels: app: billing-service spec: containers: - name: billing-service image: us-central1-docker.pkg.dev/YOUR_PROJECT/python-services/billing-service:v1 ports: - containerPort: 8080 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 Забележете ја конфигурацијата на сондата. Се проверувам за здравјето на секои 5 секунди, што во производството може да биде премногу агресивно во зависност од карактеристиките на вашата услуга. Ќе треба да ги прилагодите овие вредности врз основа на вистинското однесување. Ако самите здравствени проверки стануваат извор на оптоварување, продолжете го периодот. Ако ви треба побрзо откривање на неуспеси, скратете го – но бидете подготвени за повеќе лажни позитиви за време на транзициските проблеми. на Поставувањето е критично и често погрешно конфигурирано. Поставете го премногу кратко, а вашите pods не успеваат да ги проверат здравјето за време на нормалното стартување, создавајќи рестартирање. Поставете го предолго, и губите време пред сообраќајот да може да тече до ново скалирани pods. Типично започнувам со вредност 2x моето забележано време за стартување во развојот, а потоа се прилагодувам врз основа на метриките за производство. initialDelaySeconds Разместете ја услугата и изложете ја со овие команди: kubectl apply -f k8s/billing-deployment.yaml kubectl expose deployment billing-service --type=LoadBalancer --port 80 --target-port 8080 Ова автоматски создава GCP Load Balancer пред вашето распоредување, што нè доведува до следниот слој на интелигенција. GCP балансирање на товарот со интелигентни проверки на здравјето Кога ќе креирате услуга Kubernetes од тип на LoadBalancer, GCP обезбедува HTTP(S) Load Balancer кој длабоко се интегрира со вашиот GKE кластер. Ова не е само пренасочување на сообраќајот, туку активно го следи здравјето на задните делови, почитува состојби на подготвеност и донесува одлуки за рутирање милисекунда по милисекунда. Вистинската моќ доаѓа од овозможувањето на балансирање на оптоварувањето на контејнерите преку мрежни групи за крајни точки (NEGs). Ова му овозможува на GCP-балансирањето на оптоварувањето да се насочува директно до pod IPs наместо да поминува низ куби-прокси и iptables, намалувајќи ја латенцијата и подобрувајќи ја точноста на здравствената проверка: # k8s/billing-service.yaml apiVersion: v1 kind: Service metadata: name: billing-service annotations: cloud.google.com/neg: '{"ingress": true}' # Enables container-native load balancing spec: type: LoadBalancer ports: - port: 80 targetPort: 8080 selector: app: billing-service Оваа единствена забелешка – – ја трансформира вашата архитектура за балансирање на товарот. Мерив 20-30% подобрување на задоцнувањето во производството само од овозможување на NEGs, бидејќи елиминирате обработка на мрежни скокови и iptables. Поважно за нашите цели, тоа му дава на GCP балансерот на товарот директна видливост во здравјето на pod. Кога сондата за подготвеност не успева, тој резервен крај веднаш се отстранува од ротацијата на балансерот на товарот. Нема конечна конзистентност, нема одложување чекање за крајните точки да се ажурираат. cloud.google.com/neg Откако ќе се имплементира, можете да го усогласите однесувањето на здравствената проверка преку GCP конзолата или командите gcloud. Во производството, обично го прилагодувам интервалот на здравствената проверка за да го балансирам помеѓу брзото откривање на неуспеси и надминувањето. Јас исто така го конфигурирам нездравиот праг - колку последователни неуспеси пред отстранување на задната страна - врз основа на тоа дали претпочитам достапност (толеранција на транзициски неуспеси) или доверба (брзо неуспех). Распоредување за подготвеност, скалирање и отпорност 4.1 Овозможување на хоризонтално под автоскалирање Интелигентното балансирање на оптоварувањето не значи само ефикасно рутирање до постоечките позадина – тоа значи да се осигурате дека во секое време го имате вистинскиот број здрави позадини на располагање. Убавината на комбинирање на соодветни здравствени проверки со автоскалирање е дека новите потпови влегуваат во ротацијата на балансерот за оптоварување само кога навистина се подготвени. Не постои услови за трка каде што сообраќајот го погоди пот кој сè уште се иницијализира. Еве како обично го конфигурирам автоскалирањето за услуга како што е фактурирањето: kubectl autoscale deployment billing-service --cpu-percent=70 --min=3 --max=10 Научив преку болно искуство дека поставувањето на минималниот број на реплики е подеднакво важно како и максимумот. Работењето со помалку од 3 реплики во производството значи дека секој поединечен подот неуспех или распоредување претставува значителен процент од вашиот капацитет, што доведува до каскадно преоптоварување. Прагот на процесорот од 70% е конзервативен, што го претпочитам за услугите кои се занимаваат со финансиски трансакции. За помалку критични услуги, може да притиснете до 80-85% за да ја максимизирате ефикасноста на ресурсите. Но, тука е она што е важно: комбинирање на автоскалирање со веројатноста за читање значи дека сообраќајот се третира грациозно. Нови потпови се вртат, правилно се инициализираат (блокирани од сообраќајот по готовност), а потоа беспрекорно се приклучуваат на базенот за балансирање на товарот откако ќе бидат подготвени. Во повеќе софистицирани поставки, го проширив ова за да користам прилагодени метрики – скалирање врз основа на длабочината на редот на барањето или задоцнувањето на P95 наместо само на процесорот. GCP го прави ова можно преку API-то за прилагодени метрики, овозможувајќи вашата апликација да извезува бизнис-логично свесни метрики кои ги водат одлуките за скалирање. 4.2 Фино-гранирано поделба на сообраќајот за безбедно распоредување Дури и со интелигентни проверки на здравјето и автоскалирање, распоредувањето на нов код останува операцијата со најголем ризик во производството. Грешка која го прави да помине сценирањето може да ја преземе целата услуга ако се изведе на сите под-подови во исто време. Ова е местото каде што поделбата на сообраќајот и канарските распоредувања стануваат клучни, и каде интеграцијата на GKE со балансирање на оптоварувањето на GCP навистина блесне. Моделот што најчесто го користам е канарско распоредување со поделба на сообраќајот врз основа на проценти. Вие распоредувате нова верзија на мал број pods додека ја одржувате вашата стабилна верзија, а потоа постепено го менувате сообраќајот врз основа на забележаните здравствени метрики. Еве конфигурација за распоредување на канарски: # k8s/billing-deployment-canary.yaml apiVersion: apps/v1 kind: Deployment metadata: name: billing-service-canary spec: replicas: 1 selector: matchLabels: app: billing-service version: canary template: metadata: labels: app: billing-service version: canary spec: containers: - name: billing-service image: us-central1-docker.pkg.dev/YOUR_PROJECT/python-services/billing-service:v2 ports: - containerPort: 8080 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 Вашиот селектор за услуги ги вклучува и двете и Етикетите на верзијата, така што сообраќајот тече кон двете. Првично, со само 1 канарска реплика против 3 стабилни реплики, околу 25% од сообраќајот ја погодува новата верзија. Вие ги следите стапките на грешка, задоцнувањето и деловните метрики. Ако сè изгледа здраво по еден час, можете да ги зголемите канарските реплики на 2, а потоа на крајот да го промовирате на стабилна додека ја исклучувате старата верзија. stable canary Она што го прави ова моќно е начинот на кој комуницира со здравствените проверки. Ако вашата верзија на Канари има критична грешка која предизвикува неуспех на сондата за подготвеност, никогаш не добива сообраќај на производството на прво место. Распоредувањето се завршува, поттокот започнува, но балансерот за оптоварување продолжува да се рутира околу него. За уште пософистицирани распоредувања, директорот за сообраќај на GCP овозможува прецизни проценти за поделба на сообраќајот, рутирање врз основа на насловот за тестирање на специфични сценарија и интеграција со можностите за сервисна мрежа.Во еден производствен систем на кој работев, го насочивме внатрешниот сообраќај на вработените кон канарските верзии, додека го одржуваме целиот сообраќај на клиентите стабилен, обезбедувајќи ни тестирање во реалниот свет без ризик за клиентите. Набљудуваност: следење на здравјето, задоцнетоста и неуспесите 5.1 Логирање и следење со Cloud Operations Suite Еве ја непријатната вистина за балансирање на товарот: можете да ја архитектирате најсофистицираната логика за рутирање во светот, но без набљудување, сте слепи за тоа дали навистина функционира. Ова е местото каде што GCP Cloud Operations Suite станува неопходен. Интеграцијата со GKE е доволно длабока за да добиете метрики на ниво на под, дневници на контејнери и дистрибуирани траги со минимална конфигурација. За услугата за фактурирање, извезувам неколку класи на метрики. Прво, основите – бројот на барања, стапката на грешка, процентилите на задоцнување. Овие протокови автоматски течат низ управувањето со Прометеј на GCP ако ги изложите во вистинскиот формат. Второ, резултатите од здравствената проверка со текот на времето, што помага да се идентификуваат шемите во неуспеси. Дали pod не успева да ги провери здравствените проверки секое утро во 2 часот за време на одржувањето на базата на податоци? Тоа е сигнал за да ја прилагодите логиката на здравствената проверка или да ги прилагодите прозорците за одржување. Трето, и најважно, персонализирани деловни метрики кои го претставуваат вистинскиот здравје на услугата од корисничка перспектива. За фактурирање, тоа би можело да биде стапка на успех на плаќање, време за обработка на надоместоци или латентност за откривање на измама. Еве како да извезувате прилагодени метрики со користење на OpenTelemetry од вашата услуга Flask: # Export Flask metrics (latency, errors) using OpenTelemetry from opentelemetry import metrics from opentelemetry.exporter.cloud_monitoring import CloudMonitoringMetricsExporter from opentelemetry.sdk.metrics import MeterProvider from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader exporter = CloudMonitoringMetricsExporter() meter_provider = MeterProvider( metric_readers=[PeriodicExportingMetricReader(exporter, export_interval_millis=5000)] ) metrics.set_meter_provider(meter_provider) meter = metrics.get_meter(__name__) payment_latency = meter.create_histogram( "billing.payment.latency", unit="ms", description="Payment processing latency" ) # In your endpoint: @app.route("/pay", methods=["POST"]) def pay(): start = time.time() # ... process payment ... duration_ms = (time.time() - start) * 1000 payment_latency.record(duration_ms) return jsonify({"status": "success"}) Со овие метрики кои се пренесуваат во облак мониторинг, вашиот тим на SRE може да донесе информирани одлуки. Кога треба да скалирате? Кога канарчето е всушност побезбедно од стабилната верзија? Кои под-верзии се постојано побавни од нивните врсници? Јас изградив табла кои покажуваат дистрибуции на латенција по под, што веднаш го прави очигледно кога еден под е деградиран. Оваа видливост спречи безброј инциденти со овозможување на превентивна акција пред клиентите да забележат проблеми. Друг критичен дел е следење. Интеграцијата на Cloud Trace со GKE значи дека можете да следите барање од балансерот за оптоварување преку вашата услуга за фактурирање и во повици до процесорите за плаќање. Кога падот на P95 врши врв, можете да одредите дали тоа е ваш код, база на податоци или надворешни API повици. Оваа длабочина на видливост го трансформира отстранувањето на проблемите од претпоставка во истрага насочена кон податоци. 5.2 Предупредување за неуспеси и деградирање на доцнењето Конфигурирам политики за предупредување кои соодветно ги третираат различните типови на сигнали - некои бараат непосредни страници, други само креираат билети за истражување за време на работното време. За услугата за фактурирање, критичните предупредувања вклучуваат стапка на грешка поголема од 1% продолжена во текот на 5 минути, или било кој случај на обработка на плаќање што не успеа за сите обиди во прозорец од 2 минути. Овие страници се на повик, бидејќи тие претставуваат непосредно влијание на клиентот. Клучот е да ги поврзете предупредувањата со автоматизирани одговори каде што е можно. Кога стапката на грешка се зголемува на канарските подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни подводни под Ја изградив автоматизацијата околу овие предупредувања користејќи Cloud Functions предизвикани од Pub/Sub пораки од Cloud Monitoring. Функцијата може да ги скалира распоредувањата, да рестартира pods, па дури и да го исфрли сообраќајот од целиот кластер ако метриките укажуваат на неуспех на ниво на зоната. Безбедно вмрежување, IAM и пристап до услуги 6.1 Ограничување на внатрешниот сообраќај со VPCs Интелигентното балансирање на товарот не е само за ефикасноста на рутирање, туку и за безбедноста. Системите за производство на SaaS имаат потреба од длабока одбрана, каде што компромисирањето на една услуга не ви дава пристап до целата инфраструктура. Јас ги распоредувам производствените GKE кластери како приватни кластери, што значи дека јазлите немаат јавни IP адреси и не можат да се пристапат од интернет освен преку балансерот за оптоварување. # k8s/network-policy.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: billing-allow-internal spec: podSelector: matchLabels: app: billing-service policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: api-gateway Оваа политика гарантира дека само подмачки етикетирани можат да иницираат поврзувања со потпотите за услуги за фактурирање. Ако напаѓачот ја компромитира вашата услуга за известување, тие не можат директно да пристапат до фактурирањето. Тие ќе треба да се вртат низ порталот, кој е посилно надгледуван и заклучен. app: api-gateway Видов инциденти во кои мрежните политики го спречиле бочното движење по ранливоста на избегнување на контејнерот. Напаѓачот добил пристап до pod, но не можел да достигне до вредни услуги, бидејќи мрежните политики го блокирале сообраќајот. Политиките, исто така, комуницираат со интелигентното балансирање на оптоварувањето на суптилни начини. Со ограничување на услугите кои можат да стигнат до вашите задни краеви, ќе ги обезбедите сите надворешни протоци на сообраќај преку балансирањето на оптоварувањето каде што е предмет на здравствени проверки, ограничување на стапката и опсервабилитет. Внатрешните повици од услуга до услуга може да го заобиколат балансирањето на оптоварувањето за ефикасност, но тие се уште се предмет на мрежни политики и контроли на мрежата на услуги ако користите Istio или слично. 6.2 IAM контроли: најмала привилегија Политиките на мрежата се однесуваат на пристапот на ниво на мрежа, но IAM контролира што можат да прават аутентифицираните услуги.Јас ја конфигурирам секоја микро-услуга со сопствена сметка за услуги на Kubernetes која е поместена на одредена сметка за услуги на GCP преку идентитетот на работното оптоварување.Услугата за фактурирање има потреба од пристап до Cloud SQL за записи на трансакции и Pub/Sub за објавување на платни настани, но ништо друго. Овој принцип на најмала привилегија ме спаси неколку пати. Во еден инцидент, ранливоста во зависност дозволи произволно извршување на код во услугата за известување. Бидејќи дозволите за IAM на таа услуга беа строго опфатени за да испраќаат само е-пошта преку SendGrid, напаѓачот не можеше да пристапи до податоците за плаќање на клиентите, не можеше да ја модифицира инфраструктурата, дури не можеше да наведе кои други услуги постојат. Кога се комбинираат со интелигентно балансирање на товарот и здравствени проверки, контролите на IAM обезбедуваат дека дури и ако компромитираниот под помине здравствени проверки и добива сообраќај, штетата што може да ја направи е минимизирана. Сценарио за производство: Ракување со вистински неуспех Теоријата е задоволителна, но она што е важно е како оваа архитектура функционира кога работите одат погрешно. Еве еден сценарио со кој сум преживеал, со промени на имиња: Вие распоредувате нова верзија на услугата за фактурирање v2.1.4 која вклучува оптимизација за обработка на партиите. Промената изгледа добро во сценирањето. Во рок од неколку минути, латентноста на P95 за барања што го погоди канарскиот под скока од 200ms до 3 секунди. стапката на грешка се зголемува од 0,1% до 2%. Во старата архитектура, ова би значело дека 10% од вашите корисници имаат ужасно искуство, и ќе бидете во трка да се вратите рачно додека вашиот тим за поддршка полето лути билети. Наместо тоа, еве што се случува со интелигентното балансирање на товарот: сондата за подготвеност на канарскиот под почнува да пропаѓа, бидејќи сте го конфигурирале за да проверите не само "да ли процесот е жив", туку "неодамнешните барања успешно се завршуваат".По 3 последователни неуспеси, Kubernetes го означува pod како не е подготвен. GCP товарниот балансер веднаш престанува да насочува нов сообраќај кон него, дури и ако pod сеуште работи. Мониторинг во облак го открива моделот – канарските потци не успеаја да ги проверат здравствените проверки, а задоцнувањето е изолирано до v2.1.4. Алармен сигнал се појавува на вашиот канал Slack. Вашата автоматска политика за враќање се активира затоа што канарците ги надминаа праговите за неуспех. Во рок од 2 минути од почетната имплементација, канарците се отстрануваат, а вие се враќате целосно на стабилна v2.1.3. Вкупно влијание на клиентите: неколку десетици барања виделе зголемена задоцнување пред здравствената проверка да не успее. Вашиот инженер на повик истражува следното утро наместо во 2 часот наутро. Гледајќи ги трагите во Cloud Trace, тие откриваат дека оптимизацијата воведе барање на базата на податоци кое ги заклучува табелите за време на операциите на партијата, блокирајќи интерактивни барања. Ова е ветувањето за интелигентно балансирање на товарот – не дека системите никогаш нема да пропаднат, туку дека ќе пропаднат грациозно, ќе го содржат радиусот на експлозија и ќе обезбедат видливост за да ги поправат проблемите без драма. Вообичаени стапици и најдобри практики Дури и со архитектурата што ја опишав, постојат начини на неуспех со кои се соочив кои вреди да се повикаат експлицитно. Најчестата грешка што ја гледам е дека тимовите ги имплементираат собите за здравје и подготвеност кои ги проверуваат погрешните работи. Вашата сонда може да провери дека Flask одговара, но не и дали базенот за поврзување со базата на податоци е исцрпен. Тоа може да врати 200 OK додека позадинските нишки се заглавени. Ефективни собори проверуваат дали услугата навистина може да ја исполни својата цел, а не само дали процесот работи. Друга стапица е прилагодување на интервалите за проверка на здравјето без да се земе предвид целосното влијание. Многу агресивно проверка (секоја секунда) може да ја преплави вашата апликација со сообраќај на сонди, особено ако самата проверка на здравјето е скапа. Но, многу конзервативното проверка (секоја 30 секунди) значи дека може да потрае повеќе од една минута за да се открие неуспешен под и да се отстрани од ротација. Одлуката за неуспешно отворање против неуспешно затворање е суптилна, но критична. Кога вашиот балансер за оптоварување има повеќе нездрави резервни точки, треба да продолжи да се насочува кон нив (неуспешно отворање) или целосно да го одбие сообраќајот (неуспешно затворање)? Правилниот одговор зависи од вашата услуга. За систем за фактурирање, претпочитам неуспешно затворен – подобро е да се врати 503 и да се рестартираат клиентите отколку погрешно да се обработуваат плаќањата. За мотор за препораки, неуспешно отворање може да биде подобро – покажувајќи малку непостојани препораки е подобро од покажување ништо. Секогаш се залагам за тестирање на сценарија за неуспех во производството со алатки како хаос инженеринг. за да проверите дека сообраќајот не се префрлува гладко на здрави пот. Користете ги мрежните политики за да симулирате задоцнување или губење на пакетите. Инјектирајте неуспеси во вашите канарски распоредувања намерно за да проверите дека мониторинг ги фаќа. kubectl delete pod Конечно, тестирањето на товарот не е преговарачко. Користете алатки како Locust или k6 за да симулирате реални модели на сообраќај и да проверите дека автоскалирањето одговара соодветно, дека здравствените проверки остануваат сигурни под товарот и дека вашите претпоставки за перформанси се одржуваат. Заклучоци и конечни мисли Модерниот SaaS backend е и дистрибуиран систем и жив организам - адаптирање, само-лекување и скалирање на побарувачката.Она што го опишав во овој напис не е само теоретска архитектура; тоа е шема што ја рафинирав низ десетици системи за производство, валидирани преку инциденти кои се движат од мали прекини до прекини што се закануваат од компанијата. Вистинскиот увид, кој ми требаше години за да ги интернализирам, е дека интелигентното балансирање на товарот не е карактеристика што ја додавате на крајот. Тоа е новите својства на добрата архитектура: услугите кои искрено го пријавуваат нивниот статус, инфраструктурата која ги почитува тие сигнали и опсервабилноста која го затвора циклусот на повратни информации. Длабоката интеграција помеѓу GKE, Cloud Load Balancing и Cloud Operations значи дека не ги спојувате различни алатки – работите со кохерентна платформа каде што здравствените проверки природно течат во одлуките за рутирање, каде што метриките информираат за автоскалирање и каде што радиусот на експлозија на неуспеси е природно опфатен. Тимовите кои успеваат со архитектури како ова се оние кои опсесивно ги набљудуваат своите системи во производството, кои секој инцидент го третираат како можност за учење и кои непоколебливо ги итираат своите стратегии за контрола на сообраќајот. Ако земете една работа од оваа статија, нека биде ова: интелигентното балансирање на оптоварувањето е за градење системи кои грешат грациозно и лекуваат автоматски, давајќи ви простор за дишење за да ги поправите проблемите размислено наместо грозно. Моделите што ги споделив се тестирани во битка, но не се прописни. Вашиот SaaS ќе има различни ограничувања, различни начини на неуспех, различни бизнис барања. Прилагодете ги овие концепти на вашиот контекст, измерете што е важно за вашите услуги и изградете набљудуваност која ви овозможува да итирате со доверба.
