Какво е Service Mesh?

Здравейте отново!.. В навечерието на началото на курса "Софтуерен архитект" Подготвили сме още един полезен превод.

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

Istio от Google, IBM и Lyft в момента е най-известната мрежова архитектура за услуги. И 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 Pods). Екземплярът е едно работещо копие на микроуслуга. Понякога един екземпляр е един контейнер. В Kubernetes екземплярът се състои от малка група независими контейнери, наречени pod. Клиентите рядко имат директен достъп до инстанция или pod; по-често те имат достъп до услуга, която е набор от идентични, мащабируеми и устойчиви на грешки инстанции или pod (реплики).
• Sidecar Proxy. Sidecar Proxy работи с един екземпляр или pod. Целта на Sidecar Proxy е да насочва или прокси трафик, идващ от контейнера, с който работи, и да връща трафик. Sidecar взаимодейства с други проксита Sidecar и се управлява от рамка за оркестрация. Много внедрявания на Service Mesh използват Sidecar Proxy за прихващане и управление на целия трафик в и извън екземпляр или pod.
• Откриване на услугата. Когато един екземпляр трябва да комуникира с друга услуга, той трябва да намери (открие) здрав и наличен екземпляр на другата услуга. Обикновено екземплярът извършва DNS търсения. Рамката за оркестрация на контейнера поддържа списък с екземпляри, които са готови да получават заявки, и предоставя интерфейс за DNS заявки.
• Балансиране на натоварването. Повечето рамки за оркестриране на контейнери осигуряват балансиране на натоварването на слой 4 (транспорт). Service Mesh прилага по-сложно балансиране на натоварването на ниво 7 (ниво на приложение), богато на алгоритми и по-ефективно при управление на трафика. Настройките за балансиране на натоварването могат да се променят с помощта на API, което ви позволява да организирате синьо-зелено или канарче внедряване.
• Шифрование. Service Mesh може да шифрова и дешифрира заявки и отговори, премахвайки това бреме от услугите. Service Mesh може също така да подобри производителността чрез приоритизиране или повторно използване на съществуващи постоянни връзки, намалявайки необходимостта от скъпи изчисления за създаване на нови връзки. Най-често срещаното прилагане на криптиране на трафика е взаимен TLS (mTLS), където инфраструктура с публичен ключ (PKI) генерира и разпространява сертификати и ключове за използване от Sidecar Proxy.
• Удостоверяване и оторизация. Service Mesh може да оторизира и удостоверява заявки, направени отвън или вътре в приложението, като изпраща само валидирани заявки до инстанции.
• Поддръжка на шаблон за автоматично изключване. Service Mesh поддържа модел на автоматично изключване, който изолира нездравословните екземпляри и след това постепенно ги връща в пула от здрави екземпляри, когато е необходимо.

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

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

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

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

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

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

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