0. Предисловие
На рынке есть много статей, которые знакомят с концепцией, архитектурой, методологией и стандартизированной реализацией Servicemesh, но мы мало упоминали о том, как Servicemesh должен быть реализован эффективно и надежно. С этой точки зрения в этой статье мы надеемся обсудить, как лучше перевести систему на архитектуру Servicemesh, основываясь на опыте автора и подводных камнях в производственной среде. Эта статья предназначена для студентов, которые имеют определенное представление о концепции Servicemesh или хотят изучить эту область.
1. Взгляд на изменение концепции управления услугами
Прежде чем говорить о Servicemesh, давайте взглянем на историю управления услугами. Все мы знаем, что разработка сервисов состоит из монолитных приложений, стратификации уровня сервисов, вертикальной сегментации сервисов и даже появления идеи микросервисов."две недели"Правила рефакторинга и“Две пиццы”Ослепительные методологии разделения услуг, такие как команды, заполняют ваши уши и глаза. Это общие аргументы, но не в центре внимания этой главы. В этой главе больше внимания уделяется ключевой проблеме, с которой необходимо столкнуться в процессе разработки и разделения управления услугами: «Как будут формироваться связи после разделения услуг?», а именно:
Как сформировать сеть сложных сервисных узлов?
Из-за ограниченности места давайте кратко рассмотрим несколько важных соображений по этому вопросу.
1.1 Server Proxy
Я назову это фазой централизованного агентства. Этот этап также является самым простым решением, и централизованный одноточечный сервисный кластер в основном используется для выполнения дополнительных функций управления сервисами. Например, наиболее распространенным способом является централизованное развертывание Lvs, Nginx, Haproxy, Tengine, Mycat, Atlas, Codis и т. д. Преимущество этого метода в том, что он удобен для централизованного обслуживания функций, независим от языка и низкой стоимости запуска, поэтому имеет большую аудиторию в крупных, средних и малых компаниях, особенно в стартапах. Но и проблемы, которые это приносит, также очевидны, причем самые популярныеДоменное имя + вызов Http Rest + комбинированный пакет NginxНапример, ссылка на вызов должна пройти через несколько уровней DNS (кэш DNS), KeepAlived (Lvs) и Nginx. Длинные линии связи и несколько одноточечных систем вызовут проблемы со стабильностью и производительностью при увеличении масштаба службы. Подобные отдельные точки отказа случались много раз в Tintin Rental и Meituan. Ding Ding Renting когда-то оказала крупномасштабное влияние на бизнес из-за сбоя Nginx, DNS и Codis-Proxy. DNS, MGW и т. д. Meituan столкнулись с аналогичными проблемами и соответственно были запущены.Перейти к вызову Http в интрасети для прямого подключения Thriftтехнологические проекты. В целом, это должно быть полезно.Это больше подходит для стартапов или особенно для сценариев межъязыковых приложений.Прокси-сервер можно использовать как быстрое решение. Однако при его использовании необходимо иметь четкое представление о его недостатках, чтобы принимать правильные решения в последующей эволюции.
1.2 Smart Client
Простой и прямой прокси-сервер приносит нам удобство, но также приносит нам много проблем.В это время, чтобы справиться с такими проблемами, Smart Client быстро поднялся и расцвел своей мощной жизненной силой. Назовем его этапом кадрирования.Чтобы решить проблему одноточечных длинных ссылок, существующих в прокси-сервере, этот этап заменяет прямое соединение для построения соединения между двумя узлами. Этот шаг полностью решает проблему одноточечных длинных ссылок и может обеспечить большую оптимизацию производительности и улучшение стабильности на основе прямого подключения. Представленные продукты с открытым исходным кодом (инфраструктура услуг или структура Rpc) включают Ring-pop от Uber, Dubbo от Ali, Sofa-Rpc от Ant, Dangdang от Dubbox, Motan от Weibo, Pigeon/Zebra от Dianping, brpc/Stargate от Baidu, Grpc, Thrift и т. д. Есть две большие идеи:
1. Если жесткого недостаточно, то переходим к мягкому.Если аппаратное управление услугами не работает, перейдите к программному управлению услугами.
2. Если дистанции не хватает, то поворачиваем на ближнюю.Метод удаленного централизованного развертывания не работает, тогда тяните его в процесс приложения вместе со мной и развертывайте.
Таким образом, многие недостатки в направлении мышления прокси-сервера были решены один за другим.
Преимущества Smart Client проповедуются уже давно, так что с ним проблем нет? Она все еще должна существовать, и проблема тоже очень очевидна и видна.
Что касается первого аспекта, мы знаем, что характер микросервисной области имеет тенденцию быть автономным. Smart Client также называют полноценным клиентом, и применение этого подхода серьезно ограничит наш выбор в стеке технологий.Смена языка требует повторной реализации всех основных возможностей управления и нескольких наборов языков, которые будут добавлены позже. расходы на техническое обслуживание и модернизацию с меньшими затратами являются непосильным бременем для большинства компаний. Uber пришлось запустить версии node и go для Ring-pop, Motan от Weibo также запустил несколько языковых версий, Grpc и Thrift также не избежали этой участи. Сейчас большинство компаний смешивают более двух языков для фактической разработки. Так что этот вопрос тоже надо решать.
С другой стороны, Smart Client встроен в прикладной процесс для сосуществования с помощью мощного SDK, который полностью смешивает эксплуатацию и обслуживание управления услугами с обслуживанием бизнес-приложений. В реальных рабочих сценариях это на несколько порядков увеличивает сложность эксплуатации и сопровождения управления сервисом.Команде управления сервисом приходится сталкиваться с сосуществованием нескольких версий архитектурного кода и с кошмаром, что на это может уйти более полугода. реализовать одну версию.
Конечно, несмотря на вышеперечисленные проблемы, Smart Client по-прежнему занимает основное место в бизнес-сценариях с высокой степенью параллелизма и большим трафиком, потому что не существует зрелой альтернативы. Также можно использовать сценарии, в которых язык может максимально сходиться. Например, можно использовать Java-версию Smart Client, а Http Rest плюс доменные имена можно использовать для управления скомпрометированными службами при низком трафике Nodejs.
1.3 Local Proxy
И у прокси-сервера, и у Smart Client есть неизбежные проблемы, так есть ли другие решения? В ответ на эту проблему появился локальный прокси.Поскольку централизованное развертывание имеет проблему с одной точкой, а полнофункциональные клиенты имеют проблемы с сопряжением, почему бы не пойти на компромисс? Тогда мышление становится:
Близость к управлению на уровне процессов. То есть метод локального прокси-сервера на уровне процесса позволяет избежать проблемы централизованного одноточечного развертывания и избежать проблем, связанных с языком и сопряжением приложений.
Эта идея постепенно стала популярной, и на ее основе возникло множество планов управления.
SmartStack от Airbnb использует набор из четырех элементов для завершения всего процесса управления основной цепочкой услуг, что является простым решением.
Ctrip OSP также использует аналогичный метод для решения этой проблемы.Основное отличие от airbnb заключается в том, что вместо этого функции Synapse и Haproxy интегрированы в прокси.
В облачной сфере, поскольку кросс-язык и эффективность эксплуатации и обслуживания рассматриваются с более важной точки зрения, такое мышление еще более доминирует.В облачной архитектуре Mesos+Marathon есть аналогичные решения, использующие Haproxy для маршрутизации, центральный узел управления обновит соответствующую информацию о маршрутизации.
То же самое и с K8s, собственным сыном Google, с учетом производительности Proxy делается компромисс, и для переадресации используется внедрение правил Iptables (конечно, этот метод также имеет неизбежные проблемы).
Эти методы имеют свои соответствующие проблемы, но самая большая из них:
Как исправить падение производительности, которое оно вызывает. Независимо от того, используется ли для управления, пересылки и связи iptables или агент, существует проблема, которой нельзя избежать: насколько велика потеря производительности в сценариях с высоким трафиком и высокой степенью параллелизма? Насколько велик разрыв в производительности по сравнению со многими приложениями, которые уже оснащены Rich Client Direct? Некоторые из известных на сегодняшний день продуктов имеют большие потери в QPS и RT при высоком трафике, а некоторые решения позволяют добиться потери производительности даже в 20%, что во многих сценариях заведомо неприемлемо.
В это время на первый план был официально выдвинут последний убийца Local Proxy — Servicemesh, а 2018 год также называли первым годом Servicemesh. На мой взгляд, идея такова:
1. Принесение в жертву определенной производительности и ресурсов в обмен на высокую степень автономности и работоспособности общего управления службой;
2. Разделение исполнения и управления, разделение плоскости данных и плоскости управления;
3. Виртуализируйте, стандартизируйте, создайте продукт и определите спецификации.
Сервисная сетка освобождается от загроможденного и неорганизованного мышления, связанного с локальным прокси, и предлагает более систематическое мышление. В этой статье не предполагается делать более концептуальные описания Servicemesh, в Интернете есть немало подобных статей, которые не будут здесь расширяться из-за нехватки места. В результате Istio (чья первоначальная цель — помочь приложениям лучше перемещаться в облако), которая сотрудничала со многими гигантами, оказалась впереди, а другие компании также создали свои собственные решения, основанные на Isito:
- Али переписал Envoy на основе golang и построил на этой основе Sofa-Mosn/Pilot;
- Понизить текущую ограничивающую способность широко оклеветанного Mixer в Istio;
- Tencent трансформирует и интегрирует внутреннюю структуру услуг TSF на основе Envoy;
- Weibo разработала Motan-Mesh на основе Motan-Go и интегрировала собственную систему управления услугами;
- ServiceComb от Huawei тоже похож, Mixer полностью тонет;
- Twitter запустил Conduit, основанный на Rust, а также тонущий Mixer;
- ...
Тем не менее, у Servicemesh все еще есть несколько нерешенных проблем.Помимо проблем с производительностью, которых нельзя избежать, все больше и больше людей в настоящее время размышляют о проблеме с сеткой:
Каковы критерии для резки панели управления и панели данных? Это слишком идеалистично?
Этот вопрос в настоящее время является предметом обсуждения и не будет здесь распространяться. Хотя Servicemesh все еще находится в зачаточном состоянии и многие проблемы все еще исследуются, с точки зрения тенденции развития сферы микросервисов три концепции Servicemesh, упомянутые выше, совпадают с ней, и это должно быть общей тенденцией в будущем.
1.4 Резюме
В этой главе рассматривается процесс разработки управления услугами, и он прошел через три основных этапа размышлений. Мы возвращаемся к первоначальному замыслу. Мы видим, что на каждом этапе схемы на самом деле есть свои применимые и неприменимые сценарии. Нет лучшей схемы, только самое подходящее решение. Мы также можем проследить логику этих трех этапов и обнаружить, что на самом деле управление службами также находится в процессе повторяющихся исследований, запутывания и восхождения по спирали.
2. Учитывали ли вы потребление ресурсов?
Сетка по сути паразитирует на бизнес-машинах. Используются ресурсы бизнес-машины. В реальном тесте было обнаружено, что потребление памяти сеткой, реализованной на C++/go, относительно управляемо: по умолчанию оно занимает всего несколько M, а при высокой степени параллелизма оно обычно увеличивается только до десятков M. Это в основном незначительно для прикладных машин с памятью 8G/16G в нормальных условиях. Таким образом, проблему использования лишней памяти можно в основном игнорировать. Однако потребление им ресурсов ЦП относительно велико, обычно приближаясь к количеству ресурсов ЦП, обычно используемых бизнесом. Это означает, что после добавления сетки бизнес может использовать только половину исходных ресурсов ЦП. Это довольно большая проблема.
По этому вопросу основная дискуссия в настоящее время в отрасли полагает, что, поскольку коэффициент использования ресурсов обычных бизнес-машин составляет менее 10%, дополнительное занятие этой части не окажет существенного влияния на бизнес в реальных ситуациях, но позволит нас к большему Эффективно используйте простаивающие ресурсы и избегайте потерь. Бизнес и сетка взаимовыгодны и взаимовыгодны.
Эта логика, безусловно, останется верной еще долгое время. Однако, я думаю, исходя из этой логики, возникнут две новые проблемы:
- Ресурсы не простаивают бесконечно. Мы заметили, что из-за вовлеченного распределения затрат все больше и больше деловых сторон уделяют все больше и больше внимания использованию ресурсов.Кроме того, одной из целей облачных технологий, основной тенденции в будущем, является увеличение коэффициента использования машинных ресурсов. В соответствии с этой тенденцией, когда однажды проблема использования ресурсов будет решена относительно правильно, проблема использования ЦП сеткой станет заметной.Как эта проблема будет решаться в то время? Если сетка привязана к одному ядру ЦП или отделена от каждого ресурса бизнес-экземпляра путем привязки одного ресурса модуля, это неизбежно приведет к большому количеству отходов.
- В дополнение к показателю использования ресурсов существует также проблема пиков и спадов бизнеса.. Все мы знаем, что бизнес имеет свои взлеты и падения. Например, бизнес по доставке еды находится на пике каждый день, гостиничный бизнес — в праздничные дни, а бизнес по продаже билетов в кино — во время Весеннего фестиваля. Имеются высокие и низкие пики, указывающие на необходимость соответствующей избыточности ресурсов. Поэтому, хотя коэффициент использования ресурсов не высок, он действительно достигает пика, и ресурсы системного процессора некоторых предприятий будут расти или даже приближаться к полной В этом случае, если вводится сетка, прямое ощущение со стороны бизнеса:Пиковая пропускная способность бизнес-процессов падает вдвое. Я считаю, что деловая сторона выскажется неприемлемым, услышав этот вывод. Как бороться с этой проблемой в настоящее время? Помимо удвоения мощности бизнес-стороны, есть ли решение?
Это кажется неразрешимым предложением, потому что архитектура servicemesh такова. Это ресурсы, и они не появятся из воздуха. Однако автор хотел бы спросить, можем ли мы сломать архитектуру servicemesh или оптимизировать архитектуру servicemesh?
Давайте рассмотрим три важных направления мысли, о которых мы упоминали ранее, когда рассказывали об истории управления услугами:
Server Proxy
Smart Client
Local Proxy
Servicemesh — это один из локальных прокси-серверов, который может решить проблемы сильной связи с бизнес-стороной, сильной языковой корреляции и единой точки. Но разве другие направления мысли бесполезны? Очевидно, что нет. Другие методы по-прежнему обладают сильной жизненной силой и ценностью существования. Наше решение заключается в использовании прокси-сервера в качестве восходящего решения, когда свободных ресурсов недостаточно.логическиЦентральная сетка для решения вышеуказанных проблем:
- Sidecar обнаруживает простаивающие ресурсы
- Когда он обнаружит, что простаивающих ресурсов будет недостаточно, скажите SDK переключить трафик на Central Mesh.
- Central Mesh выполняет всю работу для Sidecar.
Central Mesh загружается всей информацией, необходимой в этом районе, и предполагает все возможности Sidecar. То есть Central Mesh также служит резервной копией sidecar в той области, где он расположен, и активно переключает трафик, когда sidecar выходит из строя или свободных ресурсов недостаточно для нормальной работы sidecar.
Причина, по которой Central Mesh называется «логической», заключается в том, что Central Mesh не обязательно представляет собой набор центральных кластеров, но может быть развернут поблизости, чтобы свести к минимуму задержку в сети и дополнительные риски, связанные с одной точкой. Например, его можно развернуть на хосте по машинному залу, по региону, по шлюзу или даже поблизости.
3. Рассматривали ли вы потерю производительности?
Потеря производительности — неизбежная проблема. Из-за еще одной переадресации и управления услугами производительность, естественно, хуже, чем у прямого метода RPC. Основываясь на наших реальных результатах теста производительности, по сравнению с прямым подключением, производительность в сетевом режиме ухудшится примерно на 20-50%.Это все еще тест без использования iptables, который более требователен к производительности. Конечно, эта увеличенная задержка находится на уровне миллисекунд, что на самом деле приемлемо для большинства бизнес-требований. Влияние на эффективность бизнеса минимально.
Тем не менее, нам все еще необходимо рассмотреть следующие потенциальные проблемы:
- проблемы с бизнес-приложениями.Для некоторых бизнес-сценариев с высокой степенью параллелизма сама задержка может быть небольшой (на уровне миллисекунд) и чувствительной к задержке. Кроме того, может быть семь или восемь или даже более десяти вызовов RPC на канал вызова. При использовании этого метода обновление может привести к серьезному ухудшению такой производительности бизнеса и даже может вызвать такие проблемы, как тайм-аут и переполнение пула потоков.
- Основные проблемы приложения.Если будущая тенденция сервисной сетки состоит в том, чтобы связать весь коммуникационный трафик, а не только трафик бизнес-приложений, то нам также необходимо учитывать.Например, после объединения трафика хранилища, который чрезвычайно чувствителен к задержкам, таким как redis, мы не сможем использовать сетку. пропускная способность.Допустимость дополнительных задержек будет дополнительно снижена. Сам Redis представляет собой сцену со сверхвысоким параллелизмом, чрезвычайно низкой задержкой и очень чувствительной к задержке. Дополнительная миллисекунда задержки может привести к удвоению доступности Redis или даже к сбою в бизнесе.
Поэтому в ответ на вышеперечисленные проблемы, с одной стороны, нам нужно иметь психологические ожидания снижения производительности, с другой стороны, мы должны сделать все возможное, чтобы оптимизировать или даже сократить лимит производительности сервисной сетки, а не отказываться от производительности. если мы выберем сетку. Вспомним знаменитый «выбор цикла событий» Netty, который максимально выжимает производительность.
Есть несколько моментов, которые можно учитывать при оптимизации производительности ячеистой связи:
- Оптимизация локальной связи процесса. Поскольку сетка находится на том же компьютере, что и бизнес-процесс, у нее есть предпосылки для использования локальной связи процесса для повышения производительности связи. Существует множество способов взаимодействия локальных процессов, таких как mmap, доменный сокет unix, канал, сигнал и т. д. Среди них наибольшей производительностью обладает mmap. traffic-shm — асинхронный фреймворк IPC без блокировок, который может легко поддерживать миллионы TPS.Он использует mmap для связи. Благодаря реальному тесту с использованием mmap в сочетании с соответствующим механизмом уведомления о событиях в некоторых сценариях с высоким параллелизмом его производительность будет улучшена более чем на 30% по сравнению с методом tcp.
- резьбовая модель. Нижний уровень базовых высокопроизводительных сервисов использует шаблон Reactor для реализации модели потоков. Конечно, с пулом потоков/пулом сопрограмм и уровнем Reactor может быть несколько путей реализации. Существует модель одного основного многоподпроцесса + одиночный поток Reactor (более высокая версия обеспечивает механизм пула потоков), например, Nginx, evio и Envoy используют «одиночный пул сопрограмм Reactor (пул потоков)», Netty использует многоуровневый Reactor + многоуровневый пул потоков. Избегайте блокирующих конструкций для сеток.
- повторное использование байта. Мы привыкли создавать новое пространство для каждого запроса для хранения некоторой информации. Однако при увеличении объема параллелизма такое выделение пространства приведет к увеличению накладных расходов на производительность и необходимости повторного использования. Следовательно, на основе партнерского алгоритма, алгоритма Slab или других методов выделение и управление одним байтом использования памяти принесет вам большую пользу. Например, Netty использует партнерский алгоритм, поскольку он применяется для памяти вне кучи, Nginx использует механизм slab, а Mosn представляет многоуровневую емкость и механизм sync.Pool, основанный на механизме распределения Golang для оптимизации.
- выравнивание памяти. Операционная система управляет памятью с точки зрения страниц. Если вы напрямую манипулируете адресом памяти для передачи данных (например, с помощью mmap), то при отсутствии выравнивания памяти это приведет к тому, что вы вытащите ненужное пространство памяти, и возникнут дополнительные накладные расходы на перемещение памяти и объединение, что напрямую привести к падению вашей производительности. Высокопроизводительная очередь памяти Disruptor также оптимизирована за счет выравнивания памяти.
- без замков. Первой реакцией на общение является решение проблемы безопасности параллелизма.Во многих случаях для обеспечения безопасности может потребоваться использование блокировок. В настоящее время рассмотрите возможность использования операции CAS на аппаратном уровне для замены обычной операции блокировки.Вы также можете использовать однопоточный метод обработки, такой как Redis, или Envoy использует пул потоков, но соединение будет выполнять однопоточную привязку. операция, чтобы избежать проблем с параллелизмом.
- объединение. Ресурсы потоков очень ценны, и их невозможно применить для десятков тысяч самих потоков, поэтому пул потоков является стандартом по умолчанию. О чем я хочу здесь рассказать, так это о том, что, например, если вы используете технологию сопрограмм, хотя сопрограмма обожествлена в легковесный поток, производительность очень высока, и вы можете легко открыть десятки тысяч, не меняя лица. Но вы должны знать, что это также серьезно повлияет на вашу реальную производительность обработки, и из-за принципа распределения сопрограмм самого golang некоторые метаданные сопрограммы не будут переработаны после использования, это связано с идеей разработчика golang: Раз такой трафик достигнут, значит, система может снова столкнуться с таким флудом, так что будьте готовы заранее». Так что нам все еще нужно рассмотреть проблему пулинга для сопрограмм. Golang-версии Motan-Go и Thrift в настоящее время не учитывают этого, в то время как Sofa-Mosn сделал соответствующий пул.
Существует множество других методов оптимизации производительности, которые здесь не будут перечислены.
4. Взаимодействие функций Sidecar
Одно из первоначальных намерений нашей сервисной сетки — решить текущую ситуацию сильной связи с бизнесом и снизить возможности управления услугами. Однако при погружении мы обнаружили, что само управление услугами также включает в себя множество вещей, динамическую настройку, управление потоком, автоматический выключатель, отработку ошибок, балансировку нагрузки, маршрутизацию, связь, обнаружение регистрации службы, централизованный журнал, распределенную цепочку, дорожные вызовы, мониторинг. закопанные точки и т.д. Все это добро втирается в тонкую коляску. Когда мы делаем это, нужно ли нам также начинать исследовать, есть ли подобные проблемы среди столь многих функций самого управления услугами, которые вызовут взаимное вмешательство, зависимость, влияние и даже конфликты на организационном и техническом уровнях? Да, это вопрос, который будет расширяться.
- Например, как гарантировать, что крупномасштабный, но неважный трафик сбора журналов вообще не повлияет на основной бизнес-трафик?
- Например, как гарантировать, что обновление определенной функции не повлияет на основное деловое общение?
- Например, как несколько команд могут вместе поддерживать Sidecar?
- ...
Выше перечислены все возможные проблемы.Конечно, вы можете использовать изолированную кабину, вы можете использовать горячее развертывание и вы можете найти способ разделить хранилище кода. Однако, когда все идет ко дну, сможете ли вы действительно хорошо решить вышеупомянутые проблемы, имея набор возможностей из семи или восьми команд, которыми нужно управлять и поддерживать вместе?
В такие моменты мы рекомендуем разбирать коляску. Возьмите определенные правила и разберите свою коляску на основе стадии разработки вашей сетки. Может разобрать и все получится. Во время написания этой статьи я увидел, что Sofa-mosn из Ant Financial разобрал отдельный dbmesh.
Следует отметить, что нецелесообразно разбирать слишком много колясок, иначе это приведет к затоплению колясок и высокой стоимости эксплуатации и обслуживания модернизаций. Вот видите, это похоже на процесс сервисизации, в процессе "сноса и сноса", упрощая проблемы и привнося новые проблемы одновременно? В этом прелесть нашего бизнеса, потому что всегда можно найти сходство в, казалось бы, несвязанных местах.
5. Ответственность только за подписку на услуги, но не за выпуск услуги?
Pilot может подписаться на услуги и подключиться к системе интерфейса XDS. Но почему нет возможности сделать регистрацию в сервисе? Автор предполагает, что это связано с тем, что Servicemesh развивается на основе локального прокси в контексте облачных технологий. В облачном нативном решении Local Proxy в принципе не отвечает за регистрацию сервиса, т.к. они будут передавать регистрацию сервиса в облако (у Mesos, Marathon, K8s и т.д. есть готовые решения) для реализации, либо вообще будут совмещать консул /etcd/zk отделяет агента для завершения регистрации службы. В это время Local Proxy просто фокусируется на работе обратного прокси.
А это, для нашей реальной производственной среды, не так уж и дружелюбно. Поскольку бизнес развивается до определенного этапа, он, как правило, имеет собственный набор схем управления услугами и принимает собственный метод регистрации услуг и подписки. Маловероятно, что они перенесут всю систему подписки на сервис и систему публикации в облачную систему, чтобы объединить управление сервисом, а это значит ставить телегу впереди лошади. Поэтому выбор адаптации неизбежен. В процессе адаптации, чтобы использовать сервис для подписки и публикации, им пришлось глубоко преобразовать Sidecar, добавить возможность регистрации сервисов, а затем позволить Sidecar подключаться к стороннему центру регистрации. Хотя работа громоздкая и сложная, она также нарушает первоначальное намерение Servicemesh скрыть различия инфраструктуры от уровня управления.
Поэтому автор считает, что Servicemesh необходимо полностью заблокировать существование конкретного реестра. Публикация и подписка должны проходить через Pilot, предоставляя потребителям единый фасад. Как бы реестр не переключался в дальнейшем, нет необходимости глубоко вторгаться и модифицировать Sidecar.
6. Как вырезать панель управления и панель данных?
Это давняя проблема. Микшер на панели управления теперь в основном находится в точке «Стена вниз, и все толкают». Istio единолично выделяет его, имея дело с такими вещами, как текущее регулирование и телеметрия данных. Первое принесет много узких мест в производительности (даже если Istio добавит в Envoy механизм кэширования в будущем), второе приведет к двойному потреблению трафика. Многие реализации Servicemesh отказываются от Mixer или упрощают его. Соответствующих статей в Интернете много, поэтому я не буду их здесь повторять.
Хотя такой дизайн Istio слишком идеален, он надеется таким образом скрыть различия в инфраструктуре, а затем обеспечить поддержку неограниченного объема памяти для Sidecar, и в то же время максимально исключить некоторую сложную и изменчивую логику из Sidecar, чтобы обеспечить что коляска полностью может быть стабильной и надежной. Но реальность все же очень жестока, и там, где есть общение, будут проблемы. Большая часть сложности распределенной среды связана с сетью.
И если Mixer тонет, приходится сталкиваться с различной сложной логикой: как сделать так, чтобы сам Sidecar был достаточно стабильным и надежным, потреблял достаточно ресурсов, вводил как можно меньше зависимостей, был достаточно маленьким и красивым?
Хотя контролировать интервью и вырезание панели данных сложно, и Istio также вызывает некоторые нарекания, но с точки зрения первопроходцев, Istio успешно интегрировала решение Local Proxy, которое разрабатывалось в течение длительного времени, и будет ли оно поднялся на вершину методологии и успешно запустил системное мышление в отрасли о панелях управления и панелях данных. Это самый большой вклад Istio. Это переход от тактики к стратегии и инновации от методов к даосизму.
7. Заключение
Мы проанализировали некоторые проблемы, которые могут возникнуть при разработке Servicemesh, с разных точек зрения. Предлагаются некоторые решения, основанные на реальном производственном опыте, в надежде помочь каждому. Конечно, любой выбор сложен, и у нас нет стандартного ответа.Как совместить реальную ситуацию каждой компании с компромиссом, это то, где отражаются способности и ценность. Хотя у Servicemesh есть некоторые проблемы, это должно стать общей тенденцией будущего развития. Это может принести нам великое воображение и человеческое освобождение.