Pull to refresh

Comments 12

Перевод ни к черту. Устоявшейся терминологии нет.
Сервисная сеть? Мне кажется, что в оригинале service mesh имеет более широкое значение, чем просто "сервисная сеть".


шлюзы доставки приложений

WAT???


плоскость управления
компаньоны

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

Главная проблема микросервисов, вне зависимости от используемой технологии, это ненадёжность сети. При том, что tcp нам обещает гарантированную доставку, оно выполняет это обещание только в одном случае — когда мы получили подтверждение отправки. Если подтверждения не было, может быть что угодно — таймауты, полуотправленное сообщение, отправленное сообщение о котором мы не получили подтверждения и т.д.


Это означает, что вместо someclass.do_it(args), который вызывается и выполняется один раз, мы должны изобретать целый идемпотентный протокол, который надо полировать внутри API и внутри клиента. Это очень, очень усложняет процесс.


И никакие прокси-сервера не помогут с решением проблемы того, что внутренние вызовы в приложении — надёжно, а сетевые — нет.

Мне кажется, что это чрезмерное упрощение.
В «жёсткой» модели обработки ошибок — ошибка «RPC» это просто ещё один тип ошибки, который подлежит классификации и обработке. То что внутри процесса таких ошибок не бывает, не отменяет необходимости классифицировать и обрабатывать другие ошибки на границах слоёв, включая те же самые механизмы классификации типа вызова (мутирующий или нет, идемпотентный или нет, кэшируемый или нет, и т.д.).
Напомню что почти под чем угодно, для чего применяются микросервисы, где-то лежит внешнее хранилище данных, а значит что в общем-то, проблемы с сетью рано или поздно превратятся в некий CommunicationException, причём неизвестно где проще его «качественно» обработать — прямо по месту вызова в некоем Repository или в координационном слое, который обладает знанием о том, какую высокоуровневую операцию пытались совершить.
Так что хоть монолит, хоть микросервисы — в распределённых системах наличие ошибок и постоянное состояние отказа части системы это норма (простите за капитанство), и утверждение «сеть ненадёжная» это просто констатация данности, а не аргумент за или против той или иной топологии одного из компонентов приложения.

Мои стандартные рекомендации: dataintensive.net, book.mixu.net/distsys, www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf

Вы не поняли с чем я сравниваю. Я сравниваю сетевое взаимодействие с вызовом функции в программе. Для такой функции есть восхитительные свойства:
а) Функция вызывается ровно столько раз, сколько была вызвана
б) Функция вызывается, если она была вызвана.
в) Функция вызывается тогда, когда была вызвана.


Появление сети превращает "вызов функции" в церемонию, в которой все ритуалы важны. И поддержка at least once (вместо exactly once), и таймауты, и решение проблемы распухания очереди и т.д.


Т.е. чем больше сетевых сервисов в приложении (и я отметаю слово "микро" как buzzword), тем больше мест для таких ритуалов. Обязательных, нарушение которых чревато рантайм-адом.


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

При этом я не считаю что микросервисы это решение всех проблем. Сначала это создание кучи других проблем, из-за того что «клей» для них пока недостаточно коммодитизирован.
Фактически, оправдание для использования микросервисов одно — масштабирование команды разработки темпами, которые превышают допустимые для монолита (грубо говоря «ну и что что-то нас тут всё на рельсах, возьмём вон тех троих и они нам биллинг на .NET Core налабают, а ещё есть на примете отличная команда пайтонистов, которые мастера в аналитике для нашей области»). Иначе микросервисы это слишком дорогой способ самодисциплины для поддержания качества кода, у которого (способа) есть лучшие альтернативы :)

Именно! Все плюсы микросервисной архитектуры — это управление (командой разработчиков) и возможность снизить порог вхождения для джуниоров.


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

Согласен, что сложность программного продукта никуда не исчезает, она просто перераспределяется по слоям абстракций и технологическим средствам (типа этой service mesh).

Я бы сказал, что сложность приложения возрастает. Мало того, что оригинальная сложность перераспределяется, так ещё и дополнительный слой сложности добавляется.


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

Я категорически против это называть микросервисами…
А причины могут многие — некоторые вещи реально на кубернетесе делать проще.

что внутренние вызовы в приложении — надёжно

И да, и нет. Внутренний вызов может точно так же упасть — не хватило памяти (и крашнулся весь апликейшен), не хватило стека (и опять операционка убила). Другой вопрос — что, да, подходы обработки локальных вызовов и сетевых немного отличается. Но это не то чтобы краеугольное отличие.

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

Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
piter.com
Employees
201–500 employees
Registered