В сегодняшнем выпуске Semaphore Uncut ведущий Дарко поговорил с Мэттом Кляйном, инженером-программистом Lyft. Мэтт является архитектором Посланника Lyft, одного из самых популярных прокси-серверов с открытым исходным кодом, который скоро выпустит новую мобильную версию.

Что побудило Мэтта и команду Lyft создать Envoy и что дальше с приложением с открытым исходным кодом? Послушайте выпуск, чтобы узнать ответы на эти и другие вопросы. Затем ознакомьтесь с некоторыми из наших любимых частей разговора в основных моментах эпизода ниже.

Вы также можете получить Semaphore Uncut в Apple Podcasts, Spotify, Google Podcasts, Stitcher и т. д.

Нравится этот эпизод? Обязательно оставьте ⭐️⭐️⭐️⭐️⭐️ отзыв в выбранном вами проигрывателе подкастов и поделитесь им с друзьями!

Основные моменты из этого эпизода

Дарко Фабижан (00:02): Добро пожаловать в Semaphore Uncut. Сегодня с нами Мэтт Кляйн. Мэтт, большое спасибо, что присоединился к нам. Пожалуйста, представьтесь.

Мэтт Кляйн: Спасибо, что пригласили меня. Меня зовут Мэтт Кляйн. Я инженер-программист в Lyft, где проработал последние четыре с половиной года. Почти всю свою карьеру я посвятил низкоуровневым технологиям, таким как гипервизоры, операционные системы, распределенные системы и сетевая производительность.

Во время работы в Lyft я работал над сетевой технологией с открытым исходным кодом под названием Envoy, которая стала довольно популярной. В настоящее время я трачу примерно половину своего времени на решение связанных с Lyft проблем, связанных с надежностью, сетями и распределенными системами. Остальные 50% своего времени я трачу на отраслевую работу с Envoy, управление открытым исходным кодом и тому подобное.

Что такое посланник?

Дарко: Хорошо, отлично. И можете ли вы дать нам пояснение по поводу Посланника?

Мэтт: Envoy — это программный балансировщик нагрузки или программный сетевой прокси. На высоком уровне это часть программного обеспечения, которое будет принимать сетевые запросы, которые могут быть соединениями протокола управления передачей (TCP) или HTTP-запросами. Он будет делать различные вещи с этими соединениями или запросами, когда они проходят через этот прокси. Это может быть наблюдаемость, балансировка нагрузки или такие вещи, как тайм-ауты и автоматические выключатели.

Существует множество вещей, которые может делать сетевой прокси. Для тех, кто слышал о других программных прокси, таких как NGNIX или HAProxy, Envoy похож.

Почему вы создали Envoy?

Дарко: Когда вы только начинали проект, была ли у вас какая-то конкретная болевая точка, которую вы хотели решить? Потому что Envoy решает целый класс проблем.

Мэтт: Основная проблема, которую мы пытались решить с помощью Envoy, была связана с наблюдаемостью. Четыре с половиной года назад Lyft полностью базировался на Amazon Web Services. Мы использовали эластичные балансировщики нагрузки для балансировки нагрузки. А четыре с половиной года назад ELB в то время не поддерживали перцентильные метрики задержки.

В то время ELB и CloudWatch не поддерживали возможность наблюдения за задержкой P50 или задержкой P99, что большинство современных разработчиков действительно считают само собой разумеющимся из системы наблюдения за сетью.

В общем, Envoy был черным ящиком. Было очень трудно понять, что происходит. Первоначальный вариант использования Envoy был в качестве пограничного прокси, и он должен был предоставлять более подробные журналы, статистику и метрики, чтобы разработчики могли понять, что на самом деле происходит.

И это было основано на моем опыте в Твиттере. Там я работал над проприетарной прокси-системой, которая предоставляла аналогичные функции, такие как расширенная наблюдаемость. Большинство решений, существовавших в то время, не поддерживали эти типы функций.

Ты прав. Сегодня Envoy поддерживает совершенно невероятное количество функций, но в то время основное внимание уделялось наблюдаемости.

От монолита к микросервисам

Дарко: (05:21) Да, когда мы переходили от наших монолитов к архитектуре микросервисов, наблюдаемость была чем-то, что поразило нас из ниоткуда. Ранее мы смогли многое узнать о нашем монолите. Однако при переходе на микросервисы появляется тот слой сети, который становится вездесущим.

Мэтт: Это очень интересно. Я думаю, что вы сейчас видите, что вокруг сервисной сетки было много шума. Кроме того, существует много негативных отзывов о сложности сервисной сетки. Честно говоря, если организация намерена перейти на архитектуру микросервисов, ей придется решить ряд проблем. Они сложны, и они в основном вращаются вокруг сетей и наблюдаемости. Потенциально вы можете решить их, написав кучу кода, поместив его в библиотеку и написав его в каждый сервис. Или вы можете попробовать посмотреть на шаблон коляски.

