Ключови изводи
Често задаван въпрос е „Какво е програмируем прокси и защо имам нужда от него?“ Тази статия се опитва да отговори на този въпрос от различни гледни точки. Ще започнем с кратко определение на това какво е прокси, след което ще обсъдим как прокситата са се развили през различни етапи, обяснявайки на какви нужди отговарят и какви ползи предлагат на всеки етап. Накрая ще обсъдим няколко аспекта на програмируемостта и ще предоставим обобщение защо се нуждаем от програмируем прокси.
Какво е прокси?
Прокси сървърът обикновено се разполага в средата на две изолирани мрежи и отговаря за прехвърлянето на данни от едната страна към другата, така че да изглеждат като една мрежа. В най-простата си форма проксито е шлюз между потребител и интернет, както съществува от раждането на компютърните мрежи. Проксито обаче действа не само като мрежов конектор, тъй като също така позволява допълнителна функционалност и случаи на използване като:
Проксита, работещи на слоеве 4 и 7 на модела ISO/OSI, понякога се наричат проксита в режим на маршрутизиране. Повечето прокси услуги са налични като софтуер с отворен код и представляват по-голямата част от софтуера за мрежова инфраструктура, предоставяйки специализирани функции в различни домейни, като проксита за специфични протоколи, проксита за балансиране на натоварването, проксита за ускоряване на кеша и т.н.
Прокси софтуерна еволюция
Свързан спонсор
Научете основите на Istio Лесният начин да научите Istio. Istio е мрежова платформа за услуги с отворен код, която помага на микроуслугите да комуникират помежду си. Научете повече.
Прокси сървърите са се развили през различни етапи на развитие:
Ера на конфигурационния файл
Това поколение прокси е изцяло базирано на конфигурация. Потребителят задава редица параметри, конфигурира правила в конфигурационен файл и след това стартира процеса на обслужване, за да изпълни тези правила.
Конфигурационна DSL ера
Статичните конфигурационни файлове затрудняват изразяването на сложна логика, така че много проксита въведоха възможности за тънък скрипт върху конфигурационните файлове. Те обикновено се наричат „езици за конфигуриране“ или специфични за домейна езици (накратко DSL), като ACL на Haprxoy или VCL на Varnish.
Ера на скриптовите езици
Тъй като логиката става по-сложна, става по-трудно да се изрази чрез конфигурационни езици. В същото време, когато броят на различните езици за конфигурация, използвани в една и съща мрежа, достигне определен праг, тяхното управление става трудно.
Използвайки шел скриптове, например, човек може да напише проста логика, но когато шел кодът достигне определено ниво на сложност, често се налага преминаване към по-структурирани скриптови езици като Perl или Python.
Такива езици носят удобството на скриптовете и структурното предимство на пълноценен език за програмиране. Примери за това са OpenResty (Nginx + Lua) и Nginx Plus (Nginx + NJS). Тази категория също така включва прокси сървъри, внедрени в редица езици за програмиране на приложения, като базиран на възел StrongLoop Microgateway и базиран на Java Spring Cloud Gateway, които често имат свои собствени възможности за скриптове.
Клъстерна ера
Скриптовите езици решават сложността, присъща на модулирането и структурирането на сложна логика. Допълнително изискване на този етап е да се интегрират проксита с други инструменти за административен контрол, следователно необходимостта от REST или подобен интерфейс. В действителност външна контролна равнина може да използва този интерфейс за динамично актуализиране на логиката в скрипта.
В същото време използването на проксита се премести от единични екземпляри към групи от проксита. Всъщност прокси софтуерът като Envoy и базираният на OpenResty Kong често поддържа самите възможности за клъстериране, като ги прилага по някакъв централизиран или споделен (чрез RDBMS и т.н.) начин, като същевременно предоставя REST административни интерфейси за управление на конфигурациите.
За проксита преди тази ера управлението на клъстерите обикновено е възможно чрез управление на конфигурацията. Инструментите за управление на конфигурацията също могат да разкрият REST интерфейси. Например Ansible + Nginx прилага подобни възможности на проксита от ерата на облака. За разлика от това, прокситата от клъстерната ера изискват повече компоненти за формиране на схемата, докато прокситата от ерата на облака премахват тежестта от управлението на движещи се части и са много предпочитани.
Ерата на облака
В ерата на облака прокси сървърите се разполагат по разпределен начин. Най-често срещаният сценарий е да се внедри един прокси за всеки процес на приложение, следвайки модела Sidecar Proxy.
В режим на клъстериране обикновено има различни конфигурации и политики за различни услуги нагоре по веригата, като например различни режими на удостоверяване и механизми за контрол на достъпа. Тъй като услугите нагоре по веригата растат, конфигурациите на тези различни услуги нагоре по веригата са логически разделени, но се изпълняват физически в един и същ прокси процес. Тази схема има някои недостатъци: повече логика, изпълнявана в един и същи процес, носи повече сложност. Освен това различни услуги нагоре по веригата споделят ресурси като CPU и памет, като си влияят взаимно. Ако скрипт на услуга нагоре по веригата има уязвимост в сигурността, конфигурациите на други услуги нагоре по веригата може да изтекат, което води до рискове за сигурността.
В ерата на облака прокси процесите за всяка услуга нагоре по веригата са независими и изолирани един от друг. Приемането на разпределени прокси сървъри отвори вратата за използване на различни правила и политики за различни услуги нагоре по веригата, тоест за възможности за много клиенти.
Различните услуги нагоре по веригата не само имат логически независими правила и политики. Осигурена е и физическа изолация, позволяваща детайлно управление на ниво процес и интерфейс. Тази изолация е силно изискване в среда с множество наематели – различните услуги нагоре по веригата принадлежат на различни наематели и наемателите не трябва да се влияят един на друг или да познават конфигурациите на другия.
Сервизните мрежи са представителни за тази ера. Сервизните мрежи са съставени от два ключови архитектурни компонента, равнина на данни и равнина на управление. Противно на това, което подсказва името, сервизната мрежа не е „мрежа от услуги“. Това е мрежа от проксита, към които услугите могат да се включат, за да абстрахират напълно мрежата. Типични примери са istio+envoy, Linkerd + Linkerd proxy.
Създаден от един от авторите на тази статия, Pipy е продукт на тази епоха и попада в тази категория. Pipy е лек, високоефективен, модулен, програмируем мрежов прокси с отворен код за облак, edge и IoT. Pipy е идеален за разнообразни случаи на употреба, вариращи от (но не само) крайни рутери, балансьори на натоварването & прокси решения, API шлюзове, статични HTTP сървъри, мрежови странични колички за услуги и други приложения. Pipy е в активна разработка и се поддържа от постоянни участници и сътрудници, въпреки че все още е ранна версия, тя е тествана в битки и се използва в производствена среда от няколко търговски клиенти.
От дискусията по-горе става ясно, че всеки етап е подобрение спрямо предишния.
Изисквания към прокси софтуера и тяхното развитие
Нека хвърлим нов поглед върху еволюцията на прокси сървърите, като вземем предвид как са се развили техните изисквания.
Ера на конфигурационния файл
Първото поколение прокси сървъри основно реализира функционалност на шлюз между потребителите и услугите и предоставя основни възможности за конфигуриране. Предаването в реално време на масивни данни изисква висока пропускателна способност, ниско забавяне и ниско потребление на ресурси. Както всеки софтуер, прокситата също трябва да поддържат модулност и разширяемост.
Прокси софтуерът на този етап е разработен основно на C, какъвто беше случаят с модулите за разширение, които се зареждат динамично в началото на процеса.
За да обобщим, изискванията за прокси на този етап са свързаност (мрежови възможности), лекота на използване (конфигурируема чрез конфигурационни файлове), надеждност (изисквания за устройства за кръстосано свързване ), висока производителност и разширяемост.
Конфигурационна DSL ера
Второто поколение прокси сървъри получи допълнителни подобрения в разширяемостта и гъвкавостта, като например известно динамично събиране на данни и възможност за извършване на някои логически решения върху придобитите данни. Въвеждането на DSL-базирани скриптове допълнително подобри използваемостта. Поддръжката за комбинаторна логика и динамично извличане на данни осигури гъвкавост, като същевременно подобрява разширяемостта.
Ерата на скриптовия език
Основните подобрения на проксита от 3-то поколение спрямо проксита от 2-ро поколение са управляемост, удобство за разработчици и програмируемост.
Производителността на разработчиците и сложността на поддържането на масивни скриптове изискват това поколение прокси сървъри да използват структуриран скриптов език, като същевременно запазват производителността, ниското използване на ресурсите и други основни възможности на предишното поколение.
Възможностите за скриптове се използват широко, главно защото е трудно да се разработват и поддържат разширения с помощта на C. Наистина, скриптовите езици са по-лесни за научаване и осигуряват по-бързо изпълнение в сравнение с компилираните езици.
Използването на структуриран и модулен скриптов език постави началото на ерата на програмируемите проксита и изискваше прокситата да предоставят две нива на програмируемост: използване на C за разработване на основни модули и скриптове за програмиране на динамична логика. С други думи, програмируемите проксита предоставиха на своя потребител силата на разработване на основни модули и динамична логика.
Клъстерна ера
Четвъртото поколение прокси сървъри започва с поддръжка на клъстери, което подобрява управляемостта.
Благодарение на REST интерфейсите прокси сървърите стават част от внедряването на мрежовата инфраструктура и отправна точка за инфраструктурата като код. REST интерфейсите, освен че подобряват управляемостта на прокситата, също така допринасят за опростяване на тяхното администриране. Външните интерфейси също са важна характеристика на програмируемите проксита и REST, като най-често срещаната форма на интерфейс.
В този момент програмируемостта се състои от три слоя: програмируеми основни модули, програмируема динамична логика и програмируеми външни интерфейси. Появата на прокси сървърни клъстери отразява промяната на перспективата в скалируемостта от разширяване на функционалността до разширяване на ресурсите (където потребителите могат да модулират функционалността в множество екземпляри, вместо да пишат монолитен скрипт). Появата на REST интерфейси осигурява техническата основа за самообслужване и управлявани услуги, които предоставят, напр. контролен панел за конфигуриране и контрол.
Облачна ера
Еволюцията на петото поколение прокси сървъри се движи от популярността и бързото развитие на облачните изчисления, носещи изискванията за еластичност, самообслужване, многонаемност, изолация и измерване.
Ако четвъртото поколение агенти е за системни администратори, петото поколение агенти е за облачни услуги. Като запазват напълно характеристиките на предишните поколения прокси софтуер, прокси сървърите от пето поколение стават готови за облак.
С разширяването на облачните изчисления до периферията, петото поколение прокси сървъри трябва да поддържат хетерогенен хардуер, хетерогенен софтуер и ниска консумация на енергия, за да оптимизират интегрирането на облака и периферията.
Петото поколение прокси сървъри също така показва напредък в програмируемостта: от основния модул, динамичната логика и външния интерфейс, които видяхме по-рано, до облачната способност, поддръжката за разпространение, многонаемността и измерването. Измерването е производно изискване на мултинаемането, което изисква изолация, от една страна, и че ресурсите могат да бъдат измерени с възможно най-малката детайлност, от друга.
Нека обобщим горната дискусия в табличен формат, където редовете отговарят на специфични изисквания, а колоните на прокси на различни етапи. За всеки етап от еволюцията ние също предоставяме типични примери или известен софтуер в скоби. Във всяка клетка използваме *, за да посочим дали такива възможности са налични и до каква степен (1-5, 5 за пълна поддръжка и 1 * за основна поддръжка).
SN | Изискване | Конфигурация (squid, httpd, nginx) | Език за конфигурация (lak, haproxy) | Поддръжка на скриптове (nginx+lua, nginx+js) | Групиране (конг, пратеник) | Облак (istio+envoy, linkerd, pipy) | Забележки |
1. | Свързване | * * * * * | * * * * * | * * * * * | * * * * * | * * * * * | Свързването в ерата на облака започна с технологии на ядрото като iptables и ebpf. Преди това имаше само процеси в потребителското пространство. |
2. | Надеждност | * * * * * | * * * * * | * * * * * | * * * * * | * * * * * | Надеждността винаги е била най-основната способност на прокси сървърите. |
3. | Висока производителност | * * * | * * * * | * * * * * | * * * * * | * * * * * | Ефективността включва пропускателна способност, латентност, процент грешки и отклонение от средната стойност. Общи показатели за латентност са P99, P999 и други. Ранният прокси софтуер има ефект на дълга опашка, така че индикаторите над P99 не са толкова добри, колкото за по-късен софтуер. Прокси с високопроизводителни скриптове често се представят по-добре от своите предшественици, когато връщат същото съдържание. Проксита, които избягват дълги опашки, са по-стабилни (с по-малко отклонение от средната стойност), като същевременно осигуряват същата производителност. |
4. | Гъвкавост | * | * * | * * * | * * * * | * * * * * | В сравнение с четвъртото поколение, прокситата от пето поколение значително подобряват възможностите за поддръжка на много протоколи, така че даваме на това поколение оценка от пет звезди. Освен това моделът на обработка от пето поколение може да се адаптира към различни протоколи и да предложи по-добра пригодност в сравнение с четвъртото поколение. |
5. | Мащабируемост | * | * * | * * * | * * * | * * * * | Подобно на гъвкавостта, прокси сървърите от 5-то поколение поддържат множество протоколи и предоставят лесни механизми за разширение за разширяване на основната функционалност или разработка на разширение на протокол на ниво персонализирано приложение (Слой 7), така че ние му даваме един звезда повече от 4-то поколение. |
6. | Хардуерна съвместимост | * * * * | * * * * | * * * * | * * * * | * * * * | Прокси сървърите, разработени на C или C++, обикновено имат по-добра хардуерна съвместимост и по-активна общност за мигриране на приложения към нови хардуерни архитектури. Прокситата, разработени с помощта на Rust, Go и Lua, мигрират относително бавно за хардуерна съвместимост. |
7. | Системна съвместимост | * * * | * * * | * * * * | * * * * | * * * * * | Системата включва основно два аспекта, единият е операционната система, а другият е облачната платформа. По отношение на съвместимостта на операционната система всяко поколение проксита е подобно. Въпреки това, по отношение на съвместимостта на облачната платформа, както четвъртото, така и петото поколение прокси сървъри осигуряват по-добра облачна съвместимост. За разлика от тях, значителната разлика между петото и четвъртото поколение се крие в способността им да поддържат многонаемане. |
8. | Лесно управление | * * | * * | * * | * * * | * * * * | Лекотата на управление е функция на работата на системата & администраторски роли. Първото и второто поколение използват главно конфигурационни файлове, базирани на използването на инструменти за управление на конфигурацията за постигане на автоматично и пакетно управление. В третото поколение, в допълнение към управлението на конфигурационните файлове, трябва допълнително да управляваме скриптовите файлове. Но по същество няма съществена разлика от първото и второто поколение по отношение на лекотата на управление. Четвъртото поколение предоставя REST интерфейси, което значително подобрява лекотата на управление. В допълнение към REST, петото поколение прокси сървъри обикновено предоставя базирана на облак контролна равнина за управление на прокси сървъри. Той също така предоставя множество външни интерфейси, за да отговори на други изисквания за управление, като мониторинг, одит и статистика. |
9. | Лекота на използване | * | * | * | * * | * * * | Основните потребители на първите три поколения проксита са ops & системни администратори. През четвъртото поколение администраторите започнаха да предоставят някои функции на потребителите и започна да се появява моделът като услуга. Петото поколение взема предвид повече потребителски сценарии и предоставя повече възможности за клиенти. |
10. | Лекота на разработка | * | * * | * * * | * * * * | * * * * * | Развитието около прокситата включва два аспекта. Единият е вътре в проксито, целящ да постигне функционалността; другият е извън проксито, целящ да постигне способността за управление на проксито. Първите три поколения осигуряват интерфейс за вътрешно развитие. Последните две поколения предоставят както вътрешни, така и външни интерфейси. Значителното подобрение, донесено от петото поколение в сравнение с четвъртото поколение, е облачният интерфейс. |
11. | Основният интерфейс е програмируем | * | * | * | * | * | Всяко поколение прокси предоставя възможност за разширяване на основните интерфейси, но тези интерфейси са на твърде ниско ниво и трудни за овладяване. |
12. | Разширението на функционалността е програмируемо | * | * * | * * * | * * * * | * * * * * | Предоставянето на възможност за по-ефективно разширяване на функциите е част от процеса, който се подобрява с всяко поколение проксита. Това е основната метрика на програмируемите проксита. |
13. | Разширенията на протокола са програмируеми | * * | * * * | Първите три поколения са основно за единичен протокол или фиксирани протоколи. Започвайки с четвъртото поколение, потребителите започнаха да търсят поддръжка за множество протоколи и персонализирани протоколи. В петото поколение разширението на протокола се счита за основна възможност в дизайна. | |||
14. | Модулен скрипт | * * * | * * * * | * * * * | Прокситата от трето поколение започват да обръщат повече внимание на структурирането на скрипта. Четвъртото и петото поколение се опитват да позволят по-структурирано програмиране, като опита на Envoy да осигури многоезична поддръжка чрез WASM; Pipy въвежда високопроизводителни JS скриптове за по-добро структуриране | ||
15. | Управлението на конфигурацията е програмируемо | * * | * * * | Първите три поколения прокси конфигурация са насочени главно към персонала за управление на операциите, а външните инструменти за управление на конфигурацията се основават на тази предпоставка. Четвъртото поколение поддържа REST интерфейси за управление. Петото поколение допълнително предоставя стандартен облачен интерфейс за управление на конфигурацията. | |||
16. | Разширенията на ресурсите са програмируеми | * | * | * | * * | * * * * | За първите три поколения разширяването на прокси капацитета имаше за цел главно да увеличи броя на нишките или процесите. Четвъртото поколение предоставя възможност за мащабиране на процеси, известна като способност за клъстериране. Въз основа на това, петото поколение предоставя от една страна възможности за хоризонтално разширение, от друга страна възможности при ограничени ресурси за поддържане на по-фино измерване и фактуриране. Тоест, той не само поддържа постепенно мащабиране, но също така предоставя възможност за намаляване на мащаба. Освен това всички тези възможности предоставят програмни интерфейси. |
17. | Програмируемо разширение на клиента | * * * | Облакът е нещо, което се появи по същото време като четвъртото поколение прокси, а мулти-наемането, като основна характеристика на облака, не се поддържа добре в четвъртото поколение. Петото поколение е проектирано на основата на облачните изчисления, като обмисля и предоставя на наемателите възможността да програмират свои собствени разширения. |
Редове от #11 до #17 в таблицата по-горе са специфичните аспекти на програмируем прокси. Тези аспекти също представляват отговора на въпроса защо да използваме програмируем прокси:
Обобщение
В тази статия се опитахме да дадем нашия отговор на това какво е програмируем прокси. За тази цел започнахме от определението какво е прокси и какви са основните му характеристики. След това разширихме нашата дискусия, за да включим еволюционния прокси, който премина, обяснявайки характеристиките и функционалностите, които бяха добавени на всеки етап. И накрая, ние обобщаваме нашето обсъждане на прокси функциите, като ги разделяме на 17 различни категории и класираме всяко поколение прокси. Тази класификация ни позволи да идентифицираме ключовите характеристики и атрибути, които са необходими, за да може проксито да бъде етикетирано като програмируемо.
Всичко за авторите
Cai Shu
Покажи повечеПокажи по-малкоAli Naqvi
Покажи повечеПокажи по-малко
