WedX - журнал о программировании и компьютерных науках

Какой тип реализации будет более подходящим на уровне обслуживания?

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

Предположим, что мое приложение получит контактную информацию от другого микросервиса, развернутого как User API.

  1. Бизнес как файл

В этом подходе в качестве имени файла используется название компании. Внутри файла есть только один общедоступный метод get, который принимает единственный параметр. Метод вызывает user-api/contact/{id}.

Имя файла: contact.service.js

Метод: get(id) -> contact

  1. API как файл

Этот подход инкапсулирует всю связь между User API и пользовательским приложением в один файл. Для каждой конечной точки существует свой метод User API.

Имя файла: user.service.js

Метод: getContact(id) -> contact

Каковы плюсы и минусы этих подходов?

microservices design-patterns service-layer
20.12.2018

Ответы:


1

На самом деле это скорее вопрос мнения, разные компании / разные разработчики программного обеспечения могут дать вам разные ответы.

Я считаю, что разделение их на отдельные файлы - вплоть до методов, если логика сложна - очень помогает с ремонтопригодностью / тестированием.

  • Тестирование: если вы используете один и тот же шаблон разделения для тестовых файлов, который я имитирую с точки зрения структуры и использую, я обнаружил, что это помогает людям легче находить код, выполнять тесты именно так, как они хотели их выполнять. Something like test contact.service.test.js где изменение изолировано, и они могут сразу же довольно легко запустить соответствующие тесты.
  • Ремонтопригодность: я стараюсь, чтобы на последнем уровне обслуживания было как можно меньше вещей. Это не значит, что все абстрагировано и слой за слоем вы не можете найти реальный код / ​​но даже тогда я бы разделил службы на их методы в разных файлах с супер удобными именами. Таким образом, документация становится безумно простой, вы можете просто записать все, что нужно, в одном файле.
  • Проверка кода: становится намного проще, это заставляет вносить небольшие изменения в каждый файл, потому что у вас есть файлы с гораздо меньшим содержанием.

Задайте себе эти вопросы.

  • Есть ли в ваших сервисах очень сложная логика, которая расширяет файл до тысяч строк, что затрудняет документирование / затрудняет выявление ошибок / затрудняет рефакторинг? Или это конечные точки меньшего размера, логика которых выгружается в какую-то другую часть системы?

  • Будут ли тесты для этих методов / сервисов существовать в (другом) единственном файле - имитируя шаблон в реализации сервиса? Сможете ли вы вызвать индивидуальный тест во время тестирования функции?

  • Готовы ли вы приспособиться к принятому вами решению по всем вашим услугам? Таким образом, ваша конкретная служба (службы) может быть относительно небольшой, а как насчет службы, которую один из ваших коллег может написать и превратить в гигантский строчный файл размером 1 КБ?

20.12.2018
Новые материалы
Как создать диаграмму градиентной кисти с помощью D3.js
Резюме: Из этого туториала Вы узнаете, как добавить градиентную кисть к диаграмме с областями в D3.js. Мы добавим градиент к значениям SVG и применим градиент в качестве заливки к диаграмме с..
Я хотел выучить язык программирования MVC4, но не мог выучить его раньше, потому что это выглядит сложно…
Просто начните и учитесь самостоятельно Я хотел выучить язык программирования MVC4, но не мог выучить его раньше, потому что он кажется мне сложным, и я бросил его. Это в основном инструмент..
Лицензии с открытым исходным кодом: руководство для разработчиков и создателей
В динамичном мире разработки программного обеспечения открытый исходный код стал мощной парадигмой, способствующей сотрудничеству, инновациям и прогрессу, движимому сообществом. В основе..
Объяснение документов 02: BERT
BERT представил двухступенчатую структуру обучения: предварительное обучение и тонкая настройка. Во время предварительного обучения модель обучается на неразмеченных данных с помощью..
Как проанализировать работу вашего классификатора?
Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..
Работа с цепями Маркова, часть 4 (Машинное обучение)
Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..
Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..
Для любых предложений по сайту: [email protected]