Дарко: Да, и, может быть, в монолите вам придется решить ее один раз с точки зрения простых вещей, таких как тайм-ауты, повторные попытки и все такое. Таким образом, это может быть одна библиотека с одной кодовой базой. А с микросервисами вам нужно решить эту проблему на разных языках и в разных местах и ​​обновить эту библиотеку в разных местах.

Мэтт: Да, и если вы посмотрите на компании, которые возглавили некоторые работы по архитектуре микросервисов, то, вероятно, это будут Amazon, Twitter, Netflix и другие компании, которые росли в то время, когда они в основном использовали Java.

Но большинство современных компаний, хорошо это или плохо, я называю полиглотами. У них есть несколько языков в разработке, таких как Java, Go, Rust и C++, и тогда им приходится выбирать между повторной реализацией и попыткой нормализовать все эти вещи на каждом языке, или они могут попытаться использовать какой-то клиентский подход. прокси с балансировкой нагрузки.

Но в конце концов, проблемы должны быть решены. Нет простого выхода. Один из вариантов — остаться с монолитом, и я говорю всем оставаться с монолитом как можно дольше.

Когда монолит не работает (как правило, из соображений масштабируемости), пришло время перейти к архитектуре микросервисов, которая может создать свой собственный набор проблем.

Envoy Mobile и мобильная архитектура

Дарко: (08:55) Судя по тому, что я видел в твиттере, вы только что выпустили что-то под названием Envoy Mobile?

Мэтт: Для тех, кто не знает, Envoy Mobile — это идея, что мы собираемся взять прокси-сервер Envoy, который мы запускаем на стороне сервера, и запустить его на телефонах.

А для тех, кто может подумать, что это абсолютно безумие, есть немало прецедентов, созданных крупными компаниями.

Facebook делал это годами. Фактически они используют тот же код в своих мобильных клиентах, прежде всего для обеспечения согласованности. И Google уже давно это делает. У них есть библиотека Cronet, которая объединяет сетевой код Chrome для Android и iOS. Это две крупные компании, которые действительно ценят мобильную архитектуру.

Они делают это по той же причине, что и вы, возможно, исследуете паттерн вспомогательной сервисной сетки. Этот код невероятно сложен, так зачем вам переписывать его дважды, когда 99% кода одинаковы?

Нет особого смысла повторно реализовывать его несколько раз, когда вы можете заплатить нескольким людям за то, чтобы они были экспертами в этом коде, и затем могли работать на сервере и на мобильных устройствах. Мы чувствовали, что здесь есть реальная возможность получить действительно комплексное решение.

Получите билеты на EnvoyCon до того, как они будут распроданы

Darko: (14:06) EnvoyCon скоро будет, не так ли? Я не записал точную дату, так что, может быть, вы поделитесь ею с нами.

Matt: Да, это за день до KubeCon — 18 ноября. Мы опубликовали расписание, и я думаю, что это будет фантастическая конференция. Для всех, кто приезжает на KubeCon и хочет узнать больше об Envoy, мы провели нашу первую конференцию в прошлом году, и она была фантастической.

Я очень взволнован конференцией этого года. Я почти уверен, что он будет распродан, поэтому я бы взял ваш билет как можно скорее.

Что дальше в дорожной карте Envoy?

Darko: (25:50) В этом зрелом состоянии проекта с открытым исходным кодом, как вы решаете, какие функции должны быть объединены в ядро ​​​​следующими, и как вы справляетесь с этим?

Мэтт: До сих пор нам удавалось оставаться довольно шустрыми. И для проекта инфраструктурного программного обеспечения, такого как Envoy, в наши дни мы очень необычны в том смысле, что мы настоящий проект, управляемый сообществом. Люди появляются и создают функции, и именно так они сливаются.

Люди всегда спрашивают меня: «Что такое дорожная карта Envoy? Что люди делали в прошлом году?» И, честно говоря, я им говорю, что не знаю. У нас нет ни комьюнити-менеджера, ни продакт-менеджера, поэтому мы идем дальше.

За всю историю проекта у нас не было серьезных разногласий среди сопровождающих. Я уверен, что это произойдет в конце концов. Но я думаю, что этого еще не произошло, потому что мы очень внимательно относимся к тому, кто становится сопровождающим, следя за тем, чтобы наши взгляды на философию совпадали.

Другая причина, по которой у нас не было много разногласий, — это то, о чем я говорил ранее: расширяемость. Это способ позволить людям указать конкретные потребности своего сайта в расширениях, чтобы мы могли сосредоточиться на ядре.

Дарко: Спасибо, что присоединился к нам, Мэтт. Удачи с EnvoyCon и удачи с проектом.

Мэтт: Отлично, большое спасибо, что пригласили меня.

Первоначально опубликовано на https://semaphoreci.com 9 октября 2019 г.