Здравствуйте, Shmj, Вы писали:
S>Давайте на примере с нашим ClientService. Вам нужно проверить не занят ли логин. Вы разбили ClientService на несколько серверов, каждый из них имеет свою базу данных.
Здравствуйте, Ночной Смотрящий, Вы писали:
scf>>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.
НС>Это и есть обещанная изоляция по данным?
Изоляцию обещали не между экземплярами микросервиса, а между микросервисами.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vsb, Вы писали:
vsb>Над DNS обычно мало контроля. Протокол старинный, мало кто готов написать DNS-сервер со своей логикой. С точки зрения клиента ещё хуже, общеупотребительные библиотеки кешируют ответы, если есть промежуточный сервер, он тоже может закешировать и тд. Это удобно, когда нужно абсолютный минимум от масштабирования. Но если тебе надо направлять на нужный сервер в зависимости от значения HTTP Cookie, то, конечно, тут уже DNS не подойдёт.
если срезать время кэширования, то запрашивать будут каждый запрос.
но это ТАКОЕ количество запросов, что днс-сервак начинает сжирает проц. в остальном для внутренних нужд свой днс написать очень легко.
Здравствуйте, scf, Вы писали:
scf>>>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД. НС>>Это и есть обещанная изоляция по данным? scf>конкретные претензии есть, или опять "голословно" "фигня" и поиск каких-то авторитетов, как будто своих мозгов нет?
Здравствуйте, neFormal, Вы писали:
F>"распределённый конфиг" — это что-то типа NoSQL-бд.
Необязательно. Например, в некоторой бразильской речной компании используют gossip-схему. Для каждого узла назначается список buddy-узлов и они обмениваются блоками информации. В блоках содержатся данные координаторов и маска активности узлов кластера.
Здравствуйте, Cyberax, Вы писали:
F>>"распределённый конфиг" — это что-то типа NoSQL-бд. C>Необязательно. Например, в некоторой бразильской речной компании используют gossip-схему. Для каждого узла назначается список buddy-узлов и они обмениваются блоками информации. В блоках содержатся данные координаторов и маска активности узлов кластера. C>См.: https://en.wikipedia.org/wiki/Gossip_protocol
угу, шарить можно разными способами.
с БД это просто самое наглядное.
Здравствуйте, Kernan, Вы писали:
C>>Ну как обычно — eventual consistency, идемпотентные запросы и фоновые reconciler'ы. K>Как оно реализуется на практике? Чере ещё один микросервис?
Нет, силами самого сервиса.
C>>А кто говорил, что будет легко? K>Фаулер говорил
Сервисная архитектура — это очень непростая вещь. Она требует планирования и большого опыта для правильного дизайна. Потому она оправдана только для уже реально больших и сложных приложений, над которыми работают множество команд.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а)всех хостов, реализущих данный сервис? НС>Нет. Он вернет какой то один. Называется round robin dns. Я ссылку выше давал, сходи и почитай.
можно же и весь список запросить. RR просто прокручивает список на каждом запросе.
Здравствуйте, namespace, Вы писали:
N>Средний такой pet-project(англ. проект собачьей будки) содержит около ~20 микросервисов, в каждом сервисе обычно от 3 до 50 строк кода.
Здравствуйте, Sharov, Вы писали:
S>Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А. S>Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B. S>И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?
Обратится к сервисам B, C, D. В чём проблема?
Именно так и работают все современные системы — когда вы размещаете заказ в веб-магазине, там за кадром участвуют сервисы процессинга кредитных карт и служб доставки.
Не говоря уже обо всяких левых штуках типа "программы лояльности" и гугл-аналитики. При этом все эти сервисы, естественно, сидят за load balancer-ами.
На всякий случай подчеркну: речь не про микросервисы, а про совершенно обычную крупноблочную SOA.
Микросервисы — они совсем не про это.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>В чем смысл микросервисов?
Смысл в том, что еще одно техническое решение, подход. Со своими достоинствами и недостатками. И если для конкретной задачи достоинства перевешивают недостатки сильнее, чем у других подходов, имеет смысл использовать именное его.
Здравствуйте, Dym On, Вы писали:
S>>В чем смысл микросервисов? DO>Смысл в том, что еще одно техническое решение, подход. Со своими достоинствами и недостатками. И если для конкретной задачи достоинства перевешивают недостатки сильнее, чем у других подходов, имеет смысл использовать именное его.
А можно вопрос? В чем смысл твоего сообщения? Этот коммент можно написать в ответ на почти любой топик в этом форуме с аналогичным успехом.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А можно вопрос? В чем смысл твоего сообщения? Этот коммент можно написать в ответ на почти любой топик в этом форуме с аналогичным успехом.
Совершенно верно, но именно такой ответ может быть на такой
S>В чем смысл микросервисов?
вопрос.
Задаешь общий вопрос, получаешь общий ответ. На тему «В чем смысл микросервисов» можно монографию в 5 томах написать, и то не осветишь все тонкости и нюансы. В сообщении на форуме получить исчерпывающий ответ не возможно, а неисчерпывающий бесполезен, ибо вопрос задан не в практической плоскости, а скорее в риторической. Следовательно и вопрос «В чем смысл твоего сообщения?» можно задать к любому сообщению в этой теме, например, к твоему
Здравствуйте, Dym On, Вы писали:
НС>>А можно вопрос? В чем смысл твоего сообщения? Этот коммент можно написать в ответ на почти любой топик в этом форуме с аналогичным успехом. DO>Совершенно верно, но именно такой ответ может быть на такой DO>
S>>В чем смысл микросервисов?
DO>вопрос.
Этот ответ может быть на любой вопрос. При этом вопрос, в отличие от ответа, вполне осмысленен, и предполагает в ответе описание границ применимости.
DO>Задаешь общий вопрос, получаешь общий ответ. На тему «В чем смысл микросервисов» можно монографию в 5 томах написать, и то не осветишь все тонкости и нюансы.
Это вряд ли. Ну и много не надо, можно осветить ключевые моменты. Впрочем, про пять томов как единственный возможный нормальный ответ — это тоже ответ на заданный вопрос.
Здравствуйте, Shmj, Вы писали:
S>Зачем все это? Ради чего?
Если они тебе не нужны — не используй.
Не в каждом приложении обосновано использование микросервисов. Учитывая, что при создании микросервисной архитектуры с нуля, самое трудное провести границы разделов для микро-сервисов
На мой взгляд микросервисы обоснованы в случае, когда в монолитном приложении проглядываются незвасимые части.
Это даже можно понять, проведя мысленный эксперимент: выносим модуль Х в отдельный сервис, если его падение, не затронит работоспособность остального монолита и остальный пользователей — модуль Х кандидат в микросервисы.
Плюсы:
— Горизонтальная масштабируемость. Для каждого сервиса можно определить кластер и выполнять балансировку нагрузки именно для этого микросервиса.
— Падение одно сервиса не означает падение других сервисов. Если используются надежные очереди, то после рестарта, упавший сервис продолжит оработку данных.
— Каждый сервис может пилиться независимыми командами.
Минусы:
— Сложность в администрировании и контроле зоопарка из сервисов
— Команды, пилящие микросервисы, должны иметь чуть-более высокую культуру разработки. Нельзя просто так взять и грохнуть поле команды или сделать вновь добавленное поле команды обязательным. И еще возникает необходимость в интеграционных тестах.
В общем, как и во всем ИТ, нет серебряной пули. Есть выбор одного из как минимум двух решений, и нет такого решения, в коором бы ты получил все, не потеряв ни чего :)
НС>Этот ответ может быть на любой вопрос. При этом вопрос, в отличие от ответа, вполне осмысленен, и предполагает в ответе описание границ применимости.
Вот это вряд ли. Когда мы хотим узнать границы применимости, мы говорим где мы их хотим узнать. Границы применимости это весьма конкретная характеристика задачи. Смотрим ТЗ, задаемся вопросом: «В чем смысл микросервисов для данной конкретной задачи?» В этом случае можно рассчитывать на конкретный ответ.
А вот когда задается вопрос вообще, это больше похоже на наброс, с целью разжигания срача. Поскольку, отвечающие будут предлагать границы применимости, исходя из своих конкретных задач, которые оспариваются другими отвечающими, исходя из своих конкретных задач. Не, на такое обсуждение иногда любопытно посмотреть, но конструктивным он бывает редко.
PS Хотя для анализа «кто чем занимается» такой вопрос годится.
Здравствуйте, Cyberax, Вы писали:
K>>Как оно реализуется на практике? Чере ещё один микросервис? C>Нет, силами самого сервиса.
Как это выглядит на практике? Вот есть у меня 10 инстансов сервиса аутентификации, причём физически они могут распологаться на разных серверах. Как оно должно работать? C>>>А кто говорил, что будет легко? C>Сервисная архитектура — это очень непростая вещь. Она требует планирования и большого опыта для правильного дизайна. Потому она оправдана только для уже реально больших и сложных приложений, над которыми работают множество команд.
Да если бы так. Сейчас чуть ли не каждый "школьник" пытается своять микросервисную систему и задеплоить её через Kubernetes. Зачем так делать, не ясно.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А. S>>Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B. S>>И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?
S>Обратится к сервисам B, C, D. В чём проблема?
А нет проблемы, но как оне будет находится? По статичному конфигу, dns, rp? Я так понял, что все-таки через RP.
Здравствуйте, white_znake, Вы писали:
_>- Команды, пилящие микросервисы, должны иметь чуть-более высокую культуру разработки. Нельзя просто так взять и грохнуть поле команды или сделать вновь добавленное поле команды обязательным. И еще возникает необходимость в интеграционных тестах.
За счет версионирования api, это сделать как раз просто. Меняем нужные поля, инкрементируем версию api. При этом желательно, чтобы старая версия работала.
