Служба REST як сервер додатків для 2000+ клієнтських машин. Це гарна ідея?

Ми будемо будувати систему з інтерфейсом в javaFx, яка буде розгорнута до 2000+ машин (мінімум 2000, але буде більше - може досягти 5000 машин).

З інших причин / обмежень він повинен бути встановлений на машині, тому ми не можемо зробити це з інтерфейсом веб-браузера.

Машини 2000+ будуть в різних географічних групах розташування. Загалом, зв’язок хороший, але може не бути таким хорошим у віддалених місцях.

Замість доступу безпосередньо до бази даних я замислююся над створенням кластеру обслуговування REST з Spring + Spring Boot + Spring Data (java).

Служба REST прийняла б і поверне Json.

Я думаю, що це гарна ідея, оскільки:

• Служба діятиме як пул підключення до бази даних (я думаю, що 2000+ підключень до бази даних спричинить проблеми);
• Можливо мати базу даних з доставкою журналу до іншої бази даних, лише для читання, для обслуговування деяких запитів;
• Це було б краще, оскільки ми можемо додати більше машин для запуску REST-послуг;
• Можна використовувати HTTPS зі стисненням з міркувань безпеки та збереження пропускної здатності;
• Можна здійснити деякі централізовані зміни для суб’єктів господарювання без перерозподілу машин 2000+;
• Він краще інтегрується з іншими системами (просто вкажіть його на послугу REST).

Це справді гарна ідея?

Чи можете ви поділитися позитивним чи негативним досвідом?

Дякую.

Це відкриті запитання з великою кількістю можливих відповідей, які залежать від того, що ви намагаєтесь зробити. Тим не менш, я додам кілька речей як відповідь, оскільки коментар буде недостатньо великим.

Служба діятиме як пул підключення до бази даних (я думаю, що 2000+ підключень до бази даних спричинить проблеми);

Так, це гарна ідея. Ви залишаєте меншою кількість з'єднань відкритими і повторно використовуєте їх, коли запити надходять до служби. Але вам потрібно знати, наскільки швидко будуть подані запити та скільки кожного запиту використовує база даних, інакше невеликий пул може бути легко вичерпаний, а інші запити будуть заблоковані під час очікування виходу з'єднання з базою даних.

Кешування може допомогти там повернути вже отримані дані (як я вже казав, залежить від того, що ви намагаєтеся зробити - якщо запити унікальні, ви не можете багато кешувати).

Також зауважте, що розмір пулу буде помножений на кількість наданих вами послуг. Кілька сервісів, і ви можете використовувати великі розміри пулу баз даних; більше служб і вам потрібно зменшити розмір пулу, щоб у вас загалом було відкрито однакове число підключень до бази даних.

Можливо мати базу даних з доставкою журналу до іншої бази даних, лише для читання, для обслуговування деяких запитів;

База даних може легко стати вашим вузьким місцем. Забагато підключень та / або занадто багато запитів, і ви можете їх порушити. Тоді не має значення, що ви можете горизонтально масштабувати свої послуги до будь-якої кількості. Усі запити з часом надійдуть до однієї бази даних.

Існують різні способи захисту: кешування, про яке я вже згадував (залежить від вашого випадку використання), дублює деяку інформацію на інших серверах для обслуговування деяких запитів, як ви згадуєте, CQRS (залежить від вашого випадку використання), використовуйте реляційний vs нереляційний (знову залежить від вашої справи використання) тощо.

Зауважте, що коли ви поширюєте такі дані, теорема CAP починає застосовуватися. Майте на увазі це, як вам може знадобитися компроміс між послідовністю та доступністю.

Це було б краще, оскільки ми можемо додати більше машин для запуску REST-послуг;

Так, служба REST буде масштабуватися, але, як я вже згадував вище, якщо ви не захистите базу даних, це може легко стати вузьким місцем.

Можна використовувати HTTPS зі стисненням з міркувань безпеки та збереження пропускної здатності;

Так, як і інші речі ... можливо, ви хочете пізніше перевірити автентифікацію / авторизацію тощо.

Можна здійснити деякі централізовані зміни для суб’єктів господарювання без перерозподілу машин 2000+;

Так, але певною мірою і не всі види змін. Якщо ви внесете переломну зміну, вам також потрібно буде оновити клієнтів. Тому подумайте про стратегію оновлення клієнтів до останньої версії або якщо ви дозволяєте літнім клієнтам все ще працювати та користуватися програмою.

Він краще інтегрується з іншими системами (просто вкажіть його на послугу REST).

Так, але це означає, що клієнти вашої послуги, які, можливо, ви не можете контролювати.

Якщо ви зробите переломну зміну, і у вас є гарна стратегія оновлення своїх 2000+ клієнтів JavaFX, тоді немає проблем. Але якщо інші клієнти існують і у вас немає контролю над ними, можливо, вам доведеться впровадити версію на сервісі REST та підтримувати більше однієї версії, поки кожен не зможе оновитись до останньої.

Як я вже казав, це залежить від того, що ви намагаєтеся зробити. Загалом, ваша хороша ідея. Але майте на увазі, що речі не прийдуть безкоштовно лише тому, що ви дотримуєтесь служби REST перед базою даних.

Тільки мої 2 копійки!