Микросервисы, SOA и API: друзья или враги?

Оригинал: Microservices, SOA, and APIs: Friends or enemies? by Kim Clark, опубликован 21 января 2016.

Сравнение ключевых концепций архитектуры приложений и интеграции для развивающегося предприятия.

• Введение
  
  
• Чрезмерно упрощенный взгляд
  
  
• Дихотомия SOA-инициатив
  
  
• Как API соотносятся с сервисами SOA
  
  
• Микросервисы: альтернативная архитектура
  
  
• Преимущества микросервисов
  
  
• Ключевые факторы, влияющие на принятие решения об использовании микросервисов
  
  
• Место микросервисов на картине SOA и проблем интеграции
  
  
• Объединение микросервисов, SOA и API в будущем
  
  
• Выводы
  
  
• Благодарности
  
  
• Ресурсы

Введение

При сравнении микросервисной и сервисно-ориентированной (SOA) архитектуры практически невозможно прийти к согласию о том, как же все-таки они соотносятся друг с другом. Добавление в список еще и application programming interfaces (APIs) картину очевидно не проясняет. Некоторые могут сказать, что это вообще абсолютно изолированные друг от друга понятия, не имеющие ничего общего и предназначенные для решения разных задач. Другие заметят, что данные концепции разделяют общие принципы и созданы для достижения неких общих целей. Микросервисная архитектура может казаться этакой "тонкоструктурной (fine-grained) SOA" или "правильно внедренной SOA".

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

Under the Hood of J2EE Clustering

Давно хотел процитировать замечательную статью еще 2005-го года написания: Under the Hood of J2EE Clustering. Некоторые факты, особенно касающиеся деталей работы тех или иных серверов приложений, а так же кластеризации EJB и JMS, уже порядком устарели, но общие принципы, изложенные в статье, остались неизменными.

Введение

Важно понимать, что кластер должен обеспечивать две вещи:

• Балансировку нагрузки (Load Balancing). Между вызываемым объектом и вызывающим субъектом должен находиться компонент, балансировщик нагрузки, задача которого - перераспределять запросы между разными экземплярами вызываемого объекта. Высокая доступность и высокая производительность реализуются именно данным способом.
  
  
• Преодоление отказа (Failover). Если целевой объект (т.е. тот, к которому перенаправляются вызовы) становится недоступен, то система преодоления отказов должна зафиксировать данный факт и перенаправить последующие запросы на доступные объекты. Именно данным способом реализуется отказоустойчивость.
  

Чтобы понять кластеризацию нужно ответить на следующие вопросы:

• какие типы объектов могут быть кластеризованы?
  
  
• где осуществляется балансировка нагрузки и преодоление отказов в моем коде?
  

В реальности не каждый объект может быть кластеризован и не всегда в коде осуществляется балансировка нагрузки и
преодоление отказа.

Например, рассмотрим следующий код:

public class A {
    ...

    public void business() {
        B instance1 = new B();
        instance1.method1();
        instance2.method2();
        ...
    }
}

public class B {
    ...

    public void method1() {
    }

    public void method2() {
    }
}

В данном коде вызовы методов класса B из класса A не обеспечивают ни балансировки нагрузки, ни преодоления отказа. Для обеспечения данных параметров необходим интерцептор между вызывающим и вызываемым объектами, который будет осуществлять диспетчеризацию и перенаправление запросов на различные копии объектов. Объекты классов A и B работают в одной и той же JVM и сильно связаны друг с другом. Очень сложно разместить логику диспетчеризации между ними.

Из данного примера мы видим, что кластеризации поддаются только те типы объектов, которые могут быть развернуты на распределенной системе. Балансировка нагрузки и преодоление отказов в коде реализуются только при вызове методов удаленных объектов, т.е. объектов, работающих на другой JVM.

Коммуникация в кластере серверов приложений Oracle WebLogic

В данной заметке мы рассмотрим довольно важный для понимания настройки и поддержки серверов приложений Oracle WebLogic вопрос - вопрос коммуникации в кластере.

Общие положения

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

• IP-сокеты - для коммуникации вида точка-точка между участниками кластера;
  
  
• IP unicast и multicast для распространения информации о доступности серверов и их состоянии, а так же для построения кластерного JNDI-дерева.
  

