class ServiceLocator
{
public function getDB(): DB
{
...
}
}catch(PDOException $sql_connect_e)
{
echo ("Ошибка подключения к базе данных. SQL erorr: ". $sql_connect_e->getMessage() ."");
die();
};catch(PDOException $sql_connect_e)
{
echo ("Ошибка подключения к базе данных. SQL erorr: ". $sql_connect_e->getMessage() ."");
throw $sql_connect_e;
};Есть нюанс в том, что у меня несколько баз в колхозе и пользователю мне нужно показывать кто упал и почему упал.
throw $sql_connect_e;
Что я должен знать? Что бубунта лучше генты? Что systemd лучше чем sysv init? Или что-то еще, более сакральное?
Вообще это был стеб и троллинг. Что ж, троллинг удался, да еще как! Заревом пылающего тухеса пожалуй дорогу можно вместо фораней освещать...
Поздравляю вас дяденька, соврамши! Откуда такое сакральное знание? Брателло, ты уверен, что я никогда ничего не собирал? Как доказывать будешь?
Пересборка мира - нелепое и утомительное занятие, есть способы и много собирать только то, что обновилось. Но тем, кто только слышал, что в генте есть "пересборка мира" этого конечно же не понять...
А ты конечно 24 часа работаешь за компом и параллельно идущая сборка у тебя его жуууууутко тормозит... Постой, так может у тебя винда?
Ой, правда? Статья написанная незнакомым мне чуваком (писал ее не я, еслиф че - меня на "большом" хабре нет и не будет до тех пор, пока там сборище... людей с определенными убеждениями) пять лет назад, в этом помогла? Ух ты... Что ж, спасибо, рекомендовать буду :DDD
Это проблемы автора :) Возможно он считает, что другие считают, что линуксоид = девственник. Я бы охотно поспорил с ним и доказал обратное (но себя хвалить неудобно). Это действительно слабый пассаж, уверенный в себе человек ничего никому не доказывает :)
Это тоже так себе ход. Реальная оптимизация ядра займет столько времени, что борода вырастет как у гнома, обычно туда приходят с конкретной проблемой. Я наоптимизировался ядра еще на FreeBSD, где без этого просто не поедет ничего.
Не обязательно. Можно иметь и жену и детей и друзей и генту - на сервере :) Потому что линух на рабочей станции - он опять же для работы, не для развлечений и собственно мало чем кроме графики от сервера отличается.
Я не чувствую себя задротистым красноглазиком. У меня есть Tinder и я встречаюсь с девочками. Им я стараюсь не рассказывать о своей любви. Система просто работает. Я чуть лучше разобрался в GNU/Linux.
Нравятся мне такие ответы... Чилавег ниасилил генту - и говорит, что он никому не нужен. Но некоторые считают, что чилавег неправ :) (я так считаю тоже, но обычно своего мнения не навязываю)
Ну и ЕДА, конечно же :)
Нет смысла защищать секреты внутри контейнеров, как уже было сказано, если есть доступ к контейнеру, их в любом случае раскроют
Vitsliputsli, в принципе, всё что вы сказали коррелирует с тем, как мы хотим организоваться. Тогда подитожу:
1) Клиент шлёт запрос через API-шлюз, запрос попадает в FastAPI-приложение;
2) Приложение назначает запросу id и размещает его как сообщение в заранее объявленной durable-очереди RabbitMQ и ждет по нему ответа;
3) Сервис-обработчик прослушивает эту очередь, скачивает сообщение, работает с ним, а затем отправляет json с данными и кодом ответа;
4) Приложение обнаруживает, что сообщение обработалось и возвращает клиенту его содержимое;
5) Если всё завершилось ожидаемым сценарием, приложение закрывает сообщение с флагом "ack".
Сейчас у меня такая картина шины данных с брокером. Надеюсь, у вас тоже.
сейчас почти все сервисы работают как прямые интеграции, т.е. креды прописаны в каждом сервисе и запись напрямую в боевые БД.
Правильно ли я вас понимаю - задача в том, чтобы назначить условный id (например либой uuid) сообщению (которое является post / get запросом клиента), а после этого "скачать" результат исполнения этой очереди и отдать его клиенту? В таком случае http-соединение не порвётся, так? Чувствуется, что время ожидания вырастет, но врядли это критично, если данные станут реально персистентны.
Vitsliputsli, Это будет точкой отказа для всех сервисов
it is common practice for an API Gateway to be load balanced, although the API Gateway itself can sometimes provide some basic load balancing capabilities for backend services.
1) Это будет точкой отказа для всех сервисов;
2) Нельзя реализовать ответ для http-запроса, ведь брокер разделяет процесс и не предназначен для синхронных запросов (так мне кажется).
Мой вопрос: следует ли реализовывать передачу данных по REST API через RabbitMQ в данном случае?
Собственно в вашем примере, DB - это Service Locator специализирующийся только на соединениях с СУБД. Service Locator - не нарушает SRP, он ничего не знает об ответственности сервисов, которыми управляет, его ответственноть только получение и возврат объекта.
На превый взгляд может показаться, что это ненужный посредник, но именно то, что он посредник и помогает. К примеру, если взять юнит-тестирование, то в варианте со статическим вызовом конкретных классов все печально, но если сделать посредника в виде ServiceLocator и в нем прописать возможность переопределения объектов, которые возвращают методы, то можно легко подменить реальные объекты на моки. А вот с универсализацией все плохо, но примерно также как и в случае с прямыми статическими обращениями к конкретным классам.