СМ, часть 1
сервисная сетка(ServiceMesh) Необычное пламя последних двух лет известно как микросервисная архитектура нового поколения. В ближайшие два месяца я буду систематически писать эту штуку, надеясь дать всем предварительное представление о новейших архитектурных технологиях.
Интернет-компании часто используют многоуровневую архитектуру микросервисов.
По мере того, как объем данных продолжает расти, пропускная способность продолжает расти, бизнес становится все более и более сложным, количество сервисов будет становиться все больше и больше, а слои будут становиться все тоньше.уровень обслуживания данных, также будет полученоуровень бизнес-услуг,Переднее и заднее разделениеи другие иерархические структуры.
Постоянно обнаруживая основное противоречие, извлекая основное противоречие, разрешая основное противоречие, архитектура развивается естественным образом, микросервисная архитектура,В чем может быть главный потенциальный конфликт?
Представляя микросервисную архитектуру, обычно вводится структура RPC для завершения всего процесса вызова RPC.
Как показано в розовой части рисунка выше, RPC делится на:
RPC-клиент, встроенный в вызывающий процесс
RPC-сервер, основа сервисного процесса
Не только микросервисы, MQ также представляет собой похожую архитектуру:
Как показано в розовой части рисунка выше, MQ делится на:
MQ-send-client
MQ-server
MQ-recv-client
Фреймворк — это только первый шаг, будет добавляться все больше и больше функций, связанных с RPC и микросервисами.
Например:балансировки нагрузки
Если вы хотите расширить несколько схем балансировки нагрузки, например:
голосование
случайный
по модулю
Согласованное хеширование
RPC-клиент нуждается в обновлении.
Например:Сбор данных
Если вы хотите собирать время обработки RPC-интерфейса для реализации унифицированного мониторинга и сигнализации, вам также необходимо обновить RPC-клиент.
-
Время обработки перспективы клиента
-
Время обработки перспективы на стороне сервера
Другой пример:обнаружение службы
Добавляется новый экземпляр службы, и центр конфигурации уведомляется о нем.Центр конфигурации уведомляет зарегистрированного RPC-клиента, отправляет трафик во вновь запущенный экземпляр службы и быстро завершает расширение.
Другой пример:отслеживание цепочки звонков
Если вы хотите отслеживать цепочку вызовов с полной связью, необходимо обновить и RPC-клиент, и RPC-сервер.
Следующие функции:
балансировки нагрузки
Сбор данных
обнаружение службы
отслеживание цепочки звонков
…
На самом деле они не являются бизнес-функциями, поэтому интернет-компании обычно имеют технический отдел, аналогичный «архитектурному отделу», для разработки и обновления соответствующих функций, в то время как технический отдел бизнес-направления напрямую использует соответствующие фреймворки, инструменты и платформы, чтобы пользоваться ими. различные «черные технологии» «Удобство.
Идеально! ! !
В идеале очень пухлые, а в реальности очень худенькие, потому что:
RPC-клиент, встроенный в вызывающий процесс
RPC-сервер, основа сервисного процесса
Часто встречаются следующие проблемы:
Бизнес- и техническим командам по-прежнему нужно тратить время на изучение и использование базовых фреймворков и различных инструментов, а не направлять свою энергию на бизнес и продукты.
Клиент должен поддерживать m версий, сервер должен поддерживать n версий, а совместимость должна тестировать m * n версий.
Если вы хотите поддерживать разные языки, вам часто нужно разрабатывать многоязычные версии C-клиента, Python-клиента, go-client, Java-клиента.
Каждый раз, когда обновляется «черная технология», необходимо продвигать вверх и вниз по течению обновления.Этот цикл часто составляет квартал, полугодие или даже дольше, а общая эффективность крайне низка.
Есть ли какие-то решения этих проблем, этих общих болевых точек?
Одна из идей состоит в том, чтобы разделить службу на два процесса и разделить их.
Процесс реализует бизнес-логику (будь то вызывающая сторона или поставщик услуг),biz, то есть белый квадрат на картинке выше
Процесс реализует базовую технологическую систему,proxy, то есть синий квадрат на картинке выше
Biz и proxy родились вместе, умерли вместе и развернули друг друга локально, то есть пунктирная рамка на рисунке выше.
Между бизом и прокси именно локальная связь, то есть черная стрелка на картинке выше
Вся связь между biz осуществляется через прокси, а между прокси есть удаленное соединение, то есть красная стрелка на рисунке выше
Таким образом, "бизнес принадлежит бизнесу, технология принадлежит технологии", и достигается полная развязка. Если все узлы разъединить, вся архитектура превратится в:
зеленый для бизнеса
синий это прокси
Весь сервисный кластер стал сеткой, которая является источником сервисной сетки Service Mesh.
Эволюция архитектуры бесконечна, болевых точек много, естественно требуется послойная развязка. Я надеюсь, что все что-то получили, а о деталях дизайна и архитектуры SM я расскажу позже.
идеиважнее заключения.
Путь Архитектора- Делитесь техническими идеями