Концепция облачных вычислений находится в самом разгаре, но есть еще лишь несколько компаний, которые действительно реализовали крупномасштабные лендинги. Ant, как ранняя испытательная компания в Китае, после более чем двух лет исследований, набор практических решения были депонированы и, наконец, пройдены Тест Double Eleven.
1. Зачем нам нужна Service Mesh?
Зачем нам нужен Service Mesh и в чем его ценность для бизнеса, мы суммировали три момента:
1. Разделение управления микросервисами и бизнес-логики.
2. Единое управление гетерогенными системами.
3. Сетевая безопасность финансового уровня.
Объясняется отдельно ниже.
1. Разделение управления микросервисами и бизнес-логики
До Service Mesh традиционная микросервисная система использовалась командой промежуточного программного обеспечения для предоставления SDK для бизнес-приложений. В SDK были реализованы различные возможности управления сервисами, такие как обнаружение сервисов, балансировка нагрузки, текущее ограничение, маршрутизация сервисов и т. Д.
Во время выполнения код SDK и бизнес-приложения фактически смешиваются и выполняются в одном процессе, и взаимосвязь очень высока, что создает ряд проблем:
-
Стоимость обновления высока. Каждое обновление требует от бизнес-приложений изменения номера версии SDK и повторного выпуска. Возьмем, к примеру, Ant: в прошлом мы ежегодно тратили тысячи человеко-дней на обновление версий промежуточного программного обеспечения.
-
Серьезная фрагментация версии. Из-за высокой стоимости обновления промежуточное ПО будет продолжать развиваться. Со временем это приведет к несовместимости версий и возможностей онлайн-SDK, что затруднит единообразное управление.
-
Эволюция промежуточного программного обеспечения сложна. Из-за серьезной фрагментации версий промежуточное ПО должно быть совместимо с разнообразной логикой старых версий в коде во время процесса прямой эволюции, что похоже на движение вперед с «игом» и не может обеспечить быструю итерацию.
С помощью Service Mesh мы можем удалить большинство возможностей SDK из приложения, дизассемблировать его в независимый процесс и запустить в режиме Sidecar. Внедряя возможности управления услугами в инфраструктуру, предприятия могут больше сосредоточиться на бизнес-логике, в то время как команды промежуточного программного обеспечения могут больше сосредоточиться на создании различных общих возможностей, действительно независимом развитии, прозрачных обновлениях и общей эффективности.
2. Единое управление разнородными системами.
С развитием новых технологий приложения и сервисы на разных языках и в разных фреймворках часто появляются в одной компании. Возьмем, к примеру, Ant. Внутренний бизнес также процветает. Существуют различные направления, такие как интерфейс, рекомендации по поиску, искусственный интеллект и безопасность. Технологические стеки, которые они используют, также очень разнообразны. Помимо Java, есть NodeJS , Golang, Python, C ++ и т. Д. Чтобы иметь возможность управлять этими службами единообразно, мы должны заново разработать полный SDK для каждого языка и каждой платформы. Стоимость обслуживания очень высока, и это также создает большие проблемы для нашей кадровой структуры.
С Service Mesh, встраивая в инфраструктуру возможности управления службами основной части, многоязычная поддержка становится намного проще. Вам нужно только предоставить очень легкий SDK, или даже во многих случаях вам не нужен отдельный SDK. может легко реализовать многоязычный, многопротокольный унифицированный контроль потока, мониторинг и другие требования к управлению.
3. Кибербезопасность финансового уровня
В настоящее время многие компании строят микросервисные системы на основе предположения о «надежности интрасети», однако это предположение может не подходить в контексте текущей крупномасштабной миграции в облако, особенно когда она включает некоторые финансовые сценарии.
С помощью Service Mesh мы можем более легко реализовать идентификацию приложений и контроль доступа. С помощью шифрования данных мы можем добиться полного доверия к ссылкам, чтобы службы могли работать в сети с нулевым доверием и повысить общий уровень безопасности.
2. Масштабная реализация Ant Service Mesh.
Именно потому, что Service Mesh приносит вышеупомянутые преимущества, с начала 2018 года мы начали техническое исследование и мелкомасштабные пилоты-посадки. Однако при первоначальном продвижении с бизнес-командой мы столкнулись с душевной пыткой:
1. Нужно ли бизнесу менять код? Деловая команда ежедневно сталкивается с очень тяжелым бизнесом, и у нее не так много энергии для технической трансформации.
2. Процесс обновления не должен повлиять на мой бизнес. Что касается бизнеса компании, стабильность должна быть на первом месте, и новая структура не может повлиять на бизнес.
3. Другие, что хотите. Подразумевается, что до тех пор, пока мы можем гарантировать, что стоимость трансформации достаточно низкая, а стабильность достаточно хорошая, бизнес-команда по-прежнему готова сотрудничать с нами для внедрения Service Mesh.
Это напоминает мне знаменитую формулу стоимости продукта:
Из этой формулы:
«Новый опыт - старый опыт» - это различные преимущества, которые дает вышеупомянутая Service Mesh, и эту часть ценности необходимо максимизировать.
«Стоимость миграции» относится к различным затратам компании в процессе перехода на новую архитектуру Service Mesh. Эта часть затрат должна быть минимизирована, в основном включая
-
Стоимость доступа: как существующая система получает доступ к Service Mesh? Есть ли трансформация бизнеса?
-
Плавная миграция: многие бизнес-системы уже работают в производственной среде, можно ли их плавно перенести на архитектуру Service Mesh?
-
Стабильность: Service Mesh - это система с совершенно новой архитектурой. Как обеспечить стабильность после миграции бизнеса?
Далее давайте посмотрим, как это делают муравьи.
Стоимость доступа
Поскольку службы Ant единообразно используют структуру SOFA, чтобы минимизировать затраты на доступ для бизнеса, наше решение заключается в изменении логики SDK SOFA для автоматического определения рабочего режима. Когда в операционной среде включена Service Mesh, он автоматически стыкуется с Sidecar, если Service Mesh не включен, он продолжит работу в режиме без Service Mesh. Что касается бизнеса, ему нужно обновить SDK только один раз, чтобы получить доступ без изменения бизнес-кода.
Давайте посмотрим, как SDK соединяется с Sidecar. Во-первых, давайте посмотрим на процесс обнаружения службы:
1. Предполагая, что сервер работает на машине 1.2.3.4 и прослушивает порт 20880, сначала сервер инициирует запрос на регистрацию службы в свой Sidecar и проинформирует Sidecar о службе, которую необходимо зарегистрировать, и порте IP +. (1.2.3.4:20880)
2. Sidecar на стороне сервера инициирует запрос регистрации службы в центр регистрации, сообщая, что служба должна быть зарегистрирована и порт IP +. Однако следует отметить, что регистрация не является портом бизнес-приложения (20880 ), но тот, который контролируется самим портом Sidecar (например: 20881)
3. Вызывающий абонент инициирует запрос на подписку на услугу в свой Sidecar, чтобы сообщить служебную информацию, на которую необходимо подписаться.
4. Сопутствующий элемент на вызывающей стороне подталкивает адрес службы к вызывающей стороне. Следует отметить, что отправленный IP-адрес - это локальный компьютер, а порт - это порт, отслеживаемый сопутствующим элементом на вызывающей стороне (например: 20882).
5. Sidecar на вызывающей стороне инициирует запрос подписки на услугу в центр регистрации, чтобы сообщить информацию об услуге, на которую необходимо подписаться.
6. Центр регистрации помещает служебный адрес в коляску вызывающего абонента (1.2.3.4:20881).
Давайте посмотрим на процесс коммуникации сервиса:
1. Адрес "сервера", полученный вызывающим абонентом: 127.0.0.1:20882, поэтому на этот адрес будет инициирован сервисный вызов.
2. После получения запроса вспомогательный элемент на вызывающей стороне может узнать конкретную служебную информацию, которая должна быть вызвана, путем анализа заголовка запроса, а затем после получения адреса, возвращенного ранее из реестра служб, может быть инициирован настоящий вызов (1.2. 3,4: 20881)
3. После того, как Sidecar сервера получит запрос, он, наконец, отправит запрос на сервер после серии обработки (127.0.0.1:20880)
Посредством вышеуказанного процесса стыковка SDK и Sidecar завершена. Некоторые люди могут спросить, почему бы не принять решение iptables? Основная причина заключается в том, что, с одной стороны, производительность iptables сильно ухудшается при большом количестве конфигураций правил. Другой более важный аспект - это плохой контроль и наблюдаемость, а также трудность устранения проблем.
Плавная миграция
В производственной среде Ant работает множество бизнес-систем со сложными восходящими и нисходящими зависимостями. Некоторые из них являются очень важными приложениями. Небольшое дрожание вызовет сбои. Поэтому для крупных архитектурных преобразований, таких как Service Mesh, плавная миграция является обязательным вариантом, но также необходима для поддержки оттенков серого и отката.
Благодаря центру регистрации, который мы сохраняем в системе архитектуры, решение для плавной миграции является относительно простым и понятным:
1. Исходное состояние
На следующем рисунке показан пример: изначально есть поставщик услуг и вызывающий абонент.
2. Прозрачный перенос абонентов
В нашем решении нет необходимости сначала переносить вызывающую или обслуживающую стороны. Предполагается, что вызывающая сторона хочет сначала перейти на служебную сетку, поэтому, пока для вызывающей стороны включена добавка sidecar, SDK будет автоматически распознать текущий Когда Service Mesh включен, он подписывается и связывается с Sidecar, а затем Sidecar подписывается на услугу и связывается с реальной обслуживающей стороной, в то время как обслуживающая сторона полностью не знает, перешел ли вызывающий. Таким образом, вызывающий может включать Sidecars один за другим в оттенках серого и просто откатиться, если возникнет проблема.
3. Прозрачный поставщик услуг миграции
Предполагая, что сервер сначала хочет перейти на Service Mesh, тогда, пока на сервере включена вставка sidecar, SDK автоматически распознает, что Service Mesh в настоящее время включен, и он будет регистрироваться и связываться с Sidecar, а затем Sidecar будет передавать себя. Поскольку поставщик услуг регистрируется в реестре, вызывающий абонент по-прежнему подписывается на услугу из реестра и совершенно не знает, осуществил ли поставщик услуг миграцию. Таким образом, обслуживающая сторона может по очереди включать Sidecar в оттенках серого и просто откатиться, если возникнет проблема.
4. Конечное состояние
Наконец, достигается конечное состояние, и как вызывающий, так и сервер плавно переходят в Service Mesh, как показано на следующем рисунке.
стабильность
Благодаря внедрению архитектуры Service Mesh мы изначально реализовали разделение приложений и инфраструктуры, значительно увеличив скорость итераций инфраструктуры, но что это означает для стабильности?
В режиме SDK после того, как одноклассники по промежуточному программному обеспечению выпустят SDK, бизнес-приложения будут постепенно обновляться и будут постепенно продвигаться в соответствии с разработкой, тестированием, предварительным выпуском, полутоновым, производственным и другими средами и полной функциональной проверкой. На самом деле существует большое количество студентов, изучающих бизнес, которые помогают тестировать продукты промежуточного слоя, и они постепенно обновляются в небольших масштабах, поэтому риск очень мал.
Однако в архитектуре Service Mesh бизнес-приложения и инфраструктура разделены. Это значительно ускоряет скорость итераций, но также означает, что мы больше не можем использовать предыдущую модель для обеспечения стабильности. Нам нужно не только обеспечить это на этапе исследований и разработок. Во время онлайн-изменений также необходимо контролировать качество продукции.
Учитывая масштаб муравьиных кластеров, онлайн-изменения часто включают сотни тысяч контейнеров.Как обеспечить стабильность такого масштабного обновления? Мы предлагаем следующее решение: автоматические изменения.
Прежде чем разбираться в автоматических изменениях, давайте взглянем на беспилотное вождение.Следующий рисунок определяет уровень зрелости беспилотного вождения, от L0 до L5. L0 соответствует большинству наших текущих режимов вождения.Сам автомобиль не имеет каких-либо возможностей автоматизации и должен полностью контролироваться водителем, а L5 - это высший уровень, позволяющий реализовать настоящее беспилотное вождение. Как и у Tesla, в том виде, в каком мы ее знаем, его автономное вождение находится между уровнями L2 и L3, и он может автономно управлять автомобилем в определенных сценариях.
Мы также обращаемся к этой системе для определения уровня автоматических изменений, как показано на следующем рисунке:
L0: Чистое изменение человеческого тела, работа на черном экране без помощи инструментов
L1: Есть некоторые инструменты, но они не связаны систематически. Людям нужно использовать разные инструменты, чтобы завершить изменение, чтобы обеспечить искусственную градацию серого.
L2: Благодаря предварительным возможностям автоматизации, система может организовать весь процесс изменения сама и имеет возможность принудительно использовать оттенки серого. Таким образом, по сравнению с уровнем L1, человеческие руки свободны, и для одного изменения требуется только одно рабочее задание.
L3: система имеет возможность наблюдать. В процессе изменения, если обнаружено отклонение, пользователь будет уведомлен, и изменение будет заблокировано. Следовательно, по сравнению с уровнем L2, человеческие глаза также освобождены. Не нужно постоянно следить за процессом изменения, но звонить Он должен быть включен, если возникнет проблема, он должен быть вовремя онлайн
L4: Он идет еще дальше. Система способна принимать решения. Когда обнаруживается, что изменение проблематично, система может автоматически обрабатывать и реализовывать самовосстановление, поэтому по сравнению с уровнем L3, человеческий мозг также освобождается. , и изменение может быть выполнено посреди ночи. Если возникнет проблема, система автоматически решит ее в соответствии с заранее определенным планом. Если ее невозможно решить, вам нужно позвонить человеку онлайн для обработки.
L5: Это конечное состояние. После внесения изменений люди могут уйти, а система автоматически выполнит работу и обеспечит отсутствие проблем.
В настоящее время наша самооценка достигла уровня L3, что в основном отражается в:
1. Система автоматически настраивает пакетные стратегии для достижения обязательной серой шкалы.
2. Введена защита от изменений, добавлена предварительная и пост-проверка, а также возможность блокировки изменений вовремя при возникновении проблем.
Процесс защиты от изменений показан на следующем рисунке:
-
После отправки заказа на изменение система разделит изменения на партии и откроет пакетные изменения в соответствии с размерами компьютерного зала, приложения и подразделения.
-
Перед началом каждой смены пакета сначала выполняется предварительная проверка, например, проверка того, является ли текущее время пиковым периодом работы, периодом сбоя и проверкой емкости системы.
-
Если предварительная проверка не пройдена, изменение будет прекращено, а учащиеся, которые изменились, будут уведомлены. Если пройдена, начнется процесс обновления или доступа Mosn.
-
После завершения изменения будет выполнена пост-верификация, такая как бизнес-мониторинг, например, снизилась ли доля успешных транзакций и платежей и т. Д., А также состояние службы, такое как RT, частота ошибок, а также восходящие и нисходящие системы. ., Он также будет связан с сигналом тревоги, чтобы проверить, есть ли ошибка во время изменения и т. Д.
-
Если пост-проверка не пройдена, изменение будет прекращено, и ученики, которые изменились, будут уведомлены.Если проверка пройдена, начнется следующая партия изменений.
Общая структура
Давайте посмотрим на общую архитектуру Ant SOFAMesh. «Двухрежимные микросервисы» здесь относятся к комбинации традиционных микросервисов на основе SDK и микросервисов Service Mesh, так что:
-
Совместимость: приложения в двух системах могут обращаться друг к другу.
-
Плавная миграция: приложения могут плавно перемещаться между двумя системами и могут быть прозрачными и незаметными для восходящих и нисходящих зависимостей.
-
Гибкая эволюция: после реализации взаимосвязи и плавной миграции мы можем выполнить гибкую трансформацию приложений и эволюцию архитектуры в соответствии с реальной ситуацией.
На поверхности управления мы представили Pilot для реализации распределения конфигурации (например, правил маршрутизации сервисов), и по-прежнему сохранили независимый реестр для обнаружения сервисов, чтобы обеспечить плавную миграцию и крупномасштабную посадку.
Что касается данных, мы используем Mosn собственной разработки, который поддерживает не только приложения SOFA, но также приложения Dubbo и Spring Cloud.
Что касается режима развертывания, мы поддерживаем не только контейнеры / k8s, но и сценарии виртуальных машин.
Посадочный масштаб и ценность для бизнеса
В настоящее время Service Mesh охватывает тысячи приложений Ant и обеспечивает полное покрытие основных ссылок. В производстве находятся сотни тысяч модулей. Количество запросов в секунду, обработанных на Double Eleven, достигло десятков миллионов, а среднее время отклика обработки было <0,2 мс. Достигнуты хорошие технические результаты.
С точки зрения бизнес-ценности, благодаря архитектуре Service Mesh мы изначально реализовали разделение инфраструктуры и бизнес-приложений, а возможности обновления инфраструктуры были увеличены с 1-2 раз в год до 1-2 раз в месяц, что не только значительно увеличивает скорость итераций. В то же время, это экономит затраты на модернизацию тысячи человеко-дней всей станции каждый год. С помощью распределения трафика Mosn реализуется сценарий планирования с разделением времени. Это занимает всего 3 мин 40 с. чтобы завершить переключение контейнеров 2w +, сэкономив 3,6 Вт + физических ядер, и реализует двойное продвижение без добавления машин; с точки зрения безопасности и надежности реализованы аутентификация личности, аутентификация службы и шифрование связи, так что служба может работать в нуле- доверительная сеть, которая повышает общий уровень безопасности; с точки зрения управления услугами она быстро подключается к сети Возможности, такие как адаптивное ограничение тока, глобальное ограничение тока, автономное стресс-тестирование и изоляция бизнес-единиц, значительно повысили уровень усовершенствованного управления услугами и принесла большую пользу бизнесу.
3. Взгляд в будущее
В настоящее время мы уже очень ясно видим, что вся отрасль проходит процесс от облачного хостинга до облачного готового к облачному собственному.
Но я хочу здесь подчеркнуть, что мы не технологии ради технологий. Развитие технологий в основном для развития бизнеса. То же самое и с нативными облаками, которые в основном предназначены для повышения эффективности и сокращения затрат, поэтому нативные облака - это не самоцель, а средство.
Благодаря крупномасштабному внедрению Service Mesh мы также сделали твердый шаг в сторону нативной облачной среды и проверили осуществимость. В то же время мы действительно увидели, что после обрушения инфраструктуры и бизнес, и команда инфраструктуры принесла НИОКР и эксплуатацию Повышение эффективности обслуживания.
В настоящее время Mosn в основном предоставляет возможности RPC и MQ. Тем не менее, в бизнес-систему в виде SDK по-прежнему встроено много логики инфраструктуры. Еще предстоит пройти долгий путь, чтобы отделить инфраструктуру от бизнеса, поэтому у нас будет больше возможностей в будущее Sink into Mosn (например, транзакция, кеш, конфигурация, планирование задач и т. д.) для реализации эволюции от Service Mesh к Mesh. Для бизнес-приложений в будущем они будут взаимодействовать с Mosn через стандартизованные интерфейсы, и нет необходимости вводить различные тяжелые SDK, так что Mosn будет развиваться от простого прокси-сервера трафика до промежуточной среды выполнения следующего поколения.
Таким образом можно еще больше уменьшить взаимосвязь между бизнес-приложениями и инфраструктурой, делая бизнес-приложения более легкими. Как показано на рисунке, эволюция от самого раннего монолитного приложения к микросервисам реализовала разделение между бизнес-командами, но не разъединила взаимосвязь между бизнес-командами и инфраструктурными командами. Будущее направление похоже на третье. Как показано на рисунке , мы надеемся, что бизнес-приложения будут двигаться в направлении чистой бизнес-логики (Micrologic) и погрузят всю не связанную с бизнесом логику в Sidecar, чтобы можно было по-настоящему достичь независимого развития бизнеса и инфраструктуры и повысить общую эффективность.
Еще одна тенденция - бессерверность, которая в настоящее время ограничена такими факторами, как размер приложения и скорость запуска.Основной сценарий бессерверного приложения все еще находится в Function.
Однако мы всегда считаем, что Serverless не ограничивается сценарием функций. Его гибкость, бесплатная эксплуатация и обслуживание, а также использование по требованию, очевидно, имеют большее значение для обычных бизнес-приложений.
Поэтому, когда бизнес-приложения переходят на Micrologic + Sidecar, с одной стороны, объем самих бизнес-приложений станет меньше, а скорость запуска увеличится. С другой стороны, инфраструктура также может быть более оптимизирована (например, подключение к базу данных и подготовить заранее. Данные кэша и т. д.), так что обычные бизнес-приложения также могут быть интегрированы в бессерверную систему и по-настоящему пользоваться преимуществами эффективности и затрат, которые приносит бессерверная система.