Веб-сервисы в теории и на практике для начинающих
Что такое веб-сервисы?
Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.
Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.
С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.
Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.
Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.
По сути, веб-сервисы — это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.
Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).
Протоколы веб-сервисов
На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:
На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.
Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.
Нас в первую очередь интересуют вопросы создания новых веб-служб, а не реализация клиентов к существующим (как правило поставщики веб-сервисов поставляют пакеты с функциями API и документацией, посему вопрос построения клиентов к существующим веб-службам менее интересен с точки зрения автора).
SOAP против REST
Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.
По мнению же автора, кратко можно выделить следующее:
SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.
В любом случае вам решать, что больше подойдет вашему приложению. Вполне вероятно, вы даже захотите реализовать оба протокола, чтобы оставить выбор за пользователями службы и — это ваше право.
Практическое применение веб-сервисов
Поскольку речь идет о практическом применении, нам нужно выбрать платформу для построения веб-службы и поставить задачу. Так как автору ближе всего PHP 5, мы и выберем его в качестве технологии для построения службы, а в качестве задачи примем следующие требования.
Допустим, нам необходимо создать службу, предоставляющую доступ к информации о курсах валют, которая собирается нашим приложением, и накапливается в базе данных. Далее посредством веб-сервиса, данная информация передается сторонним приложениям для отображения в удобном для них виде.
Как видим задача довольно проста и, с точки зрения самой службы, ограничивается лишь чтением информации, но в практических целях нам этого будет достаточно.
Этап первый — реализация приложения сбора информации о курсах валют.
Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка Украины) ежедневно и складывать в базу данных под управлением СУБД MySQL.
Создадим структуру данных.
Таблица валют (currency):
Таблица номиналов обмена (exchange):
Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:
класс Grubber (models/Grabber.php):
и сам граббер (grabber.php):
Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:
Все — у нас есть достаточно полезный сервис.
Теперь реализуем веб-сервис, который позволит другим приложениям извлекать данные из нашей базы.
Реализация SOAP сервиса
Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.
Поскольку наш веб-сервис будет публичным, хорошим вариантом будет создание WSDL файла, который описывает структуру нашего веб-сервиса.
WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.
На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.
класс CurrencyExchange (models/CurrencyExchange.php):
Отметим, что для автоматической генерации WSDL, нам необходимо написать комментарии в стиле javadoc, потому что именно в них мы прописываем информацию о типах принимаемых аргументов и возвращаемых значений. Неплохо также описывать в нескольких словах работу методов — ведь WSDL послужит описанием API для сторонних разработчиков, которые будут использовать ваш веб-сервис.
Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.
Теперь в Zend Studio входим в меню File->Export. выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl
Если вы будете добавлять новую функциональность в ваш веб-сервис, вам нужно будет пересоздавать WSDL-файл. Но здесь не так все гладко. Следует учитывать, что SOAP-клиент, который уже запрашивал ваш WSDL файл, кеширует его на своей стороне. Поэтому, если вы замените старое содержимое новым в WSDL файле, некторые клиенты его не прочтут. А значит, при добавлении новой функциональности, дописывайте версию в имя вашего файла. И не забудбте обеспечить обратную совместимость для старых клиентов, особенно если вы не являетесь их поставщиком.
С другой стороны, WSDL довольно жестко задает структуру веб-сервиса, а это значит, что, если существует необходимость ограничить функциональность клиента по сравнению с сервером, вы можете не включать определенные методы ваших классов в WSDL. Таким образом они не смогут быть вызваны, несмотря на то, что существуют.
Реализация же самого сервера не предстваляет теперь никакой сложности:
Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php
Код простейшего клиента может быть таким:
Реализация REST сервиса
REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.
И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.
Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.
Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:
Как видите все очень сходно и просто.
Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).
Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:
При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.
Простейший тестовый клиент к REST сервису может быть в нашем случае таким:
В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.
Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).
Заключение
Мы выполнили задачу минимум и показали, что такое веб-сервисы, для чего они нужны и как их реализовывать. Естественно, приведенный пример, возможно, несколько оторван от жизни, но он был выбран лишь в качестве инструмента для объяснения предмета и сущности веб-сервисов.
Кроме того мы увидели, что реализация веб-сервиса — задача довольно простая при использовании современного инструментария, который позволяет сконцентрироваться, в первую очередь, на разработке функциональности самого сервиса, не заботясь о низкоуровневой реализации протоколов.
Автор надеется, что данный материал будет действительно полезен тем, кто становится на тропу разработки веб-служб.
Веб-сервисы в Java
Когда вы взаимодействуете с любой веб-страницей, это включает запрос и ответ через HTML-страницу. Аналогично, веб-сервисы также включают запрос и ответ, но в форме XML или JSON. Java, являясь подходящим языком для взаимодействия на стороне сервера, обеспечивает взаимодействие между различными приложениями на разных платформах.
Что такое веб-сервис в Java?
Веб-сервис в Java является подходящей средой для распространения связи между клиентскими и серверными приложениями во всемирной паутине. Это программный модуль, который предназначен для выполнения определенного набора задач следующим образом:
Преимущества
Как правило, существует два типа веб-сервисов в Java:
1. Soap
Простой объектный протокол доступа (SOAP) – это стандартная спецификация протокола обмена сообщениями на основе XML. Связь между веб-сервисом и клиентом происходит с использованием сообщений XML. Простая архитектура веб-сервиса имеет два компонента, а именно клиент и поставщик услуг.
На приведенном выше рисунке вы можете заметить, как клиент будет общаться с поставщиком услуг. Поэтому для связи клиент должен знать такую информацию, как расположение сервера веб-служб, доступные функции, типы подписи и возврата, а также форматы ввода-вывода.
Поставщик услуг создаст стандартный XML-файл, который будет содержать всю вышеуказанную информацию. Таким образом, если этот файл передан клиенту, он сможет получить доступ к веб-сервису.
2. RESTful
Передача состояния представления (REST) – это клиент-серверная архитектура без сохранения состояния, в которой веб-службы рассматриваются как ресурсы и могут быть идентифицированы по их URL-адресам. Он состоит из двух компонентов REST-сервера, который обеспечивает доступ к ресурсам, и REST-клиента, который получает доступ и изменяет ресурсы REST. Взгляните на рисунок ниже для того же.
В этом стиле архитектуры REST клиент и сервер обмениваются представлениями ресурсов, используя стандартизированный интерфейс и протокол. REST не является конкретным протоколом, но когда люди говорят о REST, они обычно имеют в виду REST по HTTP. Ответ от сервера рассматривается как представление ресурсов. Это представление может быть сгенерировано из одного или нескольких ресурсов. Веб-службы RESTful используют методы протокола HTTP для операций, которые они выполняют. Он включает в себя такие методы, как GET, POST, DELETE и т. д.
Существует два основных API, определенных для разработки приложений веб-служб.
Оба эти API-интерфейса Java являются частью стандартной установки JDK, поэтому вам не нужно добавлять какие-либо jar-файлы для работы с ними.
Пример JAX-WS
Давайте создадим простое приложение Hello World JAX-WS. Здесь создадим простой файл класса с именем Demo.java и напишем программу, как показано ниже, для отображения простого сообщения.
Вы можете просто запустить это приложение, и сообщение веб-службы JAX-WS SOAP будет опубликовано.
Пример JAX-RS
Джерси является эталонной реализацией API JAX-RS, он не является частью стандартного JDK, и вы должны включить все необходимые банки. Лучший способ – использовать сборку Maven, поэтому создайте простой веб-проект Dynamic, а затем преобразуйте его в Maven в Eclipse.
Чтобы создать приложение JAX-RS, вам необходимо выполнить следующие шаги.
Шаг 1: Добавьте зависимости в файл pom.xml, как показано ниже:
Шаг 2: Теперь следующим шагом является добавление сервлета Jersey в наш дескриптор развертывания web.xml в качестве фронт-контроллера.
Шаг 3: После всего этого давайте теперь создадим простой класс обслуживания JAX-RS.
После настройки вышеуказанного файла вам просто нужно экспортировать его как файл WAR, а затем получить к нему доступ в браузере. Вы получите вывод, как показано ниже.
Собеседование по Java EE — Web services (вопросы и ответы)
Список вопросов и ответов по теме «Веб-сервисы» в Java (Java web services).
к списку вопросов раздела JEE
Вопросы
1. Что такое веб сервисы?
2. В чем разница между SOA и web service?
3. Что такое SOAP?
4. Что такое REST?
5. В чем разница между REST и SOAP веб сервисами?
6. Как бы вы решили какой из REST или SOAP веб сервисов использовать?
7. Объясните понятие WSDL.
8. Что такое JAX-WS?
9. Расскажите о JAXB.
10. Можем ли мы посылать soap сообщения с вложением?
11. Что такое MTOM?
12. Что такое XOP?
13. Объясните элемент SOAP envelope.
14. Как определяется пространство имен SOAP?
15. Что вы знаете о кодировании в SOAP (encoding)?
16. Что определяет атрибут encodingStyle в SOAP?
17. Какие два конечных типа веб сервисов используют JAX-WS?
18. Какие существуют правила для кодирования записи header?
19. Что вы знаете об инструменте wsimport?
20. Что вы знаете об инструменте wsgen?
21. Какие вы можете выделить различия между SOAP и другими техниками удаленного доступа?
22. Что такое resource в REST?
23. Какие HTTP методы поддерживаются в REST?
24. Когда можно использовать GET запрос вместо POST для создания ресурса?
25. Какая разница между GET и POST запросами?
26. Что означает WADL?
27. Какие вы знаете фреймворки, которые реализуют REST веб сервисы?
28. Какая разница между AJAX и REST?
29. Что делает аннотация @Path?
30. Что делает аннотация @PathParam?
31. Что делает аннотация @QueryParam?
32. Что делает аннотация @MatrixParam?
33. Что делает аннотация @FormParam?
34. Какие два способа получения заголовка HTTP запроса в JAX-RS вы знаете?
35. Как скачать файл с помощью JAX-RS?
Ответы
1. Что такое веб сервисы?
Веб-служба, веб-сервис (англ. web service) — идентифицируемая веб-адресом программная система со стандартизированными интерфейсами. Веб-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах (SOAP, XML-RPC, REST и т. д.). Веб-служба является единицей модульности при использовании сервис-ориентированной архитектуры приложения. К характеристикам веб сервисов относят:
2. В чем разница между SOA и web service?
Сервис-ориентированная архитектура (SOA, service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам. Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST). Веб сервисы реализующие эту концепцию используют XML, JSON и др., а так же интернет протоколы вроде HTTP(S), SMTP и др..
3. Что такое SOAP?
SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам; вплоть до спецификации 1.2) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.
4. Что такое REST?
REST (сокр. от англ. Representational State Transfer — «передача состояния представления») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC.
В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют REST-запрос), а необходимые данные передаются в качестве параметров запроса. Для веб-сервисов, построенных с учётом REST, то есть не нарушающих накладываемых им ограничений, применяют термин «RESTful».
5. В чем разница между REST и SOAP веб сервисами?
REST vs SOAP. Часть 1. Почувствуйте разницу: https://habrahabr.ru/post/131343/
6. Как бы вы решили какой из REST или SOAP веб сервисов использовать?
REST против SOAP можно перефразировать как «Простота против Стандарта». В случае REST (простота) у вас будет скорость, расширяемость и поддержка многих форматов. В случае с SOAP у вас будет больше возможностей по безопасности (WS-security) и транзакционная безопасность (ACID).
7. Объясните понятие WSDL.
WSDL (англ. Web Services Description Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML.
Каждый документ WSDL 1.1 можно разбить на следующие логические части:
Микросервисы на Java: практическое руководство
Вы можете использовать это руководство, чтобы понять что такое Java микросервисы, как вы будете их разрабатывать и создавать. А также получить обзор библиотек для разработки Java микросервисов.
7000 слов, вероятно, не стоит читать ее на мобильном устройстве. Добавьте ее в закладки и вернитесь позже.
Содержание
Основы Java микросервисов
Чтобы получить реальное представление о микросервисах Java, имеет смысл начать с самых основ: печально известного монолита на Java, что это такое и каковы его преимущества или недостатки.
Что такое монолит Java?
Представьте, что вы работаете на банк или финтех-стартап. Вы предоставляете пользователям мобильное приложение, которое они могут использовать для открытия нового банковского счета.
Для этого коде на Java требуется класс контроллера, который, упрощенно, выглядит примерно так, как показано ниже.
В чем проблема с Java монолитами?
По своей сути, в монолите Java нет ничего плохого. Просто опыт проекта показал, что если у вас:
В результате ваш маленький файл bank.jar превращается в гигантский кодовый гигабайт, который все боятся развертывать.
Как уменьшить размер монолита Java?
Это естественно приводит к вопросу о том, как уменьшить монолит. На данный момент ваш bank.jar работает в одной JVM, один процесс на одном сервере. Ни больше ни меньше.
Теперь вы можете придумать идею: «Служба проверки рисков используется другими отделами в моей компании, и она на самом деле не имеет ничего общего с моим доменом Mono (lithic) Bank, поэтому мы можем попробовать вырезать его из монолита и развернуть как его отдельный продукт, или, если говорить технически, запустите его как свой собственный процесс Java.
Что такое микросервис Java?
В практическом плане это означает, что вместо вызова метода riskCheck() внутри вашего BankController вы переместите этот метод / bean-компонент со всеми его вспомогательными классами в свой собственный проект Maven / Gradle, поместите его под контроль системы управления исходным кодом и разверните его независимо от вашего. банковского монолита.
Весь этот процесс извлечения не делает ваш новый модуль RiskCheck микросервисом как таковым, и это потому, что определение микросервисов открыто для интерпретации (что приводит к изрядному количеству обсуждений в командах и компаниях).
Вместо того, чтобы рассуждать об этом, мы будем придерживаться прагматичного подхода и делать две вещи:
Итак, подведем итог: сначала у вас был один процесс JVM, один банковский монолит. Теперь у вас есть процесс JVM банковского монолита и микросервис RiskCheck, который работает в своем собственном процессе JVM. И ваш монолит теперь должен вызвать этот микросервис для проверки рисков.
Как общаться между Java микросервисами?
По существу, у вас есть два варианта: синхронное взаимодействие или асинхронное взаимодействие.
Синхронное взаимодействие с помощью HTTP/REST сервисов
Синхронное взаимодействие микросервисов обычно осуществляется через HTTP и REST-подобные сервисы, которые возвращают XML или JSON — хотя это ни в коем случае не является обязательным (посмотрите, например, на Google Protocol Buffers).
Используйте REST-коммуникацию, когда вам нужен немедленный ответ, который мы используем в нашем случае, так как проверка риска обязательна перед открытием счета: нет проверки риска, нет счета.
Посмотрите ниже раздел Какие библиотеки лучше всего подходят для синхронных вызовов Java REST?
Асинхронное взаимодействие с помощью обмена сообщениями
Асинхронная микросервисная связь обычно осуществляется посредством обмена сообщениями с помощью реализации JMS и / или с помощью протокола, такого как AMQP. Обычно, на практике не следует недооценивать интеграцию по электронной почте / SMTP.
Используйте асинхронное взаимодействие, когда вам не нужен немедленный ответ, скажем, пользователи нажимают кнопку «купить сейчас», и вы хотите сгенерировать счет-фактуру, что, безусловно, не должно происходить в рамках цикла запроса-ответа пользователя на покупку.
Посмотрите ниже раздел Какие инструменты лучше всего подходят для асинхронного обмена сообщениями Java?
Пример: вызов REST API в Java
Предположим, что мы решили использовать синхронную микросервисную связь, наш Java код на низком уровне будет выглядеть примерно так. Низкоуровневый, потому что для микросервисных коммуникаций вы обычно создаете клиентские библиотеки, которые абстрагируют вас от реальных HTTP-вызовов.
Глядя на код, становится ясно, что теперь вы должны развернуть два Java (микро) сервиса: ваш банк и сервис RiskCheck. В итоге вы получите две JVM, два процесса. Графическое изображение этого будет выглядеть так:
Но остается вопрос: как именно вы вырезаете или настраиваете эти микросервисы? Что это за мелкие фрагменты? Какой правильный размер?
Давайте посмотрим что в реальности.
Микросервисная архитектура на Java
На практике компании пытаются разработать или спроектировать микросервисные проекты различными способами. Это зависит от того, пытаетесь ли вы превратить существующий монолит в проект микросервисов или начинаете с нового проекта.
От монолита к микросервисам
Одна довольно органичная идея — вычленить микросервисы из существующего монолита. Обратите внимание, что «микро» здесь на самом деле не означает, что сами извлеченные сервисы действительно будут микро — они сами могут быть довольно большими.
Давайте рассмотрим немного теории.
Идея: разбить монолит на микросервисы
Унаследованные проекты выигрывают от микросервисного подхода. Главным образом по трем причинам:
Это означает, что вы можете взглянуть на свой монолит Java-банка и попытаться разбить его по границам домена — это вполне разумный подход.
Реальность: пусть кто-то другой сделает это
Хотя этот подход определенно выглядит хорошо на бумаге и UML-подобных диаграммах, у него есть свои недостатки. В основном, вам нужны очень сильные технические навыки, чтобы справиться с этим. Почему?
Потому что существует огромная разница между пониманием того, что было бы неплохо извлечь, скажем, сильно связанный модуль управления учетными записями из вашего монолита, и сделать это (правильно).
Большинство корпоративных проектов достигают стадии, когда разработчики боятся, скажем, обновить 7-летнюю версию Hibernate до более новой, которая является лишь обновлением библиотеки, но требуются значительные усилия, чтобы не сломать ничего.
Эти же разработчики теперь должны копаться в старом, унаследованном коде с неясными границами транзакций базы данных и извлекать четко определенные микросервисы? Возможно, но часто это реальная проблема, и ее нельзя решить на доске или на совещаниях по архитектуре.
Здесь уместна цитата из @simonbrown в Twitter:
Я буду повторять это… если люди не могут правильно строить монолиты, микросервисы не помогут.
I’ll keep saying this… if people can’t build monoliths properly, microservices won’t help.
Simon Brown
Новый проект с микросервисой архитектурой
Ситуация выглядит немного иначе при разработке новых проектов на Java. Теперь эти три пункта, перечисленные выше выглядят немного иначе:
Это приводит к тому, что компании пытаются использовать микросервисы в новых Java проектах.
Техническая микросервисная архитектура
Первый подход является наиболее очевидным для разработчиков, вопреки настоятельным рекомендациям против него. Hadi Hariri (https://twitter.com/hhariri) рекомендует использовать рефакторинг «Extract Microservice» в IntelliJ.
Хотя следующий пример слишком упрощен, реализации, наблюдаемые в реальных проектах, к сожалению, не слишком далеки от него.
До микросервиса
С использованием Java микросервиса подстроки
Таким образом, вы, по сути, включаете вызов метода Java в вызов HTTP, без очевидных причин для этого. Одна из причин, однако, заключается в следующем: отсутствие опыта и попытка форсировать подход на основе микросервисов Java.
Рекомендация: не делайте этого.
Микросервисная архитектура, ориентированная на workflow (рабочий процесс)
Следующим распространенным подходом является разработка ваших микросервисов Java на основе рабочего процесса.
Пример из реальной жизни: в Германии, когда вы обращаетесь к (государственному) врачу, он должен записать ваше назначение в своем программном обеспечении CRM для здравоохранения.
Чтобы получить оплату от страховой компании, он отправит ваши данные о лечении и всех других пациентов, которых он лечил, посреднику через XML.
Посредник рассмотрит этот XML-файл и (упрощенно):
Если вы сейчас попытаетесь смоделировать этот рабочий процесс с помощью микросервисов, у вас получится это как минимум.
Примечание. В этом примере взаимодействие между микросервисами не имеет значения, но вполне может быть выполнено асинхронно с использованием брокера сообщений, таким как RabbitMQ, поскольку врач все равно не получает немедленной обратной связи.
Опять же, это то, что хорошо выглядит на бумаге, но сразу приводит к нескольким вопросам:
Интересно, что для некоторых архитекторов приведенная выше диаграмма выглядит проще, потому что у каждого сервиса теперь есть свое точное, четко определенное назначение. Раньше это выглядело как этот страшный монолит:
Несмотря на то, что можно спорить о простоте этих диаграмм, теперь вам определенно нужно решить дополнительные операционные задачи.
Рекомендация:
→ Не делай этого.
Прим. перев.:
Chaos Monkey — архитектурный принцип Netflix для поддержки автомасштабируемых stateless-микросервисов — любой инстанс может быть остановлен и автоматически заменен без какой-либо потери состояния. Chaos Monkey следит за тем, чтобы никто не нарушал этот принцип.
Однако с меньшей гиперболой.
Попытка моделировать микросервисы по доменным границам — очень разумный подход. Но граница домена (скажем, управление пользователями или выставление счетов) не означает, что нужно взять один рабочий процесс и разделить его на крошечные отдельные части (получить XML, проверить XML, переслать XML).
Следовательно, всякий раз, когда вы начинаете с новый проект на Java микросервисах, и границы домена все еще очень расплывчаты, старайтесь поддерживать размер ваших микросервисов на нижнем уровне. Вы всегда можете добавить больше модулей позже.
И убедитесь, что у вас есть исключительно сильные навыки DevOps в вашей команде / компании / подразделении для поддержки вашей новой инфраструктуры.
Полиглото или командно-ориентированная микросервисная архитектура
Существует третий, почти либертарианский подход к разработке микросервисов: предоставление вашим командам или даже отдельным лицам возможности реализовывать пользовательские истории с использованием любого количества языков или микросервисов (маркетинговый термин: полиглотное программирование).
Таким образом, приведенная выше служба проверки XML может быть написана на Java, в то время как микросервис правдоподобия написан на языке Haskell (чтобы сделать его математически обоснованным), а микросервис пересылки страховки должен быть написан на языке Erlang (потому что он действительно должен масштабироваться 🙂 ).
То, что может показаться забавным с точки зрения разработчика (разработка идеальной системы с вашим идеальным языком в изолированной среде), в сущности, никогда не является тем, чего хочет организация: унификация и стандартизация.
Это означает относительно стандартизированный набор языков, библиотек и инструментов, чтобы другие разработчики могли продолжать поддерживать ваш микросервис Haskell в будущем, когда вы перейдете на более экологичные пастбища.
Что интересно: историческая стандартизация зашла слишком далеко. Разработчикам в больших компаниях из списка Fortune 500 иногда даже не позволяли использовать Spring, потому что это «не входило в план компании по технологиям». Но переход на полноценный полиглотный подход — это почти то же самое, просто другая сторона той же монеты.
Рекомендация: если вы собираетесь использовать полиглотный подход, попробуйте меньшее разнообразие в одной и той же экосистеме языка программирования. Пример: Kotlin и Java (на основе JVM со 100% совместимостью друг с другом), а не Haskell и Java.
Развертывание и тестирование Java микросервисов
И есть одна замечательная вещь об экосистеме Java, или, скорее, о JVM: вы пишете свой код Java один раз, вы можете запустить его в основном на любой операционной системе, если хотите, если вы не скомпилировали свой код с более новой версией Java, чем ваша целевая версия JVM).
Это важно понимать, особенно когда речь идет о таких темах, как Docker, Kubernetes или The Cloud. Почему? Давайте рассмотрим различные сценарии развертывания:
Пример минимального развертывания микросервиса Java
Продолжая пример с банком, мы получили файл monobank.jar (монолит) и наш недавно извлеченный riskengine.jar (первый микросервис).
Следовательно, минимальное развертывание может состоять из двух каталогов, которые выглядят примерно так:
К сожалению, есть множество соблазнительных ответов на этот вопрос.
Как использовать инструменты сборки, SSH и Ansible для развертывания микросервисов Java
Скучный, но совершенно прекрасный ответ на развертывание Java-микросервисов — это то, как администраторы разворачивали любую серверную Java-программу в компаниях за последние 20 лет. С использованием набора инструментов:
Если вы не зациклены на создании «дышащего» облака на основе серверов с автоматической балансировкой нагрузки, chaos monkeys, управляющих вашими машинами, или горячего и неясного ощущения, что выборы ведущего в ZooKeeper работают, то эта установка уведет вас достаточно далеко.
Олдскулно, скучно, но работает.
Как использовать Docker для развертывания микросервисов Java
Вернемся к заманчивым выборам. Пару лет назад на сцену вышел Docker или тема контейнеризации.
Если у вас нет опыта работы с ним, это то, что нужно для конечных пользователей или разработчиков:
Это выглядит немного иначе для языков, таких как PHP или Python, где несовместимость версий или настройки развертывания исторически были более сложными.
Или, если ваше Java-приложение зависит от множества других установленных служб (с правильными номерами версий): например от базы данных, такой как Postgres, или хранилища значений ключей, таких как Redis.
Итак, основное преимущество Docker для микросервисов Java, а точнее для приложений Java, заключается в:
Если ваши развертываемые файлы похожи или вы хотите запустить небольшую базу данных Oracle на своем компьютере разработки, попробуйте Docker.
Как использовать Docker Swarm или Kubernetes для развертывания микросервисов Java
Теперь возникает вопрос: как вы управляете этим кластером, что означает запуск ваших контейнеров Docker, проверки работоспособности, развертывание обновлений, масштабирование (brrrr)?
Два возможных ответа на этот вопрос — Docker Swarm и Kubernetes.
Подробное описание обоих вариантов невозможно в рамках данного руководства, но на самом деле важно следующее: оба варианта в конце концов полагаются на то, что вы пишете файлы YAML (см. ниже Не вопрос: Рассказы об отступах в Yaml) для управления вашим кластером. Сделайте быстрый поиск в Твиттере, если хотите знать, какие чувства это вызывает на практике.
Таким образом, процесс развертывания для ваших микросервисов Java теперь выглядит примерно так:
Как протестировать микросервисы Java
Предположим, вы решили внедрить микросервисы в производство, но как вы тестируете интеграцию n-микросервисов во время разработки? Чтобы увидеть, работает ли полный рабочий процесс, а не только отдельные части?
На практике вы найдете три разных способа:
Кроме того, в дополнение к вашим микросервисам Java вам, вероятно, также понадобится работающий брокер сообщений (например, ActiveMQ или RabbitMQ) или, возможно, сервер электронной почты или любой другой компонент обмена сообщениями, с которым ваши микросервисы Java должны взаимодействовать друг с другом.
Это приводит к значительному занижению сложности на стороне DevOps. Взгляните на Microservice Testing Libraries, чтобы смягчить эту боль.
В любом случае, эта сложность приводит нас к общим проблемам микросервиса:
Общие вопросы о Java микросервиах
Давайте рассмотрим проблемы микросервисов, характерные для Java, от более абстрактных вещей, таких как устойчивость к конкретным библиотекам.
Как сделать микросервис Java устойчивым?
Напомним, что при создании микросервисов вы по сути заменяете вызовы методов JVM
на синхронные вызовы или асинхронный обмен сообщениями.
В то время как выполнение вызова метода в основном гарантировано (за исключением того, что JVM неожиданно завершает работу), сетевой вызов по умолчанию ненадежен.
Он может работать, он также может не работать по разным причинам: от неработающей или перегруженной сети, до внедрения нового правила брандмауэра и взрыва вашего брокера сообщений.
Чтобы увидеть, какое это имеет значение, давайте взглянем на примерный пример BillingService.
Шаблоны устойчивости HTTP / REST
Скажем, клиенты могут купить электронные книги на сайте вашей компании. Для этого вы только что внедрили микросервис биллинга, который может вызвать ваш интернет-магазин для создания фактических счетов в формате PDF.
Сейчас мы сделаем этот вызов синхронно, через HTTP. (Было бы более разумно вызывать эту службу асинхронно, потому что генерация PDF не обязательно должна быть мгновенной с точки зрения пользователя. Но мы хотим повторно использовать этот самый пример в следующем разделе и увидеть различия.)
Подумайте, какие возможные результаты может иметь этот HTTP-вызов. Обобщая, вы получите три возможных результата:
Обработка ошибок, а не только счастливых случаев, ожидается для любой программы. То же самое относится и к микросервисам, даже если вам нужно приложить дополнительные усилия для обеспечения совместимости всех развернутых версий API, как только вы начнете с развертываний и выпусков отдельных микросервисов.
И если вы хотите полностью использовать Chaos Monkey, вам также придется смириться с возможностью того, что ваши серверы будут просто очищены во время обработки запроса, и вы можете захотеть, чтобы запрос был перенаправлен на другой работающий экземпляр.
Интересный случай с предупреждением — это отложенный случай. Возможно, микросервисный жесткий диск респондента заполнен, и вместо 50 мс для ответа требуется 10 секунд. Это может стать еще более интересным, когда вы испытываете определенную нагрузку, так что неотзывчивость вашего BillingService начинает каскадно проходить через вашу систему. Подумайте о медленной кухне, медленно запускающей блок всех официантов ресторана.
Этот раздел, очевидно, не может дать исчерпывающий обзор темы устойчивости микросервисов, но служит напоминанием для разработчиков о том, что на самом деле это то, что нужно решать, а не игнорировать до вашего первого выпуска (что, по опыту, происходит чаще, чем следует)
Популярной библиотекой, которая помогает вам думать о задержках и отказоустойчивости, является Hystrix от Netflix. Используйте его документацию, чтобы больше погрузиться в тему.
Шаблоны устойчивости обмена сообщениями
Давайте подробнее рассмотрим асинхронное общение. Наш код BillingService теперь может выглядеть примерно так, при условии, что мы используем Spring и RabbitMQ для обмена сообщениями.
Чтобы создать счет, мы теперь отправляем сообщение нашему брокеру сообщений RabbitMQ, у которого есть несколько работников, ожидающих новых сообщений. Эти работники создают счета в формате PDF и отправляют их соответствующим пользователям.
Теперь потенциальные ошибки выглядят немного иначе, так как вы больше не получаете немедленных ответов OK или ERROR, как это было с синхронным HTTP-соединением. Вместо этого у вас будут примерно три случая ошибки:
Опять же, детальное описание каждого отдельного шаблона устойчивости асинхронного микросервиса выходит за рамки данного руководства. Более того, оно лишь дает указатели в правильном направлении, тем более что они также зависят от используемой вами технологии обмена сообщениями. Примеры:
Какой Java-микросервисный фреймворк лучший?
Недавно, частично вдохновленные параллельными разработками, такими как реактивное программирование, Kubernetes или GraalVM, возникла пара специализированных микросервисных сред.
В конце концов, вам придется сделать свой собственный выбор, но эта статья может дать некоторые, возможно, нетрадиционные рекомендации:
За исключением Spring Boot, все фреймворки для микросервисов обычно позиционируют себя как невероятно быстрые с очень быстрым временем запуска, малый объемом памяти, возможностью масштабирования до бесконечности, с впечатляющими графиками, сравнивающими себя с бегемотом Spring Boot или друг с другом.
Это поражает воображение разработчиков, которые поддерживают устаревшие проекты, которые иногда занимают несколько минут, чтобы загружаться, или разработчикам, работающим в облаке, которые хотят запустить-остановить столько микроконтейнеров, сколько им сейчас нужно, или они хотят им нужно в течение 50 мс.
Проблема, однако, заключается в том, что (искусственное) время запуска на «голом железе» и время повторного развертывания едва ли влияют на общий успех проекта, гораздо меньше, чем сильная экоструктура платформы, хорошая документация, сообщество и навыки разработчика.
Вы должны смотреть на это так.
Тогда добавление дополнительных требований для микросервисов (устойчивость, сеть, обмен сообщениями, DevOps, инфраструктура) будет иметь гораздо большее влияние на ваш проект, чем загрузка пустого hello world. А для горячих повторных развертываний во время разработки вы, наконец, вы можете использовать такие решения, как JRebel или DCEVM.
Вернемся к цитате Саймона Брауна (Simon Brown): если люди не могут создавать (быстрые и эффективные) монолиты, им будет трудно создавать (быстрые и эффективные) микросервисы — независимо от фреймворка.
Итак, выбирайте свой фреймвок с умом.
Какие библиотеки лучше всего подходят для синхронных REST вызовов Java?
Поговорим о более практических аспектах вызова HTTP REST API. На низком техническом уровне вы, вероятно, придете к одной из следующих клиентских библиотек HTTP:
Обратите внимание, что здесь я говорю «вероятно», потому что есть и другие способы, от старых добрых клиентов JAX-RS до современных клиентов WebSocket.
В любом случае, существует тенденция к генерации HTTP-клиента, вместо того чтобы возиться с HTTP-вызовами самостоятельно. Для этого вам нужно рассмотреть проект OpenFeign и его документацию в качестве отправной точки для дальнейшего чтения.
Какие брокеры являются лучшими для асинхронного обмена сообщениями Java?
Начиная разработку с асинхронного обмена сообщениями, вы, скорее всего, придете к ActiveMQ (Classic или Artemis), RabbitMQ или Kafka. Опять же, это просто популярный выбор.
Вот несколько основных моментов:
Чтобы лучше понять, когда использовать RabbitMQ (или традиционных брокеров сообщений в целом) или Kafka, в качестве отправной точки взгляните на соответствующий пост Pivotal в качестве отправной точки.
Тем не менее, в общем, старайтесь игнорировать любые искусственные причины производительности при выборе вашего брокера. Было время, когда команды и интернет-сообщества много спорили о том, насколько быстрым был RabbitMQ и насколько медленным был ActiveMQ.
Теперь у вас те же аргументы в отношении того, что RabbitMQ медленен, с только 20-30K сообщений в секунду. Для Kafka сообщается о 100K сообщений в секунду. С одной стороны, такие сравнения можно игнорировать учитывая, что вы на самом деле сравниваете яблоки и апельсины.
Но даже более того: оба значения пропускной способности могут быть на нижней или средней стороне для Alibaba Group, но вы и автор, никогда не видели проекты такого размера (миллионы сообщений в минуту) в реальном мире. Они определенно существуют, но эти цифры — не то о чем нужно беспокоиться для остальных 99% обычных бизнес-проектов Java.
Так что не обращайте внимания на шумиху и выбирайте мудро.
Какие библиотеки я могу использовать для микросервисного тестирования?
В зависимости от вашего стека вы можете использовать инструменты Spring (экосистема Spring) или что-то вроде Arquillian (экосистема JavaEE).
Вы захотите взглянуть на Docker и действительно хорошую библиотеку Testcontainers, которая помогает, например, легко и быстро настроить базу данных Oracle для разработки, локальных тестов или интеграции.
Для макетирования целых HTTP-серверов, посмотрите на Wiremock. Для тестирования асинхронного обмена сообщениями попробуйте встраивание (ActiveMQ) или докеринг (RabbitMQ), а затем написать тесты с помощью Awaitility DSL.
Кроме этого, применяются все ваши обычные «подозреваемые», такие как Junit, TestNG для AssertJ и Mockito.
Обратите внимание, что это далеко не полный список, и если вам не хватает вашего любимого инструмента, опубликуйте его в разделе комментариев, и я включу его в следующую редакцию этого руководства.
Как включить ведение журнала для всех моих микросервисов Java?
Ведение журнала в микросервисах — интересная и довольно сложная тема. Вместо того, чтобы иметь один файл журнала, с которым вы можете использовать less или grep, теперь у вас есть n файлов — журнала, которые вы хотели бы просматривать вместе.
Отличной отправной точкой для всей экосистемы ведения журнала является эта статья. Обязательно прочитайте ее, особенно раздел «Централизованное ведение журнала» с точки зрения микросервисов.
На практике вы найдете различные подходы:
Как мои микросервисы находят друг друга?
До сих пор мы предполагали, что все наши микросервисы знают друг друга, знают соответствующий IPS. Это статическая настройка. Итак, наш банковский монолит [ip = 192.168.200.1] знает, что ему нужно поговорить с сервером риска [ip = 192.168.200.2], который жестко задан в файле свойств.
Однако вы можете сделать вещи более динамичными:
В общих чертах, это то, что называется микросервисной оркестровкой и еще одна огромная тема.
Такие библиотеки, как Eureka или Zookeeper, пытаются «решить» эти проблемы, например, создание клиентов или маршрутизаторов, знающих, какие службы доступны и где. С другой стороны, они вносят много дополнительной сложности.
Просто спросите любого, кто когда-либо запускал установку ZooKeeper.
Как сделать авторизацию и аутентификацию с помощью микросервисов Java?
Еще одна огромная тема, достойная собственного эссе. Опять же, варианты варьируются от жестко закодированной базовой аутентификации HTTPS с собственными фреймворками безопасности до запуска установки Oauth2 с вашим собственным сервером авторизации.
Как мне убедиться, что все мои окружения выглядят одинаково?
То, что верно для развертываний без микросервиса, также верно и для развертываний микросервиса. Вы можете попробовать комбинацию Docker / Testcontainers, а также сценариев / Ansible.
Попробуйте и сохраняйте его проще.
Не вопрос: Рассказы об отступах в Yaml
Сделаем резкий разворот от конкретных библиотечных вопросов, давайте кратко рассмотрим Yaml. Это формат файла, который используется в качестве фактического формата файла для «записи конфигурации в виде кода». От более простых инструментов, таких как Ansible, до могучих Kubernetes.
Чтобы испытать «мучения» от отступов в YAML, попробуйте написать простые файлы Ansible и посмотрите, как часто вам нужно повторно редактировать файл, чтобы заставить отступ работать правильно, несмотря на различные уровни поддержки IDE. А затем вернитесь, чтобы закончить это руководство.
А как насчет распределенных транзакций? Тестирование производительности? Другие темы?
К сожалению, эти темы не вошли в эту редакцию данного руководства. Оставайтесь с нами, чтобы узнать больше.
Концептуальные проблемы микросервисов
Помимо специфических проблем микросервисов в Java, существуют также проблемы, которые возникают в любом микросервисном проекте. Их больше с организационной, командной или управленческой точки зрения.
Несоответствие фронтенд и бэкеенд
То, что происходит во многих микросервисных проектах, я бы назвал несоответствием внешнего интерфейса и интерфейса микросервиса. Что это обозначает?
Что в старых добрых монолитах, у разработчиков веб-интерфейса был один конкретный источник для получения данных. В микросервисных проектах у разработчиков веб-интерфейса неожиданно появляются n источников для получения данных.
Представьте, что вы создаете какой-то проект микросервисов Java-IoT. Скажем, вы выполняете мониторинг машин, таких как промышленные печи по всей Европе. И эти печи регулярно отправляют вам обновления с указанием их температуры и т.д.
Рано или поздно вы, возможно, захотите выполнять поиск печи в пользовательском интерфейсе администратора, возможно, с помощью микросервисов «поиска печи». В зависимости от того, насколько строго ваши бэкэнд-коллеги могут интерпретировать domain driven design или законы о микросервисах, может случиться так, что микросервис «поиск печи» возвращает только ваши идентификаторы, но не другие данные, такие как тип, модель или местоположение.
Для этого разработчикам фронтенда может потребоваться выполнить один или n дополнительных вызовов (в зависимости от вашей реализации пейджинга) в микросервисе «получить данные о печи» с идентификаторами, которые они получили от первого микросервиса.
И хотя это всего лишь простой (но взятый из реального проекта (!)) Пример, он демонстрирует следующую проблему:
Реальные супермаркеты получили огромное признание по определенной причине. Потому что вам не нужно ходить в 10 разных мест, чтобы покупать овощи, лимонад, замороженную пиццу и туалетную бумагу. Вместо этого вы идете в одно место.
Это проще и быстрее. То же самое касается разработчиков интерфейсов и микросервисов.
Ожидания руководства
Эта проблема вызывает нежелательные побочные эффекты со стороны отдельных разработчиков, программистских журналов или облачных компаний, предлагающих микросервисы:
У руководства сложилось впечатление, что вы теперь можете вкладывать в (всеобъемлющий) проект бесконечное количество разработчиков, поскольку разработчики теперь могут работать совершенно независимо друг от друга, каждый на своем микросервисе. В самом конце требуется лишь небольшая работа по интеграции (т.е. незадолго до запуска).
Давайте рассмотрим в следующих параграфах, почему этот взгляд является серьёзной проблемой.
Меньшие части не означают лучшие части
Одна довольно очевидная проблема состоит в том, что 20 меньших частей (как в микросервисах) на самом деле не означают 20 лучших частей. Чисто с точки зрения технического качества это может означать, что ваши отдельные службы по-прежнему выполняют 400 запросов Hibernate для выбора пользователя из базы данных по слоям и слоям не поддерживаемого кода.
Возвращаясь к цитате Саймона Брауна: если людям не удастся построить монолиты должным образом, им будет сложно создать надлежащие микросервисы.
Во многих микросервисных проектах мысли об устойчивости происходят после запуска, является такой, поэтому немного страшно смотреть, как микросервисы работают вживую.
Это имеет простую причину: поскольку Java-разработчики обычно не заинтересованы в том, чтобы не обучены должным образом в области устойчивости, сетей и других смежных тем.
Меньшие части приводят к большему количеству технических частей
Кроме того, существует печальная тенденция к тому, чтобы пользовательские истории становились все более и более техническими (и, следовательно, глупыми), более микро и отвлеченными от пользователя, от которого они получены.
Представьте, что вашей микросервисной команде предлагается написать технический микросервис для входа в систему с базой данных, примерно такой:
Теперь ваша команда может решить (и, возможно, даже убедить бизнесменов): это слишком просто и скучно, вместо службы входа в систему давайте напишем действительно «умный» микросервис UserStateChanged — без каких-либо реальных и ощутимых бизнес-требований.
А поскольку Java в настоящее время не в моде, давайте напишем микросервис UserStateChanged в Erlang. И давайте попробуем где-нибудь использовать красно-черные деревья, потому что Steve Yegge написал, что вы должны знать их наизнанку, чтобы подать резюме в Google.
С точки зрения интеграции, обслуживания и общего проекта это так же плохо, как написание слоев спагетти-кода внутри одного монолита.
Придуманный и заурядный пример? Да.
К сожалению, также не редкость в реальной жизни.
Меньшие кусочки ведут к меньшему пониманию
Затем возникает тема понимания всей системы, ее процессов и рабочих процессов, если вы, как разработчик, несете ответственность только за работу на изолированном микросервисе [95: login-101: updateUserProfile].
Это гармонирует с предыдущим параграфом, но в зависимости от вашей организации, уровня доверия и коммуникации это может привести к большому пожиманию плечами и обвинениям, если сломается какая-то часть всей микросервисной цепочки — никто не больше принимает полную ответственность.
Это не является недобросовестностью, скорее проблема в том, что на самом деле очень трудно понять количество отдельных частей и их место в общей картине.
Коммуникации и обслуживание
Это связано с последней проблемой: коммуникации и обслуживание. Это, очевидно, сильно зависит от размера компании, с общим правилом: чем больше, тем проблематичнее.
Кто работает на микросервисе № 47?
Они только что развернули новую несовместимую версию микросервиса? Где это было задокументировано?
С кем мне нужно поговорить для запроса новой функции?
Кто будет поддерживать микросервис на Erlang после того, как Макс покинул компанию?
Все наши микросервисные команды работают не только на разных языках программирования, но и в разных часовых поясах! Как мы правильно координируем?
Главной темой здесь является то, что, подобно навыкам DevOps, полноценный подход к микросервисам в более крупной, возможно, даже международной компании, сопряжен с кучей дополнительных коммуникационных проблем. Как компания, вы должны быть готовы к этому.
Заключение
Прочитав эту статью, вы можете заключить, что ваш автор строго рекомендует микросервисы. Это не совсем верно — я в основном пытаюсь выделить моменты, которые забыты в безумии микросервисов.
Баланс микросервисов
Полное использование Java-микросервисов — это одно положение маятника. Другое положение — что-то вроде сотен старых добрых модулей Maven в Монолите. Вы должны найти правильный баланс.
Особенно в новых проектах ничто не мешает вам придерживаться более консервативного, монолитного подхода и создавать меньше, лучше определенных модулей Maven, вместо того чтобы сразу начинать работу с двадцатью готовыми к работе облачными микросервисами.
Микросервисы создают тысячи дополнительных сложностей
Имейте в виду, что чем больше у вас микросервисов и чем меньше у вас действительно сильных талантов DevOps (нет, выполнение нескольких сценариев Ansible или развертывание на Heroku не учитывается), тем больше проблем у вас возникнет позже в работе.
Прочитать раздел Общие вопросы о Java микросервисах этого руководства уже утомительно. Затем подумайте о реализации решений для всех этих инфраструктурных задач. Вы очевидно поймете, что все это больше не связано с бизнес-программированием (за что вам платят), а скорее с фиксацией большего количества технологий на еще большем количестве технологий.
Siva Prasad Reddy (Шива Прасад Редди) отлично подвел итог в своем блоге:
Я не могу объяснить, как это ужасно, когда команда тратит 70% времени на борьбу с этой современной инфраструктурой и 30% времени на реальную бизнес-логику.
Стоит ли создавать микросервисы Java?
Чтобы ответить на этот вопрос, я хотел бы закончить эту статью очень дерзко, похоже на тизер Google интервью. Если вы знаете ответ на этот вопрос по своему опыту, даже если он, по-видимому, не имеет ничего общего с микросервисами, вы можете быть готовы к микросервисному подходу.
Сценарий
Представьте, что у вас есть монолит Java, работающий самостоятельно на самой маленькой выделенной машине Hetzner. То же самое относится и к вашему серверу баз данных, он также работает на аналогичной машине Hetzner.
И давайте также предположим, что ваш Java-монолит может обрабатывать рабочие процессы, такие как регистрация пользователей, и вы создаете не сотни запросов к базе данных на рабочий процесс, а только разумное количество (
