Comments 34
Зачем использовать для микросервисов то, что для них не очень подходит?
Spring boot уже научился работать без встроенного tomcat? Если нет, то неподходит tomcat, так как он из старого мира монолитных приложений и тащит много лишнего.
Но в целом, Spring Boot вроде как очень широко используется для микросервисов.
Собственно на текущем проекте планируем подключить 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 должна была использоваться, для идентификации ресурсов при межсервисном взаимодействии внутри системы.
окей, понял, спасибо
В контексте статьи выше это не очень применимая штука. Потому что статья не о том, как правильно сделать архитектуру для прод решения, а о том, что такое вообще микросервисы и как переписать на них домашний проект без кучи новых библиотек.
Проще говоря, наверное, сначала нужно такое, а потом уже углубляться во всякие библиотеки и правильные решения для микросервисов.
Насколько я знаю, именно в этом основное преимущество микросервисной архитектуры.
Переписываем домашний проект на микросервисы (Java, Spring Boot, Gradle)