Как обрабатывать два http-запроса от распределенной системы?

Question

У нас есть приложение, в котором пользователи могут войти только через Facebook. При успешном входе в Facebook выполняется еще один http отдых, чтобы сохранить имя, адрес электронной почты и некоторую другую информацию от поставщика входа в Facebook. Мы столкнемся с проблемами согласованности данных, если вторая служба RESTful не сможет сохранить информацию с fb на Mongodb

1. Пользователь может только зарегистрироваться / войти через Facebook
2. При каждой успешной регистрации Facebook отправляет обратно некоторую информацию, такую ​​как имя пользователя, адрес электронной почты и идентификатор пользователя
3. Затем мы немедленно сохраняем эту информацию в нашей базе данных

Таким образом, если третий шаг не пройден, мы теряем информацию о пользователе, который зарегистрировался через Facebook.

loginWithFacebook() {
      const provider = new firebase.auth.FacebookAuthProvider();
      provider.addScope('user_birthday');
      provider.addScope('user_friends');
      provider.addScope('user_gender');
      return new Promise<any>((resolve, reject) => {
        this.afAuth.auth
        .signInWithPopup(provider) // a call made to sign up via fb
        .then(res => {
          if (res) {
            resolve(res);
            if (res.additionalUserInfo.isNewUser) { // creatin profile only if he is a new user
              this.createProfile(res); // a call to store the response in the db
            }
            this.setTokenSession(res.credential.accessToken);
          }
        }, err => {
          console.log(err);
          reject(err);
        })
      })
    }

Есть ли аккуратный архитектурный способ организации этого?

Answer 1

Пристегнитесь, потому что это не тривиальная проблема.

Если это настоящая микросервисная архитектура, где каждая служба имеет свою собственную выделенную базу данных, то вы, очевидно, не сможете эффективно выполнить транзакцию. Возможно, вы сможете выполнить 2-фазную фиксацию , но у нее есть свои проблемы, особенно с долгоживущими блокировками БД.

Масштабируемым подходом к вашей проблеме является Шаблон распределенной саги :

Реализация каждой бизнес-транзакции, охватывающей несколько сервисов, в виде саги. Сага - это последовательность локальных транзакций. Каждая локальная транзакция обновляет базу данных и публикует сообщение или событие для запуска следующей локальной транзакции в саге. Если локальная транзакция терпит неудачу из-за нарушения бизнес-правила, тогда сага выполняет серию компенсирующих транзакций, которые отменяют изменения, сделанные предыдущими локальными транзакциями.

Я думаю, что вышеизложенное довольно лаконично, поэтому я намеренно отклонюсь от касательной:

Распределенными системами сложно управлять. Убедитесь, что вы не нарушаете YAGNI архитектурой вашей системы. Если возможно, спросите себя, действительно ли вам нужна распределенная архитектура на этом этапе.

Обеспечение согласованности данных в распределенной системе является относительно сложным Задача, которая в большинстве случаев требует специальной службы координатора, дополнительного кода для управления всем этим и всей сложности, которая сопровождает все это дополнительное оборудование.