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).
Я бы сказал, что сложность приложения возрастает. Мало того, что оригинальная сложность перераспределяется, так ещё и дополнительный слой сложности добавляется.
Это решает проблемы конкретных людей, но программисты, которые хотят попробовать микросервисы в проекте на пару человек у меня вызывают недоумение.
что внутренние вызовы в приложении — надёжно
И да, и нет. Внутренний вызов может точно так же упасть — не хватило памяти (и крашнулся весь апликейшен), не хватило стека (и опять операционка убила). Другой вопрос — что, да, подходы обработки локальных вызовов и сетевых немного отличается. Но это не то чтобы краеугольное отличие.
Что такое сервисная сеть