Ответ
Да, я самостоятельно проектировал архитектуру. Основные решения:
- Подход: Микросервисная архитектура на Spring Boot.
- Компоненты:
- API Gateway (Spring Cloud Gateway) для маршрутизации.
- Сервис аутентификации (Spring Security + JWT).
- Сервисы бизнес-логики.
- Взаимодействие: REST API для синхронных запросов, Apache Kafka для асинхронной обработки событий.
- СУБД: PostgreSQL с Hibernate в качестве ORM.
Пример кода сервиса заказов:
@RestController
@RequestMapping("/orders")
public class OrderController {
@Autowired
private OrderService orderService;
@PostMapping
public ResponseEntity<Order> createOrder(@RequestBody OrderDto dto) {
Order createdOrder = orderService.create(dto);
return ResponseEntity.ok(createdOrder);
}
}Архитектура была выбрана для обеспечения масштабируемости и отказоустойчивости. Решения принимались на основе анализа требований и компромиссов между сложностью и производительностью.
Ответ 18+ 🔞
Да ты посмотри, какой у нас тут архитектор выискался! Сам, блядь, проектировал, как бог черепаху. Ну ладно, разложу по полочкам, как я это всё замутил, а то потом вопросы будут — «а чё, а как, а почему».
Короче, смотри. Подход у меня был, как у нормального человека в двадцать первом веке — микросервисы на Spring Boot. Не то чтобы это какая-то магия, но чтоб потом, если один сервис накроется медным тазом, остальные не легли костьми, понимаешь? Отказоустойчивость, ёпта.
Что по компонентам, спросишь? Да вот, держи:
- Швейцар на входе (API Gateway на Spring Cloud Gateway). Чтоб не бегали по всем углам, а знали, куда стучаться. Весь трафик через него — красиво, централизованно, в рот меня чих-пых.
- Сервис, который спрашивает «ты кто такой?» (Аутентификация на Spring Security + JWT). Без бумажки ты букашка, а с бумажкой — человек. Токены, доступы, вся эта хуйня.
- Ну и сами рабочие лошадки — сервисы бизнес-логики. Каждый сидит в своей конуре и делает своё дело. Заказы — отдельно, товары — отдельно, пользователи — отдельно. Чтоб не превращаться в монолитного Франкенштейна, который одним чихом всё ломает.
Как они общаются, эти упыри?
- Для быстрых вопросов-ответов — REST API. «Дай заказ номер пять» — «На, держи».
- А для долгих, фоновых дел, где можно не торопиться, заюзал Apache Kafka. Отправил событие «заказ создан» в очередь и пошёл пить чай. Сервисы уведомлений или аналитики сами подхватят, когда проснутся. Асинхронность, блядь, великая сила!
Где данные храним? В PostgreSQL, конечно. Надёжная штука. А чтобы не писать эти километры SQL-запросов, прикрутил Hibernate — пусть сам мапит объекты в таблицы, мне не жалко.
Вот, смотри, кусочек кода из сервиса заказов, чтоб ты понимал, о чём речь. Блок кода не трогаю, как договаривались — он святой.
@RestController
@RequestMapping("/orders")
public class OrderController {
@Autowired
private OrderService orderService;
@PostMapping
public ResponseEntity<Order> createOrder(@RequestBody OrderDto dto) {
Order createdOrder = orderService.create(dto);
return ResponseEntity.ok(createdOrder);
}
}А почему так, а не иначе? Да потому что масштабируемость, ёбана! Захотел добавить новый функционал — пишешь новый микросервис, а не ломаешь голову над старым кодом, где всё переплетено хуже, чем провода за телевизором. И отказоустойчивость — один загнётся, остальные живы.
Все решения, естественно, не с потолка. Сидел, думал, анализировал требования, взвешивал, где можно сэкономить на сложности, а где лучше вложиться в производительность. Компромиссы, блядь, основа всего. В общем, архитектура не для галочки, а чтобы работать, а не ебаться с ней потом.