Здравствуйте, Философ, Вы писали:
DB>>Чаще всего это resume driven development. Но в некоторых случаях бывает и реально полезно.
Ф>Никогда такого выражения не слышал. Оно? Ф>
Ф>résumé driven development
Ф>when you ignore requirements and pick implementation approaches based on how good they look on your resume.
Да, оно. Термин "RDD" (Résumé Driven Development), насколько я помню, сначала появился как камень в огород на "TDD" (Test Driven Development), потом уже прижился и для всего остального.
Здравствуйте, neFormal, Вы писали:
F>а где аргументация?
А где аргументация у того, кто утверждение делал? Микросервисы и кластеризация — ортогональные понятия. Кластеры, нацеленные на резервирование и перформанс это не просто набор разрозненных микросервисов. И даже решения типа Service Fabric эту задачу полностью не решат. Ее надо решать целенаправленно, и микросервисы лишь могут облегчить начало пути, не более.
Здравствуйте, Nuzhny, Вы писали:
N>Как раз масштабироваться проще, а балансировкой нагрузки может заниматься сама ОС. Я, например, разбивал систему видеонаблюдения на множество сервисов, каждый из которых занимался анализом видео с отдельной видеокамеры и записывал архив.
Здравствуйте, Sharov, Вы писали:
НС>>И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек. S>Этого с чего вдруг?
С того что вся система оказывается плотно нанизана на относительно медленную и потенциально ненадежную среду связи. В результате в полныый рост проблемы надежности, латентности, стнхронизации и т.п.
S> Как я понимаю, если в очереди скопилось куча задач, оркестратор(или кто там) автоматически поднимет кол-во обработчиков(т.е. микросервисов) запросов.
Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы.
Здравствуйте, scf, Вы писали:
НС>>А еще снижение стабильности и надежности системы в целом. scf>Исключительно из-за роста сложности или есть другие соображения?
Из педивикии
The microservices approach is subject to criticism for a number of issues:
Services form information barriers
Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
Testing and deployment are more complicated
Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure
Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.
Ну и ссылочку еще добавлю. Оно всегда вылазит, когда мы от хипста-демок переходим к реальным энтерпрайз системам.
Здравствуйте, mrTwister, Вы писали:
K>>К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто). T>Вот этого делать не стоит
Не делай. Конкуренты сделают это за тебя.
T>, так как при недостаточных и неполных данных надо часто рефакторить систему
Надо.
T>, иначе она быстро превратится в помойку, а микросервисы делают рефакторинг оооочень дорогим. T> Микросервисы следует использовать только когда мы точно знаем, что нам надо.
А мы этого не знаем примерно никогда. А потому микросервисы на помоечку.
Здравствуйте, Cyberax, Вы писали:
C>Ну а так какие альтернативы? Дай угадаю! Запихать всё в БД в виде хранимых процедур.
Да тут и гадать нечего, какой нибудь поросший мхом координатор транзакций. И оно вполне работает даже ... если узлов мало, а соединение между ними очень надежное.
Здравствуйте, Hardballer, Вы писали:
S>>В чем смысл микросервисов? H>В практической неработоспособности других подходов к архитектуре, способной обработать десятки(сотни) тысяч команд в секунду с достаточно сложной логикой и быстрым ответом менее чем за 100 мс(а то и 1-10 мс). H>Не существует железа(либо стоит космических денег за миллионы долларов, и то не факт-что верхняя граница производительности проходит на необходимом уровне), способного сделать тоже самое, исполняя монолитное приложение и на одном физическом сетевом стеке (10Гбит канал банально узок, нужны десятки и иногда-сотни каналов).
И при чем тут микросервисы? Ты уже третий тут, кто путает микросервисы и кластеры.
Здравствуйте, a_g_99, Вы писали:
__>Cyberax говорит то что написано в методичках которые ему спустили сверху ленивые люди. Сейчас он тут начнется в следующих постах соловьем песни петь про CAP теорему
Здравствуйте, vsb, Вы писали:
vsb>1. У микросервисов есть чётко очерченные интерфейсы. Твой IAccountService можно прикастовать к AccountService и через reflection поменять ему какие-нибудь приватные переменные, хе-хе.
Это пустые страшилки. С таким уровнем вредительства за распределенные системы браться вообще не надо.
vsb>2. Микросервисы можно писать на разных языках. В том числе плавно переписывая систему, если захочется. В случае монолита это делать гораздо сложней.
Это чего это вдруг?
vsb>3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.
Здравствуйте, Shmj, Вы писали:
S>Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?
Здравствуйте, Cyberax, Вы писали:
C>Ну а так какие альтернативы? Дай угадаю! Запихать всё в БД в виде хранимых процедур.
да что вы со своими БД носитесь как девственники с мохнаткой? боже мой мужикам по 40 лет больше половины жизни прожили и до сих пор мыслят маркетинговыми буклетиками.
Все таки МС молодцы — они сайбас купили раз в 80х и до сих пор его продают без каких либо изменений. И внедрили идею в головы средних людей что БД и транзакции вещи неразделимые. Гениально!
Ну как вас так озарило что транзакция может быть только в БД в виде какой то там процедуры? Но обьясните мне ход вашей мысли принципал инженер Cyberax??
Здравствуйте, Hardballer, Вы писали:
S>>В чем смысл микросервисов? H>В практической неработоспособности других подходов к архитектуре, способной обработать десятки(сотни) тысяч команд в секунду с достаточно сложной логикой и быстрым ответом менее чем за 100 мс(а то и 1-10 мс). H>Не существует железа(либо стоит космических денег за миллионы долларов, и то не факт-что верхняя граница производительности проходит на необходимом уровне), способного сделать тоже самое, исполняя монолитное приложение и на одном физическом сетевом стеке (10Гбит канал банально узок, нужны десятки и иногда-сотни каналов).
Ты всё правильно написал. С поправкой на то, что всё это не имеет никакого отношения к микросервисам, а точнее даже противоречит их концепции.
Смотри, есть старый подход. Это грубо говоря один демон, сидящей на одном компьютере (ну да, таких компьютеров может быть несколько и они даже могут делить нагрузку с помощью какого-то балансировщика, но суть это не меняет).
Есть один современных подход, в котором одна и та же задача исполняется параллельно на множестве компьютеров. Это подход hadoop'а и ему подобных кластеров. И именно этот подход ты описал в своём сообщение. Очень полезная вещь для многих задач с высокой нагрузкой. Причём такой распределённый кластер может служить и числодробилкой и базой данных (nosql) и клиентским сервисом и ещё много чем.
И есть противоположный этому вроде как современных подход (на мой взгляд никчемное убожество) — это когда ты на одной и той же машине (ну да, их таких может быть множество, но это опять же не суть) запускаешь множество демонов разного назначения, которые совместно решают целевую задачу. Это и есть те самые микросервисы.
P.S. Я уже давно (с самого появления моды на эту глупость) с усмешкой наблюдаю за тем, как всеми силами развивают сложнейшие инструменты для управления за получаемой хренью, в то время как для управления моими сайтами (отлично держащие большие нагрузки) легко хватает какой-нибудь простейшего scp/sftp.
Здравствуйте, Ночной Смотрящий, Вы писали:
scf>>Исключительно из-за роста сложности или есть другие соображения?
НС>Services form information barriers
Вообще-то это считается преимуществом НС>Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
Да, но эти затраты невелики и чувствительны исключительно для синхронного кода, когда запросы идут по очереди, а не параллельно. НС>Testing and deployment are more complicated НС>Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure НС>Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.
да, сложно. да, при неправильном разбиении на микросервисы будет много боли
НС>Ну и ссылочку еще добавлю. Оно всегда вылазит, когда мы от хипста-демок переходим к реальным энтерпрайз системам.
я бы сказал, что в реальных системах consistency нужно для небольшого подмножества данных, которое и следует хранить в одной базе с транзакциями. На остальном можно сэкономить, значительно ускорив систему.
Здравствуйте, a_g_99, Вы писали:
__>Ну как вас так озарило что транзакция может быть только в БД в виде какой то там процедуры? Но обьясните мне ход вашей мысли принципал инженер Cyberax??
Я вообще не понимаю твой рвотный поток сознания. В чём вопрос-то?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, vsb, Вы писали:
vsb>>3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.
S>Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?
Точка входа одна. А дальше, тот же самый HAProxy, ELB (или любой другой HW LB). Или просто, DNS на несколько адресов.
Далее, (hash(login) mod N), если межлогинного (социального) взаимодействия между аккаунтами нет. По крайней мере, если нет активного взаимодействия.
Неактивное можно делать на фоне, так как можно чем-то пожертвовать из CAP (теоремы). А в большинстве случаев, это так.
Давайте на примере с нашим ClientService. Вам нужно проверить не занят ли логин. Вы разбили ClientService на несколько серверов, каждый из них имеет свою базу данных. Допустим, на первом сервере хранятся все клиенты, логин которых начинается с буквы "a". Так? Теперь вам нужно проверить не используется ли email. Ваши действия.
Здравствуйте, Shmj, Вы писали:
S>Давайте на примере с нашим ClientService. Вам нужно проверить не занят ли логин. Вы разбили ClientService на несколько серверов, каждый из них имеет свою базу данных. Допустим, на первом сервере хранятся все клиенты, логин которых начинается с буквы "a". Так? Теперь вам нужно проверить не используется ли email. Ваши действия.
Это не микросервисы, а вообще непонятно что.
Для примера, если взять сетевой магазин, то в микросервисной модели будет:
1) Отдельный сервис, отвечающий за поддержку корзины покупок.
2) Отдельный сервис для обработки карточек.
3) Отдельный сервис для валидации адреса доставки.
4) Отдельный сервис для расчёта бизнес-статистики для директора магазина.
...
При этом, сами сервисы могут быть совершенно разными внутри. Тот же сервис обработки карточек может быть хранимков в базе на Oracle, тогда как корзина покупок может лежать в новомодной Mongo и быть распределённой на тысячу узлов.
