Решили сделать статью без воды и картинок про микросервисы, чтобы любой начинающий аналитик мог понять, а что же это такое на самом деле. И конечно такая статья должны быть с практикой, а не копипастой из разных книг и статей, которую все друг другу рассказывают на собеседованиях.
Итак, эта статья не для разработчиков и опытных архитекторов, а для аналитиков, которые хотят понять, а что же такое микросервисы на самом деле. Пример здесь максимально простой и не претендует на хороший стиль написания кода. Чтобы его запустить не нужно обладать вообще никаким ИТ‑бэкграундом и не нужно настраивать никакие IDE.
Примечание. Если хотите сразу попробовать и не читать, как устроен сервис, переходите по ссылке — там исходники и инструкция. Также эту ссылку продублировал в конце, если захотите попробовать тренажёр уже после прочтения.
Немного теории о программах
Микросервис — это программа.
А в современных реалиях программа — это набор классов. Таким образом, микросервис в самом простом случае — это один класс, хоть это и грубое приближение.
Если не вдаваться в теорию, то класс — это описание данных и функций, которые работают с этими данными.
Функции называются методами класса, а данные — полями класса.
Можно принять такое приближение: класс — это набор полей(данных) и методов (функций).
Когда программа скомпилирована (переведена из исходного кода в некий исполняемый файл, который запускается на компьютере) и начинает выполняться, то компьютер размещает у себя в памяти объекты (копии) каких-то классов. Поля (данные) и методы (функции) хранятся в оперативной памяти в момент выполнения программы. Поля заполняются реальными значениями.
Ну и, соответственно, работа программы заключается в вызове каких-то методов класса, с передачей им на вход дополнительных данных (методы работают с внешними данными, которые поступают им на вход, а не только с полями).
Это очень примитивное описание, тем не менее, достаточное для базового понимания процесса работы кода.
Таким образом, микросервис можно описать так: это входные данные, затем внутренняя логика по работе с этими данными, и результат этой работы: выходные данные (ответ сервиса).
Получается, что микросервис принимает на вход какие-то параметры, что-то с ними делает (он также может сам сходить за дополнительными данными в какую-то внешнюю систему), а потом возвращает результат в ту систему, которая его вызвала.
Теория закончена. Приступим к описанию работы тренажёра.
Как тренажёр работает?
Есть два микросервиса на Flask.
Примечание. Это Python-фрэймворк, про который можно почитать в материале «Разработка web-приложения на Flask»
Первый микросервис ходит в HH.ru и по шаблону достает оттуда вакансии — осуществляет вызов во внешнюю систему, другими словами. Второй микросервис берёт эти полученные данные и записывает их в файл.
Сейчас поговорим про первый микросервис. Он простой. Собственно, вот его код.
Второй микросервис ещё проще.
В одном файле задаются параметры того, что мы хотим из HH.ru получить. Во втором указываем куда и как это добро сохранять.
Ещё немного о том, как он работает
Вот я указал конфигурационный файл, в котором прописаны параметры запроса.
Здесь указан сайт, к которому мы будем обращаться. Остальные строки — параметры того, что мы ищем (все это входные параметры микросервиса). Например, здесь мы ищем системного аналитика в Питере (код города 2), с первой страницы по 100 вакансий.
Что теперь происходит?
Подгружаем разные полезные библиотеки, конфиг, вызываем первый микросервис…
Здесь полный ответ, много системной информации, потому что мы хотим получить полезные данные.
Что делаем дальше?
Превращаем ответ в JSON, который удобен программной среде. В этот же JSON добавим директорию конфига, где лежат параметры для сохранения.
Здесь у нас прописан путь в тот файл, куда мы хотим сохранить результаты, какие столбцы вакансий мы хотим отбирать, задаём параметры фильтрации: id, name, area, salary и прочее.
Дёргаем второй микросервис.
И заходим туда, куда хотим сохранить. Вот он нам сохранил результат.
Выглядит, конечно, некрасиво, но видно и название вакансии, и ID города, и контактную информацию и прочее.
Зачем это всё?
По умолчанию, микросервисы системный аналитик должен знать. Но как знания появятся, если только в книжке или на Хабре прочитал? Поэтому я и решил, что лучше сделать реальный микросервис, чтобы каждый мог получить представление.
Идея тренажера в том, чтобы без громоздкой логики было понятно, как эта теория работает на практике: как один микросервис ходит, а другой записывает, что такое API и тому подобные вещи.
Если хотите попробовать
- Это учебный проект, он никакой логики за собой не несет.
- Не нужно Swagger‘а, нет спецификации, но зато можно видеть как все работает.
- Не нужно никакой среды, в этом плюс Jupiter и Python, мы просто запускаем всё через браузер. Дальше можно модифицировать код и смотреть, как это работает .
➡️ ➡️ ➡️ Исходники доступны по ссылке: заходите, читайте инструкцию, пользуйтесь.