![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Не повторюйся або DRY є важливим принципом у розробці програмного забезпечення. Ця публікація покаже вам, як застосувати його до конфігурації Apache APISIX.
«Не повторюйся» (DRY) — це принцип розробки програмного забезпечення, спрямований на зменшення повторення інформації, яка, ймовірно, буде змінюватися, замінюючи її абстракціями, які менш імовірно змінюватимуться, або використовуючи нормалізацію даних, яка в першу чергу уникає надмірності. .
Основна ідея DRY полягає в тому, що якщо ви повторюєте себе і інформація змінюється, ви повинні оновити змінену інформацію в кількох місцях. Це не лише додаткові зусилля; є шанс, що ви забудете про це і матимете різну інформацію в різних місцях. DRY блищить у виправленні помилок.
Уявіть, що фрагмент коду містить помилку. Уявіть тепер, що ви скопіювали фрагмент у двох різних місцях. Тепер ви повинні виправити помилку в цих двох місцях, і це найпростіше; важко знати про дублювання в першу чергу.
Існує висока ймовірність того, що особа, яка дублює, і особа, яка виправляє, різні. Якщо фрагмент було перероблено для спільного використання та викликано з двох місць, вам потрібно виправити помилку лише в цьому місці.
Більшість людей DRY асоціюють із кодом. Однак це може бути більш обмежуючим і суперечити початковій ідеї.
Принцип був сформульований Енді Хантом і Дейвом Томасом у їхній книзі «Прагматичний програміст». Вони застосовують його досить широко, включаючи схеми бази даних, плани тестування, систему збірки і навіть документацію.
Системи конфігурації звуку дозволяють DRY або навіть заохочують його.
Apache APISIX пропонує конфігурацію DRY у двох місцях.
У контексті електронної комерції ваша подорож для початківців до визначення маршруту в Apache APISIX, ймовірно, починається так:
routes: - id: 1 name: Catalog uri: /products* upstream: nodes: "catalog:8080": 1
Якщо ви знайомі з APISIX, ми визначили маршрут до каталогу за URI /products
. Однак є проблема: ви, ймовірно, хочете, щоб потенційні клієнти переглядали каталог, але не хочете, щоб люди створювали, видаляли або оновлювали продукти. Тим не менш, маршрут відповідає кожному методу HTTP за замовчуванням.
Ми повинні дозволити лише автентифікованим користувачам керувати каталогом, щоб кожен міг вільно переглядати його. Щоб реалізувати цей підхід, нам потрібно розділити маршрут на два:
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
— найпростіший плагін для цього
Ми усунули проблему безпеки найпростішим можливим способом: шляхом копіювання та вставки. Зробивши це, ми продублювали upstream
частину. Якщо нам потрібно змінити топологію, наприклад , шляхом додавання або видалення вузлів, ми повинні зробити це в двох місцях. Це порушує принцип DRY.
У сценаріях реального світу, особливо коли вони включають контейнери, ви не реалізуєте upstream
шляхом переліку nodes
. Натомість вам слід реалізувати динамічне виявлення служби , щоб врахувати зміни топології. Однак питання все ще стоїть, коли вам потрібно змінити конфігурацію або реалізацію виявлення служби. Отже, моя думка однаково стосується виявлення вузлів і служб.
Разом з абстракцією Route APISIX пропонує абстракцію Upstream для реалізації DRY. Ми можемо переписати наведений вище фрагмент так:
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
є взаємовиключними .
Ще одна область, де 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
Коротше кажучи, конфігурація plugin
в route
скасовує конфігурацію в plugin_config_id
. Це також дозволяє нам надати змінну apikey
для плагіна key-auth
в consumer
та встановити її лише в маршруті. APISIX знайде та використає ключ для кожного consumer
!
DRY — це не лише код; мова йде про керування даними загалом. Конфігурація — це дані, тому вона підпадає під цю загальну парасольку.
APISIX пропонує два параметри DRY: один для upstream
- upstream_id
і один для plugin
- plugin_config_id
. Верхня течія є ексклюзивною; плагіни дозволяють скасовувати.
Обидва механізми мають допомогти вам осушити вашу конфігурацію та зробити її більш зручною для обслуговування в довгостроковій перспективі.
Щоб піти далі:
Вперше опубліковано на сайті A Java Geek 1 вересня 2024 року