athacker, я там был - давно и много раз) мы с разных сторон на проблему смотрим. Это хорошо работает server-to-server но я говорю о том что проблема вылезет все-равно на обращение с клиента и валидацию доступа пользователя. Просто прямо сейчас из вопроса и того что уже сделано ТС это не очевидно. Многие так делали и все переделывают по тому что это наращивает огромный архитектурный долг
Задача -- обеспечить возможность получения статистики только от серверов с API-шлюзами
Что приведет очень быстро к bottleneck и slow train и в результате все-равно будет распределенная сеть микросервисов и аутентификацией пользователей независимо
Стыдно, товарищ.
Пишу что по памяти, но в голове просто закрепился данный факт. И я буду настаивать на том что асимметричное шифрование полезно для других задач. Подпись запроса это хорошо, но мы уже подписываем запрос по https (ssl) и сервер принимает на один хост только один сертификат, а это значит что для второго слоя мы должны подписывать тело запроса (которого может и не быть) и присылать какой-то идентификатор ключа.
athacker, генерировать на каждого пользователя свой сертификат и подписывать им запрос? Чушь. Запросы и так должны передаваться по SSL, а контент запроса сверху еще защищать шифрованием в целом бессмысленно. Там огромное число проблем, не говоря уже при том что при равной длине ключа симметричное шифрование безопаснее ассиметричного и служат они для разных целей. TLS это вообще - transport layer security. Идем в RFC, читаем спеки и прекращаем забивать гвозди микроскопом
athacker, это простое и масштабируемое решение, которое настраивается клац-клац) получаем стандартные протоколы безопасности и библиотеки на любой вкус и цвет + настройки. А вот то что ты заявляешь про достаточность TLS меня несколько смешит ибо это безопасность только на уровне обмена данными, но контроль доступа не обеспечивает никак. Ну и в догонку - они уже начинают разделять сервисы, а это процесс изменения архитектуры и появление SOA, а тут один путь)
Karpett, зависит от того сколько коннектов может держать один сервер (php тут не при чем) и том как написан код и как построена архитектура. Но вообще тут и одного сервера может хватить. Могу помочь с общими идеями, но это проще голосом)
1. Не корректный заголовок вопроса: архитектура это проектирование будущей системы по бизнес-требованиям. Бд это вообще частное следствие, при чем даже не в первой десятке вопросов.
2. Сначала определитесь с требованиями к системе, моделью данных, из поведением в системе и тому подобными вопросами. Там уже можно будет начать разговор
Денис, мозг) тут не может быть однозначного ответа по тому что надо понимать что за данные, как они обрабатываются, зачем, почему, как часто ..... ну и знать текущую версию архитектуры, целевую и причины вот этого всего
Денис, это плохо масштабируется, а так же не управляется версионирование ведь они могут меняться со временем. Ну и совсем не нативное место - разработчик может долго дебажить, а узнать что все происходит в процедуре.
А что по микросервисам? Это читать - долго и вдумчиво) Что по сложную логику связей - там совсем другие подходы и другие челенджи. что-то делается сложнее, а что-то куда проще
