Don't Repeat Yourself of DRY is een belangrijk principe in softwareontwikkeling. Deze post laat zien hoe je het toepast op Apache APISIX-configuratie.  Het DROOG-principe  "Don't repeat yourself" (DRY) is een principe van softwareontwikkeling dat gericht is op het verminderen van de herhaling van informatie die waarschijnlijk zal veranderen, door deze te vervangen door abstracties die minder waarschijnlijk veranderen, of door gebruik te maken van datanormalisatie om redundantie in de eerste plaats te voorkomen.  --  Wikipedia - Herhaal jezelf niet  Het hoofdidee achter DRY is dat als je jezelf herhaalt en de informatie verandert, je de gewijzigde informatie op meerdere plekken moet updaten. Het kost niet alleen extra moeite; er is een kans dat je het vergeet en dat je op verschillende plekken andere informatie hebt. DRY blinkt uit in het oplossen van bugs.  Stel je een codefragment voor dat een bug bevat. Stel je nu voor dat je het fragment op twee verschillende plekken hebt gedupliceerd. Nu moet je de bug op deze twee plekken oplossen, en dat is het makkelijke gedeelte; het moeilijke is om in de eerste plaats te weten dat er sprake is van duplicatie.  Er is een grote kans dat de persoon die dupliceert en degene die repareert verschillend zijn. Als het fragment was gerefactored om deelbaar te zijn en in plaats daarvan vanaf de twee plekken was aangeroepen, hoef je de bug alleen op deze ene plek te repareren.  De meeste mensen associëren DRY met code. Het zou echter beperkender en tegenstrijdiger kunnen zijn met het oorspronkelijke idee.  Het principe is geformuleerd door Andy Hunt en Dave Thomas in hun boek The Pragmatic Programmer. Ze passen het vrij breed toe, inclusief databaseschema's, testplannen, het bouwsysteem en zelfs documentatie.  --  Wikipedia - Herhaal jezelf niet  Geluidsconfiguratiesystemen staan DROOG toe of moedigen het zelfs aan.  DROOG in Apache APISIX  Apache APISIX biedt DRY-configuratie op twee plaatsen.  DROGE stroomopwaarts  In een e-commercecontext begint uw beginnersreis om een route op Apache APISIX te definiëren waarschijnlijk als volgt:   routes: - id: 1 name: Catalog uri: /products* upstream: nodes: "catalog:8080": 1  Als u bekend bent met APISIX, hebben we een route naar de catalogus gedefinieerd onder de   URI. Er is echter een probleem: u wilt waarschijnlijk dat potentiële klanten door de catalogus bladeren, maar u wilt voorkomen dat mensen producten maken, verwijderen of updaten. Toch komt de route standaard overeen met elke HTTP-methode. /products  We zouden alleen geauthenticeerde gebruikers de catalogus moeten laten beheren, zodat iedereen er vrij doorheen kan bladeren. Om deze aanpak te implementeren, moeten we de route in tweeën splitsen:   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  Match browsen  Stroomopwaarts gedupliceerd!  Wedstrijdmanagement  Alleen geauthenticeerde consumenten kunnen deze route gebruiken;   is de eenvoudigste plugin hiervoor key-auth  We hebben het beveiligingsprobleem op de eenvoudigste manier opgelost: door kopiëren en plakken. Daarmee hebben we de   sectie gedupliceerd. Als we de topologie moeten wijzigen,   door knooppunten toe te voegen of te verwijderen, moeten we dat op twee plaatsen doen. Het verslaat het DRY-principe. upstream bijvoorbeeld  In real-world scenario's, met name wanneer ze containers betreffen, zou u de   niet implementeren door   op te sommen. U zou in plaats daarvan een dynamische   moeten implementeren om topologiewijzigingen te accommoderen. Het punt blijft echter staan wanneer u de service discovery-configuratie of -implementatie moet wijzigen. Daarom is mijn punt evenzeer van toepassing op nodes als op service discovery. upstream nodes service discovery  Samen met de   abstractie biedt APISIX een   abstractie om DRY te implementeren. We kunnen het bovenstaande fragment als volgt herschrijven: 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: ~  Definieer een upstream met ID  1  Verwijs ernaar in de route  Als er iets in de topologie gebeurt, moeten we de wijziging alleen in de enkele   bijwerken. Upstream  Houd er rekening mee dat het definiëren van de   embedded en het ernaar verwijzen met     . upstream upstream_id elkaar uitsluiten  DRY Plugin-configuratie  Een ander gebied waar APISIX u kan helpen uw configuratie te DROGEN met de   abstractie. APISIX implementeert de meeste functies, zo niet alle, via plugins Plugin-  Laten we   implementeren op onze API. We moeten de URL herschrijven voordat we deze doorsturen. path-based versioning   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  Verwijder het   voorvoegsel voordat u doorstuurt /v1  Net als bij   hierboven, is de   sectie gedupliceerd. We kunnen de plugin configuratie ook factoriseren in een dedicated   object. Het volgende fragment heeft hetzelfde effect als het fragment hierboven: 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  Factor de pluginconfiguratie in een speciaal object  Verwijs ernaar  Oplettende lezers hebben misschien opgemerkt dat ik een deel van de configuratie mis: de   is op mysterieuze wijze verdwenen! Ik heb hem inderdaad verwijderd voor de duidelijkheid. auth-key  In tegenstelling tot   en   , zijn   en     . We kunnen het probleem oplossen door gewoon de ontbrekende   toe te voegen: upstream upstream_id plugins plugin_config_id niet wederzijds exclusief 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  Los het op!  Op deze manier kunt u de gedeelde configuratie verplaatsen naar een   object en een specifieke behouden op de plaats waar deze van toepassing is. Maar wat als dezelfde plugin met verschillende configuraties wordt gebruikt in de   en direct in de   ? De   is er vrij duidelijk over: plugin_config plugin_config route documentatie    >   >   >   >  Consumer Consumer Group Route Plugin Config Service  Kortom, de   in een   overruled de configuratie in de   . Het stelt ons ook in staat om de   variabele voor de   plugin in een   te verstrekken en deze alleen in een route in te stellen. APISIX vindt en gebruikt de sleutel voor elke   ! plugin route plugin_config_id apikey key-auth consumer consumer  Conclusie  DRY gaat niet alleen over code; het gaat over datamanagement in het algemeen. Configuratie is data en valt dus onder deze algemene paraplu.  APISIX biedt twee DRY-opties: één voor   -   , en één voor   -   . Upstreams zijn exclusief; plugins staan overruling toe. upstream upstream_id plugin plugin_config_id  Beide mechanismen helpen u bij het DROGEN van uw configuratie en maken deze op de lange termijn beter onderhoudbaar.   Om verder te gaan:   Het principe 'Herhaal jezelf niet'   Voorrang bij het samenvoegen van configuraties   Oorspronkelijk gepubliceerd op   op 1 september 2024 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Deze audio wordt geproduceerd in de originele taal van het verhaal!

Te lang; Lezen

Make resilience your competitive advantage

Hoe u uw Apache APISIX-configuratie kunt DROGEN

About Author

OPMERKINGEN

LABELS

DIT ARTIKEL WERD GEPRESENTEERD IN

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps