Ну, ви вже придираєтесь :) Все залежить від потреб системи і я переконаний, що існують системи, де необхідно підняти і 10, а може і більше mongodb кластерів. Але можна обійтись різними колекціями, схемами, або просто різними таблицями. Головна ідея, щоб дані були інкапсульовані і якщо сервісу А потрібні дані з сервісу B, то він їх може отримати тільки через сервіс B і ніяк інакше. Просто як показує практика, якщо дані не інкапсульовані, то рано чи пізно знайдеться «розумник», який вирішить полізти в БД напряму. Для кращого розуміння принципів мікросервісної архітектури ми вирішили використовувати embedded H2 DB для кожного мікросервісу.
Дякую! Дурна помилка :)
Так, ви праві. Токен перевіряється секретним ключем, який використовувався для генерації jwt. І запити до service-authority-java робити не потрібно.
Може бути таке, що для деяких сервісів база не потрібна, але якщо 2 або більше мікросервісів пишуть в одну базу, то це така собі мікросервісна архітектура :)
Дякую за коментарі та уточнення :)
1) Щодо ESB, то так, це не є обовʼязковими, але good practice, особливо якщо система велика.
2) Про спільну БД малось на увазі, що писати двом або більше сервісам в одну базу не є забороненим, навідміну, від мікросервісів, хоча погоджуюсь, що краще мати хоча б різні схеми, але як показує практика так роблять не завжди.
3) Навіть не можу згадати, чому я в схемі про мікросервіси не вказав про BFF, напевно не хотів, щоб вона була максимально схожа на схему NS. Але погоджуюсь, що варто було б зазначити.
4) Асинхроність оминав навмисно, оскільки на цю тему можна окремий воркшоп проводити, а ми і так ледь вписались в 4 години :)
5) Я думаю, що існують системи де навіть 1% матиме значення, але їх не багато, і для більшості систем це не важливо. Але те, що моноліт не матиме цієї затримки, то факт.
Не зовсім зрозумів, що ви маєте на увазі під словом «такий»?
Оу, дуже дякую, що зауважили! Тут були переплутані картинки в SOA та NS. Вже поміняв місцями :)
Маю 1 REGULAR квиток. Пишіть в ТГ — @yehorslupitskyi