Праектуйце праграмы для cloud native асяроддзя

Вызначце патрэбныя паводзіны

Cloud native практыкі падтрымліваюць паўтаральную распрацоўку і эксплуатацыю ў публічных, прыватных або гібрыдных асяроддзях. CNCF падкрэслівае сістэмы, якія застаюцца кіраванымі, назіральнымі і ўстойлівымі пры зменах. Кантэйнеры і аркестрацыя могуць падтрымліваць гэты падыход. Самі па сабе яны не забяспечваюць усіх гэтых уласцівасцей.

Пачніце з выдуманага сэрвісу справаздач. AI-інструмент стварае endpoint, працэс-апрацоўшчык (worker) і вобраз кантэйнера. Дэманстрацыя дае правільны PDF. Перад production каманда павінна адказаць на іншае пытанне: што адбываецца, калі платформа замяняе працэс-апрацоўшчык падчас задачы?

Гэта пытанне праектавання праграмы, а таксама інфраструктуры. Перазапуск можа аднавіць працэс, але страціць яго незавершаную працу.

Аддзяляйце працэс ад надзейна захаванага стану

Прататып трымае задачы ў чарзе і гатовыя справаздачы на дыску кантэйнера. Замена кантэйнера можа прыбраць і тое, і другое. Даданне новых працэсаў-апрацоўшчыкаў таксама можа даваць розныя адказы ў залежнасці ад таго, які з іх атрымлівае запыт.

Перагледжаны праект выкарыстоўвае надзейнае сховішча задач і ўхваленае аб’ектнае сховішча. Запыт запісвае ідэнтычнасць задачы. Працэс-апрацоўшчык бярэ задачу, стварае яе вынік і запісвае месцазнаходжанне выніку. Праверкі доступу ўсё яшчэ дзейнічаюць, калі карыстальнік спампоўвае справаздачу.

Трымайце сакрэты па-за вобразам. Перадавайце іх праз ухваленую сістэму сакрэтаў. Запісвайце, якія змены канфігурацыі патрабуюць новага выпуску або перазапуску працэсу.

Праектуйце паўторныя спробы перад даданнем апрацоўшчыкаў

Дапусцім, працэс-апрацоўшчык захоўвае PDF, а затым спыняецца перад пацвярджэннем задачы. Чарга перадае задачу зноў. Другая спроба не павінна паўторна спісаць плату з кліента або адправіць супярэчлівыя паведамленні аб завяршэнні.

Выкарыстоўвайце ідэмпатэнтную аперацыю там, дзе гэта дарэчы. Паўтарэнне таго самага лагічнага запыту павінна захоўваць задуманы эфект. Вызначце стабільную ідэнтычнасць запыту, надзейна запісвайце вынік і правярайце, што адбываецца ў кожным пункце збою. AWS апісвае гэты метад у дапаможніку па бяспечных паўторных спробах.

Паўторныя спробы таксама патрабуюць межаў. Выкарыстоўвайце тайм-аўт, ліміт паўторных спроб і затрымку, якая прадухіляе адначасовыя паўторныя запыты. Захоўвайце няўдалыя задачы для вывучэння замест бясконцага паўтарэння.

Зрабіце жаданы стан прыдатным для праверкі

Дэкларатыўная канфігурацыя апісвае задуманае разгортванне. Кантролер працуе, каб падтрымліваць гэты стан. Напрыклад, Kubernetes Deployment кіруе рэплікамі праграмы і кантраляванымі абнаўленнямі. Праграма ўсё роўна павінна правільна апрацоўваць замену.

Стварайце версіі інфраструктуры і канфігурацыі праграмы. Правярайце змены праз звычайны працэс пастаўкі. Назірайце фактычнае завяршэнне задач, час знаходжання ў чарзе, збоі і абмежаванні залежнасцей. Працэс, які працуе, усё роўна можа быць няздольны стварыць справаздачу.

Выберыце платформу, якую каманда можа эксплуатаваць

Cloud native не патрабуе ператвараць кожную праграму ў мікрасэрвісы. Модульная праграма ў кіраваным асяроддзі выканання можа задаволіць свае патрабаванні. Больш сэрвісаў дадаюць больш інтэрфейсаў, рашэнняў аб разгортванні і эксплуатацыйнай працы.

Дайце агенту распрацоўкі фактычны кантракт платформы: падтрыманае асяроддзе выканання, метад ідэнтычнасці, сэрвісы даных, правілы разгортвання і неабходныя доказы. Тэстуйце паводзіны пры перапыненні і замене разам з паспяховымі запытамі. Працягвайце з урокам пра даступнасць і межы збояў.