Зачем использовать для микросервисов то, что для них не очень подходит?
Spring boot уже научился работать без встроенного tomcat? Если нет, то неподходит tomcat, так как он из старого мира монолитных приложений и тащит много лишнего.
Но в целом, Spring Boot вроде как очень широко используется для микросервисов.
Если судить по статьям, вроде как предлагают использовать другие фрейморвки со встроенными http серверами.
Хотя, может я ошибаюсь, я давно не использовать Java и не знаю, как там сейчас дела(
Собственно на текущем проекте планируем подключить spring boot вместо обычного spring(наследный код) в том числе и для того, чтобы уйти от tomcat'а.
там по сути только сервер и контейнер сервелтов.
По весу-сейчас зашел на сайт томката -зип-архив стэндэлон томката весит 9.5Мб. Это будет меньше чем некоторые либы.
Томкат это почти Java EE и он поддерживает вроде неплохое число спецификаций (те же сервлеты). Как мне кажется, для микросервисов они излишни и только зря их нагружают.
Я не считаю, что Java тормозит, но мне определенно кажется, что вот такой вот workflow, с использованием нативных потоков немного устарел.
Я не прав?
Если же вам кажется что томкат вам мал, вы всегда можете подключить любой другой сервер из поддерживаемых спринг бутом или даже написать свой адаптер или даже сервер.
Проблема микросервисной архитекруты в том, что один монолит заменяется на кучу мелких структур.
И если каждая структура инициализируется большим количеством излишеств, то потом возникают отбитые статьи в духе "Мы переписали микросервисы со Sprint+Tomcat на Golang и получил выграш по всем ресурсам в 10 раз, потому что мы поменяли архитектуру потому что Java шлак, а Golang рулит".
А сервлеты необходимы, поверх них работает спринг и по сути псе что бывает на аппликэйшн серверах
public class ApiClient
{
protected readonly ApiContext _context;
protected readonly string _apiPrefix;
public ApiClient(ApiContext context, string apiPrefix)
{
_context = context;
_apiPrefix = apiPrefix;
}
protected Task<ResponseT> GetAsync<ResponseT>(string method, string param = null)
{
return RestRequest.GetAsync<ResponseT>(
RequestUrl( method, param ) + $"?accessToken={GetAccessToken()}"
);
}
protected Task<ResponseT> PutAsync<ResponseT>(string method, string param = null)
{
return RestRequest.PutAsync<ResponseT>(
RequestUrl( method, param ),
$"accessToken={GetAccessToken()}"
);
}
protected Task<ResponseT> PostAsync<ResponseT>(string method, Dictionary<string, string> fields)
{
return RestRequest.PostAsync<ResponseT>(
RequestUrl( method ),
fields
);
}
protected Task<ResponseT> DeleteAsync<ResponseT>(string method, string param = null)
{
return RestRequest.DeleteAsync<ResponseT>(
RequestUrl( method, param ) + $"?accessToken={GetAccessToken()}"
);
}
protected string RequestUrl(string method, string param = null)
{
var url = $"{_context.apiServerUrl}{_apiPrefix}";
if (!string.IsNullOrEmpty( method ))
url += "/" + method;
if (!string.IsNullOrEmpty( param ))
url += "/" + param;
return url;
}
protected string GetAccessToken()
{
if (!_context.isAuthorized)
throw new Exception("Context ins't authorized");
return _context.accessToken;
}
}
Помогите программисту J не добраться до виски.
Так специально задумано?
По клиенту — можно посмотреть в сторону Feign, есть простое и красивое решение. Пример
Сложно сказать, не засекал, но вроде как не сильно много, за исключением авторизации, с которой были проблемы. Сначала там смотрел на Redis сессии, потом уже JWT. Даже чисто по статье, на которую я ссылаюсь, сходу не вышло потому что AbstractAuthenticationProcessingFilter
не подходит для моих целей.
Без авторизации статья вышла бы на пол года раньше, никак не мог найти время чтобы разобраться до конца.
Я не знаю что такое Eureka.
Каждый сервис запускается отдельно и имеет свой адрес, а в zuul они просто прописываются, чтобы он понимал куда слать запросы.
Eureka позволяет микросервисам находить друг-друга (discovery service). Насколько я понимаю, Zuul задумывался как входной proxy и балансировщик нагрузки, а Eureka должна была использоваться, для идентификации ресурсов при межсервисном взаимодействии внутри системы.
окей, понял, спасибо
В контексте статьи выше это не очень применимая штука. Потому что статья не о том, как правильно сделать архитектуру для прод решения, а о том, что такое вообще микросервисы и как переписать на них домашний проект без кучи новых библиотек.
Проще говоря, наверное, сначала нужно такое, а потом уже углубляться во всякие библиотеки и правильные решения для микросервисов.
Очень рад что статья до сих пор полезна и помогает!
Насколько я знаю, именно в этом основное преимущество микросервисной архитектуры.
Никто не мешает поднимать ещё инстансы отдельных сервисов и впилить в эту схему балансировщик.
Но статья просто про базовую архитектуру, а-ля hello-world: берём типичный pet project и разбиваем его его на сервисы.
Переписываем домашний проект на микросервисы (Java, Spring Boot, Gradle)