[Высокая производительность, Разработка под iOS, Разработка мобильных приложений, Разработка под Android, Микросервисы] Envoy как универсальный сетевой примитив
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
В октябре прошлого года мои коллеги представили на EnvoyCon доклад "Построение гибкой подсистемы компрессии в Envoy". Вот он ниже
Извините, данный ресурс не поддреживается. :(
Судя по статистике сегодняшней статьи от SergeAx, тема компрессии сетевого трафика оказалась интересной многим. В связи с чем я немедленно возжелал вселенской славы и решил кратко пересказать содержание доклада. Тем более, что он не только о компрессии, но и том, как можно упростить сопровождение сетевой подсистемы как backend'а, так и мобильного frontend'а.
Я не стал полностью "новелизировать" видео доклада, а только ту часть, которую озвучил Хосе Ниньо. Она заинтересует больше людей.
Для начала о том, что такое Envoy.
В описании на официальном сайте значится следующее. Envoy — это высокопроизводительный распределённый прокси-сервер, спроектированный как для отдельных сервисов и приложений, так и для работы в качестве коммуникационной шины в микросервисной архитектуре, то есть в сервис-мэшах, с учётом уроков вынесенных из эксплуатации NGINX, HAProxy… И так далее.
Принцип работы прокси-сервера очень прост: клиент устанавливает сетевое соединение не напрямую с сервисом, а через прокси-сервер, который в случае необходимости, например, сжимает проходящий через него сетевой трафик. Или оконечивает TLS. Или, не разрывая соединения с клиентом, пытается повторно соединиться с временно недоступным сервисом. Или, если совсем всё плохо, соединиться с резервным сервисом. И так далее.
Главное в том, что подобная схема заметно снижает сложность кода и клиента, и сервиса. Особенно сервиса.
Однако, если перед клиентом поставить ещё один прокси-сервер, как на картинке ниже, то и его код упростится так же сильно. Это основа работы сервис-мэшей — вся сложность, необходимая для надёжной и эффективной коммуникации, включая аппаратную акселерацию, вынесена из сервисов и изолирована в прокси.
Таким образом общая архитектура в очень многих компаниях всё чаще начинает выглядеть примерно вот так.
Мобильный клиент общается с граничным прокси (Edge), который решает, куда отправлять клиентские запросы дальше, попутно балансируя нагрузку на сервера. Сервисы получают запросы от Edge не напрямую, а через вспомогательные прокси (Sidecar). Далее, сервисы формируют ответы, опционально пообщавшись друг с другом, и отсылают их к Edge.
В этой схеме, тем не менее, есть один неприятный нюанс — мобильный клиент сильно обособлен. Он участвует в сетевой коммуникации, но его сетевой стек значительно отличается от стека микросервисов в сторону усложенения. То есть код мобильного приложения требует дополнительных отличных от нуля усилий по сопровождению, если мы хотим иметь в клиенте компрессию, декомпрессию, повторные соединения по таймаутам и так далее.
Кроме того, таких мобильных клиентов может быть несколько, если хочется поддерживать не только Android. В общем, ребята в Lyft сообразили, что было бы неплохо превратить мобильные клиенты в обычные узлы сервис-мэша и унифицировать сетевой стек, используя Envoy как универсальный сетевой примитив. Тогда экспериментировать с алгоритмами компрессии, политиками реконнекта и т.д. нужно будет только в одном месте, а не в трёх. При этом
даже сетевой код трогать не придётся, достаточно доставить по месту употребления нужную конфигурацию, а код Envoy всё сделает сам не разрывая текущих соединений.
Так появился проект Envoy Mobile, который представляет собой байндинги на Java, Kotlin, Swift, Objective-C к Envoy. А тот уже линкуется к мобильному приложению как нативная библиотека.
Тогда задача уменьшения объёма трафика описанная в статье от FunCorp, могла бы быть решена примерно как на картинке ниже (если поменять местами компрессор и декомпрессор, и заменить response на request). То есть даже без необходимости установки обновлений на телефонах.
Можно пойти дальше, и ввести двустороннюю компрессию
В общем, поле для экспериментов в такой схеме сильно увеличивается в размере.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка под iOS, IT-компании] Apple попросила разработчиков вернуть DTK с чипом Apple A12Z в обмен на купон в $200. Оборудование они получили за $500
- [Разработка под iOS, Разработка мобильных приложений, Разработка под Android] Чего ждать от коробочных приложений?
- [Высокая производительность, Программирование, Java, Конференции] JPoint и Joker: какие доклады запомнились мне больше всего
- [Браузеры] Vivaldi 3.6 для Android — Внешние связи
- [Интерфейсы, Промышленное программирование, Управление разработкой, Микросервисы] Энтерпрайз, который выжил. Доклад в Яндексе
- [Разработка мобильных приложений, Тестирование мобильных приложений, Управление проектами, Управление продуктом] Как распознавание паспортов замедлило пользователей, покупающих билеты: история провала фичи
- [Программирование, Разработка под Android, Flutter] Flutter ListView и ScrollPhysics: Детальный взгляд (перевод)
- [Разработка под iOS, Разработка мобильных приложений, Разработка под Android, Аналитика мобильных приложений] Как мы просто сократили объем входящего в дата-центр трафика на 70%
- [Программирование, Java, ООП, Функциональное программирование] Java Optional не такой уж очевидный (перевод)
- [Open source, DIY или Сделай сам, Микросервисы, Kubernetes] Новая версия нашего самописного плагина, который скачали 250 тысяч раз
Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_razrabotka_pod_ios (Разработка под iOS), #_razrabotka_mobilnyh_prilozhenij (Разработка мобильных приложений), #_razrabotka_pod_android (Разработка под Android), #_mikroservisy (Микросервисы), #_compression, #_datatsentry (дата-центры), #_trafik (трафик), #_envoy_proxy, #_backend, #_ios, #_android, #_service_mesh, #_microservices, #_vysokaja_proizvoditelnost (
Высокая производительность
), #_razrabotka_pod_ios (
Разработка под iOS
), #_razrabotka_mobilnyh_prilozhenij (
Разработка мобильных приложений
), #_razrabotka_pod_android (
Разработка под Android
), #_mikroservisy (
Микросервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 20-Май 05:28
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
В октябре прошлого года мои коллеги представили на EnvoyCon доклад "Построение гибкой подсистемы компрессии в Envoy". Вот он ниже Извините, данный ресурс не поддреживается. :( Судя по статистике сегодняшней статьи от SergeAx, тема компрессии сетевого трафика оказалась интересной многим. В связи с чем я немедленно возжелал вселенской славы и решил кратко пересказать содержание доклада. Тем более, что он не только о компрессии, но и том, как можно упростить сопровождение сетевой подсистемы как backend'а, так и мобильного frontend'а. Я не стал полностью "новелизировать" видео доклада, а только ту часть, которую озвучил Хосе Ниньо. Она заинтересует больше людей. Для начала о том, что такое Envoy. В описании на официальном сайте значится следующее. Envoy — это высокопроизводительный распределённый прокси-сервер, спроектированный как для отдельных сервисов и приложений, так и для работы в качестве коммуникационной шины в микросервисной архитектуре, то есть в сервис-мэшах, с учётом уроков вынесенных из эксплуатации NGINX, HAProxy… И так далее.  Принцип работы прокси-сервера очень прост: клиент устанавливает сетевое соединение не напрямую с сервисом, а через прокси-сервер, который в случае необходимости, например, сжимает проходящий через него сетевой трафик. Или оконечивает TLS. Или, не разрывая соединения с клиентом, пытается повторно соединиться с временно недоступным сервисом. Или, если совсем всё плохо, соединиться с резервным сервисом. И так далее. Главное в том, что подобная схема заметно снижает сложность кода и клиента, и сервиса. Особенно сервиса.  Однако, если перед клиентом поставить ещё один прокси-сервер, как на картинке ниже, то и его код упростится так же сильно. Это основа работы сервис-мэшей — вся сложность, необходимая для надёжной и эффективной коммуникации, включая аппаратную акселерацию, вынесена из сервисов и изолирована в прокси.  Таким образом общая архитектура в очень многих компаниях всё чаще начинает выглядеть примерно вот так.  Мобильный клиент общается с граничным прокси (Edge), который решает, куда отправлять клиентские запросы дальше, попутно балансируя нагрузку на сервера. Сервисы получают запросы от Edge не напрямую, а через вспомогательные прокси (Sidecar). Далее, сервисы формируют ответы, опционально пообщавшись друг с другом, и отсылают их к Edge. В этой схеме, тем не менее, есть один неприятный нюанс — мобильный клиент сильно обособлен. Он участвует в сетевой коммуникации, но его сетевой стек значительно отличается от стека микросервисов в сторону усложенения. То есть код мобильного приложения требует дополнительных отличных от нуля усилий по сопровождению, если мы хотим иметь в клиенте компрессию, декомпрессию, повторные соединения по таймаутам и так далее.  Кроме того, таких мобильных клиентов может быть несколько, если хочется поддерживать не только Android. В общем, ребята в Lyft сообразили, что было бы неплохо превратить мобильные клиенты в обычные узлы сервис-мэша и унифицировать сетевой стек, используя Envoy как универсальный сетевой примитив. Тогда экспериментировать с алгоритмами компрессии, политиками реконнекта и т.д. нужно будет только в одном месте, а не в трёх. При этом даже сетевой код трогать не придётся, достаточно доставить по месту употребления нужную конфигурацию, а код Envoy всё сделает сам не разрывая текущих соединений.  Так появился проект Envoy Mobile, который представляет собой байндинги на Java, Kotlin, Swift, Objective-C к Envoy. А тот уже линкуется к мобильному приложению как нативная библиотека. Тогда задача уменьшения объёма трафика описанная в статье от FunCorp, могла бы быть решена примерно как на картинке ниже (если поменять местами компрессор и декомпрессор, и заменить response на request). То есть даже без необходимости установки обновлений на телефонах.  Можно пойти дальше, и ввести двустороннюю компрессию  В общем, поле для экспериментов в такой схеме сильно увеличивается в размере. =========== Источник: habr.com =========== Похожие новости:
Высокая производительность ), #_razrabotka_pod_ios ( Разработка под iOS ), #_razrabotka_mobilnyh_prilozhenij ( Разработка мобильных приложений ), #_razrabotka_pod_android ( Разработка под Android ), #_mikroservisy ( Микросервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 20-Май 05:28
Часовой пояс: UTC + 5