ИТ-архитектура

2023-01-06 09:45:29 Количество переездов в облака увеличилось вдвое. Как банки оказываются в облаках, как они там защищаются от шумных соседей и любителей украсть жесткий диск из гермозоны?

Когда же еще найти время узнать что-то новое архитектору? Конечно же послушать очередной интересный #podcast

https://pca.st/episode/d6259fc9-2532-42cb-a140-d24399113187 Ашу / Түсініктеме

2023-01-04 06:35:11 Оплата через сканирование QR-кода очень распространена, но знаете ли вы, что есть несколько видов такой оплаты? #перевод_для_канала_itarchitecture Есть 4 способа, независимо от того, используете ли вы PayPal, Stripe, Paytm, WeChat или Alipay. Чтобы разобрать… Ашу / Түсініктеме

2023-01-04 06:34:56 Оплата через сканирование QR-кода очень распространена, но знаете ли вы, что есть несколько видов такой оплаты?

#перевод_для_канала_itarchitecture

Есть 4 способа, независимо от того, используете ли вы PayPal, Stripe, Paytm, WeChat или Alipay. Чтобы разобрать это, мы ответим на вопросы.

Первый вопрос заключается в том, кто предъявляет QR-код:
1. Вы можете предъявить QR-код, и продавец отсканирует код для оплаты. Это называется режимом, представленным потребителем, и продавец напрямую дебетует ваш счет.

2. Очевидно, что другой способ заключается в том, что продавец предъявляет QR-код для сканирования, чтобы оплатить причитающуюся сумму. Это называется "режимом, представленным торговцем", и вы предоставляете прямой кредит со своего счета.

Второй вопрос заключается в том, является ли QR-код динамическим или статическим:
1. Динамический QR-код означает, что QR-код будет генерироваться при его предъявлении, или он будет автоматически регенерироваться каждые несколько секунд. Поскольку он генерируется динамически, он может содержать детальную информацию, такую как причитающаяся сумма, тип транзакции и т. д.

2. Статический QR-код генерируется один раз и используется везде. Обычно он содержит только информацию об учетной записи.

Таким образом, есть 2 * 2 = 4 способа сканирования QR-кода:
1. Потребительский режим + статический QR-код
2. Потребительский режим + динамический QR-код
3. Режим, представленный продавцом + статический QR-код
4. Режим, представленный продавцом + динамический QR-код

Вопросы к вам:
1. Один из указанных сценариев сканирования сопровождается красным символом - указано наличие высокого риска. Почему?
Ответ:
Статический QR, представленный потребителем, является наименее предпочтительным способом, поскольку он имеет высокий риск прослушивания и множества списаний у пользователя за одну операцию.
Идеальным случаем для методов статического QR являются случаи, когда предъявитель кода получает кредит (например, баллы, кэшбэк и т. д.). Для платежных процедур динамические QR-коды более безопасны.
2. Что лучше: динамический QR-код, представленный продавцом, или динамический QR-код, представленный потребителем?
Ответ:
QR, представленный продавцом, более удобен для обеих сторон, так как у торгового аппарата уже есть детали квитанции с ценами на все товары и общей стоимостью, налогом и т. д. Поэтому продавец создает код ссылки для операции, закодированный в форме QR, представляет его покупателю для сканирования, покупатель получает и проверяет данные до того, как он заплатит, чтобы избежать ошибок.
В противном случае потребитель должен установить детали платежа (по крайней мере, общую цену + имя продавца) вручную на своем телефоне, а затем самостоятельно создать код платежа, что требует больше времени. Ашу / Түсініктеме

2022-12-31 18:40:39 Дорогие друзья, с наступающим Новым годом!
Сейчас у канала всего 200 подписчиков, но это очень качественная аудитория!
Более 100 человек знаю лично.
Спасибо за подписку и желаю всем нам профессионального роста и гармонии в 2023 году! Ашу / Түсініктеме

2022-12-30 09:25:02 Как строятся распределенные системы такого масштаба как Ozon, как тестируется готовность к нагрузкам и как прогнозируются узкие места, почему в хайлоаде часто пишут свои велосипеды и можно ли это делать в своем проекте?

#podcast

https://pca.st/episode/dc75a768-f55f-4cb5-8336-328ae4bc4840 Ашу / Түсініктеме

2022-12-26 11:01:25 Какой технологический стек обычно используется для микросервисов?

#перевод_для_канала_itarchitecture

На диаграмме показан стек микросервисных технологий, как для этапа разработки, так и для этапа эксплуатации.

Разработка

Определение API - устанавливает контракт между фронтендом и бэкэндом. На данном этапе мы можем использовать Postman или OpenAPI.

Разработка - React, Angular и Vue популярны во фронтенд-разработке и Node.js/Java/Python/Go для разработки бэкэнда. Кроме того, нам нужно подготовить конфигурации в API Gateway в соответствии с определениями API.

Continuous Integration (непрерывная интеграция) - JUnit и Jenkins для автоматизированного тестирования. Код упакован в образ Docker и развернут как микросервисы.

