Здравствуйте, Shmj, Вы писали:
S>Зачем все это? Ради чего?
1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро. Именно микросервисная архитектура готова к таким проблемам из коробки. Также из коробки она готова к эксплуатации в режиме 24*7 без простоев;
2) Возможность изолировать различные команды и различную логику. Писать на том языке, который лучше подходит под задачу.
Естественно есть и недостатки у такой архитектуры. Ибо увеличение сложности на ровном месте, затраты на коммуникации, нужна облачная инфраструктура. Потому вообще все проекты фигачить как микросервисы — это полный идиотизм. Если есть возможность сделать проект как монолит — лучше проект сделать как монолит, а не плодить сущностей. Но не всегда можно обойтись монолитом.
А вообще, для многих задач хорошо в свое время подходила просто сервисная архитектура. Если имеем распределенные системы, эта SOA уже в мейнстриме лет 15 минимум. Но когда эта SOA стала приобретать популярность, необходимым аттрибутом этой SOA стали тяжеленные сервера приложений. В результате рестарт приложения занимал иногда часы. Микросервисная архитектура — это тоже SOA, но на более легких решениях. Не нужна тяжеленная дорогущая промышленная шина, можно использовать легкую опенсорсную бесплатную библиотеку, и самому разобраться в нормальной документации, а не платить бешенные деньги за техподдержку какого то монстра, который к тому же глючит и тормозит. Простейшие микросервисы поднимаются вообще мгновенно. Тяжелые сервисы тоже никуда не делись, от них никуда. Но так как теперь сервисы стало писать и обслуживать гораздо легче, стало легче дробить функционал на сервисы. Некоторые сервисы по прежнему довольно тяжелые, и поднимаются довольно долго. Но у них строго один функционал, и время подъема зачастую там из за того, что идет пересчет каких то показателей, выполнение различных расчетов, поднятие и построение первичного кеша и т.д. Сами коммуникации то поднимаются мгновенно.
Ну а вообще, эта микросервисность появилась как ответ на решение проблем производительности всяких фейсбуков, твиттеров, гуглов и т.д. Где миллиарды пользователей и относительно простой функционал. И весь современный хайп идет оттуда.
Здравствуйте, a_g_99, Вы писали:
__>Ну как вас так озарило что транзакция может быть только в БД в виде какой то там процедуры? Но обьясните мне ход вашей мысли принципал инженер Cyberax??
Я вообще не понимаю твой рвотный поток сознания. В чём вопрос-то?
Здравствуйте, Shmj, Вы писали:
S>В чем смысл микросервисов?
S>Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?
S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.
S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.
S>Зачем все это? Ради чего?
— Повторное использование. микросервисы проще использовать повторно, чем библиотеки, т.к. библиотеке нужна конфигурация, конкретные зависимости, иногда конкретная платформа или ОС.
— Версионирование. Можно развернуть несколько версий микросервиса и использовать их совместно из множества приложений. С библиотекой это сложнее.
— Изоляция по данным. Это очень важно, т.к. маленькую БД намного легче поддерживать, оптимизировать и кешировать.
— Изоляция по коду. При рефакторинге можно не затрагивать другие микросервисы по принципу "работает — не трогай". При наличии хорошей документации можно использовать микросервис без необходимости смотреть исходный код.
Еще побочные плюсы, вытекающие из микросервисной архитектуры:
— Масштабирование. В целом, монолитные приложения масштабируются хорошо, в отличие от огромной БД монолитного приложения. И наличия внутреннего состояния, которым грешат монолиты.
— Жесткие границы отдельных микросервисов, препятствующие превращению системы в лапшу.
— Устойчивость к отказам. Отказ от транзакций и необходимость тщательной обработки ошибки позволяет строить системы, адекватно реагирующие на перегрузку и отказ отдельных компонентов.
И минусы:
— Сложность. Микросервисная архитектура требует огромных вложений в единую архитектуру системы, девопс, мониторинг, логгирование и аналитику.
— Еще раз сложность. Правильно разбить еще не написанное приложение на микросервисы — задача нетривиальная и при ошибке реализация каждой фичи затрагивает множество микросервисов, что серьезно стопорит разработку
— И еще раз сложность. Отказ от распределенных транзакций и сетевое взаимодействие требуют очень вдумчивого подхода к обработке ошибок.
В монолите ты можешь, например, переименовать метод и тебе для этого понадобится секунда или две. Для того, чтобы переименовать метод микросервиса тебе придется пройти через такой геморрой, что проще воообще не рефакторить. А если тебе надо перераспределить ответственности между микросервисами? Что проще, выделить новую ответственность в монолите (новый класс в коде), или выделить новый микросервис?
Здравствуйте, Shmj, Вы писали:
S>Давайте на примере с нашим ClientService. Вам нужно проверить не занят ли логин. Вы разбили ClientService на несколько серверов, каждый из них имеет свою базу данных. Допустим, на первом сервере хранятся все клиенты, логин которых начинается с буквы "a". Так? Теперь вам нужно проверить не используется ли email. Ваши действия.
Это не микросервисы, а вообще непонятно что.
Для примера, если взять сетевой магазин, то в микросервисной модели будет:
1) Отдельный сервис, отвечающий за поддержку корзины покупок.
2) Отдельный сервис для обработки карточек.
3) Отдельный сервис для валидации адреса доставки.
4) Отдельный сервис для расчёта бизнес-статистики для директора магазина.
...
При этом, сами сервисы могут быть совершенно разными внутри. Тот же сервис обработки карточек может быть хранимков в базе на Oracle, тогда как корзина покупок может лежать в новомодной Mongo и быть распределённой на тысячу узлов.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Shmj, Вы писали:
S>>Зачем все это? Ради чего? E>1) Ради масштабирования
Я думаю, сэр, вы гоните дичь. Причём тут масштабирование, если это МИКРОсервисы? Каждый ест по чуть-чуть. Можно, конечно, отловить самый прожорливый микросервис, но боюсь, узкое горлышко будет совсем в другом месте.
E>...Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев
И чо? Подними хоть тысячу, КТО будет распределять по ним нагрузку?? Значит, перед каждым микросервисом тебе придётся ставить диспетчер! Не жирновато для такой проблемы?
E>2) Возможность изолировать различные команды и различную логику. Писать на том языке, который лучше подходит под задачу.
Упаси небо! Вот эти тухлые "архитекторы", "подбирающие язык под задачу" — главная проблема развала проектов. Для 99.999% приложений обычный ЯОН решает всё. Он потому и называется "общего назначения". Профи в десяти языках не существует, есть ОДИН профильный язык, на котором человек думает и пишет. Как только в проект вносят ещё один язык, на проект сразу взваливают ещё одну ненужную проблему — поддержку этого языка, т.е. людей. Люди — это ВСЕГДА ПРОБЛЕМА. При тысячах резюме, подходят по уровню лишь десятки. И только паре из них можно навешать второстепенную задачу "вы тут микросервисом позанимайтесь". Причём отдавать этот сервис студоте вы явно не захотите. Ну а кто мнит себя даже "просто разрабом", хочет за свои услуги будто он всю систему писал! И даже согласные могут заболеть, найти лучшую вакансию и т.п. В команде 10 джавистов вы всегда найдёте, кому перекинуть сервис. В команде 10 джавистов и два Перловика ваш "перлосервис" будет дамокловым мечом — заслуженным наказанием за свою бестолковость "язык под задачу". По этой фразе можно сразу увольнять с работы, моё мнение.
E>Ну а вообще, эта микросервисность появилась как ответ на решение проблем производительности всяких фейсбуков, твиттеров, гуглов и т.д. Где миллиарды пользователей и относительно простой функционал. И весь современный хайп идет оттуда.
Микросервисы там вообще не причём. Их главная задача — масштабирование и решается она куда проще.
Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?
Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.
Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.
K>Упаси небо! Вот эти тухлые "архитекторы", "подбирающие язык под задачу" — главная проблема развала проектов. Для 99.999% приложений обычный ЯОН решает всё. Он потому и называется "общего назначения". Профи в десяти языках не существует, есть ОДИН профильный язык, на котором человек думает и пишет.
Кстати, хотел тебя спросить про c# -- оно еще не сдохло?
Здравствуйте, klopodav, Вы писали:
K>Если заложиться, что система будет построена на микросервисах — как минимум, можно начать варганить эту систему и потом относительно безболезненно пристегивать к ней новую функциональность по мере развития. (это , конечно, не единственный способ решения проблемы, но один из).
Ты путаешь логическую и инфраструктурную структуру. Для вышесказанного достаточно логического разбиения на изолированне контрактами модули. Физически резать инфраструктуру на куски нет нужды.
Здравствуйте, Cyberax, Вы писали:
C>Ну а так какие альтернативы? Дай угадаю! Запихать всё в БД в виде хранимых процедур.
да что вы со своими БД носитесь как девственники с мохнаткой? боже мой мужикам по 40 лет больше половины жизни прожили и до сих пор мыслят маркетинговыми буклетиками.
Все таки МС молодцы — они сайбас купили раз в 80х и до сих пор его продают без каких либо изменений. И внедрили идею в головы средних людей что БД и транзакции вещи неразделимые. Гениально!
Ну как вас так озарило что транзакция может быть только в БД в виде какой то там процедуры? Но обьясните мне ход вашей мысли принципал инженер Cyberax??
Здравствуйте, Философ, Вы писали:
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), потом уже прижился и для всего остального.
S>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?
Эмм. Вы смешиваете три несвязанные вещи.
1. Микросервисы
2. Highload
3. DNS
Что может мне помешать поставить взрослый load-balancer с фиксированным IP-адресом и раскидывать запросы по стоящим за ним серверам? Вот есть, к примеру, очень популярный сервис с общеизвестным адресом 8.8.8.8 — чем вам не highload? При этом никаких микросервисов там нет, и никакого round-robin тоже нету.
Никто не может мне помешать делать "внешний" load-balancing путём возврата 302 на входящие запросы, раскидывая клиентов по настоящим адресам сервис-нодов.
И это мы ещё даже не начали копать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.
да, в большинстве случаев так лучше и не стоит связываться с микросервисами.
S>Зачем все это? Ради чего?
микросервис имеет смысл если есть следующее (то чем мы руководствувоемся у себя):
— когда функционал микрососервиса может быть довольно хорошо изолирован/выделен и имеет ограниченное взаимодействие с данными основного, желательно чтоб его действия не были частью другой более высокоуровневой транзакции (иначе надо решать доп. сложности как откатить его действия при отмене внешней транзакции).
— когда его пилит другая команда/компания и есть причины чтоб не делать это в исходниках одного проекта.
— когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача.
Здравствуйте, Sharov, Вы писали:
S>Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А. S>Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B. S>И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?
У каждого сервиса собственный LB, для остальных сервисов он выглядит монолитом. В чем проблема?
Здравствуйте, 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.
Ну и ссылочку еще добавлю. Оно всегда вылазит, когда мы от хипста-демок переходим к реальным энтерпрайз системам.
Здравствуйте, Sharov, Вы писали:
S>Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса.
Это называется "round-robin load balancer", его ещё называют "балансировщиком для бедных". Просто регистрируем N A- (или CNAME) записей для одного и того же хостнейма, которые бы стреляли в разные IP адреса.
Теперь у нас при каждом запросе эти IP адреса будут отдаваться более-менее равномерно.
Настоящий load balancer отличается от вот этого подобия вот чем:
1. Умеет отключать вышедшие из строя сервера (обращение к мёртвому серверу стоит клиенту длительного таймаута)
2. Умеет отслеживать фактическую нагрузку
3. Умеет поддерживать session и client affinity
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>В чем смысл микросервисов? S>Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем? S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия. S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять. S>Зачем все это? Ради чего?
Здравствуйте, Nikita Lyapin, Вы писали:
NL>Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.
Далее, сервисы нужны, если функциональность для них достаточно обширная. При этом снаружи они, действительно, могут выглядеть как get/set методы.
Sapienti sat!
Re: Связанность, design-time и run-time зацепление
Микросервисы это инструмент позволяющий увеличить связанность и уменьшить зацепление на верхнем уровне архитектуры.
Высокая связность и низкое зацепление показатель качества любой архитектуры.
Микросервисы позволяют уменьшить не только design-time, но и run-time зацепление.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, klopodav, Вы писали:
K>К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто).
Вот этого делать не стоит, так как при недостаточных и неполных данных надо часто рефакторить систему, иначе она быстро превратится в помойку, а микросервисы делают рефакторинг оооочень дорогим. Микросервисы следует использовать только когда мы точно знаем, что нам надо.
Здравствуйте, Sharov, Вы писали:
T>>а микросервисы делают рефакторинг оооочень дорогим. S>Можно ентот тезис подробнее раскрыть?
тут смотря что подразумевать под "рефакторингом".
если разделение на сервисы плохое, то переделывать всё будет дорого. на границах сред всегда всё дорого.
там и протоколы надо менять, и роутинг, и гейты, и деплой...
Здравствуйте, Sharov, Вы писали:
_>>- Команды, пилящие микросервисы, должны иметь чуть-более высокую культуру разработки. Нельзя просто так взять и грохнуть поле команды или сделать вновь добавленное поле команды обязательным. И еще возникает необходимость в интеграционных тестах. S>За счет версионирования api, это сделать как раз просто. Меняем нужные поля, инкрементируем версию api. При этом желательно, чтобы старая версия работала.
Возникает необходимость поддержки нескольких версий API и их взаимодействие, что не так уж просто. Вроде как добавили обязательное поле, но из-за того, что старая версия всё ещё должна работать — поле по факту-то не обязательное. А если у разных пользователей API разный ЖЦ, то в итоге можно получить десяток одновременно живущих версий и тогда проще застрелиться.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Аноним931, Вы писали:
А>Но юные хипстеры ВНЕЗАПНО А> — обозвали эту схему красивым словом А> — объявили чем-то принципиально новым А> — забили все интернеты своими высерами о том, как это круто и какие лохи те, кто это не использует
Юные хипстеры эту схему реально довели до ума. В частности:
1) Начали разбираться с трассировкой и отладкой: https://opentracing.io/
2) Управление траффиком, в том числе throttling и load shedding: https://linkerd.io/
3) Субстрат, на который легко разворачивать приложения (Docker, Kubernetes).
Здравствуйте, Sharov, Вы писали:
S>Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А. S>Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B. S>И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?
— сервис A делает запрос на какой-то адрес, там его встречает балансер инстансов сервиса B
— балансер смотрит на какие-нить признаки и выбирает инстанс-обработчик, прокидывает ему запрос
— инстанс получает запрос, выполняет действия, возвращает ответ
— сервис A получает свой ответ
Здравствуйте, neFormal, Вы писали:
F>·>Скажем, есть сервис сбора статистики о заказах. И вдруг понадобилось помимо содержимого заказа иметь информацию о стране доставки заказа. Никакой полной отвязки быть не может, ибо нам надо всё ещё собирать статистику по всем заказам, а не только по тем, которые присылаются новыми клиентами. Значит мы так или иначе должны проапрейдить всех клиентов, ну или делать изменение неломающим и "страна доставки" будет опциональной. А опциональность не всегда возможна. Например, требование страны может быть наложено регулятором для отслеживания выполнения требований санкций — и тут выбор, либо ты нафиг ломаешь всех клиентов, либо ты прикрываешь свой бизнес. F>хороший пример. F>а как такое решается? с точки зрения бизнеса. F>как можно заставить кучу клиентов обновиться, и что делать, если кто-то не хочет или не торопится? F>какой запас времени нужно дать клиентам? и поддерживаются ли в это время две версии?
В данном случае относительно просто — регулятор обычно явно обозначает даты, к какому сроку всё должно быть сделано — и приходится просто отрубать non-compilant клиентов.
А в общем случае — надо сразу продумывать и проговаривать с клиентами полный жизненный цикл сервиса, включая decommission старых версий. И для клиентов, любящих старые версии — устанавливать платный long term support.
Просто надо понимать, что "мы просто оставим старую версию запущенной" это по сути один из способов неявно превратить обязательный параметр в опциональный, и, кстати, не самый лучший по многим критериям.
Обычно лучше работает A/B-feature подход — выкатываем новую версию в B, переключаем постепенно всех клиентов с A на B, выключаем А. А в следующий раз выкатываем очередную новую версию в А и т.д. В таком случае явно ограничивается количество одновременно работающих версий двумя.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Kernan, Вы писали:
K>Как это выглядит на практике? Вот есть у меня 10 инстансов сервиса аутентификации, причём физически они могут распологаться на разных серверах. Как оно должно работать?
Ну, например — как Active Directory
У него есть интервал синхронизации, ЕМНИП — 15 минут. Изменения плавно реплицируются.
Есть сложности, когда хочется организовать что-то типа транзакции — например, создать пользователя И добавить его в группу.
Если не приседать, то есть шанс при втором запросе нарваться на user not found.
Для таких штук применяют, например, короткоживущий токен, который возвращает первая операция.
Если у нас есть inter-operation dependency, как в этом примере, то мы отправляем токен при втором запросе, и роутинг связывает нас с тем же инстансом, что и при предыдущем запросе.
Через 15+ минут токен теряет валидность, т.к. мы знаем, что всё уже отреплицировалось, поэтому злоупотребить affinity не выйдет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.
S>Зачем все это? Ради чего?
Ради того, чтобы развязать жизненные циклы компонент. То есть чтобы они могли разрабатываться и деплоиться независимо друг от друга. Это позволяет более эффективно масштабировать процесс разработки.
Полной независимости, конечно, достичь не получится, и придется иногда по необходимости вводить точки синхронизации при изменениях, ломающих совместимость. Но это стараются делать пореже.
К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто).
Часто бывает такая ситуация: в начале проектирования системы видно, что функцию A надо делать вот так, функцию B надо делать примерно вот так, функцию C надо делать пока что хрен знает как, но она должна быть; вместо функции D надо пока сделать заглушку, а функция E, возможно, появится в будущем. И нагрузка на эту функциональность будет пока что непонятно какая.
Если заложиться, что система будет построена на микросервисах — как минимум, можно начать варганить эту систему и потом относительно безболезненно пристегивать к ней новую функциональность по мере развития. (это , конечно, не единственный способ решения проблемы, но один из).
Здравствуйте, Kolesiki, Вы писали:
K>Я думаю, сэр, вы гоните дичь. Причём тут масштабирование, если это МИКРОсервисы? Каждый ест по чуть-чуть. Можно, конечно, отловить самый прожорливый микросервис, но боюсь, узкое горлышко будет совсем в другом месте.
Как раз масштабироваться проще, а балансировкой нагрузки может заниматься сама ОС. Я, например, разбивал систему видеонаблюдения на множество сервисов, каждый из которых занимался анализом видео с отдельной видеокамеры и записывал архив. Система стала легко масштабироваться и выиграла в надёжности: сбои, к сожалению, могут случаться и в этом случае просто перезапускался процесс, занимающийся анализом с конкретной видеокамеры. Надо больше камер? Ставим больше серверов. Стало реально проще.
Здравствуйте, Shmj, Вы писали:
vsb>>3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.
S>Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?
account-api.mysite.com на одном компьютере, mysite.com на другом, reports.mysite.com на третьем. aссount-api2.mysite.com это уже другой уровень масштабирования, для такого действительно нужно писать специальный код и никакого преимуществе перед монолитом тут нет, т.к. монолит со специальным кодом тоже можно запускать на нескольких серверах.
Здравствуйте, Sharov, Вы писали:
S>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.
Неудобно != невозможно. Существуют вполне себе готовые архитектуры, которые именно так и работают.
Вы же понимаете, что DNS — это не чудо господне, а всего лишь распределённая иерархическая СУБД? Причём у неё единожды и навсегда зафиксированная архитектура.
Поэтому если вас не устраивает тот механизм распространения, который применяется в DNS, то нет ничего сверхъестественного в использовании своей собственной архитектуры по распространению изменений.
И опять-таки: DNS не является ни единственным, ни самым лучшим механизмом балансирования нагрузки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sharov, Вы писали:
S>А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а)всех хостов, реализущих данный сервис?
Нет. Он вернет какой то один. Называется round robin dns. Я ссылку выше давал, сходи и почитай.
S> Я так понимаю, что в основе всех S>высоконагруженных сервисов и тем более микросервисов находится dns.
Нет. Это самый примитивный и старый способ. В современных сервисах как правило используется reverse proxy с набором правил и health check.
Здравствуйте, vsb, Вы писали:
vsb>Над DNS обычно мало контроля. Протокол старинный, мало кто готов написать DNS-сервер со своей логикой. С точки зрения клиента ещё хуже, общеупотребительные библиотеки кешируют ответы, если есть промежуточный сервер, он тоже может закешировать и тд. Это удобно, когда нужно абсолютный минимум от масштабирования. Но если тебе надо направлять на нужный сервер в зависимости от значения HTTP Cookie, то, конечно, тут уже DNS не подойдёт.
если срезать время кэширования, то запрашивать будут каждый запрос.
но это ТАКОЕ количество запросов, что днс-сервак начинает сжирает проц. в остальном для внутренних нужд свой днс написать очень легко.
Здравствуйте, 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.
Микросервисы — они совсем не про это.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Kernan, Вы писали:
S>>·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь. S>>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше. K>Если микросервис полностью отвязан от остального как это и дожно быть, то нет никаких препятствий использовать старую версию сервиса другими командами или компаниями до тех пор пока они не созреют для перехода.
Такое реально только в тривиальных случаях. А в тривиальных случаях почти все способы работают, неинтересно.
Скажем, есть сервис сбора статистики о заказах. И вдруг понадобилось помимо содержимого заказа иметь информацию о стране доставки заказа. Никакой полной отвязки быть не может, ибо нам надо всё ещё собирать статистику по всем заказам, а не только по тем, которые присылаются новыми клиентами. Значит мы так или иначе должны проапрейдить всех клиентов, ну или делать изменение неломающим и "страна доставки" будет опциональной. А опциональность не всегда возможна. Например, требование страны может быть наложено регулятором для отслеживания выполнения требований санкций — и тут выбор, либо ты нафиг ломаешь всех клиентов, либо ты прикрываешь свой бизнес.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
E>>1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро. НС>И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек. E>> Именно микросервисная архитектура готова к таким проблемам из коробки. Также из коробки она готова к эксплуатации в режиме 24*7 без простоев; НС>Нет, не готова.
Здравствуйте, Shmj, Вы писали:
S>В чем смысл микросервисов?
В практической неработоспособности других подходов к архитектуре, способной обработать десятки(сотни) тысяч команд в секунду с достаточно сложной логикой и быстрым ответом менее чем за 100 мс(а то и 1-10 мс).
Не существует железа(либо стоит космических денег за миллионы долларов, и то не факт-что верхняя граница производительности проходит на необходимом уровне), способного сделать тоже самое, исполняя монолитное приложение и на одном физическом сетевом стеке (10Гбит канал банально узок, нужны десятки и иногда-сотни каналов).
Здравствуйте, Shmj, Вы писали:
S>Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?
вы вообще слышали про envoy? господи как страшно жить когда такие имитации называют себя "программист", "инженер" и пр. У вас вообще есть самосознание? Вы понимаете что вы Хомо Эректус?
Здравствуйте, a_g_99, Вы писали:
__>·>А что же тогда? EJB/XA? Открой тайну-то! __>Вы друг мой смотрите на 25 лет назад, а вам надо взглянуть на 10 лет назад хотя бы. Ну про современные подходы я не буду говорить, ни к чему вам этим голову забивать раз у вас какой микрософт и EJB в голове
Так что же тогда? Рафты и прочие консенсусы? Просвети уж убогих.
__>·>Понятно. По сути сказать ничего не можешь. __>так было бы с кем поговорить я бы поговорил . а так времени жалко тратить на ликбезы
А тебя сюда никто не приглашал, ты сам припёрся и всё слюной забрызгал.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, a_g_99, Вы писали:
__>пиши еще принципал инженер Cyberax! а потом Панкай или Раджеш с компании Х приходит и ты думаешь — ну е мае люди так нужны, что бы полегче спросить?? а вот транзакция — проще простого? __>что такое транзакция Панкай? И он гордо в ответ — вестимо антипаттерн — это мне мой принципал инженер обьяснил!
И что дальше-то? Как это опровергает то, что транзакции в распределённых системах не работают?
Здравствуйте, Nuzhny, Вы писали:
N>Как раз масштабироваться проще, а балансировкой нагрузки может заниматься сама ОС. Я, например, разбивал систему видеонаблюдения на множество сервисов, каждый из которых занимался анализом видео с отдельной видеокамеры и записывал архив.
Здравствуйте, Hardballer, Вы писали:
S>>В чем смысл микросервисов? H>В практической неработоспособности других подходов к архитектуре, способной обработать десятки(сотни) тысяч команд в секунду с достаточно сложной логикой и быстрым ответом менее чем за 100 мс(а то и 1-10 мс). H>Не существует железа(либо стоит космических денег за миллионы долларов, и то не факт-что верхняя граница производительности проходит на необходимом уровне), способного сделать тоже самое, исполняя монолитное приложение и на одном физическом сетевом стеке (10Гбит канал банально узок, нужны десятки и иногда-сотни каналов).
И при чем тут микросервисы? Ты уже третий тут, кто путает микросервисы и кластеры.
Здравствуйте, Shmj, Вы писали:
S>Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?
Здравствуйте, Аноним931, Вы писали:
А>Ну то есть схема, которая уже не первое десятилетие спокойно и без лишнего шума широко используется там, где она нужна — и не используется там, где она не нужна.
А>Но юные хипстеры ВНЕЗАПНО
Ты про SOA? Это близко, но не совсем то. У SOA фокус на повторное использование сервисов и создание приложений на единой платформе, используя сервисы в качестве кирпичиков. В микросервисной архитектуре плевать на повторное использование сервисов и единую платформу, фокус на изолированность и независимость сервисов друг от друга при максимальной декомпозиции по функционалу и данным. Можно сказать, что микросервисы — это развитие SOA архитектуры, когда из нее убрали ESB, единое хранилище, единую платформу, единые стандарты коммуникаций и перефокусировались от повторного использования к максимальной изоляции сервисов друг от друга
Здравствуйте, Sharov, Вы писали:
НС>>Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы. S>Микросеривсы -- это идея, подход. Кластеры -- одна из возможных реализаций.
Еще раз нет. Открой статью в википедии и вдумчиво почитай, что обепринято понимать под микросервисами. Кластеризация однотипных инстансов это точно не оно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, scf, Вы писали:
scf>>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.
НС>Это и есть обещанная изоляция по данным?
конкретные претензии есть, или опять "голословно" "фигня" и поиск каких-то авторитетов, как будто своих мозгов нет?
НС>У каждого сервиса собственный LB, для остальных сервисов он выглядит монолитом. В чем проблема?
Ясно, благодарю. Мне казалось, что уж тут-то dns должен быть во всю, ибо взаимодействие идет на уровне http запросов. Видимо его функционала для
действительно нагруженных случаев мало, отсюда рост использования RP и проч. инструментов.
Здравствуйте, Ночной Смотрящий, Вы писали:
scf>>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.
НС>Это и есть обещанная изоляция по данным?
Изоляцию обещали не между экземплярами микросервиса, а между микросервисами.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, namespace, Вы писали:
N>Средний такой pet-project(англ. проект собачьей будки) содержит около ~20 микросервисов, в каждом сервисе обычно от 3 до 50 строк кода.
Здравствуйте, Cyberax, Вы писали:
K>>Как оно реализуется на практике? Чере ещё один микросервис? C>Нет, силами самого сервиса.
Как это выглядит на практике? Вот есть у меня 10 инстансов сервиса аутентификации, причём физически они могут распологаться на разных серверах. Как оно должно работать? C>>>А кто говорил, что будет легко? C>Сервисная архитектура — это очень непростая вещь. Она требует планирования и большого опыта для правильного дизайна. Потому она оправдана только для уже реально больших и сложных приложений, над которыми работают множество команд.
Да если бы так. Сейчас чуть ли не каждый "школьник" пытается своять микросервисную систему и задеплоить её через Kubernetes. Зачем так делать, не ясно.
Здравствуйте, white_znake, Вы писали:
_>- Команды, пилящие микросервисы, должны иметь чуть-более высокую культуру разработки. Нельзя просто так взять и грохнуть поле команды или сделать вновь добавленное поле команды обязательным. И еще возникает необходимость в интеграционных тестах.
За счет версионирования api, это сделать как раз просто. Меняем нужные поля, инкрементируем версию api. При этом желательно, чтобы старая версия работала.
Здравствуйте, Dym On, Вы писали:
НС>>Этот ответ может быть на любой вопрос. При этом вопрос, в отличие от ответа, вполне осмысленен, и предполагает в ответе описание границ применимости. DO>Вот это вряд ли. Когда мы хотим узнать границы применимости, мы говорим где мы их хотим узнать.
Звучит как бред. Если мы хотим узнать границы, мы должны сказать где границы.
DO>Границы применимости это весьма конкретная характеристика задачи.
Границы применимости это вообще не характеристики задачи, это характеристики инструмента.
DO> Смотрим ТЗ, задаемся вопросом: «В чем смысл микросервисов для данной конкретной задачи?» В этом случае можно рассчитывать на конкретный ответ.
В итоге твоя логически несвязная цепочка подменила одно на другое, границы внезапно превратились в смысл для какой то внезапно всплывшей задачи.
DO>А вот когда задается вопрос вообще, это больше похоже на наброс, с целью разжигания срача.
И ты с удовольствием решил уж точно превратить топик в срач?
Вот смотри — почти все кроме тебя таки ответили по делу, хоть и не все правильно. И только ты увидел в вопросе то, чего там не было, и не увидел то что там было. На что я тебе и намекнул.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, ·, Вы писали:
S>·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь.
S>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше.
Если микросервис полностью отвязан от остального как это и дожно быть, то нет никаких препятствий использовать старую версию сервиса другими командами или компаниями до тех пор пока они не созреют для перехода.
Здравствуйте, Kernan, Вы писали:
S>>Этого с чего вдруг? Как я понимаю, если в очереди скопилось куча задач, оркестратор(или кто там) автоматически поднимет кол-во обработчиков(т.е. микросервисов) запросов. K>Найс. Теперь у нас слабое звено — оркестратор.
Он не пропускает через себя запросы, а просто следит за размерами очередей. Никто не мешает его сделать распределённым, кстати.
Посмотрел я на граф взаимодействия и о том, то один сервис взаимодействует с половиной микросервисов, и понял, что скорее всего ребята неправильно разбили микросервисы, сделали их очень гранулярными и от того слишком общительными.
P.S. Мое мнение и мнение автора статьи совпадает с тем, что многие разрабочики не обладая хорошим опытом (а в создании архитектуры важен опыт), превратно понимают слово "микро".
S>В чем смысл микросервисов?
Сам не пользую, но периодически слушаю подкасты с обсуждением.
Основноая идея — что это позволяет гибко балансировать нагрузку и на лету подключать/отключать.
Допустим, у вас сайтик, который умеет детектировать котиков на фото, или ведет рейтинг барбершопов, или что в таком духе.
И если к вам набегут хипстеры, то сайт не ляжет, и вы сможете рекламой заработать на смузи или даже новый айфон.
Какие такие транзакции?, это же вам не банк.
Средний такой pet-project(англ. проект собачьей будки) содержит около ~20 микросервисов, в каждом сервисе обычно от 3 до 50 строк кода.
Здравствуйте, Kolesiki, Вы писали:
K>И чо? Подними хоть тысячу, КТО будет распределять по ним нагрузку?? Значит, перед каждым микросервисом тебе придётся ставить диспетчер! Не жирновато для такой проблемы?
Вообще то микросервисы крутятся в каком то кластере. Корпоративном или облачном. Этот кластер уже есть, он уже сконфигурирован. И там уже есть независимые от задачи механизмы распределения нагрузки. Уже готовые, уже сконфигурированные, и на этом кластере гоняются десятки приложений. Если кто то под каждое приложение обслуживает отдельно, а не централизованно кластер — у кого то реально большие проблемы.
K>Упаси небо! Вот эти тухлые "архитекторы", "подбирающие язык под задачу" — главная проблема развала проектов. Для 99.999% приложений обычный ЯОН решает всё. Он потому и называется "общего назначения". Профи в десяти языках не существует, есть ОДИН профильный язык, на котором человек думает и пишет.
Вот потому и появилась мода на фулстек. И на идиотизм, когда из за того, что фронтэндер хочет писать фронтэнд на JavaScript, на нем же и фигачат огроменную бекэнд логику. Ибо фронтэнд в современном мире будет по любому на JavaScript. Соответственно так как мы хотим, чтоб язык был один, этим языком будет JavaScript. Ибо от него не избавиться. И на нем все так или иначе умеют. Ибо фронтэндера современного хрен заставишь писать на статически типизированном языке, даже если бы инструменты были. Ибо ему пофиг, его задача отображение, там сложности обычно только с версткой и с приколами особенностей браузеров. И из за того, что так удобно фронтэндеру, многие додумываются проекты на миллионы строк писать на этом убожестве. Также советую попробовать пересадить математиков на что то, отличное от питона. В коде математиков один черт кроме них хрен кто разберет, там проблема не с языком. Кто будет писать кучу математических либ, которые существуют на питоне, под другие языки? Или мы будем всю систему фигачить на питоне, когда расчетная часть это весьма небольшая часть? Переписывать код математиков потом — это двойная работа. И пока ты переписываешь код математиков нормально, добиваясь чтоб то, что ты понаписал, считало аналогично, там уже к чертям требования черти как изменятся и код математиков уйдет далеко.
Здравствуйте, elmal, Вы писали:
E>1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро.
И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек.
E> Именно микросервисная архитектура готова к таким проблемам из коробки. Также из коробки она готова к эксплуатации в режиме 24*7 без простоев;
Нет, не готова.
E>2) Возможность изолировать различные команды и различную логику. Писать на том языке, который лучше подходит под задачу.
Зачем для этого создавать распределенную систему?
E>Естественно есть и недостатки у такой архитектуры. Ибо увеличение сложности на ровном месте, затраты на коммуникации, нужна облачная инфраструктура.
Ты про САР-теорему забыл, бессердечную суку, грозу всех хипстеров.
Здравствуйте, scf, Вы писали:
scf>И минусы: scf>- Сложность. Микросервисная архитектура требует огромных вложений в единую архитектуру системы, девопс, мониторинг, логгирование и аналитику. scf>- Еще раз сложность. Правильно разбить еще не написанное приложение на микросервисы — задача нетривиальная и при ошибке реализация каждой фичи затрагивает множество микросервисов, что серьезно стопорит разработку scf>- И еще раз сложность. Отказ от распределенных транзакций и сетевое взаимодействие требуют очень вдумчивого подхода к обработке ошибок.
А еще снижение стабильности и надежности системы в целом.
Проблема в том, что то, что вы называете microservices — это антипаттерн. На который наступают периодически. Антипаттерн называется Entity Service. Подробнее, например, здесь:
Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
Обычно в случае с микросервисным подходом нужно стремится к eventual consistency. Таким образом, чтобы каждый из микросервисов был независимой подсистемой. В этом очень помогает понятие bounded context из DDD. Для начала попробуйте определить агрегаты в вашей системе, многое станет понятным.
Здравствуйте, Kolesiki, Вы писали:
K>И чо? Подними хоть тысячу, КТО будет распределять по ним нагрузку?? Значит, перед каждым микросервисом тебе придётся ставить диспетчер! Не жирновато для такой проблемы?
Пытаться уличить человека, что он гонит дичь и, при этом, гнать дичь самому — конфуз .
Здравствуйте, Privalov, Вы писали:
P>Похоже, я отстал от жизни. Математики, с которыми я работал, писали исключительно на Фортране. Как их удалось пересадить на Питон?
Сейчас математики пишут либо на питоне, либо на матлабе. Причем именно на питоне куча библиотек машинного обучения, которые к тому же могут гоняться на видеокартах. Все курсы используют питон. У матлаба кластеризация из коробки, гоняют расчеты сразу на кластере. И всему этому учат прямо в институтах.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, elmal, Вы писали:
E>>1) Ради масштабирования и отказоустойчивости. Есть система, она держит нагрузку n запросов в секунду. Внезапно наплыв клиентов, нужно 10n. В случае микросервисов просто поднимаем в n раз больше инстанцев того, что тормозит. Проблема решена и решена быстро.
НС>И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек.
Этого с чего вдруг? Как я понимаю, если в очереди скопилось куча задач, оркестратор(или кто там) автоматически поднимет кол-во обработчиков(т.е. микросервисов) запросов.
Здравствуйте, Cyberax, Вы писали:
NL>>Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки. C>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн.
Здравствуйте, De-Bill, Вы писали:
S>>Зачем все это? Ради чего?
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.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, MadHuman, Вы писали:
MH>- когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача.
У меня в руках новый микроскоп, хотелось бы его опробовать в действии, а в от эта задача вроде-бы подходит под возможности инструмента. Не важно, что его возможности ты знаешь плохо, и тут лучше бы молоток подошёл...
Поубивал бы!!!
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
MH>>- когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача. Ф>У меня в руках новый микроскоп, хотелось бы его опробовать в действии, а в от эта задача вроде-бы подходит под возможности инструмента. Не важно, что его возможности ты знаешь плохо, и тут лучше бы молоток подошёл... Ф>Поубивал бы!!!
Здравствуйте, mrTwister, Вы писали:
K>>К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто). T>Вот этого делать не стоит, так как при недостаточных и неполных данных надо часто рефакторить систему, иначе она быстро превратится в помойку, а микросервисы делают рефакторинг оооочень дорогим. Микросервисы следует использовать только когда мы точно знаем, что нам надо.
Нивапрос.
Заказчик отдаст свои деньги другим более проворным ребятам.
Здравствуйте, TG, Вы писали:
TG>Нивапрос. TG>Заказчик отдаст свои деньги другим более проворным ребятам.
Ты имеешь ввиду, что заказчик уйдет к другим более проворным ребятам, которые предложат ему начать сразу с микросервисной архитектуры при недостаточных и неполных исходных данных? Ну удачи ему
Здравствуйте, elmal, Вы писали:
E>Сейчас математики пишут либо на питоне, либо на матлабе. Причем именно на питоне куча библиотек машинного обучения, которые к тому же могут гоняться на видеокартах. Все курсы используют питон. У матлаба кластеризация из коробки, гоняют расчеты сразу на кластере. И всему этому учат прямо в институтах.
Раньше все математики всё писали на Фортране, и не особо использовали чужие библиотеки. Точнее, числодробительные библиотеки получились в результате их работы.
Когда я работал с командой математиков, там использовалась только одна сторонняя библиотека: Графор. Меня тогда еще попросили сделать к ней подключение из Си. Тогда еще не было таких Интернетов, как сейчас. И математики были старше меня, успели каждый себе написать все, что требовалось.
А сейчас в институтах учат, как подключить к Питону библиотеку. Н-да...
Здравствуйте, Privalov, Вы писали:
F>>короче, вы развлекались за чужой счёт, а молодёжь пытается добиться результата. P>А библиотеки, которыми молодежь пользуется, появились сами, я верно понял?
а их по делу делали, а не из желания понаписать код.
Здравствуйте, TG, Вы писали:
TG>Здравствуйте, Философ, Вы писали:
MH>>>- когда хочется попробывать новый язык/фрэймворк и тп и есть подходящая задача. Ф>>У меня в руках новый микроскоп, хотелось бы его опробовать в действии, а в от эта задача вроде-бы подходит под возможности инструмента. Не важно, что его возможности ты знаешь плохо, и тут лучше бы молоток подошёл... Ф>>Поубивал бы!!!
TG>А есть реальные примеры таких проектов?
Прямо сейчас у меня нет, но в своей практике я с таким сталкивался с последствиями. Были одновременно Firebird, MS SQL, My SQL в купе с Delphi, .net, PHP. Это давно было.
Про такой подход неоднократно слышал: люди рвуться попробовать что-то прямо в продакшене, впендюрить туда что-то, о чём они недавно прочитали.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Shmj, Вы писали:
S>В чем смысл микросервисов?
S>Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?
S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.
S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.
S>Зачем все это? Ради чего?
1. У микросервисов есть чётко очерченные интерфейсы. Твой IAccountService можно прикастовать к AccountService и через reflection поменять ему какие-нибудь приватные переменные, хе-хе. Да, это плохо, но если есть возможность, такое будет. Причём снаружи этого видно вообще не будет, это можно увидеть только читая код пользователей класса. Микросервис это, скажем, HTTP-интерфейс и все входы-выходы обычно документированы так или иначе.
2. Микросервисы можно писать на разных языках. В том числе плавно переписывая систему, если захочется. В случае монолита это делать гораздо сложней.
3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.
Здравствуйте, zverjuga, Вы писали:
Z>сориентируйте по терминологии. обычное MVC приложение с конечным набором веб-методов + база данных — это микросервис или монолит?
Здравствуйте, vsb, Вы писали:
vsb>3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.
Как же просто на разных компах? Допустим, та же регистрация пользователя. Был у тебя сервис https://assount-api.mysite.com/ Ты поднимаешь второй https://assount-api2.mysite.com/ Так просто его заюзать не получится — вам придется изменять все в коде, чтобы для одних пользователей обращаться к первому сервису а для других ко второму. Как вы это будете делать?
Здравствуйте, Cyberax, Вы писали:
C>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн. C>Далее, сервисы нужны, если функциональность для них достаточно обширная. При этом снаружи они, действительно, могут выглядеть как get/set методы.
пиши еще принципал инженер Cyberax! а потом Панкай или Раджеш с компании Х приходит и ты думаешь — ну е мае люди так нужны, что бы полегче спросить?? а вот транзакция — проще простого?
что такое транзакция Панкай? И он гордо в ответ — вестимо антипаттерн — это мне мой принципал инженер обьяснил!
Здравствуйте, a_g_99, Вы писали:
C>>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн. C>>Далее, сервисы нужны, если функциональность для них достаточно обширная. При этом снаружи они, действительно, могут выглядеть как get/set методы. __>пиши еще принципал инженер Cyberax! а потом Панкай или Раджеш с компании Х приходит и ты думаешь — ну е мае люди так нужны, что бы полегче спросить?? а вот транзакция — проще простого? __>что такое транзакция Панкай? И он гордо в ответ — вестимо антипаттерн — это мне мой принципал инженер обьяснил!
А об чём ржач-то? Как ты предлагаешь транзакции обеспечивать в распределённой системе? Microsoft Transaction Server?
Или ты не так понял? Транзакции в пределах одного сервиса — да, можно и даже надо, а Cyberax говорит о другом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
·>А об чём ржач-то? Как ты предлагаешь транзакции обеспечивать в распределённой системе? Microsoft Transaction Server?
Да какой микрофософт ? При чем тут микрософт какой-то ? Вы еще сюда виндоуз добавьте и щарепоинт и получится ваше резюме!
·>Или ты не так понял? Транзакции в пределах одного сервиса — да, можно и даже надо, а Cyberax говорит о другом.
Cyberax говорит то что написано в методичках которые ему спустили сверху ленивые люди. Сейчас он тут начнется в следующих постах соловьем песни петь про CAP теорему и прочее что ухватил с курсов "транзакции за 21 день"
Здравствуйте, TG, Вы писали:
NL>>>Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки. C>>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн. TG>Почему? TG>И как делать без транзакций? https://martinfowler.com/articles/microservice-trade-offs.html#consistency
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, a_g_99, Вы писали:
__>·>А об чём ржач-то? Как ты предлагаешь транзакции обеспечивать в распределённой системе? Microsoft Transaction Server? __>Да какой микрофософт ? При чем тут микрософт какой-то ? Вы еще сюда виндоуз добавьте и щарепоинт и получится ваше резюме!
А что же тогда? EJB/XA? Открой тайну-то!
__>·>Или ты не так понял? Транзакции в пределах одного сервиса — да, можно и даже надо, а Cyberax говорит о другом. __>Cyberax говорит то что написано в методичках которые ему спустили сверху ленивые люди. Сейчас он тут начнется в следующих постах соловьем песни петь про CAP теорему и прочее что ухватил с курсов "транзакции за 21 день"
Понятно. По сути сказать ничего не можешь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>А что же тогда? EJB/XA? Открой тайну-то!
Вы друг мой смотрите на 25 лет назад, а вам надо взглянуть на 10 лет назад хотя бы. Ну про современные подходы я не буду говорить, ни к чему вам этим голову забивать раз у вас какой микрософт и EJB в голове
·>Понятно. По сути сказать ничего не можешь.
так было бы с кем поговорить я бы поговорил . а так времени жалко тратить на ликбезы
Здравствуйте, a_g_99, Вы писали:
__>вы вообще слышали про envoy? господи как страшно жить когда такие имитации называют себя "программист", "инженер" и пр.
Переход на личности — не от большого ума. Я себя не называл ни программист ни тем более инженер.
По теме есть что сказать?
__>У вас вообще есть самосознание?
Определи что такое самосознание. Дай научное определение.
Здравствуйте, TG, Вы писали:
C>>Транзакции в распределённых системах — это сам по себе гигантский антипаттерн. TG>Почему?
Потому, что они не работают так, как этого хотелось бы.
TG>И как делать без транзакций?
Делать без транзакций. На eventual consistency.
Здравствуйте, a_g_99, Вы писали:
__>·>Или ты не так понял? Транзакции в пределах одного сервиса — да, можно и даже надо, а Cyberax говорит о другом. __>Cyberax говорит то что написано в методичках которые ему спустили сверху ленивые люди. Сейчас он тут начнется в следующих постах соловьем песни петь про CAP теорему и прочее что ухватил с курсов "транзакции за 21 день"
Ну а так какие альтернативы? Дай угадаю! Запихать всё в БД в виде хранимых процедур.
Здравствуйте, neFormal, Вы писали:
F>а где аргументация?
А где аргументация у того, кто утверждение делал? Микросервисы и кластеризация — ортогональные понятия. Кластеры, нацеленные на резервирование и перформанс это не просто набор разрозненных микросервисов. И даже решения типа Service Fabric эту задачу полностью не решат. Ее надо решать целенаправленно, и микросервисы лишь могут облегчить начало пути, не более.
Здравствуйте, Sharov, Вы писали:
НС>>И микросервисы тут никаким боком. Скорее они добавят потенциальных бутылочных горлышек. S>Этого с чего вдруг?
С того что вся система оказывается плотно нанизана на относительно медленную и потенциально ненадежную среду связи. В результате в полныый рост проблемы надежности, латентности, стнхронизации и т.п.
S> Как я понимаю, если в очереди скопилось куча задач, оркестратор(или кто там) автоматически поднимет кол-во обработчиков(т.е. микросервисов) запросов.
Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы.
Здравствуйте, mrTwister, Вы писали:
K>>К вышеперечисленным плюсам и минусам микросервисов добавлю еще такой важный плюсик: они позволяют спроектировать и начать создавать рабочую систему в условиях неодстаточных и неполных исходных данных (что в реальной жизни встречается довольно часто). T>Вот этого делать не стоит
Не делай. Конкуренты сделают это за тебя.
T>, так как при недостаточных и неполных данных надо часто рефакторить систему
Надо.
T>, иначе она быстро превратится в помойку, а микросервисы делают рефакторинг оооочень дорогим. T> Микросервисы следует использовать только когда мы точно знаем, что нам надо.
А мы этого не знаем примерно никогда. А потому микросервисы на помоечку.
Здравствуйте, Cyberax, Вы писали:
C>Ну а так какие альтернативы? Дай угадаю! Запихать всё в БД в виде хранимых процедур.
Да тут и гадать нечего, какой нибудь поросший мхом координатор транзакций. И оно вполне работает даже ... если узлов мало, а соединение между ними очень надежное.
Здравствуйте, a_g_99, Вы писали:
__>Cyberax говорит то что написано в методичках которые ему спустили сверху ленивые люди. Сейчас он тут начнется в следующих постах соловьем песни петь про CAP теорему
Здравствуйте, vsb, Вы писали:
vsb>1. У микросервисов есть чётко очерченные интерфейсы. Твой IAccountService можно прикастовать к AccountService и через reflection поменять ему какие-нибудь приватные переменные, хе-хе.
Это пустые страшилки. С таким уровнем вредительства за распределенные системы браться вообще не надо.
vsb>2. Микросервисы можно писать на разных языках. В том числе плавно переписывая систему, если захочется. В случае монолита это делать гораздо сложней.
Это чего это вдруг?
vsb>3. У микросервисов чуть получше теоретическое масштабирование, просто запускаешь разные сервисы на разных компьютерах. С нулевыми усилиями.
Здравствуйте, 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 нужно для небольшого подмножества данных, которое и следует хранить в одной базе с транзакциями. На остальном можно сэкономить, значительно ускорив систему.
Здравствуйте, 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. Ваши действия.
C>Для примера, если взять сетевой магазин, то в микросервисной модели будет: C>1) Отдельный сервис, отвечающий за поддержку корзины покупок. C>2) Отдельный сервис для обработки карточек. C>3) Отдельный сервис для валидации адреса доставки. C>4) Отдельный сервис для расчёта бизнес-статистики для директора магазина.
Ну то есть схема, которая уже не первое десятилетие спокойно и без лишнего шума широко используется там, где она нужна — и не используется там, где она не нужна.
Но юные хипстеры ВНЕЗАПНО
— обозвали эту схему красивым словом
— объявили чем-то принципиально новым
— забили все интернеты своими высерами о том, как это круто и какие лохи те, кто это не использует
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
T>Ты про SOA?
Я про схему, описанную Цибераксом, и названную им "микросервисной"
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Ночной Смотрящий, Вы писали:
F>>а где аргументация? НС>А где аргументация у того, кто утверждение делал? Микросервисы и кластеризация — ортогональные понятия. Кластеры, нацеленные на резервирование и перформанс это не просто набор разрозненных микросервисов. И даже решения типа Service Fabric эту задачу полностью не решат. Ее надо решать целенаправленно, и микросервисы лишь могут облегчить начало пути, не более.
обычно под "микросервисной архитектурой" понимают весь комплекс проблем.
Здравствуйте, alex_public, Вы писали:
_>И есть противоположный этому вроде как современных подход (на мой взгляд никчемное убожество) — это когда ты на одной и той же машине (ну да, их таких может быть множество, но это опять же не суть) запускаешь множество демонов разного назначения, которые совместно решают целевую задачу. Это и есть те самые микросервисы.
Здравствуйте, scf, Вы писали:
scf>- Масштабирование. В целом, монолитные приложения масштабируются хорошо, в отличие от огромной БД монолитного приложения. И наличия внутреннего состояния, которым грешат монолиты. scf>- Устойчивость к отказам. Отказ от транзакций и необходимость тщательной обработки ошибки позволяет строить системы, адекватно реагирующие на перегрузку и отказ отдельных компонентов.
Как организовать совместную работу одного микросервиса со своей ДБ (пусть будет монгоДВ) чтобы обеспечить хоть как-то согласованность данных при маштабировании? Пусть будет какой-нибудь микросервис аутентификации с БД пользователей и токенами доступа в этой БД.
Здравствуйте, Kernan, Вы писали:
K>Как организовать совсемтную работу одного микросервиса со своей ДБ (пусть бует монгоДВ) чтобы обеспечить хотья как-то согласованность данных в ней? Пусть будет какой-нибудь микросервис аутентификации с БД пользователей и токеми доступа в этой БД.
Ну как обычно — eventual consistency, идемпотентные запросы и фоновые reconciler'ы.
C>Юные хипстеры эту схему реально довели до ума. В частности: C>1) Начали разбираться с трассировкой и отладкой: https://opentracing.io/ C>2) Управление траффиком, в том числе throttling и load shedding: https://linkerd.io/ C>3) Субстрат, на который легко разворачивать приложения (Docker, Kubernetes).
Я вас с этим, конечно, поздравляю, только вот все это никак не опровергает мои слова
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Cyberax, Вы писали:
C>Ну как обычно — eventual consistency, идемпотентные запросы и фоновые reconciler'ы.
Как оно реализуется на практике? Чере ещё один микросервис? C>А кто говорил, что будет легко?
Фаулер говорил
Здравствуйте, vsb, Вы писали:
vsb>account-api.mysite.com на одном компьютере, mysite.com на другом, reports.mysite.com на третьем. aссount-api2.mysite.com это уже другой уровень масштабирования, для такого действительно нужно писать специальный код и никакого преимуществе перед монолитом тут нет, т.к. монолит со специальным кодом тоже можно запускать на нескольких серверах.
А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а)всех хостов, реализущих данный сервис? Я так понимаю, что в основе всех
высоконагруженных сервисов и тем более микросервисов находится dns. Т.е. мне возвращается куча адресов необходимого сервиса, после чего по определенному алгоритму я выбираю один из. Так?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, vsb, Вы писали:
vsb>>account-api.mysite.com на одном компьютере, mysite.com на другом, reports.mysite.com на третьем. aссount-api2.mysite.com это уже другой уровень масштабирования, для такого действительно нужно писать специальный код и никакого преимуществе перед монолитом тут нет, т.к. монолит со специальным кодом тоже можно запускать на нескольких серверах.
S>А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а)всех хостов, реализущих данный сервис?
Как настроишь, так будет. Можно вернуть все адреса. Приложение должно стучаться во все адреса в указанном порядке, пока не найдёт рабочий. Можно один вернуть.
S> Я так понимаю, что в основе всех S>высоконагруженных сервисов и тем более микросервисов находится dns. Т.е. мне возвращается куча адресов необходимого сервиса, после чего по определенному алгоритму я выбираю один из. Так?
Это самый простой вариант. Не обязательно так. Я видел, когда люди в БД хранили адреса, например. Опять же желательно мерять нагрузку и отдавать наименее загруженный сервер. Если между запросами состояние, желательно одного клиента посылать на один и тот же сервер. Вообще по-моему обычно впереди стоит лоад балансёр, который по определенному алгоритму перенаправляет запросы на один из серверов за ним. А для юзера этого сервиса это выглядит как один сервер.
S>> Я так понимаю, что в основе всех S>>высоконагруженных сервисов и тем более микросервисов находится dns. Т.е. мне возвращается куча адресов необходимого сервиса, после чего по определенному алгоритму я выбираю один из. Так?
vsb>Это самый простой вариант. Не обязательно так. Я видел, когда люди в БД хранили адреса, например. Опять же желательно мерять нагрузку и отдавать наименее загруженный сервер. Если между запросами состояние, желательно одного клиента посылать на один и тот же сервер. Вообще по-моему обычно впереди стоит лоад балансёр, который по определенному алгоритму перенаправляет запросы на один из серверов за ним. А для юзера этого сервиса это выглядит как один сервер.
Речь идет именно о возможности использовать доменные имена. Т.е. я у себя в сервисе прописываю account.mysite.com и все. Далее, когда мне будет нужен соотв. функционал, я делаю запрос по http://account.mysite.com/api1 и
инфраструктура мне вернет какой-нибудь инстанс. Доменные имена использовать проще, нежели ip, кмк.
Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса. S>Это называется "round-robin load balancer", его ещё называют "балансировщиком для бедных". Просто регистрируем N A- (или CNAME) записей для одного и того же хостнейма, которые бы стреляли в разные IP адреса. S>Теперь у нас при каждом запросе эти IP адреса будут отдаваться более-менее равномерно.
S>Настоящий load balancer отличается от вот этого подобия вот чем: S>1. Умеет отключать вышедшие из строя сервера (обращение к мёртвому серверу стоит клиенту длительного таймаута) S>2. Умеет отслеживать фактическую нагрузку S>3. Умеет поддерживать session и client affinity
С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?
Здравствуйте, Kernan, Вы писали:
K>Как организовать совместную работу одного микросервиса со своей ДБ (пусть будет монгоДВ) чтобы обеспечить хоть как-то согласованность данных при маштабировании? Пусть будет какой-нибудь микросервис аутентификации с БД пользователей и токенами доступа в этой БД.
Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД. если n экземпляров микросервиса и n БД (шардинг), то проще всего сделать программный шардинг по ключам (логин пользователя, первый символ токена) — микросервис сам обращается в нужную БД. Джойнов между шардами желательно избегать, вынося их на сторону клиента.
Из минусов — при запросе связанных данных (юзер из токена, юзер-создатель юзера и т.п.) нужно быть готовым и правильно обрабатывать случай, когда их не окажется.
Здравствуйте, Sharov, Вы писали:
S>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?
если используется какой-нить распределённый конфиг, то днс можно и не использовать, имена будут в конфиге.
S>>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?
F>если используется какой-нить распределённый конфиг, то днс можно и не использовать, имена будут в конфиге.
Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.
Здравствуйте, Sharov, Вы писали:
S>>>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь? F>>если используется какой-нить распределённый конфиг, то днс можно и не использовать, имена будут в конфиге. S>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.
"распределённый конфиг" — это что-то типа NoSQL-бд.
к нему все цепляются, читают содержимое, подписываются на изменения полей.
там нет понятия "распространение".
Здравствуйте, neFormal, Вы писали:
S>>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.
F>"распределённый конфиг" — это что-то типа NoSQL-бд. F>к нему все цепляются, читают содержимое, подписываются на изменения полей. F>там нет понятия "распространение".
Вообще-то есть, иначе это не распределенный конфиг. Т.е. изменения могут дойти не сразу. Отсюда, видимо, все эти service discovery и т.д.
Здравствуйте, Sharov, Вы писали:
S>>>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах. F>>"распределённый конфиг" — это что-то типа NoSQL-бд. F>>к нему все цепляются, читают содержимое, подписываются на изменения полей. F>>там нет понятия "распространение". S>Вообще-то есть, иначе это не распределенный конфиг. Т.е. изменения могут дойти не сразу.
если ты записал что-то в БД, её изменения сразу станут доступны клиентам? сразу. вот и тут то же самое.
S>Отсюда, видимо, все эти service discovery и т.д.
сервис дискавери — это про другое. это про "более позднее связывание".
Здравствуйте, Sinclair, Вы писали:
S>Никто не может мне помешать делать "внешний" load-balancing путём возврата 302 на входящие запросы, раскидывая клиентов по настоящим адресам сервис-нодов. S>И это мы ещё даже не начали копать.
А внутри сервисы как между собой общаются, через что, если убрать статичный конфиг\базу? Т.е. какой жизненный цикл запроса http://account/service/api/do?
Здравствуйте, Sharov, Вы писали:
S>А внутри сервисы как между собой общаются, через что, если убрать статичный конфиг\базу? Т.е. какой жизненный цикл запроса http://account/service/api/do?
Не очень понятно, что вы имеете в виду. У запроса жизненный цикл простой — он начался и закончился. Это никак не зависит от архитектуры
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>А внутри сервисы как между собой общаются, через что, если убрать статичный конфиг\базу? Т.е. какой жизненный цикл запроса http://account/service/api/do? S>Не очень понятно, что вы имеете в виду. У запроса жизненный цикл простой — он начался и закончился. Это никак не зависит от архитектуры
Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А.
Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B.
И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?
Здравствуйте, scf, Вы писали:
НС>>Services form information barriers scf>Вообще-то это считается преимуществом
Кем считается?
НС>>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 scf>Да, но эти затраты невелики
Голословно.
scf> и чувствительны исключительно для синхронного кода, когда запросы идут по очереди, а не параллельно.
Фигня.
НС>>Ну и ссылочку еще добавлю. Оно всегда вылазит, когда мы от хипста-демок переходим к реальным энтерпрайз системам. scf>я бы сказал, что в реальных системах consistency нужно для небольшого подмножества данных, которое и следует хранить в одной базе с транзакциями.
Вот только жизнь типичного реального сервиса вокруг этих данных в основном и сосредоточена. А обвешивание по периметру микросервисами второго плана как правило особой ценности не несет.
Здравствуйте, mrTwister, Вы писали:
НС>>Не делай. Конкуренты сделают это за тебя. T>... НС>>А потому микросервисы на помоечку. T>Дак я не понял: на помоечку, или конкуренты их сделают за меня?
Здравствуйте, Sharov, Вы писали:
S>>> Я так понимаю, что в основе всех S>>>высоконагруженных сервисов и тем более микросервисов находится dns. Т.е. мне возвращается куча адресов необходимого сервиса, после чего по определенному алгоритму я выбираю один из. Так?
vsb>>Это самый простой вариант. Не обязательно так. Я видел, когда люди в БД хранили адреса, например. Опять же желательно мерять нагрузку и отдавать наименее загруженный сервер. Если между запросами состояние, желательно одного клиента посылать на один и тот же сервер. Вообще по-моему обычно впереди стоит лоад балансёр, который по определенному алгоритму перенаправляет запросы на один из серверов за ним. А для юзера этого сервиса это выглядит как один сервер.
S>Речь идет именно о возможности использовать доменные имена. Т.е. я у себя в сервисе прописываю account.mysite.com и все. Далее, когда мне будет нужен соотв. функционал, я делаю запрос по http://account.mysite.com/api1 и S>инфраструктура мне вернет какой-нибудь инстанс. Доменные имена использовать проще, нежели ip, кмк.
Над DNS обычно мало контроля. Протокол старинный, мало кто готов написать DNS-сервер со своей логикой. С точки зрения клиента ещё хуже, общеупотребительные библиотеки кешируют ответы, если есть промежуточный сервер, он тоже может закешировать и тд. Это удобно, когда нужно абсолютный минимум от масштабирования. Но если тебе надо направлять на нужный сервер в зависимости от значения HTTP Cookie, то, конечно, тут уже DNS не подойдёт.
S>Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса.
Load Balancer это концепция, некая сущность, которая распределяет нагрузку. DNS это один из вариантов. Другой вариант это reverse proxy, это сервер, который принимает HTTP-соединения (ну в общем случае не HTTP, но щас всё HTTP), возможно делает какие-то манипуляции с ними и пробрасывает уже тому серверу, который его будет обрабатывать. Т.е. по сути вся работа тут передавать байты от клиента к одному из рабочих серверов и назад.
Здравствуйте, scf, Вы писали:
scf>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.
Здравствуйте, Shmj, Вы писали:
S>Давайте на примере с нашим ClientService. Вам нужно проверить не занят ли логин. Вы разбили ClientService на несколько серверов, каждый из них имеет свою базу данных.
Здравствуйте, 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 просто прокручивает список на каждом запросе.
Здравствуйте, Shmj, Вы писали:
S>В чем смысл микросервисов?
Смысл в том, что еще одно техническое решение, подход. Со своими достоинствами и недостатками. И если для конкретной задачи достоинства перевешивают недостатки сильнее, чем у других подходов, имеет смысл использовать именное его.
Здравствуйте, Dym On, Вы писали:
S>>В чем смысл микросервисов? DO>Смысл в том, что еще одно техническое решение, подход. Со своими достоинствами и недостатками. И если для конкретной задачи достоинства перевешивают недостатки сильнее, чем у других подходов, имеет смысл использовать именное его.
А можно вопрос? В чем смысл твоего сообщения? Этот коммент можно написать в ответ на почти любой топик в этом форуме с аналогичным успехом.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А можно вопрос? В чем смысл твоего сообщения? Этот коммент можно написать в ответ на почти любой топик в этом форуме с аналогичным успехом.
Совершенно верно, но именно такой ответ может быть на такой
S>В чем смысл микросервисов?
вопрос.
Задаешь общий вопрос, получаешь общий ответ. На тему «В чем смысл микросервисов» можно монографию в 5 томах написать, и то не осветишь все тонкости и нюансы. В сообщении на форуме получить исчерпывающий ответ не возможно, а неисчерпывающий бесполезен, ибо вопрос задан не в практической плоскости, а скорее в риторической. Следовательно и вопрос «В чем смысл твоего сообщения?» можно задать к любому сообщению в этой теме, например, к твоему
Здравствуйте, Dym On, Вы писали:
НС>>А можно вопрос? В чем смысл твоего сообщения? Этот коммент можно написать в ответ на почти любой топик в этом форуме с аналогичным успехом. DO>Совершенно верно, но именно такой ответ может быть на такой DO>
S>>В чем смысл микросервисов?
DO>вопрос.
Этот ответ может быть на любой вопрос. При этом вопрос, в отличие от ответа, вполне осмысленен, и предполагает в ответе описание границ применимости.
DO>Задаешь общий вопрос, получаешь общий ответ. На тему «В чем смысл микросервисов» можно монографию в 5 томах написать, и то не осветишь все тонкости и нюансы.
Это вряд ли. Ну и много не надо, можно осветить ключевые моменты. Впрочем, про пять томов как единственный возможный нормальный ответ — это тоже ответ на заданный вопрос.
Здравствуйте, Shmj, Вы писали:
S>Зачем все это? Ради чего?
Если они тебе не нужны — не используй.
Не в каждом приложении обосновано использование микросервисов. Учитывая, что при создании микросервисной архитектуры с нуля, самое трудное провести границы разделов для микро-сервисов
На мой взгляд микросервисы обоснованы в случае, когда в монолитном приложении проглядываются незвасимые части.
Это даже можно понять, проведя мысленный эксперимент: выносим модуль Х в отдельный сервис, если его падение, не затронит работоспособность остального монолита и остальный пользователей — модуль Х кандидат в микросервисы.
Плюсы:
— Горизонтальная масштабируемость. Для каждого сервиса можно определить кластер и выполнять балансировку нагрузки именно для этого микросервиса.
— Падение одно сервиса не означает падение других сервисов. Если используются надежные очереди, то после рестарта, упавший сервис продолжит оработку данных.
— Каждый сервис может пилиться независимыми командами.
Минусы:
— Сложность в администрировании и контроле зоопарка из сервисов
— Команды, пилящие микросервисы, должны иметь чуть-более высокую культуру разработки. Нельзя просто так взять и грохнуть поле команды или сделать вновь добавленное поле команды обязательным. И еще возникает необходимость в интеграционных тестах.
В общем, как и во всем ИТ, нет серебряной пули. Есть выбор одного из как минимум двух решений, и нет такого решения, в коором бы ты получил все, не потеряв ни чего :)
НС>Этот ответ может быть на любой вопрос. При этом вопрос, в отличие от ответа, вполне осмысленен, и предполагает в ответе описание границ применимости.
Вот это вряд ли. Когда мы хотим узнать границы применимости, мы говорим где мы их хотим узнать. Границы применимости это весьма конкретная характеристика задачи. Смотрим ТЗ, задаемся вопросом: «В чем смысл микросервисов для данной конкретной задачи?» В этом случае можно рассчитывать на конкретный ответ.
А вот когда задается вопрос вообще, это больше похоже на наброс, с целью разжигания срача. Поскольку, отвечающие будут предлагать границы применимости, исходя из своих конкретных задач, которые оспариваются другими отвечающими, исходя из своих конкретных задач. Не, на такое обсуждение иногда любопытно посмотреть, но конструктивным он бывает редко.
PS Хотя для анализа «кто чем занимается» такой вопрос годится.
Здравствуйте, 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.
Здравствуйте, Kernan, Вы писали:
K>Да если бы так. Сейчас чуть ли не каждый "школьник" пытается своять микросервисную систему и задеплоить её через Kubernetes. Зачем так делать, не ясно.
затем, что об этом есть статья, и учёные мужи на хабре авторитетно рекомендовали так делать.
Здравствуйте, ·, Вы писали:
·>Возникает необходимость поддержки нескольких версий API и их взаимодействие, что не так уж просто. Вроде как добавили обязательное поле, но из-за того, что старая версия всё ещё должна работать — поле по факту-то не обязательное. А если у разных пользователей API разный ЖЦ, то в итоге можно получить десяток одновременно живущих версий и тогда проще застрелиться.
До десятка доводить не нужно, но пока есть старые клиентs, сохранять совместимость. Как клиенты обновяться, прибить инстансы со старым api.
Здравствуйте, neFormal, Вы писали:
_>>И есть противоположный этому вроде как современных подход (на мой взгляд никчемное убожество) — это когда ты на одной и той же машине (ну да, их таких может быть множество, но это опять же не суть) запускаешь множество демонов разного назначения, которые совместно решают целевую задачу. Это и есть те самые микросервисы. F>почему обязательно на одной машине?
В тексте же однозначно написано, что не обязательно на одной. Но это вполне распространённый сценарий.
Здравствуйте, Sharov, Вы писали:
НС>>Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы. S>Микросеривсы -- это идея, подход. Кластеры -- одна из возможных реализаций.
Феерично.
Ну вот запустил я тут на hadoop кластере расчёт аналитической (с помощью ML) задачки — покажи, что тут у нас является микросервисами.
Здравствуйте, Sharov, Вы писали:
S>Этого с чего вдруг? Как я понимаю, если в очереди скопилось куча задач, оркестратор(или кто там) автоматически поднимет кол-во обработчиков(т.е. микросервисов) запросов.
Найс. Теперь у нас слабое звено — оркестратор.
Здравствуйте, Sharov, Вы писали:
S>·>Возникает необходимость поддержки нескольких версий API и их взаимодействие, что не так уж просто. Вроде как добавили обязательное поле, но из-за того, что старая версия всё ещё должна работать — поле по факту-то не обязательное. А если у разных пользователей API разный ЖЦ, то в итоге можно получить десяток одновременно живущих версий и тогда проще застрелиться. S>До десятка доводить не нужно, но пока есть старые клиентs, сохранять совместимость. Как клиенты обновяться, прибить инстансы со старым api.
В таких условиях можно наоборот действовать — заставить всех клиентов посылать новое поле, потом объявить его обязательным, а потом уже спокойно его юзать в сервисе с уверенностью, что оно всегда есть.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, neFormal, Вы писали:
F>затем, что об этом есть статья, и учёные мужи на хабре авторитетно рекомендовали так делать.
Перечитай ещё о чём идёт речь.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Sharov, Вы писали:
_>Феерично.
_>Ну вот запустил я тут на hadoop кластере расчёт аналитической (с помощью ML) задачки — покажи, что тут у нас является микросервисами.
Феерии не вижу, в случае выше совместная обработка задачи. Это, вестимо, не микросервисы.
Здравствуйте, alex_public, Вы писали:
F>>почему обязательно на одной машине? _>В тексте же однозначно написано, что не обязательно на одной. Но это вполне распространённый сценарий.
я просто пытаюсь связать "на одной машине" и "убожество"
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Sharov, Вы писали:
·>В таких условиях можно наоборот действовать — заставить всех клиентов посылать новое поле, потом объявить его обязательным, а потом уже спокойно его юзать в сервисе с уверенностью, что оно всегда есть.
Заставьте всех в netflix'е, а я посмотрю. Проще выкатывать новую функц. не ломая старой.
,
можно не знать слово "микросервисы", но при этом руководствуясь здравым смыслом не создавать монолитную архитектуру.
Конечно наверняка есть средства направленные на максимально быструю разработку простых сервисов, оркестровку работы множества сервисов,
но здесь опять же, я считаю можно обойтись без модного слова "микросервисы",
в котором слово "микро" может направить в неправильное русло,
величина сервиса не микро и не макро, а такая какая оптимальна в данных условиях.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, Sharov, Вы писали:
S>·>Здравствуйте, Sharov, Вы писали: S>·>В таких условиях можно наоборот действовать — заставить всех клиентов посылать новое поле, потом объявить его обязательным, а потом уже спокойно его юзать в сервисе с уверенностью, что оно всегда есть. S>Заставьте всех в netflix'е, а я посмотрю. Проще выкатывать новую функц. не ломая старой.
Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь.
Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше.
Здравствуйте, Sharov, Вы писали:
S>·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь. S>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше.
Но если не ждать — будет десяток старых версий.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Kernan, Вы писали:
S>>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше. K>Если микросервис полностью отвязан от остального как это и дожно быть, то нет никаких препятствий использовать старую версию сервиса другими командами или компаниями до тех пор пока они не созреют для перехода.
А это Вы не мне объясняйте, а точке. Я с этим тезисом полностью согласен.
Здравствуйте, Kernan, Вы писали:
S>>·>Ты путаешься в показаниях. Ты ведь как-то собираешься заставлять всех переходить на новую версию, чтобы не пришлось поддерживать десяток старых. Так и тут заставишь. S>>Нет, не путаюсь. Дилемма ждать, пока все соизволят перейти на новое api, либо начать уже использовать ничего не ломая. Суть таже, но время вывода новой функц. в эксплуатцию сущ. меньше. K>Если микросервис полностью отвязан от остального как это и дожно быть, то нет никаких препятствий использовать старую версию сервиса другими командами или компаниями до тех пор пока они не созреют для перехода.
Хуже того, ты подразумеваешь, что есть какой-то код, который где-то лежит у богом забытых клиентов и хлеба не просит. А в реальной жизни старые версии сервиса таки надо поддерживать, ибо их надо разворачивать, управлять ими, применять секьюрити-апдейты и прочее. Или вот что-то упало у клиента древней версии — и тебе надо разобраться что же случилось. Ну да, можно достать старую версию исходников, но она уже не собирается, т.к. тулзы у тебя поменялись и прав на запись в "C:/" у тебя вдруг не стало. И в итоге через неделю археологических раскопок очень приятно узнать что эта бага была пофкишена два года назад и благополучно всеми забыта. Так что весь этот старый код, если он хоть кем-то используется — типичный технический долг.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sharov, Вы писали:
_>>Феерично. _>>Ну вот запустил я тут на hadoop кластере расчёт аналитической (с помощью ML) задачки — покажи, что тут у нас является микросервисами. S>Феерии не вижу, в случае выше совместная обработка задачи. Это, вестимо, не микросервисы.
Совершенно верно. И соответственно из этого примера видно, что кластер — это совсем не реализация идеи микросервисов.
Здравствуйте, neFormal, Вы писали:
F>>>почему обязательно на одной машине? _>>В тексте же однозначно написано, что не обязательно на одной. Но это вполне распространённый сценарий. F>я просто пытаюсь связать "на одной машине" и "убожество"
Убожество — это уже моя субъективная оценка. Да, и кстати она следует совсем не из одной/нескольких машин, а из того насколько неадекватно сложно становится решать простейшие задачи с использованием подобной архитектуры.
Здравствуйте, Kernan, Вы писали:
K>>>Как оно реализуется на практике? Чере ещё один микросервис? C>>Нет, силами самого сервиса. K>Как это выглядит на практике? Вот есть у меня 10 инстансов сервиса аутентификации, причём физически они могут распологаться на разных серверах. Как оно должно работать?
Например, на каждом сервере выделяется поток, который в фоновом режиме будет убирать мусор из базы данных. Но можно выделить и полностью отдельный сервер — всё зависит от потребностей.
C>>Сервисная архитектура — это очень непростая вещь. Она требует планирования и большого опыта для правильного дизайна. Потому она оправдана только для уже реально больших и сложных приложений, над которыми работают множество команд. K>Да если бы так. Сейчас чуть ли не каждый "школьник" пытается своять микросервисную систему и задеплоить её через Kubernetes. Зачем так делать, не ясно.
Ну вот и не надо так делать. Точнее, развёртывание через K8S — это нормально, а вот дизайн из 100500 сервисов — не очень.
Здравствуйте, Cyberax, Вы писали:
K>>Найс. Теперь у нас слабое звено — оркестратор. C>Он не пропускает через себя запросы, а просто следит за размерами очередей. Никто не мешает его сделать распределённым, кстати.
Здравствуйте, ·, Вы писали:
·>Скажем, есть сервис сбора статистики о заказах. И вдруг понадобилось помимо содержимого заказа иметь информацию о стране доставки заказа. Никакой полной отвязки быть не может, ибо нам надо всё ещё собирать статистику по всем заказам, а не только по тем, которые присылаются новыми клиентами. Значит мы так или иначе должны проапрейдить всех клиентов, ну или делать изменение неломающим и "страна доставки" будет опциональной. А опциональность не всегда возможна. Например, требование страны может быть наложено регулятором для отслеживания выполнения требований санкций — и тут выбор, либо ты нафиг ломаешь всех клиентов, либо ты прикрываешь свой бизнес.
хороший пример.
а как такое решается? с точки зрения бизнеса.
как можно заставить кучу клиентов обновиться, и что делать, если кто-то не хочет или не торопится?
какой запас времени нужно дать клиентам? и поддерживаются ли в это время две версии?
Здравствуйте, Ночной Смотрящий, Вы писали:
K>>>Найс. Теперь у нас слабое звено — оркестратор. C>>Он не пропускает через себя запросы, а просто следит за размерами очередей. Никто не мешает его сделать распределённым, кстати. НС>Но по факту обычно не делают.
Уже делают, есть linkerd. Если использовать что-то типа AWS/Azure для масштабирования, то там координаторы тоже распределённые.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, white_znake, Вы писали:
_>>- Команды, пилящие микросервисы, должны иметь чуть-более высокую культуру разработки. Нельзя просто так взять и грохнуть поле команды или сделать вновь добавленное поле команды обязательным. И еще возникает необходимость в интеграционных тестах.
S>За счет версионирования api, это сделать как раз просто. Меняем нужные поля, инкрементируем версию api. При этом желательно, чтобы старая версия работала.
Это-то я знаю, спасибо за поучение.
Микросервисы могут общаться и не через рест, а могут общаться через команды и шину сообщений. В этом случае версионировать труднее, но все равно есть возможность через Nuget пакеты или NPM-пакеты ставить нужную версию команды и соответственно сервера, обрабатывающего эту команду.
Что все равно налагает дополнительные требования. И само версионирование рест АПИ — это тоже дополнительные требование и усилия.
Здравствуйте, Cyberax, Вы писали:
C>Уже делают, есть linkerd. Если использовать что-то типа AWS/Azure для масштабирования, то там координаторы тоже распределённые.
Координаторы чего? Машина оркестратора в кластере AKS в Ажуре — одна.
Математики, с которыми я работал, писали исключительно на Фортране. Как их удалось пересадить на Питон?
