Не се повторувај или не се суши е важен принцип во развојот на софтвер. Овој пост ќе ви покаже како да го примените на конфигурацијата на Apache APISIX.  Принципот на суво  „Не се повторувај“ (DRY) е принцип на развој на софтвер кој има за цел да го намали повторувањето на информациите кои веројатно ќе се променат, заменувајќи ги со апстракции кои со помала веројатност ќе се променат или користење на нормализација на податоците што на прво место го избегнува вишокот .  --  Википедија - Не се повторувај  Главната идеја зад DRY е дека ако се повторувате и информациите се сменат, тогаш мора да ги ажурирате променетите информации на повеќе места. Тоа не е само дополнителен напор; постои можност да заборавите на тоа и да имате различни информации на различни места. DRY сјае при поправање грешки.  Замислете фрагмент од код кој содржи бубачка. Замислете сега дека сте го дуплирале фрагментот на две различни места. Сега, мора да ја поправите грешката на овие две места, и тоа е полесниот дел; тешко е да се знае за дуплирањето на прво место.  Има големи шанси личноста што се дуплира и таа што поправа се различни. Ако фрагментот бил рефакториран за да може да се сподели и наместо тоа повикан од двете места, треба само да ја поправите грешката на ова едно место.  Повеќето луѓе го поврзуваат DRY со код. Сепак, тоа би можело да биде поограничувачко и спротивно на првичната идеја.  Принципот е формулиран од Енди Хант и Дејв Томас во нивната книга Прагматичен програмер. Тие го применуваат доста широко за да вклучат шеми за бази на податоци, планови за тестирање, систем за градење, дури и документација.  --  Википедија - Не се повторувај  Системите за конфигурација на звук овозможуваат СУШЕЊЕ или дури и го поттикнуваат.  СУШИ во Apache APISIX  Apache APISIX нуди DRY конфигурација на две места.  СУВИ Нагорни текови  Во контекст на е-трговија, вашето почетничко патување за да дефинирате рута на Apache APISIX веројатно започнува вака:   routes: - id: 1 name: Catalog uri: /products* upstream: nodes: "catalog:8080": 1  Ако сте запознаени со APISIX, дефиниравме маршрута до каталогот под   URI. Сепак, постои проблем: веројатно сакате потенцијалните клиенти да го прелистуваат каталогот, но сакате да ги спречите луѓето да создаваат, бришат или ажурираат производи. Сепак, рутата стандардно се совпаѓа со секој HTTP метод. /products  Треба да дозволиме само автентицирани корисници да управуваат со каталогот за да може секој слободно да го прелистува. За да го имплементираме овој пристап, треба да ја поделиме рутата на два дела:   routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] #1 uri: /products* upstream: #2 nodes: "catalog:8080": 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] #3 uri: /products* plugins: key-auth: ~ #4 upstream: #2 nodes: "catalog:8080": 1  Прелистување натпревар  Дупликат нагоре!  Управување со натпревари  Само автентицирани потрошувачи можат да ја користат оваа рута;   е наједноставниот приклучок за ова key-auth  Безбедносниот проблем го решивме на наједноставен можен начин: со copy-paste. Со тоа, го дуплиравме делот   . Ако треба да ја смениме топологијата,   , со додавање или отстранување јазли, тоа мора да го направиме на две места. Го поразува принципот на СУВО. upstream на пр.  Во сценаријата од реалниот свет, особено кога тие вклучуваат контејнери, нема да го имплементирате   со наведување   . Наместо тоа, треба да имплементирате динамично   за да се приспособат на промените во топологијата. Сепак, поентата сè уште стои кога треба да ја промените конфигурацијата или имплементацијата за откривање услуга. Оттука, мојата поента се однесува подеднакво на јазлите и откривањето на услугите. upstream nodes откривање на услугата  Заедно со апстракцијата   , APISIX нуди апстракција   за спроведување на DRY. Горенаведениот фрагмент можеме да го преработиме вака: Route Upstream   upstreams: - id: 1 #1 name: Catalog nodes: "catalog:8080": 1 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /products* upstream_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /products* upstream_id: 1 #2 plugins: key-auth: ~  Дефинирајте возводно со ID  1  Наведете го во маршрутата  Ако нешто се случи во топологијата, мора да ја ажурираме промената само во единечниот   . Upstream  Забележете дека дефинирањето на вграденото   и неговото упатување со     . upstream upstream_id меѓусебно се исклучуваат  Конфигурација на приклучокот DRY  Друга област каде што APISIX може да ви помогне да ја исушите вашата конфигурација со апстракцијата   . APISIX ги имплементира повеќето функции, ако не и сите, преку приклучоци на приклучокот  Ајде да имплементираме   на нашето API. Треба да го преработиме URL-то пред да го проследиме. верзии базирани на патеки   routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1  Отстранете го префиксот   пред препраќање /v1  Како и со   , делот   е дупликат. Ние, исто така, можеме да ја факторизираме конфигурацијата на приклучокот во посветен објект   . Следниот фрагмент го има истиот ефект како оној погоре: upstream plugins за конфигурација на приклучокот   plugin_configs: - id: 1 #1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2  Факторирајте ја конфигурацијата на приклучокот во посветен објект  Референцирај го  Разумните читатели можеби забележале дека ми недостасува дел од конфигурацијата:   мистериозно исчезна! Навистина, го отстранив заради јасност. auth-key  За разлика од   и   ,   и     . Можеме да го решиме проблемот со само додавање на   што недостасува: upstream upstream_id plugins plugin_config_id не се исклучуваат меѓусебно plugin   routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 plugins: key-auth: ~ #1  Поправете го!  На овој начин, можете да ја преместите споделената конфигурација во објект   и да задржите одредена на местото каде што се применува. Но, што ако истиот приклучок со различни конфигурации се користи во   и директно во   ?   е прилично јасна за тоа: plugin_config plugin_config route Документацијата    >   >   >   >  Consumer Consumer Group Route Plugin Config Service  Накратко, конфигурацијата   во   ја отфрла конфигурацијата во   . Исто така, ни овозможува да ја обезбедиме променливата   за приклучокот   кај   и да ја поставиме само во рута. APISIX ќе го најде и користи клучот за секој   ! plugin route plugin_config_id apikey key-auth consumer consumer  Заклучок  DRY не е само за код; се работи за управување со податоци воопшто. Конфигурацијата е податок и затоа спаѓа под овој општ чадор.  APISIX нуди две DRY опции: една за   -   , и една за   -   . Возводните текови се ексклузивни; приклучоците дозволуваат отфрлање. upstream upstream_id plugin plugin_config_id  Двата механизми треба да ви помогнат да ја исушите вашата конфигурација и да ја направат поодржлива на долг рок.   За да продолжите понатаму:   Принципот Не се повторувај   Предност на спојување на конфигурацијата   Првично објавено во   на 1 септември 2024 година A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Ова аудио е произведено на оригиналниот јазик на приказната!

Премногу долго; Да чита

Make resilience your competitive advantage

Како да го исушите вашиот Apache APISIX Config

About Author

КОМЕНТАРИ

ВИСЕТЕ ТАГОВИ

ОВОЈ СТАТИЈА БЕШЕ ПРЕТСТАВЕН ВО

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps