Специальное примечание
Это переводный документ о совместном использовании облачных технологий и эволюции архитектуры командой simviso. В основном речь идет о совместном использовании Service Mesh. Участником совместного использования является технический директор компании Kong. У этой компании есть известный проект с открытым исходным кодом:github.com/Kong/kong
Давайте вместе узнаем, как этот технический директор перешел от монолитной архитектуры приложений к архитектуре микросервисов, что сделал Конг, какую роль в этом сыграл K8S и что такое конечный автомат (на основе событийной архитектуры для получения дизайна), какие ямы и опыт будет встречаться в этом процессе, все в обмене видео
Адрес видео:
Авторский текст видео переводаsimvisoвсе:
Кстати, рекомендую кружок профессиональных программистов back-end группы WeChat:
предисловие
Меня зовут Марко Палладино, я основатель Kong и технический директор компании.
Как он сказал, я из Сан-Франциско, Калифорния, и сегодня я хочу поговорить с вами о Service Mesh.
Чтобы создать архитектурную систему, подходящую для модернизации, наша архитектурная организация использует Service Mesh для перехода
Я хочу сказать, что когда наше предприятие станет больше и станет распределенным управлением путем разделения, тогда организация этого предприятия станет такой же сложной, как многоклеточные организмы. (Он разделен на несколько ячеек в виде одной ячейки для сотрудничества, и это все еще похоже на эту жизнь в целом)
На самом деле, будь то наша команда или программное обеспечение, как только оно станет сложным, оно будет отделено и будет управляться распределенным образом.
Как вы понимаете, модернизация вашей архитектуры с помощью сервисной сетки выходит за рамки внедрения технологий.
Способы разработки программного обеспечения также меняются благодаря следующим трем направлениям:
Один из них — технологическое обновление
Во-вторых, изменение организационной структуры.
Так как же должна измениться архитектурная организация, чтобы справиться с новой микросервисной архитектурой?
Тем не менее, режим работы, который мы ранее использовали с монолитными системами, должен был измениться. То есть мы не можем развертывать, расширять, версионировать и документировать эту новую микросервисную архитектуру прежним способом.
Эти три направления меняют то, как мы разрабатываем программное обеспечение.
С выпуском docker и kubernetes в 2013 и 2014 годах началась настоящая программная революция.
Docker и kubernetes дают нам совершенно новый способ создания приложений Со временем, на их основе, мы сможем лучше расширить эти приложения. Не только преимущества, которые приносят технологии, но, что более важно, они могут стать первым выбором для расширения нашего бизнеса.
На самом деле, помимо технических аспектов, в этом докладе я расскажу о бизнес-целях, которых мы хотим достичь.
Если мы не сможем координировать использование новых технологий при достижении бизнес-целей, мы не сможем продвинуться вперед в трансформации технологий.
В процессе мы должны стать более прагматичными
Это процесс перехода от сервисов монолитной архитектуры к агрегированным сервисам (таким как мультимодули Maven) и микросервисам. У вас в кармане куча конфет, каждая конфета — это микросервис, и каждый микросервис может быть сервисом, который мы обычно реализуем, или сервисом, реализованным функцией
В то же время API также меняют свою роль в нашей системе.
Обычно мы выполняем управление мониторингом производительности APM (мониторинг производительности приложений) с API в качестве степени детализации. С появлением мобильных устройств в 2007–2008 годах нам нужен был способ взаимодействия с нашими монолитными приложениями. Таким образом, у нас есть трафик север-юг (обмен север-юг обычно относится к взаимодействию данных между несколькими терминалами и сервером, то есть мы можем получить доступ к серверу через внешних разработчиков или мобильное приложение или другие внешние формы, основное внимание уделяется внешний)
Нам необходимо разделить функции нашего программного обеспечения.В настоящее время роль API в нашей системе становится все более и более важной.
Трафик восток-запад (обмен восток-запад, по сравнению с вышеизложенным, фокус внутренний), обычно это относится к системам, разработанным нашими разными командами, и к взаимодействию данных между различными системными продуктами. Далее мы обсудим использование Service Mesh для разделения уровня данных и уровня управления, чтобы постоянно оптимизировать и расширять нашу систему.
Некоторые важные моменты для перехода на микросервисы
1 What does it mean?
Но сделав шаг назад, с прагматической точки зрения, зачем использовать Service Mesh для перехода микросервисов
Целью нашего рефакторинга монолитных приложений является повышение производительности команды и улучшение масштабируемости бизнеса.
Ключом ко всему переходу на данном этапе является продуктивность команды и масштабируемость связанного с ней бизнеса.
При переходе к микросервисам, если мы не делаем ни того, ни другого, мы, так сказать, не делаем ничего, кроме как выясняем это. Поэтому, прежде чем делать это, мы должны спросить себя, используем ли мы его для производства или используем эту технологию.
В этом процессе бизнес должен быть главной движущей силой, потому что цель написания проектов — достижение бизнес-целей. После определения бизнес-стратегии, а затем принятия микросервисной архитектуры для ее реализации, мы должны определить, когда начинать и, что более важно, когда заканчивать.
2 мы должны это сделать?
Следующий второй вопрос, также для тех, кто хочет перевести свои проекты на микросервисы Должны ли мы это делать, должны ли мы переходить на микросервисы, должны ли мы отказаться от нашей нынешней архитектуры?
Что касается технологических тенденций, мы должны спросить себя, следует ли внедрять технологию на основе реальных потребностей или потому, что технология очень зрелая.
Процесс перехода на микросервисы может быть намного сложнее, чем запуск монолитного приложения. Тяжело, когда одна система содержит все функции, а потом мы разбиваем ее на группу систем с одной функцией
В настоящее время мы едва ли развертываем или масштабируем большие монолитные приложения таким же образом. Но мы можем добиться исходной функции, разделив полную систему на сотни или тысячи монолитных систем с различными функциями.
Если микросервисы в настоящее время не решат нашу проблему управления монолитным приложением, это еще больше усугубит ситуацию.
Следовательно, техническая архитектура и члены команды должны быть достаточно зрелыми, чтобы действительно решать существующие проблемы.
На самом деле, я действительно рекомендую использовать пошаговый подход к переходу на микросервисы.
По следующим причинам. Во-первых, идя шаг за шагом к достижению поставленных целей, это может повысить доверие команды и дать им почувствовать, что они справятся с этим делом. В то же время мы также можем адаптировать и изменить наш процесс в любой момент процесса.
В то же время с переходом бизнес-лидеры станут более уверенными в том, что переход идет в правильном направлении, расширяя и делая бизнес более актуальным с течением времени.
На самом деле, когда мы смотрим на микросервисы, мы смотрим на такие крупные компании, как Netflix или Amazon. На самом деле они уже давно превратились в микросервисы, еще когда не существовало kubernetes и docker.
Что побуждает эти компании к такой трансформации?
Возьмем, к примеру, Netflix, чтобы расширить масштабы своего бизнеса и больше не придерживаться одной страны и единой пользовательской системы, он хочет перейти на весь мир, поэтому он изменился.
Так что это также их бизнес-цель
Для бизнес-требований, которых они хотели достичь, их предыдущая архитектура была недостаточной. Поэтому они обратились к архитектуре микросервисов для удовлетворения потребностей бизнеса.
То же самое верно и для Amazon, потому что он не только довольствуется продажей одного вида вещей, но и более склонен к разнообразию товаров, поэтому изменение структуры может удовлетворить более сложные потребности.
Таким образом, микросервисы тесно связаны с этими бизнес-требованиями. Для достижения наших целей Мы не можем действовать в одиночку, будь то команда разработчиков или руководство. Возьмите Amazon в качестве примера, это успешный пример микросервисов.
Итак, кого вы знаете, кто решил позволить Amazon превратиться в микросервисы?
Генеральный директор Amazon Джефф Безос однажды ввел в действие шесть принципов, которые, если вы им не будете следовать, Затем этих людей можно сразу уволить (этот абзац на самом деле о принципиальных вопросах, которые Безос просил сотрудников соблюдать в 2002 году).
Трудно поверить, что это изменение было предложено не командой разработчиков, а их генеральным директором.
Как бизнес-лидеры, внося постепенные изменения для достижения своих целей и в то же время делая их более уверенными, это правильный способ двигаться вперед.
Из всего вышеперечисленного, чтобы достичь цели, нам придется пройти через бесчисленные трудности и препятствия.
Мы можем решить, является ли микросервис большим или маленьким, в зависимости от сложности.
На самом деле размер этих микросервисов определяется потребностями самого бизнеса, лишь бы он устраивал
3 Let's do it!
Но только когда мы почувствуем, что микросервисы — это то, что нам нужно, и мы на правильном пути, мы сможем продолжить трансформацию.
При переходе на микросервисы я определил две разные стратегии Один из них называется «зачерпывание мороженого». Большие ведра мороженого могут выкапывать свои собственные сервисы и бизнес-логику, которые затем можно запускать и развертывать отдельно в разных процессах.
Второй — это метод Лего (строительные блоки), что означает, что мы не избавимся полностью от оригинального монолитного приложения, которое обычно подходит для старых проектов.
Но новые функции будут построены с новой архитектурой.
Поэтому вам нужно найти способ переподключить микросервисы к старым приложениям, иначе переход будет затруднен.
Третий я называю ядерным методом, что также означает, что мы строим все с нуля.
В процессе перехода на микросервисную архитектуру нам необходимо сохранить исходное монолитное приложение.
С первого дня перехода на микросервисы мы не можем разрабатывать с нуля, потому что это худший вариант
Для этого требуется сильная техническая команда, а также необходимо определить технические границы в соответствии с реальной ситуацией. Когда у вас есть две разные команды, работающие одновременно, одна может работать непрерывно, в то время как другая команда занимается рефакторингом и микросервисами проекта.
Когда мы перестраиваем эту новую кодовую базу, функциональность старой кодовой базы преобразуется в новую кодовую базу, здесь Вопрос в том, где мы должны создавать новые функции, потому что в настоящее время наш бизнес все еще работает на старой кодовой базе и не использует новую кодовую базу.
То есть мы столкнулись с очень сложной ситуацией, которую трудно решить, поэтому нельзя все бросать и начинать с 0. Далее идет стратегия мороженого, которую мы собираемся изучить сегодня.
Например, у нас есть объектно-ориентированная монолитная сервисная архитектура, в которой есть все необходимые нам функции, и эти функции реализованы через разные объекты и классы в этой монолитной сервисной архитектуре.
Разные сервисы используют одну и ту же базу данных. Если мы хотим масштабировать это монолитное приложение, мы можем только развернуть больше экземпляров этого монолитного приложения. (Чтобы уменьшить нагрузку на определенный сервис расширения, другие сервисы пассивно выполняют ненужное горизонтальное расширение, что увеличивает сложность)
Если это единственное приложение является веб-сайтом электронной коммерции, таким как наш обычный amazon.com, то у нас будет множество различных сервисов, таких как управление пользователями, управление заказами, управление запасами, поиск по сайту и т. д.
Это типичный пример архитектуры с одной службой, на этой диаграмме каждый отдельный блок представляет другую бизнес-логику.
Поскольку это крупномасштабная монолитная сервисная архитектура, нам нужно много команд, чтобы поддерживать ее вместе. В этом случае три разные команды поддерживают монолит, создают для него новые функции и запускают их в производство.
Теперь я полагаю, что теперь вы также знаете некоторые плюсы и минусы монолитной архитектуры и микросервисной архитектуры. В монолитной архитектуре возникает проблема Если одна из команд разработчиков делает частые коммиты, требуется большая координация между другими командами для правильного развертывания этих изменений в рабочей среде.
По мере роста кодовой базы растет и команда разработчиков продукта. Со временем проблема будет усугубляться. Это может серьезно повлиять на эффективность нашего цикла выпуска новой версии.
Когда команда 2 (с несколькими командами, разрабатывающими вместе) также начала часто вносить изменения в код. Проблемы, с которыми мы сталкиваемся, более сложны. В настоящее время, как мы можем изменить статус-кво?
Так как команда 2 работает над поисковыми сервисами, инвентарем и другими модулями, если модуль требует много итераций, как мы извлекаем этот модуль (для отдельной разработки)
Таким образом, стратегия мороженого, которую мы используем, состоит в том, чтобы извлечь бизнес-логику из монолитной архитектуры и отделить ее от других.
Все эти сервисы очень важны, но они не являются микросервисами. Вот что нам нужно сделать сегодня, чтобы постепенно превратить их в микросервисы.
Мы хотим убедиться, что извлеченные новые сервисы не могут полагаться на исходную базу данных, используемую старой системой.
Наше первоначальное намерение состоит в том, чтобы надеяться, что извлеченные новые услуги будут действительно независимыми.
Если старая система делает слишком много запросов к базе данных
то база данных станет недоступной
Поскольку мы не хотим, чтобы служба была затронута, мы хотим разделить и изолировать службу.
Затем мы тестируем его в производственной среде, а затем, когда одну или несколько частей (здесь имеются в виду блоки на рисунке) также необходимо сильно изменить, указываем на них и извлекаем.
Итак, теперь у нас есть три разных сервиса (как показано на рисунке), один из них — наша старая система, за ним следует чуть более крупный сервис и, наконец, небольшой сервис.
Практически, выполняя этот вид извлечения услуг из монолита снова и снова Или дополнительно извлечь из отдельных сервисов, чтобы сделать их меньше, чтобы решить проблемы, с которыми мы сталкиваемся сейчас.
Весь итеративный процесс не может быть завершен сразу, мы можем только шаг за шагом выполнять гибкую разработку для извлеченного бизнеса с прагматичным отношением.
С помощью этого пошагового процесса мы можем изменить другую связанную логику в этой организации проекта, кстати.
Чтобы обеспечить большую поддержку разделения для последующих итераций проекта
По сути, в процессе перехода это рефакторинг, аналогичный рефакторингу сервисов, который мы привыкли делать внутри монолитной сервисной архитектуры. Здесь у нас есть несколько вещей, чтобы прояснить
Прежде всего, нам нужно понять, что это за модель. Если мы не понимаем, что делает код, нам сложно определить границы службы.
Вы знаете, что логика большинства монолитных сервисов слишком запутана. Из-за этого нам необходимо определить границы сервисов и разделить сервисы. Если мы этого не знаем, то мы вообще не можем это извлечь
Чтобы иметь возможность реконструировать старую систему, нам также необходимо понять, какой клиент используется в текущей системе, и какое влияние он окажет на клиента в случае возникновения ошибки.
Перед преобразованием микросервиса нам нужно знать, какие сервисы будут затронуты.
Итак, третье, что мы делаем, как и любой другой рефакторинг, нам нужно запустить интеграционные тесты, чтобы убедиться, что логика, которую мы хотим изменить, верна. Это гарантирует, что наш рефакторинг не повлияет на исходную систему.
Мы хотим расширить нашу систему, не влияя на внутреннюю работу системы.
Мы не хотим прерывать (влиять) на необходимые сервисы, по крайней мере, мы не можем расширять или изменять бизнес-логику одновременно, это можно делать только шаг за шагом
Когда старая система работает, есть некоторые вещи, может быть, небольшое изменение метода, тогда нам не нужно расширять его так же, как раньше.
Например, обновление нашего клиента или обновление маршрутов, чтобы правильно направлять запросы к другому сервису.
Клиенты делают запросы к нашему монолиту, но теперь эти запросы обрабатываются уже не нашим монолитом, а другими сервисами. Так как же нам перенаправить эти запросы?
В традиционной бизнес-модели мы размещаем балансировщик нагрузки (например, nginx) между клиентом и сервером.
Например, нашим клиентом может быть мобильное приложение, когда мы развертываем монолитную систему, нам нужно только запустить несколько экземпляров этого приложения за балансировщиком нагрузки.
Но поскольку наша система шаг за шагом извлекается и отделяется для формирования множества микросервисов, нам необходимо сделать некоторые аспекты всей операционной архитектуры более интеллектуальными.
Первое, что вам нужно сделать, это принять адаптивный API-шлюз.
Если этот шлюз может обеспечить интеллектуальную балансировку нагрузки
Затем, когда мы отделяем службу, мы можем использовать API-шлюз в качестве прокси-сервера между сервером и клиентом и реализовывать функциональную маршрутизацию. Это позволяет нам направлять запросы к этим новым службам без необходимости обновления клиента. это очень важно для нас Если мы этого не сделаем, нам придется обновить клиент, у исходной версии будут проблемы, а качество обслуживания клиентов будет очень плохим, а это значит, что это очень плохо скажется на нашем бизнесе.
Прокси между клиентом и сервером также является шлюзом, который должен быть достаточно интеллектуальным, чтобы помочь нам выполнять некоторые операции в нашей архитектуре. Как я уже говорил, переход на микросервисы — это не только техническое внедрение, такое как kubernetes, но и переход к оперативному управлению.
Мы не можем развертывать архитектуру микросервисов и архитектуру SOA так же, как развертывание монолитных приложений.
Нам нужны некоторые стратегии для снижения риска
Например, когда выходит новая версия сервиса, мы можем направить 10% трафика на новую версию сервиса, используя стратегию выпуска в градациях серого.
Только когда она будет стабильной, мы сможем полностью направить трафик на новую версию сервиса и избавиться от старой версии сервиса. В то же время нам также необходимо сохранить работоспособность старой версии на случай, если нам потребуется откатиться на предыдущую версию.
Прежде чем углубиться в микросервисы и сервисную сетку, я хочу уделить немного времени объяснению гибридных и мультиоблачных технологий.
Когда мы используем микросервисы, нам нужно использовать такую платформу, как kubernetes, для запуска наших сервисов.
Поскольку у нас все еще есть несколько сервисов, работающих в старой системе, мы не будем запускать их все в kubernetes. Мы по-прежнему будем запускать старую систему на платформе, которую мы использовали раньше, например, на виртуальной машине.
Когда мы планируем переход на микросервисы, мы должны разработать стратегию эффективного соединения старых и новых платформ приложений.
У нас нет возможности запустить все поверх Kubernetes за одну ночь.
Итак, что мы должны сделать, чтобы переподключить службы, работающие в kubernetes, с соответствующими зависимыми службами исходной старой системы?
Как я уже говорил, здесь вся ткань представляется как сложная ткань человека. Тогда мы можем думать о разных командах, продуктах и бизнес-требованиях, их общая цель (разработанная программная единица) быть независимой друг от друга.
С точки зрения высокого уровня, вся организация не обязана использовать гибрид или мультиоблако, для этого требуется решение сверху вниз.
Проектные организации некоторых компаний уже работают на разных облачных платформах, и причина использования гибридного и мультиоблачного Это означает, что со временем эти разные команды выбирают разные облачные платформы в зависимости от потребностей проектной организации.
С точки зрения высокого уровня всей проектной организации этих компаний, почему они внедряют гибридное облако, это не потому, что они хотят его использовать, а потому, что они должны его использовать.
В идеале мы хотели бы, чтобы все сервисы работали на одной платформе.
Но давайте посмотрим правде в глаза, ситуация такова, что нам нужно иметь несколько систем, работающих везде. Поэтому нам нужна архитектура с более высоким уровнем абстракции, где нам нужны инструменты для управления мультиоблаком и гибридом в рамках этой организации проекта.
4 Детализация обслуживания
По мере того, как мы извлекаем все больше и больше микросервисов из этой монолитной сервисной архитектуры
Хочу дать совет, чтобы разумно определять границы микросервисов, совмещая их с текущими целями. Я думаю, это очень важно. Вот что я узнал из тех случаев извлечения, которые были очень успешными.
Как и в моем предыдущем примере, мы не можем делать микросервисы за один шаг. Мы можем взять относительно большой сервис и постепенно отделять его, делая его все меньше и меньше.
Когда мы смотрим на сервисные сетки и архитектуры микросервисов, в идеале все эти сервисы должны быть небольшими. и будут связаны друг с другом таким же образом.
Но реальность такова, что размер всех этих услуг зависит от масштаба, генерируемого нашими бизнес-целями наилучшим образом.
Мы не должны форсировать использование микросервисов в погоне за микросервисами, иногда нам может понадобиться более крупный сервис.
5 Сеть
хорошо, теперь мы получаем много микросервисов через развязку, эти развязанные микросервисы создаются и развертываются независимо разными командами Важно подчеркнуть, что эти сервисы не могут существовать поодиночке, им необходимо общаться друг с другом, чтобы функционировать.
Итак, мы собираемся отказаться от некоторого использования в монолитном приложении. Мы основаны на объектах в кодовой базе (здесь объекты относятся к классам реализации интерфейса, а не к нашим POJO) Интерфейсы и вызовы функций, безупречно выполняя эти вызовы функций, мы можем вызывать и получать доступ к различным объектам.
Но когда мы разделяем их на микросервисы, эти объекты класса реализации интерфейса становятся сервисами.
Интерфейс по-прежнему существует, но весь доступ между микросервисами будет осуществляться по сети.
Например, в монолите Java при выполнении вызова функции (вызов метода в определенном интерфейсе) Поскольку нижний уровень основан на JVM, нам вообще не нужно беспокоиться об этом вызове, он будет успешно обработан, виртуальная машина Java примет вызов и направит вызов в правильный класс реализации.
Но в микросервисах мы не сможем сделать предыдущий
Поскольку мы будем выполнять вызовы функций по сети, мы не сможем гарантировать, где именно в сети будут вызываться такие запросы функций.
В нашей системе сеть является очень ненадежным фактором. Сеть может работать медленно, с задержками и простоями Короче говоря, разница между сетевым уровнем и уровнем отдельного приложения заключается в том, что у него будут различные проблемы, влияющие на наши системные службы.
В системе с микросервисной архитектурой у нас есть разные команды, которые запускают и развертывают эти сервисы.
Мышление команды также должно измениться
В монолитном приложении у него есть два состояния: рабочее и нерабочее.
Но в микросервисах в любой момент, если у сервиса есть проблема в запущенном процессе В этот момент мы должны изменить способ мышления, то есть здесь должна быть деградация сервиса, то есть в нашей архитектуре должна быть часть деградации сервиса.
Поскольку у каждого из этих разных сервисов будут проблемы, чем больше ухудшенных сервисов мы создадим, тем больше команд смогут развернуть их независимо друг от друга.
В то же время, с точки зрения организационной структуры, наша проектная команда также должна изменить соответствующий образ мышления.
В какой-то момент, когда возникает проблема с сервисом, система деградации сервиса должна выяснить, как с этим справиться, обеспечивая при этом очень хороший опыт для конечного пользователя.
Все это мы делаем для конечных пользователей, а не для себя, мы делаем это, чтобы предоставить конечным пользователям лучший опыт работы с продуктом.
Задерживать
Далее поговорим о задержке, я не могу игнорировать задержку, вызванную вызовами между API.
Мы все знаем, что сетевая задержка очень важна для традиционного доступа мобильных приложений к монолитным.
Если задержка доступа мобильного приложения к нашей системе составляет сотни миллисекунд, это для нас Ситуация не оптимистичная, мы можем уменьшить задержку и улучшить скорость обработки сети через CDN или кеш
В микросервисах задержка возникает из-за того, что взаимных запросов между разными микросервисами становится все больше, а сервис А потребляет Потребляет сервис B, а также потребляет сервис C. Как видите, это вызовет задержку в вызовах друг друга между сервисами.
В архитектуре передачи микросервисов, как только в базовой службе возникает время простоя, вызывающий абонент, вызывающий службу времени простоя, также испытывает новое время простоя. В монолитной сервисной архитектуре при возникновении исключения в сервисе возникает исключение и в связанных с ним вызовах.
В микросервисах, когда время отклика истекает, это повлияет на другие связанные микросервисы, что приведет к цепной реакции, как будто вся система больше не работает.
Таким образом, задержка — это первая проблема, которую нам нужно решить, а не то, что мы хотим исправить постфактум. Как и безопасность и производительность, эти два компонента не являются функциональными, мы не можем добавить их позже. Мы можем помнить об этом только при написании системы, как писать, чтобы обеспечить производительность, и как писать, чтобы обеспечить безопасность системы.
Безопасность также становится еще одним компонентом этого (как показано), поэтому теперь все эти сообщения, которые у нас есть в Интернете, мы хотим иметь возможность шифровать и защищать эти взаимодействия.
Например, шифруйте сетевые соединения, применяя взаимный TLS или используя методы, которые, как вы знаете, используются между различными службами.
Кстати, эти службы не обязательно запускать через restful API.
Мы можем использовать любой транспортный протокол, который подходит для нашего сценария, вы можете использовать rest или gRPC или любой другой транспортный протокол.
Мы не привязаны к какому-то одному конкретному транспорту или протоколу, нам нужно знать, как прозрачно защитить и зашифровать все эти коммуникации.
Как я упоминал ранее о маршрутизации, теперь, когда у нас есть разные службы, как нам настроить службы маршрутизации где-то в системе? Маршрутизация к разным версиям наших сервисов, маршрутизация запросов к тем микросервисам, которые мы разворачиваем на разных облачных хостах
Точно так же, если наша служба больше не работает, нам нужно выполнить обработку исключений в это время. Нам нужно иметь возможность прерывать передачу запросов к этим неработающим экземплярам или службам. Итак, здесь нам нужен автоматический выключатель и проверка работоспособности.
В рамках единой сервисной архитектуры нам не нужно устанавливать автоматические выключатели или проверки работоспособности. Но когда масштаб достигает определенной точки, например запуска тысячи монолитных приложений, они становятся чрезвычайно важными. Если бы мы не сделали этого с самого начала, мы были бы на грани перехода на микросервисы.
Кроме того, наблюдаемость в монолитных сервисах отличается от прежней. В монолитной архитектуре нам не нужно заботиться о том, куда пойдет запрос (потому что это понятно), но теперь в микросервисной архитектуре мы должны знать
Потому что нам нужно уметь находить слабые звенья в нашей архитектуре микросервисов. Итак, нам нужно отслеживать запросы от одного сервиса к другому, а также собирать метрики производительности и логи. Это облегчает нам понимание того, что делает микросервис в любое время, и, если что-то пойдет не так, определить, где что-то пошло не так.
Сложность перехода на микросервисы без определения границ служб Потому что в какой-то момент что-то неизбежно пойдет не так, и мы не сможем использовать правильные инструменты, чтобы копаться и найти проблему.
Service Mesh Pattern
Перейдем к обсуждению Service Mesh.
Во-первых, Service Mesh — это не технология, а шаблон проектирования, и мы можем реализовать Service Mesh разными способами.
Но обычно у нас есть прокси, работающий с нашим сервисом, с помощью которого ненадежные сети можно сделать надежными.
Исходя из этого, нам не нужно беспокоиться о том, как бороться с проблемами латентности, наблюдаемости (observability) и взаимного TLS при построении наших сервисов и т. д.
Поскольку точка подключения больше не является службой для службы, а представляет собой плоскость данных (DP, плоскость данных) для плоскости данных.
Эти точки подключены через внешнюю сеть, фактически эти точки подключения общаются через Data Plane.
В то же время, поскольку Data Plane может выполнять логику без учета сервисов, здесь мы можем обрабатывать исключения, задержки и наблюдаемость.
В Service Mesh Data Plane является одновременно и прокси-сервером, и обратным прокси-сервером, в зависимости от того, куда направляется запрос.
Например, если эта служба хочет вызвать эту службу, то эта плоскость данных будет действовать как прокси. Поскольку текущие запросы (этой) службы будут проксироваться через эту плоскость данных
Но когда эта плоскость данных получает запрос, эта плоскость данных будет действовать как обратный прокси-сервер, который примет запрос и проксирует его в связанную с ним службу.
Нам нужна Data Plane, мы можем реализовать сервисную сетку по-разному. Каждая базовая виртуальная машина или реплика каждой службы, которую вы запускаете, может иметь плоскость данных.
Последний называется Sidecar Cycle Proxy, потому что у нас будет экземпляр Data Plane для каждого экземпляра службы на сервере.
Здесь будет точка, независимо от того, имеем ли мы одну плоскость данных на реплику или одну плоскость данных на базовую виртуальную машину, это одно и то же. Идея состоит в том, что всякий раз, когда существует связь между службами, связь сначала перенаправляется на уровень данных, а затем принимается уровнем данных.
Эти службы больше не взаимодействуют друг с другом напрямую, а должны проходить через эту другую систему (плоскость данных). Это позволяет нам внедрить дополнительную логику в Data Plane, что означает, что сервис-агностик лучше всего Поскольку все операции взаимного TLS и наблюдения выполняются «из коробки», команде не нужно встраивать их в сервис.
Как видите, эти плоскости данных действуют как точки соприкосновения, через которые мы можем делать все, что угодно. Включение базы данных в эту систему управления. Также потому, что когда служба использует базу данных, мы все равно хотим, чтобы это использование наблюдалось. Мы по-прежнему хотим иметь все функции, которые предоставляет Data Plane, поэтому все будет передаваться через Data Plane.
Поэтому мы делаем много сетевых вызовов через разные сервисы через децентрализованные прокси.
Он называется децентрализованным, потому что, в отличие от традиционных ESB, мы не централизуем экземпляры прокси, а распределяем их по сервисам.
Определение Кубернета
Итак, прокси-сервер Sidecar, о котором я только что упомянул, мы уже должны знать, что это такое. Далее вернемся к определению Kubernetes.
Kubernetes абстрагирует способ развертывания модулей на базовых виртуальных машинах.
Мы используем kubernetes, чтобы наш кластер виртуальных машин выглядел как хост для использования.
Kubernetes решит, куда пойдут эти поды
Когда мы говорим kubernetes, что я хочу, чтобы этот прокси был контейнером sidecar
Для других модулей этого назначенного сервисного контейнера Мы сообщаем kubernetes, что я хочу развернуть этот прокси на базовой виртуальной машине, где находятся эти сервисы (т. е. в поде, где находится каждый сервис, есть дополнительный контейнер).
Мы хотим, чтобы прокси-сервер Sidecar всегда был развернут на базовой виртуальной машине, поскольку мы хотим, чтобы связь между службой и прокси-сервером всегда осуществлялась на локальном хосте (для каждой реплики).
Предполагая, что на локальном хосте его успех (общение) всегда равен 100%
Потому что мы не ушли отсюда (во внешнюю сеть), а остались в виртуальной машине
Проблемы с сетью между здесь и там будут обрабатываться Data Plane. (Специальное примечание переводчика: sidecar используется для Kubernetes, а Data Plane используется для сервисной сетки в разных местах, обратите внимание)
У нас будет экземпляр этого агента, объединенный с моделью Sidecar для каждого экземпляра нашего сервиса.
Теперь это усугубляет проблему в Data Plane, которая действительно должна поддерживать очень маленькое использование ресурсов и занимать очень мало места.
Потому что мы будем запускать по одному (прокси) для каждой реплики каждой службы в нашей системе. Это означает, что если сам агент потребляет много ресурсов, у нас закончатся ресурсы памяти (как в базовой виртуальной машине).
Поэтому, если мы используем больше циклических агентов, мы должны убедиться, что этот агент очень, очень мал и занимает мало ресурсов.
То же самое верно и для нашего собственного сервиса, кстати, не может занять слишком много памяти В противном случае либо мы используем очень большую (память) виртуальную машину, либо нам очень быстро не хватит памяти.
Поэтому и сервисы, и прокси должны быть очень маленькими с точки зрения использования ресурсов.
Вот почему вы не можете поставить ESB туда.
Вы можете представить запуск экземпляра ESB для каждого экземпляра службы, и нельзя ожидать, что ваша служба будет работать.
Теперь мы хотим, чтобы эти разные сервисы работали на разных уровнях данных, а затем нам нужно настроить эти уровни данных как можно скорее.
Когда наша служба обменивается данными, на самом деле эти плоскости данных полагаются на сертификат протокола, который мы установили для связи. В целом, весь протокол очень сложен, и нам сложно с ними общаться (нам нужно сделать много потенциальных приготовлений, и легко ошибиться, если мы не будем осторожны)
Таким образом, мы не хотим вручную передавать конфигурацию на эти разные плоскости данных.
Здесь мы говорим о Control Plane.
Data Plane и Control Plane очень хорошо известны тем, что обрабатывают это на сетевом уровне.
(Например) у вас есть несколько коммутаторов Cisco, работающих в вашем центре обработки данных, и вы хотите перенести свою конфигурацию на эти коммутаторы Casco.
Итак, нам нужна плоскость управления, которая позволит нам это сделать.
Примените ту же концепцию к программному обеспечению
Мы передаем конфигурацию в каждую плоскость данных через плоскость управления.
Или эта плоскость управления может позволить плоскости данных получить эту конфигурацию из единого места.
Но это также может быть способом сбора метрик (параметров запуска).
Прямо сейчас Data Plane собирает весь этот трафик (коммуникационное поведение) одновременно. Мы хотим иметь компонент, который позволяет нам собирать журналы, собирать метрики и по-прежнему находиться в плоскости управления.
Плоскость данных находится на запрошенном пути выполнения
Плоскость управления предназначена только для настройки, она используется только для получения этих метрик, Плоскость управления никогда не находится на пути выполнения нашего запроса API.
По сути, наш шлюз север-юг просто становится еще одной плоскостью данных, еще одним прокси-сервером. Это не наша плоскость данных, но она позволяет нам общаться с базовой плоскостью данных.
Поскольку все они являются частью этой сетки, мы можем применять взаимный TLS между этими различными плоскостями данных, обеспечивая защиту наших систем.
Мы по-прежнему можем делать эти вещи без сервисной сетки, но тогда нам нужно встраивать свои собственные сервисы, чтобы делать эти вещи.
С технической точки зрения, микросервисы не обязательно должны выполняться через сервисную сетку. Но проблема в том, что если вы хотите иметь эти преимущества, вы должны создать их сами.
И вам не обязательно нужен Kubernetes в сервисной сетке, но идею сервисной сетки можно применить к любой платформе.
kubernetes просто упрощает запуск микросервисов в масштабе, но ничто не мешает нам запускать сервисную сетку на виртуальных машинах.
Нам просто нужно развернуть наш экземпляр плоскости данных на виртуальной машине, где работает служба, и у нас есть сервисная сетка, работающая на виртуальной машине.
На самом деле, мы больше хотим, чтобы сервисная сетка могла работать в Kubernetes.
Но, как я уже говорил, у нас все еще есть монолитные приложения, работающие на виртуальных машинах или устаревших платформах.
и, надеюсь, он каким-то образом станет частью сервисной сетки. Так что надеемся, что платформа данных не только в kubernetes, но и работает в среде нашего монолитного приложения
Мы надеемся, что этот шаблон (монолитное приложение выше) также может быть частью сервисной сетки.
Если вы хотите сделать переход на микросервисы более практичным, то независимость от платформы, безусловно, очень важна.
Как было сказано ранее, разные сервисы могут быть построены на разных языках, что является одним из преимуществ микросервисов.
Потому что мы можем создавать сервисы на уровне данных с минимальными зависимостями и функциональной независимостью, что означает, что нам не нужно повторять одну и ту же логику снова и снова.
Среди двух микросервисов, написанных на двух разных технологиях, уровень данных принадлежит внешнему агенту обработки, который работает на одной виртуальной машине с соответствующими микросервисами.
событийная архитектура
Я уделю немного времени, чтобы поговорить об архитектуре, основанной на событиях.
Когда мы говорим о service mesh, т.е. когда мы говорим о микросервисах, мы обычно говорим о коммуникации между сервисами, но это не единственный способ реализации этих систем
Еще один способ — использовать событийную архитектуру для их создания.
Это означает, что мы будем распространять событие через архитектуру, чтобы более эффективно обрабатывать такие вещи, как захват состояния.
Это предполагает наличие двух разных микросервисов: одного для заказа и другого для выставления счетов.
Каждый раз, когда мы создаем заказ, мы выставляем новый счет, звучит хорошо
Однако, если по какой-то причине микрослужба выставления счетов становится недоступной, мы будем повторять попытки до тех пор, пока время запроса не истечет.
Окончательный счет-фактура не будет создан успешно, конечно, лучше не допускать такой ситуации.
Если бы это произошло, то распространение состояния в системе было бы прервано, и впоследствии исправить это было бы дорого.
Итак, для приведенного выше случая, когда состояние распространяется, мы можем рассмотреть возможность использования событий
Например, пусть микросервис инвойсов будет готов до обработки события создания заказа, чтобы наше состояние не потерялось
Риск такого подхода заключается в том, что мы можем использовать что-то вроде kafka в качестве сборщика событий, но другие службы в системе могут иметь некоторые исключения.
Поэтому мы хотим иметь плоскость данных перед этими службами, потому что мы хотим убедиться, что события службы могут достигать сборщика событий (kafka).
Таким образом, мы можем использовать Kafka или какой-либо сборщик журналов для обработки некоторых наших вариантов использования, конечно, мы должны убедиться, что сборщик журналов доступен без сбоев.
Часто проще сосредоточиться на поддержании службы в рабочем состоянии (например, на сборе журналов), чем на распространении информации о состоянии для каждой службы.
Поскольку у нас есть только один компонент, нам просто нужно убедиться, что он продолжает работать правильно, и наоборот, если компонентов много, то все они должны быть запущены и работать. Мы можем сосредоточиться на том, чтобы сделать операции немного более надежными и повысить надежность распространения состояния.
Как я уже сказал, организационная структура предприятия меняется, и наша система постепенно движется к сложному живому телу, поэтому я люблю использовать в качестве аналогии нервную систему.
Наше тело состоит из двух разных компонентов головного мозга: ЦНС (центральная нервная система) и ПНС (периферическая нервная система).
Периферическая нервная система хранит всю информацию, которую может понять наше тело, а затем передает ее в ЦНС (центральную нервную систему), чтобы ЦНС (центральная нервная система) могла ее обработать.
Это очень похоже на концепцию плоскости управления и плоскости данных.
Плоскость данных будет находиться по периметру каждого из наших сервисов, каждого из наших монолитных приложений и по периметру каждого функционала (например, лямбда-выражения).
Но соответствующая конфигурация, мониторинг и наблюдаемость будут обрабатываться плоскостью управления.
что сделал Конг
Я уже говорил, что являюсь соучредителем и техническим директором компании Kong, которая предоставляет эффективную плоскость управления с открытым исходным кодом и плоскость данных, позволяющую управлять различными архитектурами в организации.
Более миллиона экземпляров Kong работают по всему миру, чтобы помочь разработчикам управлять плоскостью данных. Мы предоставляем техническую поддержку командам, которым необходимо выполнить архитектурный переход, чтобы помочь им перейти от монолита к микросервисам, к сервисной сетке и бессерверным технологиям.
Переход на микросервисы — сложная тема, поскольку она затрагивает три разные области.
Но что более важно, мы должны привести этот процесс в соответствие с бизнес-целями, которых мы хотим достичь, иначе, как я уже сказал, это просто тыква и тыква, микросервисы ради использования микросервисов.
Во-первых, трансформация бизнеса.
Мы должны быть реалистами, нам не нужно сразу переходить на микросервисы или иметь тысячи микросервисов, если в этом нет необходимости.
В основном потому, что у нас всегда есть время сделать сервис все меньше и меньше.
Так что не спешите, сначала извлеките сервис до среднего размера, а затем со временем уменьшите его.
На самом деле, я бы сказал, что только когда сервис должен быть меньше, тогда мы можем сделать его меньше. Это лучший способ перехода
Потому что это повышает нашу производительность и улучшает наш бизнес.
Используя технологический подход, который позволяет нам перейти к этим новым архитектурным микросервисам.
Но также возможно подключить старые приложения, которые теперь предоставляют бизнес-услуги, очень прагматичным образом (программы, подлежащие рефакторингу).
Это по-прежнему самые важные компоненты, их соединение с нашей новой (недавно разработанной) микросервисной архитектурой станет будущим нашей системы.
Так что это требует связи между старым и новым
Спасибо за внимание
задавать вопросы
Итак, у вас есть другие вопросы?
Часть вопроса: Например, еще одно отдельное приложение, согласно тому, что говорил спикер ранее, постепенно отделяет сервис, чтобы сделать его все меньше и меньше. Amazon сказал, что это будет дорого для них, поэтому они сдались на полпути. Что вы думаете о том, чтобы начать сначала, запустить полноценные микросервисы (выбросить старую систему)
Как я уже сказал, это на самом деле вариант. Пока команда предприятия/разработчика готова выполнить полную подготовку микросервиса. При этом тоже есть четкая идея, поэтому этот переход на микросервисы тоже желателен
Принимая этот вариант, мы должны проанализировать все за и против. Конечно, проанализировав их плюсы и минусы, Amazon Если вы решите перестроить, а не медленно переходить от монолитных приложений к микросервисам, преимущества намного перевешивают недостатки.
На мой взгляд, это все еще стратегия, при которой немногие компании успешно перешли на микросервисы.
Конечно, мы также должны принять во внимание эти вещи
Общий смысл вопросной части: Много обращений между микросервисами Однако задержка нашей сетевой связи через Data Plane намного выше, чем локальный вызов между сервисами и сервисами, можно ли как-то уменьшить задержку?
Система может дать нам метрики, чтобы понять, где находится узкое место задержки. Поэтому, если нам нужно пройти через сеть, мы получим большую задержку, чем через локальный вызов функции, который работает
На самом деле эта сетевая обработка добавляет еще большую задержку, если прокси установлен неправильно.
Поскольку вы знаете, что взаимные операции TLS и наблюдаемость увеличивают задержку в нашей обработке.
Итак, что мы можем сделать, так это кэшировать некоторую информацию на уровне Data Plane, чтобы запросу не нужно было отправляться во внешнюю сеть, поэтому я подумал о следующем: Организация смысла глобального кэширования между этими разными сервисами, если это возможно, потому что для некоторых вариантов использования (сценариев) мы не можем реализовать (кэширование)
Для других они полностью приняли концепцию в конечном счете согласованной архитектуры, а задержка — только ее часть.
И так устроен клиент, они это учитывают, так что все получается с небольшой задержкой Мы увидим информацию на стороне клиента, она не обязательно должна быть актуальной, но в конечном итоге она будет согласованной.
При рассмотрении проблемы задержки сервисная сетка может помочь нам найти проблему задержки с помощью ряда методов, которые представляют собой не только задержку сети, но и задержку обслуживания.
Нам нужен механизм наблюдения, чтобы иметь возможность определить, должны ли мы обновлять сервисы, которые уже мешают работе других сервисов. На практике это также позволяет нам реализовать некоторые методы кэширования для повышения производительности нашей архитектуры.
Конечно, поскольку мы запрашиваем на основе сети, мы должны начать с фактического Чтобы различать, какие задержки являются нормальными, а какие нет. если не нормально Затем мы должны обеспечить возможную согласованность системы, и на этой предпосылке мы строим наш клиент.