Я думаю, что сначала нужно установить несколько условий.
1.Ваша продукция не является (не должна быть) отдельной от ваших API.
Большинство компаний используют внешние API, которые у них есть, так или иначе.Почему бы не они?Он надежен / отслеживается / распределяется / балансируется нагрузкой, поэтому он будет отличным сервисом для использования.Они могут иметь некоторые внутренние версии этих API для целей тестирования / выпуска, но в первую очередь их интерфейс будет построен на том же стеке, который вы можете вызвать.Поэтому вы не должны рассматривать API полностью отдельно от того, что у вас есть в вашей продукции.В наши дни это действительно часть системы.
2.Репликация базы данных
Обе эти диаграммы выглядят для меня некорректно.Верхний выглядит неправильно, потому что вы явно читаете из другого экземпляра, а нижний выглядит неправильно, потому что у вас нет репликации.Теперь репликация - это очень длинная тема - короткий урок - , вам обязательно нужно иметь репликацию. Проверьте эту ссылку, чтобы увидеть различные типы согласований для репликации данных: https://en.wikipedia.org/wiki/Consistency_model Вам придется сделать несколькокомпромиссы здесь, но в качестве примера в зависимости от вашей нагрузки и схемы загрузки;Вы можете реплицировать свою БД, разрешить чтение для нескольких регионов, записи для одного региона и бизнес-уровень, который также позволяет использовать API в нескольких регионах.(Это если у вас достаточно трафика)
3.Проблемы проектирования
Ну, есть несколько проблем с дизайном, но давайте сначала ответим на ваши вопросы.
В случае (1) (Репликация), как я могу иметь дело с реальным временемданные?Например: Расположение автобуса?
- Проверьте различные типы консистенции и выберите тот, который подходит вам лучше всего.
- Какой ваш идеальный опыт в реальном времени?Является ли это картографическое приложение, в которое вы отправляете уведомления о местоположении шины на устройства / или вы ожидаете, что пользователи подключатся и запросят информацию, когда появится следующая шина?В зависимости от ваших потребностей у вас могут быть разные дизайнерские решения. (Также я очень сомневаюсь, что ваше местоположение шины будет исходить от БД) Ни один из них не влияет на репликацию, хотя согласованность + соотношение чтения / записи и общая схема загрузки / загрузки являются более важными в этомcase.
В случае (2), какие у меня могут быть проблемы?(производительность, безопасность ...)
Вы не должны использовать вариант 2.
Я думаю, вы должны определить требования своего пользователя и системы прежде всего.Также очень сложно проектировать только по этим диаграммам, так как мы не можем точно знать, проектируем ли мы эту систему для локального района или всемирной системы.В идеале вы должны иметь избыточность для всего (например, несколько серверов, обслуживающих сетевой трафик / несколько БД / несколько CDN для вашего статического контента и т. Д.), Чтобы у вас было более высокое качество обслуживания и гораздо меньшие шансы на падение.Иногда даже целые регионы облачных сервисов выходят из строя из-за стихийных бедствий / поэтому репликация в разных регионах - хорошая идея, но вашей системе это может и не понадобиться.В любом случае ваш публичный API не должен быть отделен от вашего производства.