Компании Google (https://cloudplatform.googleblog.com/2017/05/istio-modern-ap... IBM (https://developer.ibm.com/dwblog/2017/istio/) и Lyft представили новый открытый проект Istio (https://istio.io/), в рамках которого объединили свои наработки в области координации работы микросервисов. О намерении принять участие в развитии проекта также объявили (https://blog.openshift.com/red-hat-istio-launch/) компании Red Hat, Datawire, Pivotal и Tigera. Код компонентов проекта открыт (https://github.com/istio/) под лицензией Apache 2.0.
Концепция микросервисов подразумевает разбиение сложных монолитных приложений на набор обособленных микросервисов, каждый из которых берёт на себя определённую функциональность приложения. Микросервисы могут работать параллельно, адаптируясь к изменению нагрузки. Таким образом приложение реализуется в виде сети из связанных между собой микросервисов, каждый из которых запускается в отдельном контейнере. Для управления контейнерами предлагается использовать средства оркестровки, подобные Kubernetes (https://www.opennet.dev/opennews/art.shtml?num=46278), Cloud Foundry и Mesos.
Istio представляет собой слой абстракции, работающий поверх средств оркестровки контейнеров, и выполняет задачи по распределению нагрузки по микросервисам, организации аутентификации, разграничению доступа к микросервисам, защищённого взаимодействия между микросервисами, мониторинга и балансировки нагрузки. При помощи Istio набор запущенных в разных контейнерах микросервисов обретает слаженную функциональность и может работать как единое целое.Основные составные части Istio:
- Envoy - прокси для обработки входящго и исходящего трафика между сервисами в кластере, а также обращений к внешним сервисам. Envoy позволяет организовать взаимодействие между микросервисами, составляющими приложение, поверх сети, предоставляемой нижележащей платформой для управления контейнерами. Прокси образуют mesh-сеть из микросервисов, предоставляя такие функции, как обнаружение новых сервисов, маршрутизация потоков данных, построение цепочки обработки запроса и сбор данных телеметрии;
- Mixer - представляет средства для централизованного управления прокси и микросервисами, обеспечивая применение ACL, ограничений пропускной способности, квот, аутентификации, трассировки запросов и накопления сведений о телеметрии.- Manager - управляющий интерфейс, позволяет на лету изменять настройки и управлять работой компонентов Envoy и Mixer.
Особенности платформы:- Автоматическая балансировка трафика HTTP, gRPC и TCP;
- Тонкое управление поведением трафика в зависимости от правил маршрутизации, обеспечения отказоустойчивости и возникновения/симулирования (https://ru.wikipedia.org/wiki/%D0%92%D0%... сбоев;- Подключаемый слой для применения политик и API для управления доступом, ограничением пропускной способности и квотами;
- Автоматический сбор метрик, логов и трассировок для всего входящего и исходящего трафика в кластере;
- Организация защищённых каналов связи между сервисами с аутентификацией каждого сервиса в кластере.В отличие от недавно представленной похожей платформы Linkerd (https://linkerd.io/), Istio не ограничивается организацией сетевого взавимодействия и дополнительно предоставляет такие возможности, как аутентификация и обеспечение правил доступа (policy control (https://istio.io/docs/concepts/policy-and-control/mixer.html)). При этом Istio пока поддерживает только Kubernetes, в то время как Linkerd доступен для Kubernetes, DC/OS (https://www.opennet.dev/opennews/art.shtml?num=44276), Mesos и Docker.
URL: https://cloudplatform.googleblog.com/2017/05/istio-modern-ap...
Новость: http://www.opennet.dev/opennews/art.shtml?num=46598
Круто! Да еще и на Go )
Вот так оно, Linkerd много лет парился и создавал стартап, пытающийся повторить платформы микросервисов Google, Twitter и Yahoo. Но тут пришли Google с IBM, открыли часть своих разработок и растоптали все усилия Linkerd.
«Linkerd много лет парился»: много — это сколько, если анонс первого их Open Source-релиза (0.1.0) состоялся в феврале 2016 года (https://blog.buoyant.io/2016/02/18/linkerd-twitter-style-ope...?«открыли часть своих разработок» — ключевым звеном стал Envoy, который разработан совсем не Google и не IBM.
Зато Linkerd уже в CNCF и у них есть пара солидных клиентов. Да и здоровая конкуренция в этом молодом направлении не повредит.
На POWER7 заработает? А то железо утилизировать надо
насколько мощное?
https://blog.komand.com/microservices-please-dont
А в google то и не знали
Хорошая иллюстация к Step 4: Disappointment
https://blog.daftcode.pl/hype-driven-development-3469fc2e9b2...
Почему только к четвертому шагу? Там сразу же есть и пятый, то есть трезвые размышления/рекомендации на тему: кому и при каких условиях нужны микросервисы.
Там рекомендации вида "если у вас ни черта нет архитектуры и вы не хотите о ней думать то миксросервисы вам не помогут".По факту же - я бы сказал, что первый фпункт самый существенный аргумент в пользу микросервисов. Если архитектура принуждает писать лучший код - это жирнейший плюс. Да, можно и добровольно... Только выходит редко, всегда найдётся миллион оснований сделать вот для данного конкретного случая маленькое исключение... со всеми вытекающими. А вот если "наляпать абы как" просто не ложится в платформу - как правило, резко находятся возможности сделать по-людски.
Кубернетс поверх кубернетса
И кубернетсом погоняет
Погонщики на галере!
Эта платформа не «для управления микросервисами», а для обеспечения разных видов взаимодействия между ними.
P.S. Месяц назад переводил статью «Что такое service mesh» от авторов Linkerd: https://habrahabr.ru/company/flant/blog/327536/ (англоязычный оригинал здесь: https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-....
Благодарю за перевод!
Очень хорошая статья.
Вы не правы. Istio несколько шире, чем Linkerd, поэтому официально преподносится как платформа для "developing and managing microservices". Связь между сервисами там лишь одна из многих функций.
Микросевисами должна рулить микроплаформа.
на базе микро ос, написанной в микрофирме...с символичным микроназванием... например в микрософт :)
Вот только со времён ДОСа у них плохо получалось с микро* что-то там. МиБы жрались как не в себя.
Ты наверное хотел сказать "со времен висты" или хотя бы "со времен win2k", так как до этого системные требования винды и офиса были весьма скромными.
>весьма скромнымиУ тебя весьма нескромные понятия о скромности.
3.1 весила что-то около 7-8МиБ.
А 95 и вовсе была на 15-20 1.44 дискетах.
И это во времена винтов в сотни МиБ.
>Ты наверное хотел сказатьТак что нет. Я хотел сказать именно то, что сказал.
Сравнивать надо с альтернативами. Мелкомягкие в то время смогли сделать win 3.x и xenix, которые работали на процессорах ниже 80386, а мало что умеющий тогда linux требовал не меньше 80386. Во времена win95 его прямой конкурент os/2 warp имел примерно те же требования. Также ко времени выхода win95 компакт диски уже получили широкое распространение и такие нескромные по твоему мнению 30 метров инсталляции помещались где-то в дальнем уголке стандартного 650mb cd-rom.
работающей на микроволновке..
А писать их должны микроцефалы.
Не, пока что микроцефалы здесь пишут только кто что кому должен.
Порцию попозаживина этому писателю микросервисов.
это что-то вроде erlang?
Почитаешь про такое и десять раз подумаешь о том, что хорошо что оставил свой монолит )))
hello world?
Классическая концепция монструозных обработчиков запросов "всё в одном вечноживущем (теоретически, на практике это хромает) процессе" привела к рождению тонн уродцев. Нет бы сразу на PHP посмотреть, который реализовал не монолитную, а позапросную модель. Там по сути каждый модуль - модное хипстерское слово "микросервис".