Микросервисы для разработчиков Java: коммуникация микросервисов

1. Введение

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

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

2. Использование HTTP

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

Семантика протокола HTTP действительно проста, но в то же время гибка и достаточно мощна. Существует несколько основных парадигм взаимодействия (или стилей), построенных поверх протокола HTTP (точнее, HTTP / 1.1 ), которые явно занимают доминирующее положение по отношению к реализациям архитектуры микросервиса .

2.1 МЫЛО

SOAP (или простой протокол доступа к объектам ) является одной из первых спецификаций для обмена структурированной информацией при реализации веб-сервисов. Он был разработан еще в 1998 году и сосредоточен на сообщениях XML, передаваемых в основном по протоколу HTTP .

Одной из особенно инновационных идей, появившихся в результате эволюции протокола SOAP , является язык описания веб-сервисов (или просто WSDL ): язык определения интерфейса на основе XML, который использовался для описания функциональных возможностей, предлагаемых веб-сервисами SOAP . Как мы увидим позже, уроки, извлеченные из WSDL, научили нас, что в той или иной форме понятие явного контракта на обслуживание (или схемы, спецификации, описания) абсолютно необходимо для объединения поставщиков и потребителей.

SOAP более 20 лет, зачем даже упоминать об этом? Удивительно, но существует довольно много систем, которые взаимодействуют с использованием веб-служб SOAP и все еще используются очень интенсивно.

2.2 ОТДЫХ

Для многих появление архитектурного стиля REST означало конец эры SOAP (что, строго говоря, оказалось неправдоподобным).

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

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

https://en.wikipedia.org/wiki/Representational_state_transfer

Корни термина « репрезентативное состояние» восходят к 2000 году, когда Рой Филдинг представил и определил его в своей знаменитой докторской диссертации «Архитектурные стили и проектирование сетевых программных архитектур» .

Интересно, что архитектурный стиль REST в основном не зависит от используемого протокола, но приобрел огромную популярность и признание благодаря HTTP . Это не совпадение, так как в наши дни веб-приложения и API представляют значительную часть приложений.

Существует шесть ограничений, которым должна соответствовать система или приложение, чтобы считаться RESTful . Все они на самом деле очень хорошо играют по правилам архитектуры микросервиса .

Единый интерфейс: не имеет значения, кто является клиентом, запросы выглядят одинаково.
Разделение клиента и сервера : серверы и клиенты действуют независимо (разделение интересов).
Отсутствие состояния: между запросами не сохраняется специфичный для клиента контекст на сервере, и каждый запрос от любого клиента содержит всю информацию, необходимую для обслуживания.
Кэшируемый : клиенты и посредники могут кэшировать ответы, тогда как ответы неявно или явно определяют себя как кэшируемые или нет, чтобы предотвратить получение устаревшими данными клиентами.
Многоуровневая система : клиент обычно не может сказать, подключен ли он напрямую к конечному серверу или к посреднику.
Код по требованию (необязательно): серверы могут временно расширять или настраивать функциональность клиента, передавая исполняемый код (обычно некоторые виды сценариев)

При использовании REST в контексте протокола HTTP используются ресурсы, унифицированные указатели ресурсов ( URL ), стандартные методы HTTP , заголовки и коды состояния для проектирования взаимодействия между серверами и клиентами. В приведенной ниже таблице показано типичное сопоставление семантики протокола HTTP с мыслимыми веб-API управления библиотеками, разработанными в соответствии с архитектурным стилем REST .

