мы прошли полный круг с микросервисами, возвращаясь к очень старым школьным подходам?

9

С точки зрения архитектуры и дизайна программного обеспечения, как микросервисы «складываются» (каламбур) против промежуточного программного обеспечения? Я пришел из Java, и похоже, что когда вы уходите от простого REST в качестве API и абстрагируетесь от различных слоев и параметров соединения, по крайней мере, в Java, вы почти полностью вернулись к некоторым очень старым школьным идеям. , Мы вернулись к виртуализации ... тогда как JVM уже виртуальная.

С точки зрения агностики вы можете, и я бы поспорил с преимуществами, абстрагировать RESTful API от CORBA. Или, в более Java-центре, JMS или MDB.

Когда-то EJB был большим событием в Java, затем он был признан чем-то вроде кластерного эффекта, но теперь мы вернулись к началу?

Или же микросервисы предлагают то, чего не хватает в CORBA или, что еще лучше, в MDB? Когда я читаю (TLDR) Мартина Фаулера, объясняющего микросервисы, это кажется мне хорошим решением плохой проблемы, если хотите. Или, скорее, закрытый подход, который вводит уровень сложности, только подталкивая проблему вокруг. Если сервисы действительно микро и многочисленны, то каждый из них имеет стоимость в долларах, чтобы запустить и поддерживать его.

Кроме того, если один микро сервис из множества меняет свой API, то все, что зависит от этого сервиса, ломается. Это не кажется слабо связанным, это кажется противоположностью проворной. Или я неправильно употребляю эти слова?

Конечно, между этими крайностями существует неопределенный выбор.

Акула против Гориллы ... иди! (Для педантиков, это должно быть иронично, и это совсем не мое намерение. Вопрос должен быть принят за чистую монету. Если вопрос можно улучшить, пожалуйста, сделайте это, или прокомментируйте, и я исправлю. )

Представьте себе множество микросервисов, работающих в докере, все на одной машине, разговаривающих друг с другом ... безумие. Трудно поддерживать или администрировать, и почти невозможно что-либо изменить, потому что любое изменение будет каскадным и приведет к непредвиденным ошибкам. Как это лучше, что эти сервисы разбросаны по разным машинам? И, если они распространяются, то, безусловно, некоторые очень, очень старые школьные методы решили, по крайней мере, в определенной степени, распределенные вычисления.

Почему горизонтальное масштабирование настолько распространено или, по крайней мере, желательно?

Суфир
источник
4
Голосование закрыть. Непонятно, что ты спрашиваешь и почему ты это спрашиваешь. Микросервисная архитектура - это просто другая архитектура. Ни больше ни меньше.
davidk01
1
Вы также можете найти эту статью полезной: devweek.com/blog/microservices-the-good-the-bad-and-the-ugly
davidk01
1
Я предпочитаю «Так что теперь у них есть сотни маленьких поддельных сервисов, и вместо монолита им приходится беспокоиться о том, что произойдет, когда кто-то захочет изменить контракт одной из этих услуг. Клубок пряжи под другим именем. Вместо этого задаваясь вопросом, будет ли код компилироваться, если они вносят изменения, они задаются вопросом, будет ли он выполняться на практике ". - Отказ от микросервисов для сварливых шеек : нет, я не бородатый, это просто юмористическая статья.
Туфир
«Вместо того, чтобы интересоваться, будет ли код компилироваться ... они задаются вопросом, будет ли он работать ...» На самом деле это вообще не проблема. Просто потому, что если разработчик меняет контракт, не уведомляя об этом все заинтересованные стороны, его следует отшлепать очень сильно. Буквально. Если мы используем срочный контракт, то представьте, меняет ли ваш оператор мобильной связи условия контракта, не спрашивая и не информируя вас? Вот почему это контракт - все участвующие стороны должны быть осведомлены об изменениях контракта / согласны с ними, и когда это изменение произойдет (при условии правильного развития), все должно быть протестировано и работать без сбоев.
Алексей Каменский
1
@Thufir Как было сказано до MS, это еще один подход, у него будут свои преимущества и недостатки. Я действительно работал с этим подходом (даже до того, как услышал, что у него есть специальное название) для нескольких проектов. Как примечание стороны - это не водопад, это то, что вы делаете. Поскольку я работал над одним проектом, разрабатывающим (в команде) часть мобильной ОС, этот подход является единственным способом, потому что ОС не может быть выполнена как giant blob, у нее должны быть интерфейсы, поэтому каждая часть, начинающаяся с ядра, является своего рода MS, и первым делом прежде любая команда, начавшая писать код, должна была согласовать спецификации v0.0.1.
Алексей Каменский

Ответы:

2

TL; DR. Я имел удовольствие пить много Kool-Aid со вкусом Microserver, так что я могу немного рассказать о причинах этого.

Плюсы:

  • Службы знают, что их зависимости стабильны и успели испечь
  • Разрешить непрерывное развертывание новых версий
  • Позвольте компонентам быть возвращенными, не затрагивая более высокие слои.

Минусы:

  • Вы не можете использовать новые и блестящие функции ваших зависимостей.
  • Вы никогда не можете нарушить обратную совместимость API (или, по крайней мере, в течение многих циклов разработки).

Я думаю, что вы в корне не понимаете, как должна работать микросервисная архитектура. Способ, которым он должен работать, состоит в том, что каждый микросервис (далее именуемый MS) имеет жесткий API, с которым согласны все его клиенты. MS может вносить любые изменения, которые она хочет, при условии сохранения API. MS может быть выброшена и переписана с нуля, если API сохраняется.

Для облегчения слабой связи каждая MS зависит от версии n-1 своих зависимостей. Это позволяет текущей версии службы быть менее стабильной и более рискованной. Это также позволяет версиям выходить волнами. Сначала обновляется 1 сервер, затем половина и, наконец, остальные. Если в текущей версии когда-либо возникают какие-либо серьезные проблемы, MS можно откатить до предыдущей версии без потери функциональности на других уровнях.

Если необходимо изменить API, его необходимо изменить с учетом обратной совместимости.

Константин Таращанский
источник
«MS может быть выброшена и переписана с нуля, если API сохраняется». - ничего нового там нет, но хорошо. С точки зрения производительности, на противоположном конце спектра, как все эти MS сравниваются с монолитным приложением / службой / системой? С точки зрения распределения, это звучит так , и, пожалуйста, исправьте меня, если не так, что есть потенциальный выигрыш в производительности от размещения n MS на одной машине ... виртуализированной на мэйнфрейме ?? Это похоже на то, что чем больше вы масштабируете MS по горизонтали, тем проще его масштабировать по вертикали ...? Бонусные баллы за то, что я не читал мой вопрос :)
Thufir
1
Как и в случае любого уровня косвенности, вы получаете удар по производительности по сравнению с большим шариком грязи. В случае MS это особенно дорого, так как при каждом вызове вы совершаете обход в сеть. Использование виртуализации или контейнеров делает этот круговой обход значительно короче, поскольку вызов на самом деле никогда не покидает машину. Это также означает, что вы получаете большую изоляцию (безудержная служба не может повредить своим партнерам) при меньшей стоимости оборудования.
Константин Таращанский
5

Каждая техника разработки программного обеспечения, которую мы когда-либо изобретали, была так или иначе связана с управлением сложностью. Огромная часть из них была и остается посвященной абстракции, инкапсуляции и слабой связи. Микросервисы - это еще один способ выполнения этих задач, поэтому, вероятно, он напоминает многие старые методы на высоком теоретическом уровне, но это не делает его менее полезным или актуальным.

Что касается слабой связи, я думаю, вы немного не поняли цель. Если задача A должна вызвать задачу B, никогда не будет способа сделать A и B разделенными на 100%. Никогда не случится. Что вы можете сделать, так это убедиться, что, если задача B вызывает задачу C, тогда задача C никогда не должна беспокоиться об изменениях в A. Если все эти три задачи связаны друг с другом в один большой двоичный объект, передавая структуры друг другу, то есть значительный шанс, что им всем придется измениться, если кто-нибудь из них это сделает. Но если все три являются микросервисами, то вы в основном гарантированы, что изменение A приведет к принудительному обновлению только B (если только это не настолько серьезное изменение основных функций A, что вы, вероятно, должны были сделать его совершенно новым сервисом). Это особенно верно, если все обновления микросервиса выполняются обратно совместимым способом, каким они и должны быть.

Что касается гибкого комментария, я могу сказать вам по личному опыту, что наш микросервисный код гораздо лучше работает с гибким кодом, чем наш код, «связанный в большой блоб». В последнем случае, когда кто-то исправляет ошибку в низкоуровневой функции, он буквально должен послать по электронной почте всему отделу исследований и разработок сообщение: «Пожалуйста, перенесите ваши задачи, иначе они все рухнут в пятницу». Мы получаем пару таких каждую неделю . Если бы его код был в микросервисе, мы все автоматически извлекли бы выгоду из исправления, как только он развернул новую версию.

