Klíčové poznatky
Často se setkáváme s otázkou „Co je programovatelný proxy a proč jej potřebuji?“ Tento článek se snaží odpovědět na tuto otázku z různých úhlů pohledu. Začneme stručnou definicí toho, co je proxy server, poté probereme, jak se proxy vyvíjela v různých fázích, vysvětlíme, na jaké potřeby reagovali a jaké výhody v každé fázi nabízely. Nakonec probereme několik aspektů programovatelnosti a poskytneme shrnutí toho, proč potřebujeme programovatelný proxy.
Co je proxy?
Proxy server je obvykle nasazen uprostřed dvou izolovaných sítí a je zodpovědný za přenosy dat z jedné strany na druhou, takže vypadají jako jedna síť. Ve své nejjednodušší podobě je proxy brána mezi uživatelem a internetem, jak existuje od zrodu počítačových sítí. Proxy však nefunguje pouze jako síťový konektor, protože také umožňuje další funkce a případy použití, jako jsou:
Proxy pracující na vrstvách 4 a 7 modelu ISO/OSI se někdy označují jako proxy servery v "režimu směrování". Většina služeb proxy je k dispozici jako software s otevřeným zdrojovým kódem a odpovídá za většinu softwaru síťové infrastruktury a poskytuje specializované funkce v různých doménách, jako jsou proxy pro konkrétní protokoly, proxy pro vyrovnávání zátěže, proxy pro akceleraci mezipaměti atd.
Vývoj proxy softwaru
Související sponzor
Naučte se základy Istio Snadný způsob, jak se naučit Istio. Istio je open-source síťová platforma služeb, která pomáhá mikroslužbám komunikovat mezi sebou. Další informace.
Proxy servery se vyvíjely v různých fázích vývoje:
Éra konfiguračních souborů
Tato generace proxy je zcela založena na konfiguraci. Uživatel nastaví řadu parametrů, nakonfiguruje pravidla v konfiguračním souboru a poté spustí proces služby k provedení těchto pravidel.
Éra konfigurace DSL
Statické konfigurační soubory ztěžují vyjádření složité logiky, takže mnoho serverů proxy zavedlo kromě konfiguračních souborů také možnosti tenkého skriptování. Ty se běžně označují jako „konfigurační jazyky“ nebo jazyky specifické pro doménu (zkráceně DSL), jako je Haprxoy's ACL nebo Varnish's VCL.
Éra skriptovacích jazyků
S tím, jak se logika stává složitější, je stále obtížnější ji vyjádřit pomocí konfiguračních jazyků. Současně, když počet odlišných konfiguračních jazyků používaných ve stejné síti dosáhne určité hranice, jejich správa se stává obtížnou.
Pomocí skriptů shellu lze například psát jednoduchou logiku, ale když kód shellu dosáhne určité úrovně složitosti, je často nutné přejít na strukturovanější skriptovací jazyky, jako je Perl nebo Python.
Takové jazyky přinášejí pohodlí skriptování a strukturální výhodu plnohodnotného programovacího jazyka. Příklady toho jsou OpenResty (Nginx + Lua) a Nginx Plus (Nginx + NJS). Tato kategorie také zahrnuje proxy servery implementované v řadě aplikačních programovacích jazyků, jako je StrongLoop Microgateway založený na Node a Spring Cloud Gateway založený na Javě, které často mají vlastní skriptovací schopnosti.
Éra klastrů
Skriptovací jazyky řeší složitost, která je vlastní modularizaci a strukturování složité logiky. Dalším požadavkem v tomto bodě je integrace proxy s jinými nástroji pro správu správy, a proto je potřeba REST nebo podobné rozhraní. Externí řídicí rovina může skutečně použít toto rozhraní k dynamické aktualizaci logiky ve skriptu.
Zároveň se používání serverů proxy přesunulo z jednotlivých instancí na shluky serverů proxy. Ve skutečnosti proxy software, jako je Envoy a Kong založený na OpenResty, často sám o sobě podporuje klastrovací schopnosti a implementuje je nějakým centralizovaným nebo sdíleným způsobem (prostřednictvím RDBMS atd.), přičemž také poskytuje administrativní rozhraní REST pro správu konfigurací.
U serverů proxy před touto érou je správa clusteru obecně možná prostřednictvím správy konfigurace. Nástroje pro správu konfigurace mohou také odhalit rozhraní REST. Například Ansible + Nginx implementuje podobné funkce jako proxy servery z cloudové éry. Naproti tomu proxy servery z éry clusteru vyžadují k vytvoření schématu více komponent, zatímco servery proxy z éry cloudu odstraňují zátěž se správou pohyblivých částí a jsou mnohem preferovanější.
Cloudová éra
V éře cloudu jsou servery proxy nasazovány distribuovaným způsobem. Nejběžnějším scénářem je nasazení jednoho proxy pro každý aplikační proces podle vzoru Sidecar Proxy.
V režimu shlukování obvykle existují různé konfigurace a zásady pro různé upstream služby, jako jsou různé režimy ověřování a mechanismy řízení přístupu. S růstem upstreamových služeb jsou konfigurace těchto různých upstreamových služeb logicky odděleny, ale fyzicky běží ve stejném proxy procesu. Toto schéma má některé nevýhody: více logiky běžící ve stejném procesu přináší větší složitost. Různé upstream služby navíc sdílejí zdroje, jako je CPU a paměť, a vzájemně se ovlivňují. Pokud má skript nadřazené služby chybu zabezpečení, může dojít k úniku konfigurací jiných nadřazených služeb, což má za následek bezpečnostní rizika.
V éře cloudu jsou procesy proxy pro každou službu upstream nezávislé a vzájemně izolované. Přijetí distribuovaných proxy otevřelo dveře k používání různých pravidel a zásad pro různé upstream služby, tedy k možnostem více nájemců.
Různé upstream služby mají nejen logicky nezávislá pravidla a zásady. K dispozici je také fyzická izolace, která umožňuje granulární správu na úrovni procesu a rozhraní. Tato izolace je silným požadavkem v prostředí s více nájemci – různé upstream služby patří různým nájemcům a nájemci by se neměli vzájemně ovlivňovat ani znát své konfigurace.
Servisní sítě reprezentují tuto éru. Sítě služeb se skládají ze dvou klíčových architektonických komponent, datové roviny a řídicí roviny. Na rozdíl od toho, co název napovídá, síť služeb není „síť služeb“. Je to síť proxy, do které se mohou služby zapojit, aby síť zcela oddělily. Typickými příklady jsou istio+envoy, Linkerd + Linkerd proxy.
Pipy, vytvořený jedním z autorů tohoto článku, je produktem této doby a spadá do této kategorie. Pipy je open source, lehký, vysoce výkonný, modulární, programovatelný síťový proxy server pro cloud, edge a IoT. Pipy je ideální pro různé případy použití, od (mimo jiné) okrajových směrovačů, vyvažovačů zátěže & proxy řešení, API brány, statické HTTP servery, servisní síťové postranní vozíky a další aplikace. Pipy je v aktivním vývoji a je spravován tvůrci a přispěvateli na plný úvazek, ačkoli je to stále raná verze, byla otestována a v produkčním provozu několika komerčními klienty.
Z výše uvedené diskuse je jasné, že každá fáze je oproti předchozímu vylepšením.
Požadavky na proxy software a jejich vývoj
Podívejme se znovu na vývoj proxy serverů s ohledem na to, jak se vyvíjely jejich požadavky.
Éra konfiguračních souborů
První generace proxy implementovala především funkci brány mezi uživateli a službami a poskytovala základní konfigurovatelné možnosti. Přenos masivních dat v reálném čase vyžaduje vysokou propustnost a nízkou latenci a nízké využití zdrojů. Jako každý software jsou také vyžadovány servery proxy pro podporu modularity a rozšiřitelnosti.
Proxy software v této fázi byl vyvíjen hlavně v C, stejně jako tomu bylo u rozšiřujících modulů, které se dynamicky načítají na začátku procesu.
Abych to shrnul, požadavky na server proxy v této fázi jsou konektivita (síťové možnosti), snadné použití (konfigurovatelné pomocí konfiguračních souborů), spolehlivost (požadavky na zařízení s křížovým propojením ), vysoký výkon a škálovatelnost.
Éra konfigurace DSL
Druhá generace proxy získala další vylepšení v rozšiřitelnosti a flexibilitě, jako je například dynamické získávání dat a schopnost provádět některá logická rozhodnutí o získaných datech. Zavedení skriptů založených na DSL dále zvýšilo použitelnost. Podpora kombinatorické logiky a dynamického načítání dat zajistila flexibilitu a zároveň zlepšila škálovatelnost.
Éra skriptovacích jazyků
Hlavními vylepšeními serverů proxy 3. generace oproti serverům proxy 2. generace jsou spravovatelnost, přívětivost pro vývojáře a programovatelnost.
Produktivita vývojářů a složitost údržby masivních skriptů vyžaduje, aby tato generace proxy používala strukturovaný skriptovací jazyk, přičemž si zachovala výkon, nízké využití zdrojů a další základní schopnosti předchozí generace.
Schopnosti skriptování jsou široce používány, hlavně proto, že je obtížné vyvíjet a udržovat rozšíření pomocí jazyka C. Skriptovací jazyky se ve srovnání s kompilovanými jazyky skutečně snáze učí a poskytují rychlejší obrat.
Použití strukturovaného a modulárního skriptovacího jazyka zahájilo éru programovatelných serverů proxy a vyžadovalo, aby servery proxy poskytovaly dvě úrovně programovatelnosti: použití jazyka C pro vývoj základních modulů a skripty pro programování dynamické logiky. Jinými slovy, programovatelné proxy poskytovaly svým uživatelům sílu vývoje základních modulů a dynamické logiky.
Éra clusterů
Čtvrtá generace serverů proxy začíná podporou clusteru, která zlepšuje spravovatelnost.
Díky rozhraním REST se proxy stávají součástí implementace síťové infrastruktury a výchozím bodem pro infrastrukturu jako kód. Rozhraní REST kromě zlepšení proxy spravovatelnosti přispívají také ke zjednodušení jejich správy. Externí rozhraní jsou také důležitou vlastností programovatelných proxy a REST jako nejběžnější forma rozhraní.
V tuto chvíli se programovatelnost skládá ze tří vrstev: programovatelné základní moduly, programovatelná dynamická logika a programovatelná externí rozhraní. Vznik clusterů proxy serverů odráží změnu pohledu na škálovatelnost od rozšíření funkčnosti k rozšíření zdrojů (kde uživatelé mohou modularizovat funkčnost do více instancí, namísto psaní monolitního skriptu). Vznik rozhraní REST poskytuje technický základ pro samoobslužné a řízené služby, které poskytují např. ovládací panel pro konfiguraci a ovládání.
Cloudová éra
Vývoj páté generace proxy je poháněn popularitou a rychlým rozvojem cloud computingu, který přináší požadavky na elasticitu, samoobslužnost, multipronájem, izolaci a měření.
Pokud je čtvrtá generace agentů pro správce systému, pátá generace agentů je pro cloudové služby. Při plném zachování vlastností předchozích generací proxy softwaru jsou servery proxy páté generace připraveny na cloud.
S rozšířením cloud computingu na okraj potřebuje pátá generace proxy podporovat heterogenní hardware, heterogenní software a nízkou spotřebu energie, aby optimalizovala integraci cloudu a edge.
Pátá generace proxy také ukazuje pokroky v programovatelnosti: od základního modulu, dynamické logiky a externího rozhraní, které jsme viděli dříve, až po cloudovou podporu, podporu distribuce, multitenancy a měření. Měření je odvozeným požadavkem vícepronájmu, který na jedné straně vyžaduje izolaci a na druhé straně to, aby bylo možné měřit zdroje s nejmenší možnou granularitou.
Pojďme shrnout výše uvedenou diskusi do tabulkového formátu, kde řádky odpovídají konkrétním požadavkům a toproxy sloupců v různých fázích. Pro každý vývojový stupeň také uvádíme typické příklady nebo známý software v závorkách. V každé buňce používáme * k označení, zda jsou takové schopnosti dostupné a v jakém rozsahu (1-5 , 5 pro plnou podporu a 1 * pro základní podporu).
SN | Požadavek | Konfigurace (chobotnice, httpd, nginx) | Konfigurační jazyk (lak, haproxy) | Podpora skriptování (nginx+lua, nginx+js) | Shlukování (kong, vyslanec) | Cloud (istio+envoy, linkerd, pipy) | Poznámky |
1. | Připojení | * * * * * | * * * * * | * * * * * | * * * * * | * * * * * | Konektivita v éře cloudu začala s technologiemi jádra, jako jsou iptables a ebpf. Dříve existovaly pouze procesy v uživatelském prostoru. |
2. | Spolehlivost | * * * * * | * * * * * | * * * * * | * * * * * | * * * * * | Spolehlivost byla vždy nejzákladnější schopností proxy serverů. |
3. | Vysoký výkon | * * * | * * * * | * * * * * | * * * * * | * * * * * | Výkon zahrnuje propustnost, latenci, chybovost a odchylku od průměru. Běžné metriky latence jsou P99, P999 a další. Raný proxy software má efekt dlouhého ocasu, takže indikátory nad P99 nejsou tak dobré jako u pozdějšího softwaru. Proxy s vysoce výkonnými skripty často fungují lépe než jejich předchůdci, když vrací stejný obsah. Proxy, které se vyhýbají long tailům, jsou stabilnější (s menšími odchylkami od průměru) a poskytují stejný výkon. |
4. | Flexibilita | * | * * | * * * | * * * * | * * * * * | Ve srovnání se čtvrtou generací servery proxy páté generace výrazně vylepšují schopnost podpory více protokolů, takže tuto generaci hodnotíme pěti hvězdičkami. Model zpracování páté generace se navíc může přizpůsobit různým protokolům a nabídnout lepší vhodnost ve srovnání se čtvrtou generací. |
5. | Škálovatelnost | * | * * | * * * | * * * | * * * * | Podobně jako flexibilita, proxy 5. generace podporují více protokolů a poskytují snadné rozšiřující mechanismy pro rozšíření základní funkčnosti nebo vývoj rozšíření protokolu customdapplication layer (Layer 7), takže jim dáváme jeden hvězda více než 4. generace. |
6. | Hardwarová kompatibilita | * * * * | * * * * | * * * * | * * * * | * * * * | Proxy vyvinuté v C nebo C++ mají obecně lepší hardwarovou kompatibilitu a aktivnější komunitu pro migraci aplikací na nové hardwarové architektury. Proxy vyvinuté pomocí Rust, Go a Lua byly kvůli kompatibilitě hardwaru relativně pomalé při migraci. |
7. | Kompatibilita systému | * * * | * * * | * * * * | * * * * | * * * * * | Systém zahrnuje především dva aspekty, jedním je operační systém a druhým cloudová platforma. Z hlediska kompatibility operačního systému je každá generace proxy podobná. Z hlediska kompatibility cloudových platforem však servery proxy čtvrté i páté generace poskytují lepší cloudovou kompatibilitu. Naproti tomu významný rozdíl mezi pátou a čtvrtou generací spočívá v jejich schopnosti podporovat více nájemců. |
8. | Snadná správa | * * | * * | * * | * * * | * * * * | Snadná správa je funkcí provozu systému & administrátorské role. První a druhá generace používají především konfigurační soubory, založené na použití nástrojů pro správu konfigurace k dosažení automatické a dávkové správy. Ve třetí generaci musíme kromě správy konfiguračních souborů dále spravovat soubory skriptů. Ale v podstatě zde není žádný výrazný rozdíl oproti první a druhé generaci, co se týče jednoduchosti ovládání. Čtvrtá generace poskytuje rozhraní REST, což výrazně usnadňuje správu. Kromě REST poskytuje pátá generace proxy obvykle cloudovou řídicí rovinu pro správu proxy. Poskytuje také několik externích rozhraní pro splnění dalších požadavků na správu, jako je monitorování, auditování a statistiky. |
9. | Snadné použití | * | * | * | * * | * * * | Primárními uživateli prvních tří generací proxy jsou ops & správci systému. Ve čtvrté generaci začali administrátoři poskytovat uživatelům některé funkce a začal se objevovat model as-a-service. Pátá generace bere v úvahu více uživatelských scénářů a poskytuje více možností tenanta. |
10. | Snadný vývoj | * | * * | * * * | * * * * | * * * * * | Vývoj kolem serverů proxy zahrnuje dva aspekty. Jeden je uvnitř proxy, jehož cílem je dosáhnout funkčnosti; druhý je mimo zástupce, jehož cílem je dosáhnout manažerské schopnosti zástupce. První tři generace poskytují rozhraní pro interní vývoj. Poslední dvě generace poskytují interní i externí rozhraní. Významným vylepšením, které přinesla pátá generace oproti čtvrté generaci, je cloudové rozhraní. |
11. | Rozhraní jádra je programovatelné | * | * | * | * | * | Každá generace proxy poskytuje možnost rozšířit základní rozhraní, ale tato rozhraní jsou příliš nízkoúrovňová a obtížně se ovládají. |
12. | Rozšíření funkčnosti je programovatelné | * | * * | * * * | * * * * | * * * * * | Poskytování schopnosti efektivněji rozšiřovat funkce je součástí procesu, který se zlepšuje s každou generací proxy. Je to základní metrika programovatelných proxy. |
13. | Rozšíření protokolu jsou programovatelná | * * | * * * | První tři generace jsou hlavně pro jeden protokol nebo pevné protokoly. Počínaje čtvrtou generací začali uživatelé hledat podporu pro více protokolů a vlastních protokolů. V páté generaci je rozšíření protokolu považováno za základní schopnost návrhu. | |||
14. | Modulární skriptování | * * * | * * * * | * * * * | Proxy třetí generace začínají věnovat více pozornosti strukturování skriptů. Čtvrtá a pátá generace se pokouší umožnit strukturovanější programování, jako je pokus Envoy poskytovat vícejazyčnou podporu prostřednictvím WASM; Pipy představuje vysoce výkonné JS skripty pro lepší strukturování | ||
15. | Správa konfigurace je programovatelná | * * | * * * | První tři generace konfigurace proxy se zaměřují především na personál správy operačních systémů a externí nástroje pro správu konfigurace jsou založeny na tomto předpokladu. Čtvrtá generace podporuje rozhraní pro správu REST. Pátá generace dále poskytuje standardní cloudové rozhraní pro správu konfigurace. | |||
16. | Rozšíření zdrojů jsou programovatelná | * | * | * | * * | * * * * | U prvních tří generací bylo rozšíření kapacity proxy zaměřeno hlavně na zvýšení počtu vláken nebo procesů. Čtvrtá generace poskytuje schopnost škálování procesů, známou jako schopnost shlukování. Na základě toho pátá generace poskytuje na jedné straně možnosti horizontálního rozšíření, na druhé straně možnosti v rámci omezených zdrojů pro podporu jemnějšího měření a účtování. To znamená, že nejen podporuje přírůstkové škálování, ale také poskytuje možnost zmenšovat. Kromě toho všechny tyto funkce poskytují programovací rozhraní. |
17. | Prodloužení nájemce programovatelné | * * * | Cloud je něco, co se objevilo ve stejné době jako čtvrtá generace proxy, a multi-tenancy jako základní funkce cloudu není ve čtvrté generaci dostatečně podporována. generace. Pátá generace je navržena na základě cloud computingu, zvažuje a poskytuje nájemcům možnost programování vlastních rozšíření. |
Řádky #11 až #17 v tabulce výše představují specifické aspekty programovatelného proxy. Tyto aspekty také tvoří odpověď na otázku, proč používat programovatelný proxy:
Shrnutí
V tomto článku jsme se pokusili poskytnout odpověď na to, co je to programovatelný proxy. Za tímto účelem jsme vycházeli z definice toho, co je proxy a jaké jsou jeho klíčové vlastnosti. Poté jsme naši diskuzi rozšířili o evoluční proxy, kterou jsme prošli, a vysvětlili jsme vlastnosti a funkce, které byly přidány v každé fázi. Nakonec shrneme naši diskusi o funkcích proxy tak, že je rozdělíme do 17 různých kategorií a seřadíme každou generaci proxy. Tato klasifikace nám umožnila identifikovat klíčové charakteristiky a atributy, které jsou nutné k tomu, aby byl proxy označen jako programovatelný.
O autorech
Cai Shu
Zobrazit víceZobrazit méněAli Naqvi
Zobrazit víceZobrazit méně
