|
02.06.2021, 12:28 | #1 |
Участник
|
Когда говорят о микросервисах, то в качестве их преимуществах говорят о слабосвязанности.
А насколько она - слабосвязанность - нужна? В концептуальном анализе есть прием - антропоморфная редукция. Это когда сложные системы понятий проектируются на человека и/или его деятельность - при этом все должно вставать на свои места и сложные понятия становятся простыми до очевидности. Попробуем спуститься еще ниже - не до человека, а до повара (повароморфная редукция, мда..). Представим повара и его, ну например, микроволновку (сервис). Повар засовывает в него курицу (информационный продукт) и, согласно контракту, микроволновка должна его разморозить. При этом: - если открыть дверцу микроволновки во время работы она должна выключиться. Это жесткая функциональная связь, реализуемая на "железячном" уровне. - после отработки микроволновки повар (процессный движок) должен вынуть курицу (информационный продукт) из микроволновки и засунуть её в кастрюлю, согласно рецепту (шаблон бизнес-процесса). Здесь связи определяются процессом и также достаточно жесткая, хотя может в процессе приготовления меняться. - после отработки микроволновка блямкает - посылает сигнал о завершении работы в космос. Кому он нужен? Да мало ли кому - на кухне и в зале трётся много народа. Может кому и сгодится. И только вот эти, самые малозначимые с точки процесса, связи и являются "слабосвязанными". И только они в достаточной мере годны для реализации микросервисами. Получается, что основная выгода от микросервисов - реализация самых малозначимых компонентов системы. |
|
02.06.2021, 13:09 | #2 |
Участник
|
Цитата:
Cоздадим монолит: привяжем повара к микроволновке цепочкой, и мордочку закрепим скотчем на уровне дверцы: он сразу будет видеть курочку, а это конкурентное преимущество над микросервисом. Тут же вырисовываются и проблемы: поваренок должен быть мелким иначе проигрываем по габаритам и не на каждую кухню влезет такая система + есть опасность потребления ресурсов со стороны поваренка. Последний раз редактировалось axm2017; 02.06.2021 в 13:13. |
|
02.06.2021, 13:30 | #3 |
Участник
|
Давайте определим что такое слабосвязанность?
Когда говорят о микросервисах, то обычно разделяют следующие выгоды:
В качестве минуса - Eventual consistency - повар может не услышать сообщение от микроволновки и думать что еда готовится, когда еда уже готова. |
|
|
За это сообщение автора поблагодарили: Sancho (1), Dynamics365Eng (1). |
02.06.2021, 15:46 | #4 |
Участник
|
Когда говорят о микросервисах возникает одно ощущение — мешанина.
Начиная от определения, например Фаулера: архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP. Мешанина туманной концепции (небольшие сервисы) и конкретной реализации. Теперь к нашим баранам, сиречь повару. Независимость повара и микроволновки, производителя микроволновки, команды микроволновки и установки микроволновки определяемтя не микросервисной архитектурой (использованием отдельного процесса, отдельного источнока данных и протокола HTTP), а компонентной архитектурой. Вспомним приснопамятную RAD-архитектуру и наборы компонентов для Delphi, покупаемых на Горбушке. Без микроскрвисов. Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов. Единственное применение микросервисов - использование другой технологии (скорее всего, языка программирования). Я знаю не много языков, но мне не особо верится что есть такие технологии, которые можно реализовать в одном языке и невозможно реализовать в другом. Конечно, беря во внимание наиболее распространенные универсальные языки. Скорее, речь пойдет о том, что независимая команда не шарит в языке и технологии, на которой реализована основная система. Причиина опять не технологическая, а организационная. И особенно доставляет слушать доклады с всевозможных конференция о историях успеха внедрения микросервисной архитектуры (или особенно какой-нибудь Event-Driven Microservice Architecture) в крупных гигантах. Ребята все делают правильно, а получают неуправляемый ворох сервисов и перекосы в системе хранения данных. Но это неважно, ведь используются самые передовые технологии, правдв? |
|
02.06.2021, 16:09 | #5 |
Участник
|
Цитата:
Цитата:
Естественно как у любой архитектуры есть + и - и бездумно применять не стоит ps домохозяйкам на заметку https://habr.com/ru/post/249183/ Не фан микросервисов (мне например не нравятся слухи об invoice машинах и прочем внутри MS как отдельных сервисах так как беглый опрос показывает что MS ники видят это как black boxes со всеми вытекающими) но имеет место быть. Последний раз редактировалось axm2017; 02.06.2021 в 17:00. |
|
|
За это сообщение автора поблагодарили: mau (1). |
02.06.2021, 19:58 | #6 |
Участник
|
Цитата:
В случае микросервиса, хранение и администрирование лежит на команде, которая поддерживает микросервис, она может даже сменить вид хранилища по желанию. Цитата:
Цитата:
Цитата:
Цитата:
Сообщение от mau
И особенно доставляет слушать доклады с всевозможных конференция о историях успеха внедрения микросервисной архитектуры (или особенно какой-нибудь Event-Driven Microservice Architecture) в крупных гигантах. Ребята все делают правильно, а получают неуправляемый ворох сервисов и перекосы в системе хранения данных.
Но это неважно, ведь используются самые передовые технологии, правдв? |
|
03.06.2021, 08:16 | #7 |
Участник
|
Цитата:
Понятно, что никто не выйдет и не скажет "Ребята, мы обделались". Все будут говорить о проблемах и их решении. Но послушайте, с какими проблемами они столкнулись на пустом месте. Именно из-за того, что у них куча отдельных микросервисов с собственными источниками данных. |
|
03.06.2021, 08:38 | #8 |
Участник
|
И опять мы скатываемся в "технологийщину", я же хотел бы вернуться в "концептуальщину" (простите за грубое слово). Ведь организовать взаимодействие с внешним процессом можно по-разному - этому занятию лет 30 (а то и 50).
На сколько мне известно, термин "микро" был применен из-за того, что при проектировании сервисов стремились максимально упростить его функциональность за счет сужения контекста использования. Упростить настолько, что полная реализация его становилась очевидной и обозреваемой одним разработчиком, чтобы избежать ошибок. Но по факту получается что выделенная в микросервис часть отчуждается из основной системы и в системе остается только её API. Т.е. выделенный кусок должен быть целостным, из него не должно торчать куча необходимых внешних связей (прежде всего логических), которые необходимо реализовывать техническим кардебалетом. Много ли таких частей в средней ERP, низведенных до масштаба "микро"? Мне кажется нет. В основном, это те самые приблудные псы на заднем дворе кухни, у которых от звяканья микроволновки начинают течь слюни. Да они нужны, они создают информационную инфраструктуру. Но существуют за рамками понятия ERP. |
|
04.06.2021, 18:10 | #9 |
Участник
|
Цитата:
Некоторые рекумендуют взять DDD и бить по bounded context. Цитата:
Сообщение от mau
На сколько мне известно, термин "микро" был применен из-за того, что при проектировании сервисов стремились максимально упростить его функциональность за счет сужения контекста использования. Упростить настолько, что полная реализация его становилась очевидной и обозреваемой одним разработчиком, чтобы избежать ошибок.
Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services. This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further. Так как у "микро" нет абсолютно строгого определения, то см. выше. Ориентировочно там написано "no more than a dozen people". |
|
|
За это сообщение автора поблагодарили: mau (1). |