URL: https://api.library.com/books/
ПОЛУЧИТЬ	ПОЛОЖИТЬ	PATCH	ПОЧТА	УДАЛИТЬ	ПАРАМЕТРЫ	ГЛАВА
Получить все ресурсы в коллекции.	Замените всю коллекцию другой коллекцией.	Обычно не используется.	Создайте новую запись в коллекции. URI новой записи обычно возвращается операцией.	Удалить всю коллекцию.	Перечислите доступные методы HTTP (и могут быть другие варианты).	Получить все ресурсы в коллекции (должны возвращать только заголовки).
URL: https://api.library.com/books/17
ПОЛУЧИТЬ	ПОЛОЖИТЬ	PATCH	ПОЧТА	УДАЛИТЬ	ПАРАМЕТРЫ	ГЛАВА
Получить представление единственного ресурса.	Замените ресурс полностью (или создайте его, если он еще не существует).	Обновить ресурс (обычно, частично.	Обычно не используется.	Удалить ресурс.	Перечислите доступные методы HTTP (и могут быть другие варианты).	Получить один ресурс (должен возвращать только заголовки).
Идемпотент: да	Идемпотент: да	Идемпотент: нет	Идемпотент: нет	Идемпотент: да	Идемпотент: да	Идемпотент: да
Сейф: да	Сейф: нет	Сейф: нет	Сейф: нет	Сейф: нет	Сейф: да	Сейф: да

Есть другие тонкие, но исключительно важные ожидания (или неявные предпосылки, если хотите), связанные с каждым методом HTTP в контексте REST (и в частности, с микросервисами ): идемпотентность и безопасность. Операция считается идемпотентной, когда даже если один и тот же вход отправляется на нее несколько раз, эффект будет одинаковым (при отправке этого входа только один раз). Следовательно, операция безопасна, если не изменяет ресурс (или ресурсы). Предположения относительно идемпотентности и безопасности имеют решающее значение для обработки сбоев и принятия решений по их устранению.

Подводя итог, очень легко начать создавать веб-API RESTful, поскольку в большинстве языков программирования есть HTTP- сервер и клиент, встроенный в его базовую библиотеку. Потреблять их тоже не сложно: из командной строки ( curl , httpie ), с помощью специализированных клиентов для настольных компьютеров ( Postman , Insomnia ) или даже из веб-браузера (хотя вы вряд ли сможете обойтись без установки дополнительных плагинов).

Эта простота и гибкость REST имеют свою цену: отсутствие первоклассной поддержки обнаружения и самоанализа. Соглашение между сервером и клиентом о ресурсах и содержимом входных и выходных данных является внеплановым.

Книга стилей API с ее рекомендациями по дизайну и темами дизайна — это замечательный ресурс для изучения лучших практик и шаблонов для создания великолепных веб-API RESTful . Кстати, если у вас сложилось впечатление, что архитектурный стиль REST ограничивает ваши API в соответствии с семантикой CRUD (создание / чтение / обновление / удаление), это, безусловно, миф .

2.3 ОТДЫХ: контракты на спасение

Отсутствие явного, общего и описательного контракта (помимо статической документации) для веб-API RESTful всегда было областью активных исследований и разработок в сообществе. К счастью, в последнее время усилия были завершены созданием инициативы OpenAPI и выпуском спецификации OpenAPI 3.0 (ранее известной как Swagger ).

Спецификация OpenAPI (OAS) определяет стандартное описание интерфейса REST API , не зависящее от языка программирования , которое позволяет людям и компьютерам обнаруживать и понимать возможности службы, не требуя доступа к исходному коду, дополнительной документации или проверке сетевого трафика. , При правильном определении через OpenAPI потребитель может понимать и взаимодействовать с удаленной службой с минимальным количеством логики реализации. Подобно тому, что описания интерфейсов сделали для низкоуровневого программирования, спецификация OpenAPI устраняет догадки при вызове службы. — https://github.com/OAI/OpenAPI-Specification

OpenAPI является не стандартом де-факто, который каждый обязан использовать, а продуманным, всеобъемлющим средством управления контрактами ваших веб-API RESTful . Еще одно преимущество, с которым оно приходит, как мы увидим позже в этом уроке, заключается в том, что инструментарий вокруг OpenAPI просто потрясающий.

Среди альтернативных вариантов стоит упомянуть API Blueprint , RAML , Apiary и Apigee . Честно говоря, не имеет значения, что вы собираетесь использовать, сдвиг в сторону контрактной разработки и сотрудничества делает.

2.4 GraphQL

Все движется вперед, и доминирующее положение REST было потрясено новым ребенком в блоке, а именно GraphQL .

GraphQL — это язык запросов для API и среда выполнения для выполнения этих запросов с вашими существующими данными. GraphQL предоставляет полное и понятное описание данных в вашем API, дает клиентам возможность запрашивать именно то, что им нужно, и ничего более, облегчает разработку API со временем и предоставляет мощные инструменты для разработчиков. — https://graphql.org/

У GraphQL интересная история. Первоначально он был создан в Facebook в 2012 году для решения проблем обработки их моделей данных для клиент-серверных приложений . Разработка спецификации GraphQL под открытым небом началась только в 2015 году, и с тех пор эта довольно новая технология постоянно завоевывает популярность и широкое распространение.

GraphQL — это не язык программирования, способный к произвольным вычислениям, а язык, используемый для запросов к серверам приложений, которые имеют возможности, определенные в этой спецификации. GraphQL не требует определенного языка программирования или системы хранения для серверов приложений, которые его реализуют. Вместо этого серверы приложений используют свои возможности и сопоставляют их с единым языком, системой типов и философией, которые кодирует GraphQL . Это обеспечивает единый интерфейс, удобный для разработки продукта, и мощную платформу для создания инструментов. — http://facebook.github.io/graphql/June2018/

Что делает GraphQL особенно привлекательным для микросервисов , так это набор его основных принципов проектирования:

Он иерархический : большая часть данных в наши дни организована в иерархические структуры. Чтобы достичь соответствия с такой реальностью, сам запрос GraphQL структурирован иерархически.
Сильный тип : Каждое приложение объявляет собственную систему типов (также известную как схема). Каждый запрос GraphQL выполняется в контексте этой системы типов, в то время как сервер GraphQL обеспечивает выполнение и правильность такого запроса перед его выполнением.
Клиентские запросы : сервер GraphQL публикует возможности, доступные для его клиентов. Клиент несет ответственность за точное указание того, как он будет использовать эти опубликованные возможности, поэтому данный запрос GraphQL возвращает именно то, что запрашивает клиент.
Внутренняя: конкретная система типов, которая управляется конкретным сервером GraphQL, должна запрашиваться самим языком GraphQL .

GraphQL позволяет клиентам контролировать, какие данные им нужны. Несмотря на некоторые недостатки, неоспоримые преимущества строгой типизации и самоанализа часто делают GraphQL предпочтительным вариантом.

Неудивительно, что большинство реализаций GraphQL также основаны на HTTP и по веским причинам: служат основой для создания веб-API. В двух словах, сервер GraphQL должен обрабатывать только методы HTTP GET и POST . Поскольку концептуальная модель в GraphQL является графом сущностей, такие сущности не идентифицируются URL-адресами. Вместо этого сервер GraphQL работает с единственной конечной точкой (обычно /graphql ), которая обрабатывает все запросы для данной службы.

Удивительно (или нет?), Многие люди относятся к GraphQL и REST как к прямым конкурентам: вы должны выбрать одно или другое. Но правда в том, что оба они являются отличным выбором и могут успешно сосуществовать, чтобы решать бизнес-задачи наиболее эффективным образом. Это и есть микросервисы , верно?

Реализации GraphQL существуют во многих языках программирования (например, graphql-java для Java, Sangria для Scala, и это лишь некоторые из них), но JavaScript- код является выдающимся и задает темп всей экосистеме.

Давайте посмотрим, как веб-API RESTful из предыдущего раздела могут быть описаны в терминах схемы и типов GraphQL .

schema {
  query: Query
  mutation: Mutation
}
 
type Book {
  isbn: ID!
  title: String!
  year: Int
}
 
type Query {
  books: [Book]
  book(isbn: ID!): Book
}
 
# this schema allows the following mutation:
type Mutation {
  addBook(isbn: ID!, title: String!, year: Int): Book
  updateBook(isbn: ID!, title: String, year: Int): Book
  removeBook(isbn: ID!): Boolean
}

Разделение между мутациями и запросами обеспечивает естественные явные гарантии безопасности конкретной операции.

Справедливо сказать, что GraphQL медленно, но неуклонно меняет ландшафт веб-API, поскольку все больше и больше компаний адаптируют его или уже адаптировались. Вы можете этого не ожидать, но RESTful и GraphQL часто развертываются рядом. Одним из новых шаблонов, появившихся в результате такого сосуществования, являются бэкенды для веб- интерфейсов ( BFF ), где веб-API GraphQL выходят на веб-сервисы RESTful .

3. Не только HTTP

Хотя HTTP — король, есть несколько коммуникационных сред и библиотек, которые выходят за рамки этого. Как, например, разговоры в стиле RPC , самая старая форма межпроцессного взаимодействия.

По сути, RPC является протоколом запрос-ответ , в котором клиент отправляет запрос на удаленный сервер для выполнения указанной процедуры с предоставленными параметрами. Если связь между клиентом и сервером не асинхронна, клиент обычно блокируется, пока удаленный сервер не отправит ответ обратно. Хотя RPC довольно эффективен (в большинстве случаев формат обмена является бинарным), у RPC возникали огромные проблемы с совместимостью и переносимостью между различными языками и платформами. Так зачем сгребать старый пепел?

3,1 гРПЦ

HTTP / 2 , основная редакция протокола HTTP , разблокировала новые способы продвижения коммуникаций в сети. gRPC , популярная, высокопроизводительная универсальная среда RPC с открытым исходным кодом от Google , — это та, которая связывает семантику RPC с протоколом HTTP / 2 .

Чтобы добавить примечание, хотя gRPC является более или менее независимым от базового транспорта, нет другого поддерживаемого транспорта, кроме HTTP / 2 (и нет планов по его изменению в ближайшем будущем). Под капотом gRPC построен поверх еще одной широко распространенной и зрелой части технологии от Google , называемой буферами протокола .

Протоколные буферы — это гибкий, эффективный, автоматизированный механизм для сериализации структурированных данных — представьте XML, но меньше, быстрее и проще. Вы определяете, как вы хотите, чтобы ваши данные были структурированы один раз, затем вы можете использовать специальный сгенерированный исходный код, чтобы легко записывать и считывать ваши структурированные данные в различные потоки данных и из них, используя различные языки. Вы даже можете обновить свою структуру данных, не нарушая развернутые программы, скомпилированные со «старым» форматом. — https://developers.google.com/protocol-buffers/docs/overview

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

Например, здесь очень упрощенная попытка переопределить веб-API из предыдущих разделов с использованием спецификации буферов протокола .

syntax = "proto3";
 
import "google/protobuf/empty.proto";
 
option java_multiple_files = true;
option java_package = "com.javacodegeeks.library";
 
package library;
 
service Library {
  rpc addBook(AddBookRequest) returns (Book);
  rpc getBooks(Filter) returns (BookList);
  rpc removeBook(RemoveBookRequest) returns (google.protobuf.Empty);
  rpc updateBook(UpdateBookRequest) returns (Book);
}
 
message Book {
  string title = 1;
  string isbn = 2;
  int32 year = 3;
}
 
message RemoveBookRequest {
  string isbn = 1;
}
 
message AddBookRequest {
  string title = 1;
  string isbn = 2;
  int32 year = 3;
}
 
message UpdateBookRequest {
  string isbn = 1;
  Book book = 2;
}
 
message Filter {
  int32 year = 1;
  string title = 2;
  string isbn = 3;
}
 
message BookList {
  repeated Book books = 1;
}

gRPC обеспечивает привязки для многих основных языков программирования и использует инструменты буфера протокола и плагины для генерации кода (но если вы программируете на Go , вам повезло, поскольку языковая экосистема Go — это современное состояние). gRPC — это отличный способ установить эффективные каналы для внутренней коммуникации между сервисами или сервисами.

В эти дни вокруг gRPC происходит множество интересных событий. Наиболее многообещающим является gRPC для веб-клиентов (в настоящее время в бета-версии), который собирается предоставить клиентскую библиотеку JavaScript, которая позволит клиентам браузера напрямую обращаться к серверам gRPC .

3.2 Apache Thrift

Чтобы быть справедливым, gRPC не является единственной доступной структурой стиля RPC . Apache Thrift — это еще один инструмент, предназначенный для разработки масштабируемых кросс-языковых сервисов. Он объединяет программный стек с механизмом генерации кода для создания сервисов, которые эффективно и без проблем работают на многих языках.

Apache Thrift специально разработан для поддержки неатомарных изменений версий кода клиента и сервера. Это очень похоже на буферы gRPC и протокола и разделяет одну и ту же нишу. Хотя он не так популярен, как gRPC , он поддерживает привязки для 25 языков программирования и использует модульный механизм транспорта (включая HTTP ).

У Apache Thrift есть собственный диалект языка определения интерфейса, который довольно сильно напоминает буферы протокола . Для сравнения, вот еще одна версия нашего определения веб-API, переписанная с использованием Apache Thrift .

namespace java com.javacodegeeks.library
 
service Library {
  void addBook(1: Book book),
  list getBooks(1: Filter filter),
  bool removeBook(1: string isbn),
  Book updateBook(1: string isbn, 2: Book book)
}
 
struct Book {
  1: string title, 
  2: string isbn,
  3: optional i32 year
}
 
struct Filter {
  1: optional i32 year;
  2: optional string title;
  3: optional string isbn;
}

3.3 Apache Avro

И последнее, но не менее важное: Apache Avro , система сериализации данных, часто используется для обмена сообщениями в стиле RPC и обмена сообщениями. Что отличает Apache Avro от других, так это то, что схема представлена в формате JSON , например, вот наши веб-API, переведенные на Apache Avro .

{
  "namespace": "com.javacodegeeks.avro",
  "protocol": "Library",
 
  "types": [
    {
      "name": "Book", 
      "type": "record",
      "fields": [
          {"name": "title", "type": "string"},
          {"name": "isbn", "type": "string"},
          {"name": "year", "type": "int"}
      ]
    }
  ],
 
  "messages": {
     "addBook": {
       "request": [{"name": "book", "type": "Book"}],
       "response": "null"
     },
     "removeBook": {
       "request": [{"name": "isbn", "type": "string"}],
       "response": "boolean"
     },
     "updateBook": {
       "request": [
           {"name": "isbn", "type": "string"},
           {"name": "book", "type": "Book"}
       ],
       "response": "Book"
     }
  }
}

Еще одна уникальная особенность Apache Avro — оформление спецификаций различного типа на основе расширений имен файлов, например:

* .avpr : определяет спецификацию протокола Avro
* .avsc : определяет спецификацию схемы Avro
* .avdl: определяет IDL Avro

Подобно Apache Thrift , Apache Avro поддерживает различные транспорты (которые дополнительно могут быть без сохранения состояния или с сохранением состояния ), включая HTTP .

4. REST, GraphQL, gRPC, Thrift… как выбрать?

Чтобы понять, где каждый из этих стилей взаимодействия подходит лучше всего, статья Understanding RPC, REST и GraphQL является отличной отправной точкой.

5. Передача сообщений

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

Обмен сообщениями является сердцем и душой четных приложений и микросервисов . На практике они реализуются главным образом на принципах архитектуры Sourcing Event Sourcing или Command Query Responsibility ( CQRS ), однако определение того, что значит быть управляемым событиями, выходит за рамки этого.

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

5.1 WebSockets и отправленные сервером события

Если ваша микросервисная архитектура состоит из веб-сервисов RESTful , выбор родного решения для обмена сообщениями HTTP является логичным решением.

Протокол WebSocket обеспечивает двунаправленные ( полнодуплексные ) каналы связи между клиентом и сервером через одно соединение. Интересно, что WebSocket является независимым протоколом на основе TCP , но в то же время «… он предназначен для работы через HTTP-порты 80 и 443, а также для поддержки HTTP-прокси и посредников…» ( https://tools.ietf.org / html / rfc6455 ) .

Для двунаправленной связи отправленные сервером события (или, вкратце, SSE ) являются отличным и простым способом, позволяющим серверам передавать данные клиентам через HTTP (или с помощью выделенных протокольных протоколов).

С ростом популярности HTTP / 2 роль WebSocket и событий, отправляемых сервером, постепенно уменьшается, поскольку большинство их функций уже включены в сам протокол.

5.2. Очереди сообщений и брокеры

Обмен сообщениями является исключительно интересным и переполненным пространством в разработке программного обеспечения. Служба сообщений Java (JMS), Расширенный протокол очереди сообщений (AMQP), Простой (или потоковый) текстовый протокол обмена сообщениями (STOMP), Apache Kafka , NATS , NSQ , ZeroMQ , не говоря уже о Redis Pub / Sub , предстоящих потоках Redis и тоннах облачных решений. Что сказать, даже PostgreSQL включает один !

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

эффективно публиковать схемы сообщений (чтобы поделиться тем, что упаковано в сообщение)
развивать схемы сообщений с течением времени (в идеале, не ломая вещи)

Удивительно, но наши старые буферы протоколов друзей, Apache Thrift и Apache Avro , отлично подходят для этих целей. Например, Apache Kafka часто используется с реестром схем для хранения версионной истории всех схем сообщений. Реестр построен на основе Apache Avro .

Другими интересными библиотеками, о которых мы не говорили (поскольку они ориентированы исключительно на форматы сообщений, а не на службы или протоколы), являются FlatBuffers , Cap’n Proto и MessagePack .

5.3 Актерская модель

Модель акторов, созданная в 1973 году, представляет концепцию акторов как универсальных примитивов параллельных вычислений, которые взаимодействуют друг с другом, отправляя сообщения асинхронно. Любой субъект в ответ на полученное сообщение может одновременно выполнить одно из следующих действий:

отправить конечное количество сообщений другим актерам
создать конечное число новых актеров
изменить назначенное поведение для обработки следующего полученного сообщения

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

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

В JVM бесспорным лидером является Akka : инструментарий для создания высококонкурентных, распределенных и устойчивых приложений, управляемых сообщениями, для Java и Scala. Это началось как реализация модели актера, но с годами превратилась в полноценный швейцарский нож для разработчиков распределенных систем.

Честно говоря, идеи и принципы, лежащие в основе актерской модели, делают ее серьезным кандидатом на внедрение микросервисов .

5.4 Аэрон

Для высокоэффективных и критичных к задержке коммуникаций платформы, которые мы обсуждали до сих пор, могут быть не лучшим выбором. Вы, конечно, можете вернуться к заказному транспорту TCP / UDP, но есть хороший набор опций.

Aeron — это эффективный надежный одноадресный UDP, многоадресный UDP и транспорт сообщений IPC . Он поддерживает Java из коробки с производительностью, являющейся ключевым направлением. Aeron разработан для обеспечения максимальной пропускной способности при минимальной и наиболее предсказуемой задержке из всех систем обмена сообщениями. Aeron интегрируется с Simple Binary Encoding (SBE) для наилучшей производительности при кодировании и декодировании сообщений.

5.5 RSocket

RSocket — это двоичный протокол для использования в транспортных потоках байтов, таких как TCP , WebSockets и Aeron . Он поддерживает несколько симметричных моделей взаимодействия через асинхронную передачу сообщений, используя только одно соединение:

запрос / ответ (поток 1)
запрос / поток (конечный поток многих)
огонь и забыл (нет ответа)
канал (двунаправленные потоки)

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

6. Облако родное

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

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

В случае, если безсерверные вычисления кажутся вам новыми, хорошее введение в такую архитектуру дается в этой статье в блоге Мартина Фаулера

6.1 Функция как услуга

Одним из лучших примеров безсерверных вычислений в действии является функция как услуга ( FaaS ). Как вы можете догадаться, единицей развертывания в такой модели является функция (в идеале, на любом языке, но Java, JavaScript и Go, скорее всего, те, которые вы могли бы реально использовать прямо сейчас). Ожидается, что функции будут запущены в течение нескольких миллисекунд, чтобы обрабатывать отдельные запросы или реагировать на входящие сообщения. Когда эти функции не используются, они не потребляют никаких ресурсов и не несут никакой оплаты.

Каждый облачный провайдер предлагает свой вид функции в качестве сервисной платформы, но стоит упомянуть Apache OpenWhisk , OpenFaaS и рифф- проекты, пару устоявшихся функций с открытым исходным кодом в качестве реализации сервиса .

6.2 Knative

Это буквально новорожденный участник безсерверного движения, о котором Google объявил всего несколько недель назад .

Компоненты Knative расширяют возможности Kubernetes, предоставляя набор компонентов промежуточного программного обеспечения, которые необходимы для создания современных, ориентированных на исходные коды и контейнерных приложений, которые могут работать где угодно: в помещениях, в облаке или даже в стороннем центре обработки данных. … Компоненты Knative предлагают разработчикам собственные API-интерфейсы Kubernetes для развертывания функций, приложений и контейнеров в стиле без сервера в режиме автоматического масштабирования. — https://github.com/knative/docs

Knative находится на очень ранних стадиях разработки, но его потенциальное влияние на серверные вычисления может быть революционным.

7. Выводы

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

8. Что дальше

В следующем разделе учебного пособия мы собираемся оценить ландшафт Java и наиболее широко используемые фреймворки для создания производственных микросервисов на JVM.

Полный набор файлов спецификаций доступен для скачивания .