Обмен технологиями

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Разделение услуг:

1. Принцип единой ответственности. В микросервисной архитектуре служба должна отвечать только за одну функцию или область бизнеса. Каждая служба должна иметь четкие определения и границы и фокусироваться только на своей конкретной области бизнеса.

2. Автономия сервиса. Автономия сервиса означает, что каждый микросервис должен иметь высокую степень автономии, то есть каждый сервис должен иметь возможность независимо разрабатываться, независимо тестироваться, независимо конструироваться, независимо развертываться и независимо эксплуатироваться.

3. Односторонняя зависимость

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

Круговая зависимость: A->B->C->A

Двусторонняя зависимость: A->B,B->A

Пример:

1. Список заказов

2. Список продуктов

Услуга заказа: укажите идентификатор заказа и получите подробную информацию о заказе.

Обслуживание продукта: возврат сведений о продукте на основе идентификатора продукта.

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

выполнить:

Идея реализации: Служба заказа отправляет http-запрос в службу обслуживания продуктов, объединяет возвращенный результат с результатом заказа и возвращает его вызывающей стороне.

Метод реализации: использование RestTemplate, предоставленного Spring.

1. Определите RestTemplate

@Конфигурация

открытый класс BeanConfig{
@Бин

публичный RestTemplate restTemplate{

вернуть новый RestTemplate();

      }

}

2. Используйте restTemplate в контроллере заказов.

RestTemplate:

Отдых(Повторнопрезентационный СТейт Тranfer) представляет собой передачу статуса ресурса слоя

Ресурсы: данные в Интернете, такие как изображения, видео, тексты и т. д., являются ресурсами.

Уровень представления: форма представления ресурсов (например, форма представления текста — txt, форма представления изображения — jpg, а некоторые ресурсы выражены в json, xml или двоичном формате и т. д.).

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

Спокойный стиль обычно имеет следующие характеристики:

1. Ресурсы

2. Унифицированный интерфейс. Для операций с ресурсами, таких как получение, создание, изменение и удаление, эти окна соответствуют методам GET, POST, PUT и DELETE, предоставляемым протоколом http. Другими словами, если вы используете интерфейс в стиле RESTful. , из интерфейса. Вы можете только найти его ресурсы, но не можете знать, какие конкретно операции он выполнил. Вам необходимо точно знать, какие операции произошли, и судить по типу метода HTTP-запроса (например: тот же URL: GET/). blog/{blogId }: Запросить блог DELETE/blog/{blogId} Удалить блог)

Недостатки RESTful API:

1. Метод операции громоздкий. RESTful API обычно различает действия операции с ресурсами по GET, POST, PUT и DELETE.
HTTP-метод нельзя наблюдать напрямую, и его необходимо отслеживать с помощью таких инструментов, как захват пакетов. Будет более интуитивно понятно, если действие будет размещено на URL-адресе.
Это более способствует взаимопониманию и общению в команде.
2. Некоторые браузеры не очень дружелюбно поддерживают запросы, отличные от GET и POST, и требуют дополнительной обработки.
3. Чрезмерное внимание к ресурсам. Однако реальные потребности бизнеса могут быть более сложными, и их невозможно удовлетворить простым добавлением, удалением, изменением и принудительным использованием.
RESTful API увеличит сложность и стоимость разработки.

Есть проблема с проектом
1. При удаленном вызове IP-адрес и номер порта URL-адреса жестко закодированы (http://127.0.0.1:9090/product/). Если вы меняете IP-адрес, вам необходимо изменить код.
код
2. Как звонящий может не полагаться на IP провайдера?
3. Развертывание нескольких машин, как разделить нагрузку?
4. При удаленных вызовах очень легко написать неправильный URL-адрес, а возможность повторного использования невысока. Как элегантно реализовать удаленные вызовы?
5. Все сервисы могут вызывать этот интерфейс. Есть ли какие-либо риски?