Эксплуатация

Nginx, HAProxy и Apache - распространенный выбор для балансировщиков нагрузки. Cloudflare предоставляет CDN (сеть доставки контента). 

API Gateway - мы можем использовать Spring Boot в качестве шлюза и Eureka/Zookeeper для Service Discovery (обнаружения сервисов).

Микросервисы развертываются в on-premise и в "облаках". У нас есть варианты: AWS, Microsoft Azure или Google GCP.

Кэш и полнотекстовый поиск: Redis - это распространенный выбор для кэширования пар ключ-значение. ElasticSearch используется для полнотекстового поиска.

Коммуникации - чтобы сервисы могли общаться друг с другом, мы можем использовать инфраструктуру обмена сообщениями Kafka или RPC.

Хранение - мы можем использовать MySQL или PostgreSQL для реляционной базы данных, NoSQL-решения (MongoDB/CosmosDB/DynamoDB) и Amazon S3/Minio для объектного хранилища. При необходимости можем использовать Cassandra для организации хранилища с широкими столбцами.

Управление и мониторинг - для управления таким количеством микросервисов потребуются инструменты Ops, включающие Prometheus, Elastic Stack и Kubernetes. Ашу / Түсініктеме

2022-12-22 09:31:15 Какие моменты стоит учитывать при проектировании архитектуры, только ли этим занимаются архитекторы и как учиться архитектурным тонкостям?

#podcast

https://pca.st/episode/72283b11-a1dd-45bd-9e8d-debffc4fbcf2 Ашу / Түсініктеме

2022-12-20 10:30:49 Данные кэшируются везде -  от фронтенда до бэкенда! #перевод_для_канала_itarchitecture Эта диаграмма иллюстрирует, где мы кэшируем данные в типичной архитектуре. Вдоль этого потока лежит несколько слоев: 1. Клиентские приложения: HTTP-ответы могут быть… Ашу / Түсініктеме

2022-12-20 10:30:36 Данные кэшируются везде -  от фронтенда до бэкенда!

#перевод_для_канала_itarchitecture

Эта диаграмма иллюстрирует, где мы кэшируем данные в типичной архитектуре.

Вдоль этого потока лежит несколько слоев:

1. Клиентские приложения: HTTP-ответы могут быть кэшированы браузером. Мы впервые запрашиваем данные по HTTP, и они возвращаются с политикой истечения срока действия в заголовке HTTP; мы снова запрашиваем данные, и клиентское приложение сначала пытается получить данные из кэша браузера.

2. CDN: CDN кэширует статические веб-ресурсы. Клиенты могут извлекать данные с ближайшего узла CDN.

3. Балансировщик нагрузки: Балансировщик нагрузки также может кэшировать ресурсы.

4. Инфраструктура обмена сообщениями: Брокеры сообщений сначала хранят сообщения на диске, а затем потребители получают их по мере необходимости. В зависимости от политики хранения данные кэшируются в кластерах Kafka в течение определенного периода времени.

5. Сервисы информационной системы: В сервисах есть несколько уровней кэша. Если данные не кэшируются в кэше центрального процессора (CPU), сервис попытается получить данные из памяти (RAM). Иногда сервис имеет кэш второго уровня для хранения данных на диске.

  6. Распределенный кэш: Распределенный кэш, такой как Redis, хранит пары ключ-значение для нескольких сервисов в памяти. Это обеспечивает гораздо лучшую производительность чтения/записи, чем в базах данных.

7. Полнотекстовый поиск: Иногда нам нужно использовать полнотекстовый поиск, такой как Elastic Search для поиска документов или поиска в логах. Копия данных также индексируется в поисковом движке.

8. База данных: Даже в базе данных у нас разные уровни кэшей:
- WAL(Write-ahead Log - упреждающая журнализация): Данные записываются в WAL перед созданием индекса B-tree
- Buffer pool: Область памяти, выделенная для кэширования результатов запроса
- Materialized View: Предварительно вычисляет результаты запросов и хранит их в таблицах базы данных для лучшей производительности запросов
- Transaction Log: Логирует все транзакции и обновления базы данных
- Replication Log: Используется для записи состояния репликации в кластере баз данных

Вопрос к вам:
Как мы можем гарантировать, что конфиденциальные пользовательские данные будут полностью удалены из систем, если данные кэшируются на многих уровнях?

Ответ:
Системы кэширования обычно работают с учетом трех временных факторов:
- промежуток времени;
- повторная валидация;
- очистка.
В зависимости от необходимости мы можем стереть данные.
Кроме того, кэшем можно управлять на стороне пользователя. Ашу / Түсініктеме

2022-12-14 15:58:06 Лучшие практики в разработке API #перевод_для_канала_itarchitecture В повседневной работе в качестве инженеров-программистов большинство использует или создает REST API. Стандартный подход обеспечения коммуникации между системами - посредством API. Поэтому… Ашу / Түсініктеме