Многие программисты слышали, что иногда код необходимо разделить на отдельные библиотеки для дальнейшего повторного использования.
Однако вопрос о том, какой код следует выделить в отдельную сущность, смущает многих разработчиков.
При чтении статей/разговоров на эту тему обычно приходит на ум проблема преждевременного обобщения.
У опытных программистов обычно есть свои правила, следуя которым, они понимают, нужно ли разделять код на повторно используемый код. Например, если один и тот же (или очень похожий) код используется в трех и более местах.
Однако все, с кем я разговаривал на эту тему, согласны с тем, что такой повторно используемый код должен существовать, что его создание — это хорошо, и что на него стоит тратить время.
Мне бы хотелось поднять тему повторного использования кода в контексте создания сервис-ориентированной и микросервисной архитектуры.
Что такое многоразовый код?
Многоразовый код — это код, выделенный в отдельную сущность, называемый на разных языках по-разному — библиотека, пакет, зависимость и т. д. Обычно такой код хранится в отдельном репозитории, и имеется документация по подключению и использованию этого кода (README. мкр).Дополнительно код может быть покрыт тестами, могут быть инструкции по внесению изменений (CONTRIBUTING.md) и настроена CI. Различные значки, прикрепленные к описанию, лишь улучшают визуальное представление о зрелости этой сущности, а количество присвоенных звезд будет указывать на популярность данного решения.
За примерами далеко ходить не придется — просто откройте на github страницу любого из популярных фреймворков на любимом языке, например vue.js .
В общем, для качественного оформления библиотеки есть только тележка и маленькая тележка.
Сервисы и микросервисы
В этой статье сервис определяется как целостная сущность, выполняющая определенный набор определенных задач в своей области ответственности и предоставляющая интерфейс для взаимодействия.Сервис или микросервис в этой статье с архитектурной точки зрения могут быть идентичными понятиями, вопрос только в масштабе.
Сервис может состоять из набора микросервисов, реализующих собственный раздел бизнес-логики, или быть одним микросервисом.
Сервис-ориентированная архитектура предполагает, что каждый сервис минимально связан с другими.
Однако межсервисная связь не исключается, а скорее ожидается, что она должна быть сведена к минимуму.
Для получения запросов сервис обычно реализует какой-то стандартизированный API. Это может быть что угодно — REST, SOAP, JSONRPC или новомодный GraphQL. Условно услуги можно разделить на инфраструктурные и продуктовые.
Продуктовые услуги — это те, которые реализуют логику клиентского продукта.
Например, работают с приложениями для его подключения, или организуют поддержку этого продукта на протяжении всего жизненного цикла работы с клиентом.
Инфраструктурные сервисы — это скорее базовый функционал компании (или проекта), например сервис, содержащий информацию о клиентах, или сервис, хранящий информацию об определенных заказах.
К сервисам инфраструктуры также относятся сервисы, реализующие вспомогательный функционал, например, сервис информирования клиентов (отправка push-сообщений или SMS) или сервис взаимодействия с данными.
Давайте немного пофантазируем
Допустим, есть гипотетический интернет-магазин, построенный с использованием сервис-ориентированной архитектуры.Разработчики этого чуда инженерной мысли смогли договориться между собой и пришли к выводу, что в качестве API все их сервисы будут работать, например, по протоколу jsonrpc. Однако, поскольку интернет-магазин большой, он не стоит на месте и активно развивается, там есть несколько групп разработки, пусть их будет больше двух — две дизайнерские, одна для поддержки уже написанного.
Также для большего эффекта все команды пишутся в одном стеке.
Архитектура гипотетического интернет-магазина: 
В Интернет торчит только API-сервис, обеспечивающий доступ ко всем фронтенд-системам – веб-интерфейсу интернет-магазина, а также мобильным приложениям.
Служба информации о клиентах хранит информацию о клиентах, может их создавать, авторизовать и предоставлять необходимую информацию о них.
Сервис товарной информации хранит информацию о товарах, их остатках и наличии для заказа, а также предоставляет способы удобного получения необходимой информации.
Служба заказов обрабатывает заказы.
Здесь находится логика оформления заказа, его подтверждения, выбора типа оплаты и адреса доставки и т.д. Служба информации о клиентах может отправлять PUSH/SMS/сообщения по электронной почте.
Тип связи, например, зависит от настроек конкретного клиента; клиент также может настроить желаемое время получения уведомлений.
Эти сервисы являются условно инфраструктурными, поскольку без них интернет-магазин как таковой не может функционировать.
В ближайшее время проектными командами планируется разработать сервисы для проведения акций и предложений, а также распространения дайджестов.
Эти услуги условно являются продуктовыми услугами.
Очевидно, что любой новый продукт-сервис в большинстве случаев не сможет существовать без взаимодействия с инфраструктурными сервисами — ему, скорее всего, придется получать информацию о клиентах или отправлять уведомления.
В описанном выше примере детали реализации каждого из сервисов намеренно скрыты.
Так, например, служба информации о клиентах, вероятно, имеет механизм отложенного выполнения кода, такой как очередь выполнения, а служба информации о продуктах может иметь собственную админ-панель для удобного управления продуктами, а API для интерфейсных систем, вероятно, имеет несколько реплик.
Более того, описанная архитектура может быть не оптимальной; это просто взято из моей головы.
В контексте предлагаемой архитектуры сразу становится понятно, что готовые библиотеки необходимы для быстрой разработки продукта.
Итак, важно иметь готовую реализацию jsonrpc-сервера, а также клиента для него, поскольку это основной протокол организации межсервисного взаимодействия.
Также в этом примере в полную силу встает вопрос документации API. Очевидно, что у команд также должен быть готовый инструмент для генерации документации.
Если предположить, что есть еще и готовый инструмент для генерации smd-схем для jsonrpc-серверов, то скорость разработки новых сервисов может возрасти еще больше.
В результате в идеале внутри компании должен быть набор готовых библиотек, которые все команды используют для выполнения стандартных задач.
Эти библиотеки могут быть как ваши собственные, так и открытые, главное, чтобы они хорошо выполняли свои задачи.
Очевидно, что команда, которая находится в общем стеке и пишет сервисы с использованием готовых библиотек, будет более эффективной, чем команда, которая постоянно циклится.
Наличие единого фреймворка и единой базы библиотек, которые используются во всех проектных командах, я называю единой экосистемой.
Как обстоят дела в крупных компаниях?
У крупных компаний гораздо больше инфраструктурных сервисов, а также используемых протоколов взаимодействия.Количество готовых библиотек может исчисляться десятками и даже сотнями.
Здесь еще важнее выделить повторно используемый код. Так уж получилось, что у меня есть опыт работы в компании, в которой работает около 200 разработчиков, пишущих на разных языках — java, c#, php, python, go, js и т. д. Удивительно, но общая экосистема, в разрезе единого stack. Не все команды разработчиков имеют и используют их.
Казалось бы, очевидная вещь — подготовка многоразового кода, его правильное форматирование и использование — далеко не очевидна.
Конечно, команды разработчиков решают свои проблемы.
Кто-то использует шаблон сервиса — набор кода, образующий ядро каждого нового сервиса, из которого выкидывается всё ненужное и добавляется необходимое.
Другие команды разработчиков используют свои собственные велосипеды, копируют и вставляют их из проекта в проект и не утруждают себя их документированием или тестированием.
В целом, похоже, существует множество различий в инструментах и подходах, используемых в одном и том же стеке в одной и той же компании.
При этом географически расположены в одном городе.
Преимущества единой экосистемы
Формирование единой экосистемы позволяет решить множество сложностей и имеет огромный потенциал для повышения продуктивности крупной компании.Фактически, эта практика взята из сообщества Open Source — лучшие решения в своей области выживают и пользуются наибольшей популярностью.
В наше время достаточно открыть любой менеджер зависимостей и просто удивиться обилию предлагаемых решений.
Но именно такой подход можно реализовать внутри компании.
Преимущества такого подхода при внедрении нового сервиса заключаются в следующем:
- Высокая стабильность – использование проверенных, хорошо документированных библиотек повышает стабильность сервиса в целом;
- Легкая ротация коллег между командами — если все команды находятся в рамках единой экосистемы, то при переходе из одной команды в другую разработчику не придется тратить много времени на знакомство с используемыми инструментами, поскольку он уже знаком с их;
- Концентрация на бизнес-логике — ведь разработка нового сервиса сводится к тому, что нужно подкрутить необходимые зависимости, решающие все инфраструктурные проблемы, и писать только бизнес-логику;
- Ускоренная разработка — цикличность не требуется, все готово, кроме бизнес-логики;
- Упрощение тестирования — тестировать нужно только бизнес-логику, потому что библиотеки уже протестированы;
Ложка дегтя
Понятно, что для достижения такого подхода следует следовать некоторым практикам, а именно разрабатывать библиотеки с использованием семантического управления версиями, позаботиться о документации и тестах, а также настроить ci. Это своего рода показатель зрелости не только команды разработчиков, но и разработчиков в компании в целом.
ПС
А пакетно-ориентированный подход заключается только в том, что повторно используемый код в моем стеке называется пакетом.Ну, это звучит забавно.
Недавно у меня произошел следующий диалог с одним из моих коллег, который побудил меня написать эту статью:
— Коллега: вы превращаетесь в кассира в пятикомнатной - я: что ты имеешь в виду?) — Коллега: скоро вы спросите «нужна посылкаЭ» — я: пожалуйста, выскажите свою мысль.Все дело в том, что в нашем сообществе разработчиков внутри компании около 20 готовых пакетов, и создание нового сервиса приводит к подтягиванию необходимых зависимостей, а также написанию бизнес-логики.Я не понимаю — Коллега: ну вот у вас опять готовый пакет для решения моей проблемы
Затраты на проводку в плане написания кода практически сводятся на нет. В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Есть ли в вашей компании традиция разделения кода на отдельные библиотеки? 61,54% Да 40 38,46% Нет 25 Проголосовали 65 пользователей.
12 пользователей воздержались.
Теги: #Микросервисы #Системный анализ и проектирование #soa #повторное использование кода
-
Как Использовать Google Дуо?
19 Oct, 24 -
Точка Зрения
19 Oct, 24 -
Умная Крышка Для Контроля Хлебной Закваски
19 Oct, 24 -
Мучения С Ubuntu
19 Oct, 24 -
Входить
19 Oct, 24
