Не повторюйся або DRY є важливим принципом у розробці програмного забезпечення. Ця публікація покаже вам, як застосувати його до конфігурації Apache APISIX.  Принцип DRY  «Не повторюйся» (DRY) — це принцип розробки програмного забезпечення, спрямований на зменшення повторення інформації, яка, ймовірно, буде змінюватися, замінюючи її абстракціями, які менш імовірно змінюватимуться, або використовуючи нормалізацію даних, яка в першу чергу уникає надмірності. .  --  Вікіпедія – не повторюйтесь  Основна ідея DRY полягає в тому, що якщо ви повторюєте себе і інформація змінюється, ви повинні оновити змінену інформацію в кількох місцях. Це не лише додаткові зусилля; є шанс, що ви забудете про це і матимете різну інформацію в різних місцях. 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  Ми усунули проблему безпеки найпростішим можливим способом: шляхом копіювання та вставки. Зробивши це, ми продублювали   частину. Якщо нам потрібно змінити топологію,   , шляхом додавання або видалення вузлів, ми повинні зробити це в двох місцях. Це порушує принцип DRY. 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: ~  Визначте вгору з ідентифікатором  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 Config   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

About Author

КОМЕНТАРІ

ПОВІСИТИ БИРКИ

ЦЯ СТАТТЯ БУЛА ПРЕДСТАВЛЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps