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

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

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

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

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

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

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

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

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

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

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

Плюсы:

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

Минусы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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