Якщо ви хотіли використовувати мікросервіси, щоб отримати вигоду від масштабованості, нещільного з'єднання та легкої незалежної модифікації кожної служби, вам слід дотримуватися цього в максимально можливій мірі.
Загальна архітектура
Я думаю, що найкращим підходом був би:
- мати мікросервіс для загального управління інформацією про користувачів;
- зберігати специфічну для користувачів мікросервісу інформацію (наприклад, профілі, авторизацію, налаштування) у кожній мікросервісі (використовуючи референ загального ідентифікатора)
Додаткове читання:
- Ця стаття дуже добре описує таку архітектуру та обґрунтування, з конкретним випадком дозволів.
- У цій статті описані проблеми та рішення управління ідентифікацією користувачів, щоб уникнути доступу всіх служб до одного сховища.
- Ця стаття описує можливість використання JWT для передачі ідентичності користувача між службами (зазначаючи, що деяка основна інформація може бути надана в токені id, що дозволяє уникнути необхідності запитувати службу користувача ще один раз після входу, принаймні для дуже базового інформація).
Обмін кодом
Тепер, якщо ви погоджуєтесь з рішенням вище, у нас є мікросервіс користувача (інкапсуляція доменної моделі для користувача), а всі інші послуги є споживачами однієї мікросервісу. Тоді питання полягає в тому, щоб знати, чи хочете ви:
- або кожен мікросервіс, щоб винаходити споживчий код, дотримуючись догми про сильне розмежування щодо забезпечення гнучких і чітких циклів випуску,
- або поділитися споживчим кодом як частиною бібліотеки, вважаючи, що ця основна інформація є розширенням структури інфраструктури "шасі" .
Я не займатимуся чітко вирішеною позицією щодо цього, оскільки існують опозиційні віри думок на цю тему спільного використання коду, і я не думаю, що я в змозі зайняти об'єктивну позицію. Ось уже додаткове читання:
- Ця стаття вважає, що немає найкращого рішення, і все залежить від ваших цілей
- Ця стаття полягає в тому, що спільний доступ до коду є поганим лише в тому випадку, якщо він створює міцну зв'язок, а спільний доступ до коду може принести деякі синергії
- Ця стаття (про людей, які впроваджували мікросервіси в масштабі) наполягає на необхідності створення окремих побудов та можливих проблем з виведенням з експлуатації старого коду. Наявність спільної бібліотеки для споживання з твердим управлінням версіями не заважає цим передовим практикам.
Моя власна думка з цього приводу полягає в тому, що ви НЕ повинні ДІЛЯТИ код між користувачем-провайдером та користувачем-споживачами, щоб уникнути тісного з'єднання. Однак ви МОЖЕТЕ ПОДІЛИТИ код споживачів між споживачами, якщо у вас є чітке управління версіями. Цей підхід матиме деякі переваги:
- Різні споживчі мікросервіси можуть бути створені з різними версіями спільного коду споживача (якщо версії сумісні з незалежним користувачем-провайдером). Така ж гнучкість, що і винахід колеса, але вища продуктивність.
- Ви можете самостійно змінити послугу постачальника послуг, не впливаючи на споживачів.
- Якщо помилка виявлена на стороні споживання, ви можете її виправити один раз і розгорнути всіх споживачів якнайкраще (завдяки керуванню версіями). Це навіть може призвести до підвищення якості обслуговування.
- Якщо з якоїсь причини ви зобов'язані оновити API провайдера користувачів, ви можете швидше розгорнути оновлене споживання користувача. Якщо ви підтримуєте стару та нову послугу постачальника активними під час переходу, така можливість спільного використання може дозволити швидше закрити старішу версію споживача-постачальника.