Pull to refresh

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". И вплоть до того, что клиенты отказывались принимать работу, поскольку не знали каким словом это назвать (мой клиент все-таки придумал название — "тамагочи"))).


Теперь же я любое решение, которое не требует контейнера, я с гордосью называю "микросервис" и вопросов не возникает.

Ну я об этом и толкую. Это все можно уже лет 10 как в таком же ровно виде делать.

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

Может быть я не совсем по теме, но все же: почему бы вам не сделать, что-то типа на подобии краудфандинговой площадки в области перевода книг?

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

Мне кажется, кроме перечисленных решений (копипаста и чуть большая связанность), есть ещё два: выделить библиотеку в отдельный микросервис со своим API, и, ИМХО, лучший вариант, отказаться от разделения тех микросервисов, которые делят общий код — скорее всего их разделение искусственно.
Sign up to leave a comment.