При создании кластера с помощью Configuration Wizard по умолчанию устанавливается режим обмена unicast, а при создании кластера с помощью WLST - multicast. Если есть проблемы с распространением JNDI-дерева на кластер с помощью unicast, то может помочь использование нового свойства - ClusterMBean.MessageOrderingEnabled. По умолчанию данное свойство не включено. Чтобы его включить нужно добавить следующую строчку в config.xml:

<message-ordering-enabled>true</message-ordering-enabled>.

Если данная настройка не решает проблему, то нужно перейти на использование multicast режима.

Валидация XML-сообщений

В статье Проектирование контракта сервиса мы отметили, что действительно самодокументируемый контракт подразумевает возможность автоматической валидации сообщений, которыми данный сервис общается с внешним миром. Пришло время рассмотреть данный процесс подробнее.

Прежде всего давайте разберемся в каких случаях необходима валидация сообщений.

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

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

Не обязательно осуществлять валидацию сообщений в следующих случаях:

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

В данной заметке мы рассмотрим некоторые приемы валидации сообщений, а так же способы обработки ошибок, возникающих при проверке некорректных сообщений.

Уровни сложности сервисов

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

Eclipse Indigo: Пять причин обратить внимание на ECF

Поздравляю всех читателей с официальным выходом Eclipse 3.7 Indigo. Здесь камрад James Sugrue написал статью на JavaLobby - Eclipse Indigo Highlights: Five Reasons to Check Out ECF. Позволю себе перевести ее на русский язык.

Eclipse Communication Framework [1] - традиционный участник Eclipse release trains (перевод "поездов релизов Eclipse" мне как-то не очень нравится, однако термин "поезд" применительно к релизу ПО меня забавляет уже третий год) - непрерывно добавляет новое в свой впечатляющий список возможностей. Данный год не стал исключением - в релиз Eclipse Indigo включен ECF 3.5. В данной статье я сосредоточусь на пяти ключевых возможностях новой версии.

Про моноиды (с примерами на F#)

Введение

Apocalips порадовал статьей, в которой четко и доходчиво объяснил что такое моноид применительно к алгебре над списками и теории категорий. В данной заметке представлен очень вольный перевод его статьи, снабженный примерами на F# (у Apocalips'a примеры на Scala).

Прежде всего рассмотрим обобщенное определение моноида:

1. type IMonoid<'T> =


2.    abstract member mempty : 'T


3.     abstract member mappend : 'T * 'T -> 'T

Другими словами, моноид заданного типа 'T - это объединение двух элементов: функции mappend: 'T -> 'T -> 'T и значения mempty: 'T. Для моноида должны выполняться следующие правила:

1. Функция mappend должна быть ассоциативна, т.е. mappend (x, mappend(y, z)) == mappend(mappend(x, y), z).
2. Значение mempty должно быть единицей функции mappend, другими словами: mappend(x, mempty) == mappend (mempty, x) == x

Hibernate: это должен помнить каждый - 2

При определении идентификатора - первичного ключа - таблицы в Hibernate можно явно указать стратегию генерации его значения. Делается это в мэпинге с помощью тега generator, у которого указывается атрибут class. Например, так:

<id name="uid" column="uuid" type="string" length="32">

   <generator class="ru.naumen.bpm.commons.util.PrefixUUIDGenerator"/>

</id>

Помимо того, что можно определить свою стратегию генерации как класс, реализующий интерфейс org.hibernate.id.IdentifierGenerator, фреймворк содержит ряд уже готовых генераторов. Рассмотрим их подробнее.

Модульная Java, что это?

Позволю себе привести свой перевод статьи Modular Java: What Is It?. Это мой первый более-менее крупный перевод, поэтому иногда наблюдаются отступления от канонического текста, но ногами все равно прошу не пинать.

В последние несколько лет модульность в Java является активно обсуждаемой темой. От (уже утратившего силу) JSR 277 через принятие JSR 291 и продолжаясь в JSR 294 модульность видится как необходимый этап в эволюции Java. Даже новые, основанные на Java языки (такие, как Scala), учитывают модульность. Данная статья, первая в серии о модульной Java, объясняет, что значит модульность и почему об этом нужно беспокоиться.