Comments 6
Впечатление такое, что обманули, причем непонятно где:)
Есть сервис, есть его клиентское API в виде отдельного модуля и клиентами он подтягивается.
В чем новизна и необычность? Зачем большая статья, когда это умещается в 2х строчках?
Еще мне интересно — почему сервис не должен зависеть от модуля API?
API обычно включает интерфейсы, сервис — их реализацию. Примеров таких куча:
- Логирование:
slf4j-api
<-logback-classic
- Валидация:
javax.el-api
<-org.glassfish.web.javax.el
- JPA:
hibernate-jpa-2.1-api
<-hibernate-core
* Улучшается масштабирование – различные части приложения масштабируются независимо друг от друга
Тема не раскрыта. Попробуйте масштабировать такой сервис в рамках предложенной архитектуры и расскажите, что получилось. Скорее всего — не получится.
* Эффективное устранение сильной связанности между различными частями системы – это всегда желательно, но лучше всего достигается именно при помощи микросервисов
Ага. Ценой сильного снижения производительности. JSON же везде и REST. Вообще утверждение про «лучше всего» ни на чем не основано, и скорее всего — неправда. И попросту недоказано.
* Повышается надежность системы – при отказе одного сервиса остальные сохраняют работоспособность.
Не показано, как сохраняется работоспособность при отказе одного из этих сервисов. Можно было выбрать любой. Намек — никак не сохраняется. Это достигается другими способами, обычно более сложными, чем просто разбиение системы на микросервисы.
* Свобода при выборе технологий – каждый сервис можно реализовывать при помощи той технологии, которая лучше всего подходит для данного случая.
Как правило это нафиг никому не нужная свобода.
* Улучшенная многоразовость компонентов – сервисы (даже те, что уже развернуты) можно совместно использовать в разных проектах
Это не было продемонстрировано.
Ну и в целом — берем любую книгу о том, как писать EJB, примерно 5-10 летней давности (желательно чтобы это были EJB 3, и там уже было JAX RS). И имеем примерно такой же по объему код, ровно с теми же свойствами. Разворачиваем внутри tomcat, и имеем «множество других достоинств», которые тут не созволили продемонстрировать и даже назвать. Например, централизованный мониторинг.
Берем любую книгу на тему, как писать OSGI сервисы, и снова имем тоже самое. Потому что в мире Java микросервисы давно уже существуют в том или ином виде, и никому их не нужно демонстрировать, особенно таким вот примитивным способом.
У меня сложилось такое впечатление, что сейчас под трендом "микросервисы" пытаются втюхать Spring Boot, Rest и иногда каким-то образом припаять Docker. И если посмотреть в Google Trends, то собственно так оно и есть. То есть чтобы в мозгу разработчика четко отложилось: java-приложения, оказывается, можно разрабатывать без контейнера, но для этого нужен Spring Boot, который нам даст Rest. И это теперь называется микросервисами.
Тем не менее, 10 лет назад в эпоху засилия SOA и JavaEE, когдя я писал что-то вроде:
@WebService
public class AddService {
@WebMethod
public int add(int a, int b) {
return a+b;
}
public static void main(String[] args ){
Endpoint.publish("http://0.0.0.0:1234/AddService", new AddService());
}
}
не было подходящего названия для этого. Люди недоумевали: если это java-приложение, то где интерфейс с кнопочками? Если это веб-приложение, то где сервер приложений, куда оно должно деплоиться? Здесь даже не было более-менее знакомого слова "Spring". И вплоть до того, что клиенты отказывались принимать работу, поскольку не знали каким словом это назвать (мой клиент все-таки придумал название — "тамагочи"))).
Теперь же я любое решение, которое не требует контейнера, я с гордосью называю "микросервис" и вопросов не возникает.
Только раньше к этому не прилагалось лишних обещаний типа легкой масштабируемости или повышения надежности. Которые на самом деле и не выполняются — потому что для этого нужно еще много чего, скажем, вы не сможете смасштабировать написанный вот так «на коленке» REST, потому что везде, извините, номер порта захардкодили.
Может быть я не совсем по теме, но все же: почему бы вам не сделать, что-то типа на подобии краудфандинговой площадки в области перевода книг?
Мне кажется, кроме перечисленных решений (копипаста и чуть большая связанность), есть ещё два: выделить библиотеку в отдельный микросервис со своим API, и, ИМХО, лучший вариант, отказаться от разделения тех микросервисов, которые делят общий код — скорее всего их разделение искусственно.
Многократное использование кода в микросервисной архитектуре — на примере SPRING BOOT