Какво е Service Mesh?

Здравейте отново!.. В преддвери на старта на курса „Архитект на софтуер“ подготвихме още един полезен превод.

Service Mesh – това е конфигурируем инфраструктурен слой с ниска латентност, необходим за обработка на голям обем мрежови междупроцесни комуникации между интерфейсите на приложенията (API). Service Mesh осигурява бърза, надеждна и безопасна комуникация между контейнеризираните и често ефимерни услуги в инфраструктурата на приложенията. Service Mesh предлага функции като откриване на услуги, баланс на натоварването, криптиране, прозрачност, проследимост, удостоверяване и авторизация, както и поддръжка на шаблона за автоматично прекъсване (circuit breaker).
Service Mesh обикновено се реализира чрез предоставяне на прокси екземпляр за всеки екземпляр на услуга, наречен Sidecar. Sidecar обработват комуникациите между услугите, извършват мониторинг и отстраняват проблеми със сигурността, т.е. всичко, което може да бъде абстрахирано от отделните услуги. По този начин разработчиците могат да пишат, поддържат и обслужват кода на приложението в услугите, а системните администратори могат да работят с Service Mesh и да стартират приложението.

Istio от Google, IBM и Lyft, в момента е най-известната архитектура на Service Mesh. А Kubernetes, който първоначално е разработван в Google, сега е единственият фреймворк за оркестрация на контейнери, който се поддържа от Istio. Доставчиците се опитват да създадат търговски поддържани версии на Istio. Интересно е какво ново могат да внесат в проекта с отворен код.

Въпреки това Istio не е единственият вариант, тъй като се разработват и други реализации на Service Mesh. Шаблонът sidecar proxy е най-популярната реализация, както може да се съди по проектите Buoyant, HashiCorp, Solo.io и други. Съществуват и алтернативни архитектури: технологичният инструментариум на Netflix е един от подходите, при който функционалността на Service Mesh се реализира чрез библиотеки Ribbon, Hysterix, Eureka, Archaius, както и платформи като Azure Service Fabric.

Service Mesh също така има собствена терминология за компонентите на услугите и функциите:

• Фреймворк за оркестрация на контейнери. С увеличаването на броя на контейнерите в инфраструктурата на приложението, възниква нуждата от отделен инструмент за наблюдение и управление на контейнерите – фреймворк за оркестрация на контейнери. Kubernetes зае твърде тясно тази ниша, до такава степен, че дори основните му конкуренти Docker Swarm и Mesosphere DC/OS предлагат интеграция с Kubernetes като алтернатива.
• Услуги и инстанции (Kubernetes подове). Инстанция е една единствена стартирана копия на микросervice. Понякога една инстанция е един контейнер. В Kubernetes инстанцията се състои от малка група независими контейнери, наречени подове. Клиентите рядко се обръщат директно към инстанцията или пода, по-често те се обръщат към услугата, която представлява набор от идентични мащабируеми и отказоустойчиви инстанции или подове (реплики).
• Пр Proxy на Sidecar. Пр Proxy на Sidecar работи с една инстанция или под. Смисълът на Пр Proxy на Sidecar е да насочва или проксира трафика, идващ от контейнера, с който работи, и обратно. Sidecar взаимодействат с други Пр Proxy на Sidecar и се управляват от фреймворка за оркестрация. Много реализации на Service Mesh използват Пр Proxy на Sidecar за прихващане и управление на целия входящ и изходящ трафик на инстанцията или пода.
• Откриване на услуги. Когато инстанцията трябва да взаимодейства с друга услуга, тя трябва да намери (да открие) работеща и налична инстанция на друга услуга. Обикновено инстанцията извършва търсенето чрез DNS. Фреймворкът за оркестрация на контейнери поддържа списък на инстанции, готови да получават заявки, и предоставя интерфейс за DNS запитвания.
• Балансировка на натоварването. Повечето фреймворкове за оркестрация на контейнери осигуряват балансировка на натоварването на 4-то ниво (транспортно). Service Mesh реализира по-сложна балансировка на натоварването на 7-мо ниво (приложно), богата на алгоритми и по-ефективна в управлението на трафика. Параметрите на балансировката на натоварването могат да бъдат променяни чрез API, което позволява оркестрация на синьо-зелено или канарейско разгръщане.
• Шифриране. Service Mesh може да криптира и декриптира заявки и отговори, освобождавайки услугите от това бреме. Service Mesh също може да повиши ефективността, като приоритизира или повторно използва съществуващи постоянни връзки, което намалява необходимостта от скъпи изчисления за създаване на нови връзки. Най-разпространената реализация на криптиране на трафика е mutual TLS (mTLS), където инфраструктурата на публичните ключове (PKI) генерира и разпространява сертификати и ключове за използване в Sidecar Proxy.
• Аутентификация и авторизация. Service Mesh може да авторизира и аутентифицира заявки, направени извън или вътре в приложението, изпращайки на инстанции само валидирани заявки.
• Поддръжка на шаблон за автоматично изключване. Service Mesh поддържа шаблон за автоматично изключване, който изолира нездравословни инстанции и след това постепенно ги връща в пул от здрави инстанции, когато е необходимо.

Частта от приложението Service Mesh, която управлява мрежовия трафик между инстанциите, се нарича Data Plane. Създаването и разполагането на конфигурацията, която управлява поведението Data Plane, се извършва с помощта на отделен Control Plane. Control Plane обикновено включва или е проектирана да се свързва с API, CLI или GUI за управление на приложението.

Control Plane в Service Mesh разпределя конфигурацията между Sidecar Proxy и Data Plane.

Често архитектурата на Service Mesh се прилага за решаване на сложни оперативни задачи с помощта на контейнери и микросервизи. Пионери в тази област микросервизи са компании като Lyft, Netflix и Twitter, които предоставят стабилно работещи услуги на милиони потребители по целия свят. (Тук можете да се запознаете с подробно описание на някои архитектурни задачи, с които се е сблъскал Netflix). За по-малко взискателни приложения вероятно ще бъде достатъчна по-проста архитектура.

Архитектурата на Service Mesh едва ли някога ще стане отговор на всички въпроси, свързани с работата на приложенията и тяхното доставяне. Архитектите и разработчиците разполагат с огромен арсенал от инструменти, и само един от тях — чукът, който сред многото задачи трябва да решава само едно – забиването на гвоздеи. Microservices Reference Architecture от NGINX, например, включва няколко различни модела, които предлагат непрекъснат спектър от подходи към решаване на задачи с помощта на микросервизи.

Елементите, които се обединяват в архитектурата Service Mesh, като NGINX, контейнери, Kubernetes и микросервизи като архитектурен подход, могат да бъдат използвани с не по-малка производителност и в реализации без Service Mesh. Например, Istio е разработен като пълноценна архитектура Service Mesh, но модулността показва, че разработчиците могат да избират и прилагат само необходимите им компоненти на технологиите. Имайки това предвид, е необходимо да се формира ясно разбиране за концепцията на Service Mesh, дори ако не сте сигурни, че някога ще можете изцяло да я реализирате в приложението си.

Модулни монолити и DDD

Източник: habr.com