Можно никто не запрещает :) Типа да, ты можешь там отловить ошибку самой платежной системы если причина на стороне платежки, показать оповещение “платежи недоступны”. Но один сбой в монолите может повлиять на что угодно ну то есть на все :) А в микросервисах всё реально разделено.
Упал сервис email рассылки ну и ладно, письма потом отправим, ничего критичного. Главное, чтобы заказ оформили. Лёг сервис уведомлений ничего страшного, просто не пришло пуш уведомление, пользователь всё равно заказ сделал и оплатил. Потом доставим. Каталог товаров работает, но упал сервис рекомендаций ну нет блока “вам также может понравиться” и что? Магазин всё ещё работает. Слетел сервис аналитики система не умирает, просто временно не считаем метрики. Пользователю вообще пофиг. Проблемы с чатом поддержки ничего, добавим “Извините, чат временно недоступен, напишите на почту”. Да даже если сервис отзывов/комментариев лёг тоже не страшно. Временная заглушка, типа “не удалось загрузить отзывы”, и поехали дальше. И т д там примеров куча на самом деле.
Ну и плюс обновлять, масштабировать, мониторить удобнее. Выкатил один сервис остальное не трогаешь. Да, сложнее на старте, но зато стабильнее на росте. В монолите тоже можно что то похожее сделать, просто это всё усложняется и начинает напоминать микросервисы внутри монолита а это уже звоночек :) Это как раз про устойчивость. Монолит легче сделать, но он сложнее масштабируется и хуже переживает частичные сбои. А в микросервисах у тебя появляется гибкость один сервис масштабируешь, другой выкатываешь без остановки всей системы, третий деплоишь в экспериментальном режиме и т д.
Раньше я тоже так думал, что у интернет магазина одна база на всех и это логично, если проект делается как одно большое приложение. Другими словами, это монолитная архитектура, которая вполне имеет место быть, особенно на старте, когда нужно быстро запустить что то рабочее и проверить гипотезы.
Обычно в крупном бизнесе бывает так нужно протестировать какую то идею на ограниченной аудитории, например 500–1000 пользователей. Делают MVP иногда прямо на коленке, часто на PHP потому что быстро. Выкатывают первую версию, смотрят, как всё работает. Если гипотезы подтверждаются начинают двигаться дальше выстраивают архитектуру, режут монолит на части, готовятся к росту.
Потом запускается маркетинг, трафик растёт, и проекту уже нужны другие подходы надёжность, масштабируемость, независимые релизы. И вот тут приходит микросервисная архитектура. В ней каждый сервис отвечает только за свою часть данных и не лезет в чужие. Это сложнее, но даёт гибкость и устойчивость при больших нагрузках.
Например, сервис заказов хранит только заказы, сервис платежей только информацию о платежах, сервис пользователей только данные профилей. Если заказ создан, один сервис кидает событие, а другие на него реагируют. Так и всё синхронизируется. Подходы могут быть разные.
Да, это сложнее. Да, возникают вопросы с отменами, транзакциями и т д. Но взамен мы получаем систему, где каждый сервис можно отдельно обновлять, масштабировать, копировать и вообще гибко управлять ими. И если в каком то сервисе случится сбой это не сломает всю систему. Например, сайт продолжит работать, а пользователь просто увидит сообщение вроде "Платежи временно недоступны".
Так что все ОК. Просто вы смотрите на задачу с позиции одного общего проекта то есть монолита. Такой подход отлично подходит для MVP, быстрых запусков и проверки гипотез. Но когда речь идёт о миллионах пользователей, монолит режут на части, чтобы система работала не только быстро, но и предсказуемо.
Когда пользователей становится больше, растёт и инфраструктура появляется много сервисов, API, очередь задач, логирование, мониторинг, CI/CD, облака и т.д. В этот момент один человек который разработал MVP на коленках уже не может всё успевать. Формируется команда из бекенд разработчиков, devOps, аналитики, тестировщики, тим лиды, архитекторы ...
В вопросе я разобрался полностью. Статью накидал скажем так, это основа основ, чтобы те, кто вообще не в курсе, как работает end-to-end шифрование, могли получить хотя бы общее представление о том, как оно реализуется. По хорошему, стоило бы написать вторую часть статьи о том, как генерируются приватные и публичные ключи, потому что были предложения на пайтоне и описание концепции в комментарии выше, а также о методах их хранения, но это уже дело фантазии каждого. В моём проекте, например, создание приватного и публичного ключей происходит на бэкенде, написанном на Golang, там же оно и шифруется паролем пользователя, кто то может реализовать это и на устройстве клиента используя только js ...
Тут я с вами соглашусь пул потоков действительно ограничен. В идеале всю тяжёлую логику стоит перенести в веб воркеры, чтобы основной поток был занят только обработкой пользовательского ввода, включая клики. Это особенно заметно на бюджетных мобильных устройствах за $100, где часто наблюдаются микролаги и прочие задержки. Воркеры могут помочь с этой проблемой.
Что касается WebCrypto, он выполняется вне основного потока и никак на него не влияет. Таким образом, если вернуться к теме статьи, шифрование и дешифрование именно сообщений обходится недорого даже для слабых устройств.
Да, всё верно если пароль утерян, восстановить сообщения уже не получится. Но это лишь один из возможных сценариев. Приватный ключ можно шифровать не только паролем пользователя, но и другими ключевыми словами. Например, это могут быть recovery codes, которые система случайным образом генерирует и затем использует для шифрования приватного ключа.
Допустим, сгенерировано 6 recovery codes тогда система создаёт 6 зашифрованных копий приватного ключа, каждая из которых связана с одним из этих кодов. Эти копии необходимо дополнительно хранить, например, в базе данных. При смене пароля пользователю стоит предлагать восстановить сообщения с помощью recovery codes и заранее обратить внимание на важность их сохранения ...
Обратите внимание, что приватный ключ дополнительно шифруется. В качестве примера его можно зашифровать паролем пользователя при регистрации аккаунта или любым другим ключевым словом, известным только вам. После шифрования приватный ключ сохраняется в базе данных. При авторизации клиенту передаётся только зашифрованный приватный ключ, который он расшифровывает с помощью пароля, введённого при авторизации. Затем ключ сохраняется на устройстве пользователя до окончания сессии авторизации. Но если пользователь забудет свой пароль от своей учетной записи, возникает проблема он больше не сможет расшифровать свои старые сообщения.
Точно так же я думал два года назад. Много раз я бросал и возвращался к этому методу в течение нескольких лет это было сложно, но со временем мозг адаптируется. Другие методики полезны лишь до тех пор, пока сохраняется сильная мотивация учиться. Однако после длительных повторений интерес может угаснуть а это уже катастрофа, особенно если было потрачено несколько месяцев интенсивной учебы возникает риск забыть многое, что ведёт к неэффективному обучению и потере времени. Кроме того, материал без визуального подкрепления и регулярных повторений со временем забывается. Приходится постоянно держать под рукой кучу заметок, перечитывать их снова и снова. При использовании этой методики достаточно закрыть глаза и полчаса помедитировать, блуждая по своему ментальному городу.
На первом этапе ваш город будет сильно или умерено размытым, но с каждым возвращением вы будете замечать, как картинка становится всё чётче и ярче. И что особенно важно исчезает ощущение умственного напряжения, особенно заметно на ранних этапах построения города. Тем не менее это своеобразная тренировка, которая развивает навыки детальной визуализации а это особенно полезно для программистов.
Тем не менее, практическое применение описано. То, как вы её реализуете, зависит от вашей фантазии. Эта статья отправная точка, а не подробная методичка.
Вы правы, к сожалению, сейчас нет такого человека, который сидел бы там постоянно, но я активно тестирую со своими знакомыми и исправляю недочеты, которые нахожу.
Спасибо за ваш комментарий. Мне очень жаль, что вам не удалось никого найти. Проект только стартовал, и людей там сейчас мало, и они бывают там в разное время, к сожалению.
Спасибо за ваш комментарий. Вы абсолютно правы, проект еще сыроват, но основные функции работают. Вы правы, что через VPN не получается соединиться с сигнальным сервером. К сожалению, пока проблему с VPN не удалось решить, но я уже работаю над этим вопросом. Мне очень жаль, что у вас не получилось зайти на сайт без VPN. Буду исправлять недочеты.
Спасибо за ваш комментарий. В чат рулетке можно предварительно отклонить заявку на общение, опираясь на популярность собеседника. Если популярность низкая, есть вероятность, что данного пользователя дизлайкали за активность в тех или иных действиях. Человек сам решает, будет ли он общаться с предложенным системой собеседником, или нет, на свой страх и риск, как говорится. В будущем планирую добавить блок, указывающий на то, за что именно дизлайкали, к примеру, за матерные выражения, эротический контент, неуважение и так далее.
Спасибо за ваш комментарий. Возможно, в следующей статье я сделаю обзор или мини-гайд по сигнальному серверу на Go. Если у меня будут на это силы. Сейчас, к сожалению, я занят продвижением проекта.
Можно никто не запрещает :) Типа да, ты можешь там отловить ошибку самой платежной системы если причина на стороне платежки, показать оповещение “платежи недоступны”. Но один сбой в монолите может повлиять на что угодно ну то есть на все :) А в микросервисах всё реально разделено.
Упал сервис email рассылки ну и ладно, письма потом отправим, ничего критичного. Главное, чтобы заказ оформили.
Лёг сервис уведомлений ничего страшного, просто не пришло пуш уведомление, пользователь всё равно заказ сделал и оплатил. Потом доставим.
Каталог товаров работает, но упал сервис рекомендаций ну нет блока “вам также может понравиться” и что? Магазин всё ещё работает.
Слетел сервис аналитики система не умирает, просто временно не считаем метрики. Пользователю вообще пофиг.
Проблемы с чатом поддержки ничего, добавим “Извините, чат временно недоступен, напишите на почту”.
Да даже если сервис отзывов/комментариев лёг тоже не страшно. Временная заглушка, типа “не удалось загрузить отзывы”, и поехали дальше. И т д там примеров куча на самом деле.
Ну и плюс обновлять, масштабировать, мониторить удобнее. Выкатил один сервис остальное не трогаешь. Да, сложнее на старте, но зато стабильнее на росте. В монолите тоже можно что то похожее сделать, просто это всё усложняется и начинает напоминать микросервисы внутри монолита а это уже звоночек :) Это как раз про устойчивость. Монолит легче сделать, но он сложнее масштабируется и хуже переживает частичные сбои. А в микросервисах у тебя появляется гибкость один сервис масштабируешь, другой выкатываешь без остановки всей системы, третий деплоишь в экспериментальном режиме и т д.
В конце недели
Раньше я тоже так думал, что у интернет магазина одна база на всех и это логично, если проект делается как одно большое приложение. Другими словами, это монолитная архитектура, которая вполне имеет место быть, особенно на старте, когда нужно быстро запустить что то рабочее и проверить гипотезы.
Обычно в крупном бизнесе бывает так нужно протестировать какую то идею на ограниченной аудитории, например 500–1000 пользователей. Делают MVP иногда прямо на коленке, часто на PHP потому что быстро. Выкатывают первую версию, смотрят, как всё работает. Если гипотезы подтверждаются начинают двигаться дальше выстраивают архитектуру, режут монолит на части, готовятся к росту.
Потом запускается маркетинг, трафик растёт, и проекту уже нужны другие подходы надёжность, масштабируемость, независимые релизы. И вот тут приходит микросервисная архитектура. В ней каждый сервис отвечает только за свою часть данных и не лезет в чужие. Это сложнее, но даёт гибкость и устойчивость при больших нагрузках.
Например, сервис заказов хранит только заказы, сервис платежей только информацию о платежах, сервис пользователей только данные профилей. Если заказ создан, один сервис кидает событие, а другие на него реагируют. Так и всё синхронизируется. Подходы могут быть разные.
Да, это сложнее. Да, возникают вопросы с отменами, транзакциями и т д. Но взамен мы получаем систему, где каждый сервис можно отдельно обновлять, масштабировать, копировать и вообще гибко управлять ими. И если в каком то сервисе случится сбой это не сломает всю систему. Например, сайт продолжит работать, а пользователь просто увидит сообщение вроде "Платежи временно недоступны".
Так что все ОК. Просто вы смотрите на задачу с позиции одного общего проекта то есть монолита. Такой подход отлично подходит для MVP, быстрых запусков и проверки гипотез. Но когда речь идёт о миллионах пользователей, монолит режут на части, чтобы система работала не только быстро, но и предсказуемо.
Когда пользователей становится больше, растёт и инфраструктура появляется много сервисов, API, очередь задач, логирование, мониторинг, CI/CD, облака и т.д. В этот момент один человек который разработал MVP на коленках уже не может всё успевать. Формируется команда из бекенд разработчиков, devOps, аналитики, тестировщики, тим лиды, архитекторы ...
В вопросе я разобрался полностью. Статью накидал скажем так, это основа основ, чтобы те, кто вообще не в курсе, как работает end-to-end шифрование, могли получить хотя бы общее представление о том, как оно реализуется. По хорошему, стоило бы написать вторую часть статьи о том, как генерируются приватные и публичные ключи, потому что были предложения на пайтоне и описание концепции в комментарии выше, а также о методах их хранения, но это уже дело фантазии каждого. В моём проекте, например, создание приватного и публичного ключей происходит на бэкенде, написанном на Golang, там же оно и шифруется паролем пользователя, кто то может реализовать это и на устройстве клиента используя только js ...
Тут я с вами соглашусь пул потоков действительно ограничен. В идеале всю тяжёлую логику стоит перенести в веб воркеры, чтобы основной поток был занят только обработкой пользовательского ввода, включая клики. Это особенно заметно на бюджетных мобильных устройствах за $100, где часто наблюдаются микролаги и прочие задержки. Воркеры могут помочь с этой проблемой.
Что касается WebCrypto, он выполняется вне основного потока и никак на него не влияет. Таким образом, если вернуться к теме статьи, шифрование и дешифрование именно сообщений обходится недорого даже для слабых устройств.
Да, всё верно если пароль утерян, восстановить сообщения уже не получится. Но это лишь один из возможных сценариев. Приватный ключ можно шифровать не только паролем пользователя, но и другими ключевыми словами. Например, это могут быть recovery codes, которые система случайным образом генерирует и затем использует для шифрования приватного ключа.
Допустим, сгенерировано 6 recovery codes тогда система создаёт 6 зашифрованных копий приватного ключа, каждая из которых связана с одним из этих кодов. Эти копии необходимо дополнительно хранить, например, в базе данных. При смене пароля пользователю стоит предлагать восстановить сообщения с помощью recovery codes и заранее обратить внимание на важность их сохранения ...
Обратите внимание, что приватный ключ дополнительно шифруется. В качестве примера его можно зашифровать паролем пользователя при регистрации аккаунта или любым другим ключевым словом, известным только вам. После шифрования приватный ключ сохраняется в базе данных. При авторизации клиенту передаётся только зашифрованный приватный ключ, который он расшифровывает с помощью пароля, введённого при авторизации. Затем ключ сохраняется на устройстве пользователя до окончания сессии авторизации. Но если пользователь забудет свой пароль от своей учетной записи, возникает проблема он больше не сможет расшифровать свои старые сообщения.
Точно так же я думал два года назад. Много раз я бросал и возвращался к этому методу в течение нескольких лет это было сложно, но со временем мозг адаптируется. Другие методики полезны лишь до тех пор, пока сохраняется сильная мотивация учиться. Однако после длительных повторений интерес может угаснуть а это уже катастрофа, особенно если было потрачено несколько месяцев интенсивной учебы возникает риск забыть многое, что ведёт к неэффективному обучению и потере времени.
Кроме того, материал без визуального подкрепления и регулярных повторений со временем забывается. Приходится постоянно держать под рукой кучу заметок, перечитывать их снова и снова.
При использовании этой методики достаточно закрыть глаза и полчаса помедитировать, блуждая по своему ментальному городу.
На первом этапе ваш город будет сильно или умерено размытым, но с каждым возвращением вы будете замечать, как картинка становится всё чётче и ярче.
И что особенно важно исчезает ощущение умственного напряжения, особенно заметно на ранних этапах построения города. Тем не менее это своеобразная тренировка, которая развивает навыки детальной визуализации а это особенно полезно для программистов.
Пока читал статью, успел три раза подумать, что это не про меня и три раза словил дежавю)
Если есть сильная мотивация, методика действительно работает. Главное чтобы запал не угас.
Спросите у нейросетей в чем различия этой методики от других...
Для мозга визуализация в спокойном состоянии это естественный процесс. Гораздо больше энергии уходит на чтение и анализ символов....
Вы перечислили похожие методики на базе которых была создана эта методика.
Тем не менее, практическое применение описано. То, как вы её реализуете, зависит от вашей фантазии. Эта статья отправная точка, а не подробная методичка.
Удачи
Вы правы, к сожалению, сейчас нет такого человека, который сидел бы там постоянно, но я активно тестирую со своими знакомыми и исправляю недочеты, которые нахожу.
Спасибо за ваш комментарий. Мне очень жаль, что вам не удалось никого найти. Проект только стартовал, и людей там сейчас мало, и они бывают там в разное время, к сожалению.
Спасибо за ваш комментарий. Вы абсолютно правы, проект еще сыроват, но основные функции работают. Вы правы, что через VPN не получается соединиться с сигнальным сервером. К сожалению, пока проблему с VPN не удалось решить, но я уже работаю над этим вопросом. Мне очень жаль, что у вас не получилось зайти на сайт без VPN. Буду исправлять недочеты.
Спасибо за ваш комментарий. В чат рулетке можно предварительно отклонить заявку на общение, опираясь на популярность собеседника. Если популярность низкая, есть вероятность, что данного пользователя дизлайкали за активность в тех или иных действиях. Человек сам решает, будет ли он общаться с предложенным системой собеседником, или нет, на свой страх и риск, как говорится. В будущем планирую добавить блок, указывающий на то, за что именно дизлайкали, к примеру, за матерные выражения, эротический контент, неуважение и так далее.
Спасибо за ваш комментарий. Возможно, в следующей статье я сделаю обзор или мини-гайд по сигнальному серверу на Go. Если у меня будут на это силы. Сейчас, к сожалению, я занят продвижением проекта.