EMy

где можно получить быстрый сапорт в случае какой-то проблемы

Ессно где больше сообщество. Если выбирать только из этих двоих - я бы выбрал дебиан.

очень популярен в последнее время(#1 distrowatch),

Абсолютно неавторитетный источник с нулевой полезностью.
Берите Debian.

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

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

https://ru.wikipedia.org/wiki/Микросервисная_архит...

Понятие позволяющее разбить проект на людей, которые каждый пишут на своем языке.
Смысл сводится к тому, что программы обмениваются данными через интернет, а не запускаются в рамках одного компьютера - соответственно пропадает понятие классы-интерфейсы-неймспейсы, появляется понятие "запрос-ответ-косяк" :)

Точно так же как программу на ООП можно разбить на подпапки по неймспейсам - платежи там, регистрация здесь - так же можно разбить программу на несколько маленьких программ. Размер не определен то есть можно только авторизацию сделать на отдельном компе, а можно целый пласт функционала - и то и то микросервис. А можно сначала написать монолит большое приложение, а потом там где просадка будет замечена - этот кусок функционала на другую машину выбросить.

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

Связан с тотальным гемором о шинах сообщений и откату свалившихся задач - если в базе данных ты в транзакцию завернул и забыл, то когда задача пошла по цепочке и свалилась где-то посредине начинается игра в "поймай кто сломался".

Преимущества безусловно есть. Когда ты можешь увеличить производительность на конкретной задачи скопировав её одну на еще 10 компьютеров, это менее болезненно чем копировать гигантский проект и вырезать из него часть функционала. Но и гемора хватит с головой.

Не знаю, почему все ругаются на диаграмму. Вполне традиционная. Просто сервера приложений обычно предоставляют кучу "коннекторов", одним из них может являться и http.

В вашем случае tomcat + spring являются и web-сервером и сервером приложений. Или если сказать по другому. Tomcat - контейнер для web-приложений, а spring - приложение для web. Томсат - web-сервер, Spring - web-приложение. В один Tomcat можно упихнуть десятка три-четыре web-приложений на Spring.

Лучше всего прочитать про модель TCP/IP, тогда сразу поймете, что к чему. Не знаю откуда эта диаграмма, но она еще сильнее вас запутает, можете смело удалять её со всех носителей информации. А так, грубо говоря (на пальцах), возьмем в пример php-приложение.
Запрос => Веб-сервер(nginx) => Сервер-приложений(php-fpm, например) => бд(если этого требует скрипт) => Сервер-приложений => Веб-сервер => Ответ.

AJAX

Выскажу непопулярное мнение: Spring имеет смысл учить только тогда, когда уже есть несколько лет опыта работы с Java.

А учить его надо по учебникам. На Тостере уже много раз спрашивали по каким именно - Хороший туториал или книгу по Spring?

вот два ресурса - там конечно не только ди

https://www.baeldung.com/inversion-control-and-dep...
https://martinfowler.com/articles/injection.html
но это самое важное что там есть:

The Spring Framework is a very comprehensive framework. ... Spring provides a light-weight container, e.g. the Spring core container, for dependency injection (DI). This container lets you inject required objects into other objects. This results in a design in which the Java class are not hard-coupled.Oct 25, 2018