Я не совсем понимаю комментарий о COBRA и MDB, так как они кажутся не программными архитектурами, а скорее их компонентами; Насколько я понимаю, это потенциальные способы определения протоколов обмена сообщениями ваших микросервисов и / или реализации указанных микросервисов, а не сами по себе альтернативы микросервисам.

Ixrec
источник
1
«Если все эти три задачи связаны друг с другом в одном большом объекте ...» У меня есть только перспектива Java на это, но я бы сказал «нет», плохая идея, не делайте этого. Создайте библиотеку, API # 1, API # 2 и т. Д., Чтобы достичь точной точки ".. Задача C никогда не должна беспокоиться об изменениях в A", поскольку C является клиентом только B, а не A вообще. , В этом отношении, я не вижу в этом ничего нового, простите. Я знаю, что вопрос, который я задал, был нечетким. Это нечеткий вопрос, потому что я не совсем понимаю, о чем это все. Каждый ответ был полезен для меня, хотя бы для того, чтобы помочь мне с лексикой.
Thufir
1
@Thufir Если библиотеки все динамически связаны, и все задачи выполняются на одном и том же наборе машин, то вы правы, это действительно позволило бы раздельное развертывание. Но микросервисы позволяют отбросить даже эти предположения, если вы хотите зайти так далеко от разделения. Это совершенно разумно, чтобы не.
Иксрек
CORBA - это (была) распределенная технология, которая обеспечивала распределенные архитектуры в то время (конец 1990 года), когда еще не было широко распространенных имен для их определения. Вы могли свободно внедрять системы на основе CORBA с крупнозернистой или мелкозернистой структурой, которые в конечном итоге стали называться SOA или микросервисами. CORBA не выжил, но мы делаем это снова, просто с другой технологией. Проблема, однако, была не в технологии. Так что да, мы идем полный круг. Я надеюсь, что мы узнали что-то в процессе.
Xtian
4

Как это лучше, что эти сервисы разбросаны по разным машинам?

Из-за облака.

Закончили смеяться еще? Если серьезно, то для многих предприятий самая большая стоимость программного обеспечения - это не программное обеспечение. Это пропускная способность, аппаратное обеспечение, стоимость CDN и т. Д. Теперь, когда у каждого есть мобильное устройство, трафика становится намного больше. И это будет только хуже, так как ваш тостер получает собственное подключение к Интернету.

Таким образом, компании стремятся управлять этими затратами. В частности, они пытаются решить бизнес-проблему: «если эта штука взорвется, как я могу обслуживать миллионы людей, получающих / использующих мое программное обеспечение - без предварительной оплаты серверов, чтобы обслуживать миллионы людей, получающих / использующих мое программное обеспечение» ?».

Почему горизонтальное масштабирование настолько распространено или, по крайней мере, желательно?

Потому что это решает эту (огромную и растущую) проблему бизнеса.

Когда у вас есть дюжина пользователей, вы можете выбросить все службы в один ящик. Это хорошо, так как вы хотите заплатить только за одну коробку. И вы также не хотите платить за изменения в приложении, чтобы разделить различные услуги, когда ваш бизнес масштабируется. В наши дни у вас нет времени, чтобы сделать это, прежде чем толпа клиентов в любом случае зажжет ваши серверы.

Это также хорошо, потому что позволяет манипулировать распределением серверов, чтобы вы могли:

  1. использовать большую часть серверов, которые у вас есть, оставляя мало «отходов».
  2. измерять производительность отдельных элементов вашего программного обеспечения.
  3. сократить время развертывания / простоя, вызванное выпусками.

Наличие очень детального развертывания делает эти две вещи проще / лучше (в дополнение к обеспечению лучшего разделения проблем).

Telastyn
источник
Хорошо, я вижу преимущество. Существует низкий барьер для входа, но он может увеличиваться. Я полагаю, что бросает меня в петлю, когда вы масштабируете горизонтально n MS, это только кажется ... очень ... ретро? Что-то. Я не могу выразить словами, почему это кажется неправильным.
Thufir
Масштабирование приложений - это проблема, которая не обязательно требует микросервисов: вы можете очень легко увеличить мощность виртуальной машины в AWS (даже по требованию) или добавить больше виртуальных машин за балансировщиком нагрузки в традиционной архитектуре.
xtian
@ xtian - конечно, но вы часто ошибаетесь и тратите больше денег, чем нужно. Идея микросервисов заключается в том, что вы просто масштабируете то, что вам нужно (процессор, память, диск, пропускная способность, gpu)
Теластин