JSON и JSON Schema
JSON (JavaScript Object Notation) — это структурированный текстовый формат обмена данными. Легко читается людьми. Имеет открытый стандарт.
Где используется
JSON независим от языков программирования и используется повсеместно, например:
💩 при обмене данными через API. Например, мы можем как один из вариантов передавать body HTTP-запроса в формате JSON (но не обязательно только JSON!)
💩 при создании параметров конфигурации для систем и сервисов
💩 в NoSQL базах данных, например, в MongoDB
Синтаксис
Json-объект — это неупорядоченное множество пар вида {"ключ": "значение"}.
💩 Ключ – это название параметра, пишется в двойных кавычках
💩 Значение для ключа указывается после двоеточия
💩 Между парами ключ-значение ставится запятая. После последней пары запятая не ставится
💩 Писать ключи можно в любом порядке
Типы данных
💩 Строка –
💩 Число – целое или с запятой –
💩 boolean – true или false –
💩 null – пустое значение –
💩 Массив –
💩 Объект –
Классический JSON (по стандарту RFC 8259) не поддерживает комментарии. Однако существует расширение стандартного JSON – JSON5, в котором можно вставлять комментарии.
А где же тип “дата”? JSON не даёт строгих указаний, в каком формате передавать дату и время. Можно использовать unix-time или передавать дату в строке по ISO 8601, например,
JSON Schema
JSON Schema – это способ описания структуры и ограничений JSON-документов. Схема создана для описания JSON-данных, но и сама она при этом является JSON-объектом. С помощью ключевых слов в схеме создаются правила валидации структуры объекта и типов его полей.
В отличие от XML-схемы, которая имеет стандарт и строго диктует определение документа в рамках XML, JSON-схема более гибкая и простая.
Применение JSON Schema
1️⃣ Описание формата данных в API-контрактах, которое читается машиной и понятно человеку
2️⃣ Валидация данных в JSON-документах. Здесь имеется в виду не просто проверка на корректность формата, а проверка специфических требований и ограничений
3️⃣ Автоматическая генерация примеров запросов и ответов API: JSON Schema позволяет генерировать динамические данные, соответствующие схеме. Эти примеры ответов можно использовать для создания заглушек
4️⃣ Создание автоматической документации к API
5️⃣ Автоматическая генерация кода. На основе схемы можно создавать SDK для API на любой платформе
📄 Спецификации
1. RFC 8259 — про JSON
2. ISO 8601 — про формат дат
3. JSON Schema
4. JSON5
📎 Материалы по JSON
0. Пример JSON
1. Что такое JSON и как с ним работать
2. Хорошо написанная статья в англоязычной Википедии
3. Типичные ошибки в JSON
4. JSON онлайн редактор
5. JSON конвертер в YAML
6. XML конвертер в JSON
7. YAML конвертер в JSON, XML, CSV
📎 Материалы по JSON Schema
1. Объяснение JSON-схемы с примерами от ВК
2. JSON Schema. Быть или не быть?
3. Понимание JSON схемы
4. Пример JSON-схемы
5. Пример онлайн-валидатора JSON-схемы
6. Конвертер JSON-схемы на разные языки
⏯ Видео
1. JSON за 5 минут
2. Формат JSON. От основ к практике
3. Полный курс по JSON для начинающих
4. Валидация JSON в Postman
#проектирование #api
JSON (JavaScript Object Notation) — это структурированный текстовый формат обмена данными. Легко читается людьми. Имеет открытый стандарт.
Где используется
JSON независим от языков программирования и используется повсеместно, например:
Синтаксис
Json-объект — это неупорядоченное множество пар вида {"ключ": "значение"}.
Типы данных
"name": "Вася""years": 24"resident": true"children": null"experience": [ "Повар", 2, "Аналитик", 1 ]"experience": { "Повар": 2, "Аналитик": 1 }Классический JSON (по стандарту RFC 8259) не поддерживает комментарии. Однако существует расширение стандартного JSON – JSON5, в котором можно вставлять комментарии.
А где же тип “дата”? JSON не даёт строгих указаний, в каком формате передавать дату и время. Можно использовать unix-time или передавать дату в строке по ISO 8601, например,
"2012-04-21T18:25:43-05:00".JSON Schema
JSON Schema – это способ описания структуры и ограничений JSON-документов. Схема создана для описания JSON-данных, но и сама она при этом является JSON-объектом. С помощью ключевых слов в схеме создаются правила валидации структуры объекта и типов его полей.
В отличие от XML-схемы, которая имеет стандарт и строго диктует определение документа в рамках XML, JSON-схема более гибкая и простая.
Применение JSON Schema
1️⃣ Описание формата данных в API-контрактах, которое читается машиной и понятно человеку
2️⃣ Валидация данных в JSON-документах. Здесь имеется в виду не просто проверка на корректность формата, а проверка специфических требований и ограничений
3️⃣ Автоматическая генерация примеров запросов и ответов API: JSON Schema позволяет генерировать динамические данные, соответствующие схеме. Эти примеры ответов можно использовать для создания заглушек
4️⃣ Создание автоматической документации к API
5️⃣ Автоматическая генерация кода. На основе схемы можно создавать SDK для API на любой платформе
1. RFC 8259 — про JSON
2. ISO 8601 — про формат дат
3. JSON Schema
4. JSON5
📎 Материалы по JSON
0. Пример JSON
1. Что такое JSON и как с ним работать
2. Хорошо написанная статья в англоязычной Википедии
3. Типичные ошибки в JSON
4. JSON онлайн редактор
5. JSON конвертер в YAML
6. XML конвертер в JSON
7. YAML конвертер в JSON, XML, CSV
📎 Материалы по JSON Schema
1. Объяснение JSON-схемы с примерами от ВК
2. JSON Schema. Быть или не быть?
3. Понимание JSON схемы
4. Пример JSON-схемы
5. Пример онлайн-валидатора JSON-схемы
6. Конвертер JSON-схемы на разные языки
1. JSON за 5 минут
2. Формат JSON. От основ к практике
3. Полный курс по JSON для начинающих
4. Валидация JSON в Postman
#проектирование #api
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥45👍19❤8
CAP-теорема
CAP-теорема – это утверждение о том, что в любой распределенной системе можно обеспечить выполнение только 2-х из 3-х следующих свойств:
1️⃣ Consistency (согласованность) – все узлы распределенной системы содержат актуальные и одинаковые данные в любой момент времени. Это свойство гарантирует, что любой запрос к системе вернет правильный и последний результат, независимо от того, к какому узлу он обращается.
2️⃣ Availability (доступность) – каждый запрос к системе возвращает результат. Без гарантий, что результат содержит последние данные. Даже если какие-то узлы выпали, система всё равно должна вернуть ответ.
3️⃣ Partition tolerance (устойчивость к разделению) – система продолжает работать даже при потере коммуникации между узлами. Например, если между двумя узлами отвалилась связь, то они продолжают работать независимо друг от друга.
Варианты сочетания свойств
💫 💫 (Consistency + Availability) – все узлы системы имеют одинаковые и актуальные данные, и все запросы получают ответ. Такие системы возможны при поддержке ACID-требований к транзакциям (Атомарность, Согласованность, Изоляция, Долговечность) и абсолютной надежности сети. На практике таких решений почти не существует. Классическим примером CA-системы называют распределённую службу каталогов LDAP, а также реляционные базы данных (PostgreSQL, MySQL, MS SQL Server).
💫 💫 (Consistency + Partition tolerance) – все узлы системы имеют одинаковые и актуальные данные, и система продолжает работать, даже если между узлами потеряно соединение. Однако, эти системы могут не отвечать на некоторые запросы. Устойчивость к разделению требует дублирования изменений во всех узлах системы.
Как это работает: система CP отрабатывает транзакцию только в том случае, если изменения удалось распространить по всем узлам. Система продолжает обрабатывать запросы даже при отказе одного из узлов. Но пока система не убедится в своей целостности и согласованности, запросы могут не обрабатываться или обрабатываться с задержкой.
Примеры хранилищ данных: Apache HBase, MongoDB, Redis.
💫 💫 (Availability + Partition tolerance) – все запросы получают ответ, и система продолжает работать, даже если между узлами потеряно соединение. Эти системы подходят для обработки данных, когда требуется высокая доступность, но можно претерпеть небольшие расхождения в данных. AP-система может быть представлена кластером из нескольких узлов, каждый из которых может принимать данные, но не обязуется в тот же момент распространять их на другие сервера. Такая система отлично справляется с отказами нескольких узлов, но возможна выдача пользователям старых данных. К AP-системам относят CoucheDB, Cassandra, Amazon DynamoDB.
Так как де-факто в распределённых системах сеть может пропадать, соответственно, приходится поддерживать устойчивость к разделению (P). Остаётся пойти на компромисс между согласованностью (C) и доступностью (A).
Применимость CAP-теоремы
Следует учитывать недостатки теоремы CAP. Большинство из них сводится к тому, что теорема CAP заставляет делать жесткий выбор между двумя из трех свойств, хотя на практике можно достичь различных компромиссов и гибридных решений. CAP не даёт метрик для измерения доступности или согласованности данных.
Основная ценность CAP-теоремы в том, что она поднимает вопрос о неизбежности компромиссов при проектировании распределённых систем. Необходимо осознанно выбирать, какие из принципов будут иметь приоритет, исходя из конкретных требований системы.
📎 Статьи по теме
1. CAP-теорема: принципы согласованности, доступности и устойчивости
2. CAP-теорема простым, доступным языком
3. Несколько фактов о CAP-«теореме»
4. CAP двенадцать лет спустя: как изменились «правила»
5. Всё, что вы не знали о CAP теореме
6. Мифы о CAP теореме
#проектирование
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
CAP-теорема – это утверждение о том, что в любой распределенной системе можно обеспечить выполнение только 2-х из 3-х следующих свойств:
1️⃣ Consistency (согласованность) – все узлы распределенной системы содержат актуальные и одинаковые данные в любой момент времени. Это свойство гарантирует, что любой запрос к системе вернет правильный и последний результат, независимо от того, к какому узлу он обращается.
2️⃣ Availability (доступность) – каждый запрос к системе возвращает результат. Без гарантий, что результат содержит последние данные. Даже если какие-то узлы выпали, система всё равно должна вернуть ответ.
3️⃣ Partition tolerance (устойчивость к разделению) – система продолжает работать даже при потере коммуникации между узлами. Например, если между двумя узлами отвалилась связь, то они продолжают работать независимо друг от друга.
Варианты сочетания свойств
Как это работает: система CP отрабатывает транзакцию только в том случае, если изменения удалось распространить по всем узлам. Система продолжает обрабатывать запросы даже при отказе одного из узлов. Но пока система не убедится в своей целостности и согласованности, запросы могут не обрабатываться или обрабатываться с задержкой.
Примеры хранилищ данных: Apache HBase, MongoDB, Redis.
Так как де-факто в распределённых системах сеть может пропадать, соответственно, приходится поддерживать устойчивость к разделению (P). Остаётся пойти на компромисс между согласованностью (C) и доступностью (A).
Применимость CAP-теоремы
Следует учитывать недостатки теоремы CAP. Большинство из них сводится к тому, что теорема CAP заставляет делать жесткий выбор между двумя из трех свойств, хотя на практике можно достичь различных компромиссов и гибридных решений. CAP не даёт метрик для измерения доступности или согласованности данных.
Основная ценность CAP-теоремы в том, что она поднимает вопрос о неизбежности компромиссов при проектировании распределённых систем. Необходимо осознанно выбирать, какие из принципов будут иметь приоритет, исходя из конкретных требований системы.
📎 Статьи по теме
1. CAP-теорема: принципы согласованности, доступности и устойчивости
2. CAP-теорема простым, доступным языком
3. Несколько фактов о CAP-«теореме»
4. CAP двенадцать лет спустя: как изменились «правила»
5. Всё, что вы не знали о CAP теореме
6. Мифы о CAP теореме
#проектирование
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26👍9❤5⚡1
Паттерны CQRS и Event Sourcing в микросервисной архитектуре
CQRS (Command and Query Responsibility Segregation) — это паттерн, который предлагает разделить операции чтения и записи на отдельные типы операций: Query (запросы) и Command (команды).
Query — операция, которая возвращает данные из хранилища, но не изменяют его. В HTTP Query соответствует метод GET.
Command — операция, которая изменяет состояние хранилища, но не возвращают данные. В HTTP Commands соответствуют методы POST/PUT/PATCH/DELETE.
Event Sourcing — паттерн хранения данных в виде последовательности событий. Идея в том, чтобы записывать в БД каждое событие, которое меняет состояние какой-либо сущности.
База данных, куда записываются события, называется event source. Данные в ней изменять нельзя, и, как правило, они записаны в денормализованном виде – специально, чтобы операция чтения выполнялась как можно быстрее.
Как CQRS и Event Sourcing работают вместе?
Организуем два хранилища данных:
💩 Первое – первоисточник данных. Используется в командах
💩 Второе – оптимизированное для чтения хранилище. Данные сюда сохраняются после выполнения команд.
Процесс при выполнении команд:
1. Микросервис получает команду, проверяет её валидность
2. Если команда валидна, микросервис выполняет команду и генерирует событие
3. Микросервис сохраняет событие в хранилище-первоисточник
4. Микросервис публикует событие в очередь сообщений, где его могут подписаться другие микросервисы
5. Каждый микросервис, который подписан на это событие, обновляет свое хранилище для чтения, применяя событие к своей проекции данных.
6. В хранилище для чтения получаем новый слепок состояния первоисточника данных
При обработке запросов
1. Микросервис получает запрос, который должен вернуть данные из системы.
2. Микросервис обращается к своему хранилищу для чтения (event source), и возвращает данные, не обращаясь к хранилищу для записи.
✅ Преимущества CQRS и Event Sourcing
💩 Независимое масштабирование. CQRS позволяет раздельно масштабировать нагрузки чтения и записи, снижая риски конфликтов
💩 Оптимизированные схемы данных. Для query можно применить схему, оптимизированную для запросов, а для command — другую схему, оптимизированную для изменений
💩 Безопасность. Разделение операций позволяет настроить более гибкую систему доступа.
💩 Восстановление состояния. С помощью Event Sourcing можно восстановить состояние системы на любой момент времени, откатить ошибочные операции или исправить поврежденные данные.
⛔️ Недостатки
💩 Сложность. Несмотря на простоту идеи, реализация CQRS + Event Sourcing может привести к усложнению проекта приложения, особенно если реализовывать его в связке с другими паттернами, такими как Domain-Driven Design, Saga, Eventual Consistency и т.д.
💩 Несогласованность данных. Из-за асинхронной природы обмена сообщениями, данные в хранилищах для чтения и записи могут быть не согласованы на некоторое время.
💩 Сложнее тестирование и отладка
📎 Статьи
1. Паттерны CQRS и Event Sourcing
2. Погружение в CQRS
3. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS: часть 1 и часть 2
4. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS
5. Сможет ли Event Sourcing перерасти базы данных?
#архитектура
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
CQRS (Command and Query Responsibility Segregation) — это паттерн, который предлагает разделить операции чтения и записи на отдельные типы операций: Query (запросы) и Command (команды).
Query — операция, которая возвращает данные из хранилища, но не изменяют его. В HTTP Query соответствует метод GET.
Command — операция, которая изменяет состояние хранилища, но не возвращают данные. В HTTP Commands соответствуют методы POST/PUT/PATCH/DELETE.
Event Sourcing — паттерн хранения данных в виде последовательности событий. Идея в том, чтобы записывать в БД каждое событие, которое меняет состояние какой-либо сущности.
База данных, куда записываются события, называется event source. Данные в ней изменять нельзя, и, как правило, они записаны в денормализованном виде – специально, чтобы операция чтения выполнялась как можно быстрее.
Как CQRS и Event Sourcing работают вместе?
Организуем два хранилища данных:
Процесс при выполнении команд:
1. Микросервис получает команду, проверяет её валидность
2. Если команда валидна, микросервис выполняет команду и генерирует событие
3. Микросервис сохраняет событие в хранилище-первоисточник
4. Микросервис публикует событие в очередь сообщений, где его могут подписаться другие микросервисы
5. Каждый микросервис, который подписан на это событие, обновляет свое хранилище для чтения, применяя событие к своей проекции данных.
6. В хранилище для чтения получаем новый слепок состояния первоисточника данных
При обработке запросов
1. Микросервис получает запрос, который должен вернуть данные из системы.
2. Микросервис обращается к своему хранилищу для чтения (event source), и возвращает данные, не обращаясь к хранилищу для записи.
✅ Преимущества CQRS и Event Sourcing
⛔️ Недостатки
📎 Статьи
1. Паттерны CQRS и Event Sourcing
2. Погружение в CQRS
3. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS: часть 1 и часть 2
4. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS
5. Сможет ли Event Sourcing перерасти базы данных?
#архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥6❤2👏2
Forwarded from Библиотека Системного Аналитика
Тарасенко_Ф_П_Прикладной_системный_анализ.pdf
6.4 MB
«Прикладной системный анализ»
Прикладной системный анализ
✍️ Автор: Ф.П. Тарасенко
🗓 Год издания: 2017
🔤 Язык: русский
📚 Объём: 321 стр.
Описание:
Книга считается классикой отечественной школы теории систем. Автор описывает базовые понятия системологии, необходимые для обоснования и изложения технологии системного анализа, а также рекомендует последовательность операций и методы преодоления трудностей при решении проблем различной природы. Книга содержит множество примеров, контрольных вопросов и заданий, а также ссылки на дополнительную литературу. Книга будет полезна всем тем, кто хотят научиться системному мышлению и применять его в своей деятельности.
#развитие
Прикладной системный анализ
✍️ Автор: Ф.П. Тарасенко
🗓 Год издания: 2017
🔤 Язык: русский
📚 Объём: 321 стр.
Описание:
Книга считается классикой отечественной школы теории систем. Автор описывает базовые понятия системологии, необходимые для обоснования и изложения технологии системного анализа, а также рекомендует последовательность операций и методы преодоления трудностей при решении проблем различной природы. Книга содержит множество примеров, контрольных вопросов и заданий, а также ссылки на дополнительную литературу. Книга будет полезна всем тем, кто хотят научиться системному мышлению и применять его в своей деятельности.
#развитие
👍31🔥13❤8
🆚 Сравнение JSON, XML и YAML
JSON, XML и YAML — это языки сериализации данных, то есть способы представления структурированных данных в виде текста. Сериализация данных позволяет обмениваться данными по API и не только, а также часто используется в качестве описания параметров конфигураций.
➖ JSON часто используется в веб-разработке и API благодаря простоте и эффективности парсинга.
➖ XML часто используется в легаси-системах, когда критически важна безопасность передаваемых данных. Может быть менее эффективным в обработке из-за сложной структуры.
➖ YAML менее популярен, но предпочтителен для конфигурационных файлов и удобочитаемых данных благодаря простоте и читаемости. На нём, кстати, составляется разметка Swagger для документации REST API.
Подготовили для вас более подробную сравнительную таблицу основных характеристик каждого формата. Надеемся, вам будет полезно.
В комментариях таблица без сжатия
#сравнение
JSON, XML и YAML — это языки сериализации данных, то есть способы представления структурированных данных в виде текста. Сериализация данных позволяет обмениваться данными по API и не только, а также часто используется в качестве описания параметров конфигураций.
Подготовили для вас более подробную сравнительную таблицу основных характеристик каждого формата. Надеемся, вам будет полезно.
В комментариях таблица без сжатия
#сравнение
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥45👍12❤9🥱2
🐳 Docker: Краткое описание и подборка материалов
Docker — это платформа для разработки, доставки и запуска приложений в контейнерах. Помогает развернуть множество контейнеров на одной хост-машине независимо от ее операционной системы.
Основные понятия
💩 Контейнер — изолированная среда, в которой запускаются приложения вместе со всеми зависимостями, включая библиотеки и компоненты, необходимые для работы приложения.
💩 Image (образ) — шаблон для создания контейнера, описывающий, что именно должно быть в контейнере. Образы можно создавать самостоятельно или загружать из репозиториев, таких как Docker Hub.
💩 Dockerfile — текстовый файл с инструкцией для создания образа (что должно находиться в образе, какие команды, зависимости и процессы он будет содержать)
💩 Registry (реестр/репозиторий) —удалённое (открытое / закрытое) хранилище образов. Docker Hub – публичное хранилище образов.
💩 Host — ОС, на которой работает Docker.
💩 Platform — программа, которая упаковывает и запускает приложения в контейнере. Собирает код и зависимости
💩 Volumes — хранилище данных для приложения.
💩 Docker Compose — инструмент для определения и запуска многоконтейнерных приложений с помощью YAML-файла. Docker Compose позволяет настроить параметры, такие как имя сервиса, образ, порты, тома, сети и зависимости между сервисами.
💩 Docker Swarm — режим работы Docker, в котором несколько хостов объединяются в кластер для управления и масштабирования контейнеров. Docker Swarm обеспечивает высокую доступность, балансировку нагрузки и обнаружение сервисов.
Архитектура Docker
Docker построен на клиент-серверной архитектуре. Docker-Client общается с Docker-Daemon, который создает, запускает, распределяет контейнеры. Клиент и сервер могут работать как на одной машине, так и удаленно. Интерфейс общения: Socket или REST API.
✏️ Примеры использования
➖ Работа с веб-приложением. К примеру, веб-приложение на PHP и нужно его запустить на своем компьютере. Вместо того, чтобы устанавливать PHP, веб-сервер и др. зависимости напрямую, можно использовать Docker для создания контейнера, в который упаковывается всё необходимое для работы веб-приложения.
Далее этот контейнер запускается на вашем компьютере и веб-приложение работает в изолированной среде, не требуя установки всех компонентов на операционной системе.
➖ Контейнеризация БД. Например, компания использует БД MongoDB для хранения данных. Чтобы облегчить управление и развертывание, администратор использует Docker для создания контейнера с MongoDB. Этот контейнер содержит необходимую версию MongoDB и все конфигурационные файлы. Это позволяет легко масштабировать, резервировать и обновлять базу данных с минимальными усилиями, а также обеспечивает изоляцию от других приложений и сервисов.
➖ Работа с микросервисами. Например, есть веб-приложение, состоящее из нескольких микросервисов: сервис авторизации, обработки заказов и управления пользователями.
Каждый микросервис может быть упакован в свой собственный Docker-контейнер:
один с Node.js для авторизации, другой с Python для обработки заказов и так далее.
Это облегчает масштабирование и управление каждым сервисом независимо.
✅ Преимущества
▫️Изоляция и безопасность: Docker помогает создавать изолированные среды для разработки и тестирования ПО без влияния на основную систему. Например, перенести приложение со всеми зависимостями на другую систему с помощью пары команд в терминале.
▫️Ускорение разработки: Docker позволяет быстро создавать и уничтожать контейнеры. Разработчики могут работать над приложением независимо от ОС
▫️Масштабируемость и отказоустойчивость: позволяет запускать одно приложение в нескольких контейнерах для повышения производительности. Для масштабирования используются платформы оркестрации: OpenShift, Kubernetes, Docker Swarm, Nomad, и тд
⛔️ Недостатки
◾️Повышенная потребность в вычислительных ресурсах
◾️Необходимость оркестрации для крупных приложений
◾️Сложности на Windows и macOS (так как изначально разработан для Linux)
Подборка материалов в следующем посте 👇
#инструменты
Docker — это платформа для разработки, доставки и запуска приложений в контейнерах. Помогает развернуть множество контейнеров на одной хост-машине независимо от ее операционной системы.
Основные понятия
Архитектура Docker
Docker построен на клиент-серверной архитектуре. Docker-Client общается с Docker-Daemon, который создает, запускает, распределяет контейнеры. Клиент и сервер могут работать как на одной машине, так и удаленно. Интерфейс общения: Socket или REST API.
✏️ Примеры использования
Далее этот контейнер запускается на вашем компьютере и веб-приложение работает в изолированной среде, не требуя установки всех компонентов на операционной системе.
Каждый микросервис может быть упакован в свой собственный Docker-контейнер:
один с Node.js для авторизации, другой с Python для обработки заказов и так далее.
Это облегчает масштабирование и управление каждым сервисом независимо.
✅ Преимущества
▫️Изоляция и безопасность: Docker помогает создавать изолированные среды для разработки и тестирования ПО без влияния на основную систему. Например, перенести приложение со всеми зависимостями на другую систему с помощью пары команд в терминале.
▫️Ускорение разработки: Docker позволяет быстро создавать и уничтожать контейнеры. Разработчики могут работать над приложением независимо от ОС
▫️Масштабируемость и отказоустойчивость: позволяет запускать одно приложение в нескольких контейнерах для повышения производительности. Для масштабирования используются платформы оркестрации: OpenShift, Kubernetes, Docker Swarm, Nomad, и тд
⛔️ Недостатки
◾️Повышенная потребность в вычислительных ресурсах
◾️Необходимость оркестрации для крупных приложений
◾️Сложности на Windows и macOS (так как изначально разработан для Linux)
Подборка материалов в следующем посте 👇
#инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19❤10👍5
Системный Аналитик
🐳 Docker: Краткое описание и подборка материалов Docker — это платформа для разработки, доставки и запуска приложений в контейнерах. Помогает развернуть множество контейнеров на одной хост-машине независимо от ее операционной системы. Основные понятия…
Подборка материалов по изучению Docker
Теория по Docker доступна в предыдущем посте.
🌐 Официальная документация Docker
📎 Статьи
1. О Докер с примером на пицце + серия статей
2. Кратко про Docker
3. Термины и концепции.
4. Как работает Docker
5. Подробнее о компонентах
6. Руководство по Docker: с нуля до кластера на AWS — для тех, кто хочет попробовать сам
7. Всегда ли нужны Docker, микросервисы и реактивное программирование?
8. Руководство по Docker Compose для начинающих
9. Про Docker Swarm
⏯ Видео
1. Пример. Экосистема контейнеров в Yandex.Cloud
2. Зачем нужен и как работает Docker
3. Практический курс Docker и Kubernetes
4. Коротко о Docker
5. Docker образы. Микросервисы — Демо-занятие курса «DevOps практики и инструменты»
6. Курс по Docker
Теория по Docker доступна в предыдущем посте.
🌐 Официальная документация Docker
📎 Статьи
1. О Докер с примером на пицце + серия статей
2. Кратко про Docker
3. Термины и концепции.
4. Как работает Docker
5. Подробнее о компонентах
6. Руководство по Docker: с нуля до кластера на AWS — для тех, кто хочет попробовать сам
7. Всегда ли нужны Docker, микросервисы и реактивное программирование?
8. Руководство по Docker Compose для начинающих
9. Про Docker Swarm
1. Пример. Экосистема контейнеров в Yandex.Cloud
2. Зачем нужен и как работает Docker
3. Практический курс Docker и Kubernetes
4. Коротко о Docker
5. Docker образы. Микросервисы — Демо-занятие курса «DevOps практики и инструменты»
6. Курс по Docker
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍11
Сначала рекомендуем изучить пост про Docker
Kubernetes — платформа с открытым исходным кодом для управления приложениями в контейнерах. Kubernetes позволяет автоматизировать развёртывание, масштабирование и координацию приложений в условиях кластера — набора физических или виртуальных машин, на которых запускаются контейнеры.
Kubernetes активно используется в микросервисной архитектуре, так как он предоставляет необходимые абстракции и механизмы для оркестровки контейнеров, в которых развёртываются микросервисы.
Основные понятия
Главные функции K8s
1️⃣ Централизованное управление (оркестровка) контейнерами. Kubernetes автоматически управляет жизненным циклом контейнеров от развёртывания до откатов обновлений.
2️⃣ Распределение нагрузки и масштабирование кластера. Kubernetes распределяет контейнеры по узлам так, чтобы они не тратили лишние ресурсы. Если нагрузка на систему растёт, Kubernetes может автоматически добавлять контейнеры и узлы.
3️⃣ Управление конфигурациями. В Kubernetes есть средство для центрального управления конфигурациями — ConfigsMaps для настроек и Secrets для конфиденциальных данных. Если разместить в них свои настройки, то приложения смогут получить к ним доступ из любого узла.
Kubernetes 🆚 Docker
🔸 Docker — инструмент для создания и запуска контейнеров. Docker работает в рамках отдельных узлов. Если у вас несколько узлов, то на каждом из них запущен докер-демон, который ничего не знает о существовании других узлов. Каждый демон знает лишь о том, что происходит на его узле.
🔹 Kubernetes — оркестратор, инструмент для управления контейнерами. Kubernetes позволяет построить кластер — распределенную отказоустойчивую систему, в то время как Docker работает на отдельном узле. В кластере может быть много узлов, контейнеров и настроек, но всеми ими можно управлять через единый сервер. В кластер можно, например, отправить команду на обновление приложения, и Kubernetes сам найдет, на каких узлах оно находится, и обновит его.
Ещё есть Docker Swarm — встроенный в докер инструмент оркестровки контейнеров. Его как как раз и можно полноценно сравнивать с Kubernetes.
✅ Преимущества Kubernetes
▫️Масштабируемость. Kubernetes позволяет горизонтально масштабировать приложения, добавляя или удаляя поды в зависимости от нагрузки. Kubernetes также поддерживает вертикальное масштабирование, изменяя выделенные ресурсы для подов.
▫️Надежность. Kubernetes обеспечивает высокую доступность приложений, перезапуская поды в случае сбоя. Kubernetes поддерживает стратегии бесперебойного обновления, которые позволяют внедрять новые версии приложений без простоя.
▫️Эффективность. Kubernetes позволяет оптимально распределять поды по доступным узлам. Kubernetes автоматически управляет ресурсами и позволяет задавать ограничения и приоритеты для подов.
⛔️ Недостатки Kubernetes
◾️Сложность. Kubernetes сложно изучать, настраивать и поддерживать, требуются дополнительные инструменты и процессы для работы приложений.
◾️Необходимость адаптации приложений. Kubernetes требует, чтобы приложения соответствовали определенным правилам и практикам. Это может потребовать изменения или создания приложений с нуля.
◾️Высокие требования к ресурсам. Kubernetes занимает много ресурсов. Это может снизить производительность или увеличить стоимость приложений.
Подборка материалов в следующем посте👇
#инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍4❤3
Конспект по Kubernetes доступен в предыдущем посте.
🌐 Официальная документация
1. Про Docker
2. Виртуализация, контейнеризация и оркестрация
🗒 Статьи (теория)
1. Кратко о Kubernetes
2. Kubernetes — основные понятия
3. Про возможности Kubernetes в сравнении с Docker
4. Подробнее про компоненты Kubernetes
5. Внутреннее устройство Kubernetes-кластера простым языком
6. Kubernetes: большой обзор технологии, установка и настройка
7. Docker Swarm vs Kubernetes
📝 Практика
1. Инструкция по установке и настройке Kubernetes на Ubuntu
2. Подробный гайд для новичков по установке Kubernetes
3. Попробовать потыкать Kubernetes на тестовом кластере
4. Визуальное руководство по диагностике неисправностей в Kubernetes
5. Шеринг GPU в Kubernetes с помощью MIG и TimeSlicing
6. Гайд по запуску приложений с высокой доступностью (HA) в Kubernetes
7. 10 типичных ошибок при использовании Kubernetes
💼 Кейсы по компаниям из цикла статей на Хабре
1. 4200 подов и TessMaster у eBay
2. Concur и SAP
3. GitHub
4. SoundCloud
5. Цифровой банк Monzo
6. BlaBlaCar
7. BlackRock
8. Huawei
9. ЦЕРН и 210 кластеров K8s
10. Reddit
1. Курс по Kubernetes с нуля
2. Что такое Kubernetes за 9 минут
3. 49 видеоуроков по Kubernetes
4. Открытая вечерняя школа. Kubernetes для разработчиков
5. Практика по Kubernetes — серия уроков
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍10❤4
Ждём ваших идей
2023-й стал для канала годом расцвета — преодолена отметка в 5000 подписчиков.
Никогда не рассчитывал на такое число. Канал начинался 2 года назад исключительно как личный канал, куда я писал конспекты в качестве подготовки к собеседованиям. Получив желаемую вакансию, я перестал публиковать что-либо, но с удивлением обнаружил, что сами собой возникают подписчики. Так за 2 года набралось 200+ человек.
В августе этого года решил начать на регулярной основе публиковать краткие конспекты и подборки полезных материалов для системных аналитиков. Корыстный мотив (а он есть) не был для меня главным — это отличный способ заставить себя развиваться самому, хоть что-то изучать. В качестве среднесрочной цели хотелось бы иметь исчерпывающий список материалов по главным навыкам аналитика.
Ведение канала занимает очень много времени и сил. Недавно нашёл соавтора, стало полегче, но работы всё равно больше, чем возможностей :)
В комментариях к этому посту можете оставить свои пожелания по поводу тем публикаций. Постараемся в ближайшее время сделать посты по вашим запросам.
Во время праздников полноценных подборок не будет. Это время лучше посвятить отдыху и близким, а также можно сделать то, на что многие из нас не находят сил и времени — почитать профессиональную литературу. 1 января выйдет большая подборка книг со ссылками на скачивание.
А пока приглашаем вас в комментарии. Ставьте цели, развивайтесь, отдыхайте, любите и радуйтесь — пусть 2024-й даст всем нам возможности, а с остальным мы справимся!
P.S. критика в комментах тоже приветствуется
2023-й стал для канала годом расцвета — преодолена отметка в 5000 подписчиков.
Никогда не рассчитывал на такое число. Канал начинался 2 года назад исключительно как личный канал, куда я писал конспекты в качестве подготовки к собеседованиям. Получив желаемую вакансию, я перестал публиковать что-либо, но с удивлением обнаружил, что сами собой возникают подписчики. Так за 2 года набралось 200+ человек.
В августе этого года решил начать на регулярной основе публиковать краткие конспекты и подборки полезных материалов для системных аналитиков. Корыстный мотив (а он есть) не был для меня главным — это отличный способ заставить себя развиваться самому, хоть что-то изучать. В качестве среднесрочной цели хотелось бы иметь исчерпывающий список материалов по главным навыкам аналитика.
Ведение канала занимает очень много времени и сил. Недавно нашёл соавтора, стало полегче, но работы всё равно больше, чем возможностей :)
В комментариях к этому посту можете оставить свои пожелания по поводу тем публикаций. Постараемся в ближайшее время сделать посты по вашим запросам.
Во время праздников полноценных подборок не будет. Это время лучше посвятить отдыху и близким, а также можно сделать то, на что многие из нас не находят сил и времени — почитать профессиональную литературу. 1 января выйдет большая подборка книг со ссылками на скачивание.
А пока приглашаем вас в комментарии. Ставьте цели, развивайтесь, отдыхайте, любите и радуйтесь — пусть 2024-й даст всем нам возможности, а с остальным мы справимся!
P.S. критика в комментах тоже приветствуется
❤76🔥34👍7🎉4👏2👎1
📚 Подборка книг для развития системного аналитика
Новогодние праздники — прекрасное время, чтобыотдохнуть почитать профессиональную литературу, что постоянно откладывалось на потом.
Будет очень круто, если вы будете оставлять отзывы о книгах из этого списка, которые вы прочитали.
Требования
📖 Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению
📖 Алистер Коберн. Современные методы описания функциональных требований к системам
📖 Дин Леффингуэлл. Принципы работы с требованиями к программному обеспечению
📖 Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО
📖 Халл Элизабет. Инженерия требований
📖 Юрий Химонин. Сбор и анализ требований к программному продукту
Архитектура и проектирование
📕 Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения
📕 Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📕 Вон Вернон. Реализация методов предметно ориентированного проектирования (DDD)
📕 Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
📕 Сэм Ньюмен. Создание микросервисов
📕 Беллемар Адам. Создание событийно-управляемых микросервисов
📕 C. Cомасегар. Руководство Microsoft по проектированию архитектуры приложений
Проектирование
📒 Александр Швец. Погружение в Паттерны Проектирования
📒 System Design. Подготовка к сложному интервью
📒 Мартин Фаулер. P of EAA: Шаблоны корпоративных приложений
Интеграции
📗 Грегор Хоп и Бобби Вульф. Шаблоны интеграции корпоративных приложений
📗 Джей Гивакс. Паттерны проектирования API
📗 Арно Лоре. Проектирование веб-API
📗 Сергей Константинов. API
📗 Дилан Скотт. Kafka в действии
📗 Ian Robinson. REST in Practice: Hypermedia and Systems Architecture
📗 Emil Koutanov. Effective Kafka
Своды знаний
📔 SEBoK — Systems Engineering Body of Knowledge
📔 BABOK — Business Analysis Body Of Knowledge
📔 INCOSE Guide for Writing Requirements
📔 DAMA-DMBOK — Data Management Body of Knowledge
Навыки
📓 Ф.П. Тарасенко. Прикладной системный анализ
📓 Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке
📓 Алан Купер. Психбольница в руках пациентов
📓 Карл Андерсон. Аналитическая культура
📓 Вера Иванова. Путь аналитика. Практическое руководство
📓 Максим Ильяхов и Людмила Сарычева. Пиши, сокращай: Как создавать сильный текст
📓 Роберт Фитцпатрик. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?
📓 Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы
UML
💣 Мартин Фаулер. UML. Основы
💣 Буч Грэди. Язык UML. Руководство пользователя
💣 Дж. Шмуллер. Освой самостоятельно UML за 24 часа
💣 Крэг Ларман. Применение UML и шаблонов проектирования
💣 Джим Арлоу. UML 2 и Унифицированный процесс
💣 М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка
💣 Александр Леоненков. Самоучитель UML
Python
🐍 Эрик Мэтиз. Изучаем Python: программирование игр, визуализация данных, веб-приложения
🐍 Пол Бэрри. Изучаем программирование на Python
🐍 Эл Свейгарт. Автоматизация рутинных задач с помощью Python
🐍 Марк Лутц. Python. Карманный справочник
🐍 Аллен Б. Дауни. Основы Python. Научитесь думать как программист
Эта навигация будет дополняться в Библиотеке Системного Аналитика
#подборка
Новогодние праздники — прекрасное время, чтобы
Будет очень круто, если вы будете оставлять отзывы о книгах из этого списка, которые вы прочитали.
Требования
📖 Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению
📖 Алистер Коберн. Современные методы описания функциональных требований к системам
📖 Дин Леффингуэлл. Принципы работы с требованиями к программному обеспечению
📖 Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО
📖 Халл Элизабет. Инженерия требований
📖 Юрий Химонин. Сбор и анализ требований к программному продукту
Архитектура и проектирование
📕 Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения
📕 Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📕 Вон Вернон. Реализация методов предметно ориентированного проектирования (DDD)
📕 Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
📕 Сэм Ньюмен. Создание микросервисов
📕 Беллемар Адам. Создание событийно-управляемых микросервисов
📕 C. Cомасегар. Руководство Microsoft по проектированию архитектуры приложений
Проектирование
📒 Александр Швец. Погружение в Паттерны Проектирования
📒 System Design. Подготовка к сложному интервью
📒 Мартин Фаулер. P of EAA: Шаблоны корпоративных приложений
Интеграции
📗 Грегор Хоп и Бобби Вульф. Шаблоны интеграции корпоративных приложений
📗 Джей Гивакс. Паттерны проектирования API
📗 Арно Лоре. Проектирование веб-API
📗 Сергей Константинов. API
📗 Дилан Скотт. Kafka в действии
📗 Ian Robinson. REST in Practice: Hypermedia and Systems Architecture
📗 Emil Koutanov. Effective Kafka
Своды знаний
📔 SEBoK — Systems Engineering Body of Knowledge
📔 BABOK — Business Analysis Body Of Knowledge
📔 INCOSE Guide for Writing Requirements
📔 DAMA-DMBOK — Data Management Body of Knowledge
Навыки
📓 Ф.П. Тарасенко. Прикладной системный анализ
📓 Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке
📓 Алан Купер. Психбольница в руках пациентов
📓 Карл Андерсон. Аналитическая культура
📓 Вера Иванова. Путь аналитика. Практическое руководство
📓 Максим Ильяхов и Людмила Сарычева. Пиши, сокращай: Как создавать сильный текст
📓 Роберт Фитцпатрик. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?
📓 Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы
UML
Python
Эта навигация будет дополняться в Библиотеке Системного Аналитика
#подборка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥123👍21❤18⚡2
Подписка на закрытый канал для системных аналитиков
Новые подборки полезных материалов теперь будут публиковаться в закрытом канале, который будет доступен по подписке.
Оформить подписку можно через кнопки ниже:
1. Нажимаете на кнопку с выбранным тарифом
2. Бот Donate присылает ссылку на оплату
3. После оплаты вам будет предоставлен доступ к закрытому каналу. Ссылки на чаптер системных аналитиков и канал с тестовыми заданиями будут в описании закрытого канала.
Что будет входить в подписку:
➖ 2-3 подборки материалов каждую неделю в закрытом канале
➖ навигация по всем материалам
➖ коммьюнити подписчиков — обмен опытом и общение
➖ доступ к каналу с тестовыми заданиями из собеседований
➖ тесты для самопроверки
➖ (скоро) обновляемая база знаний по ключевым темам системного анализа
➖ (скоро) исчерпывающая интерактивная карта навыков системного аналитика со ссылками на материалы из базы знаний
Тарифы:
💩 350 ₽ — месяц
💩 3400 ₽ — год (283 р/мес)
Что будет с текущим каналом?
Все уже опубликованные материалы в текущем канале (Системный Аналитик) останутся бесплатными. Однако новые материалы будут выходить реже:
— 2-3 полноценные подборки в месяц
— 1-2 конспекта по темам системного анализа еженедельно
— 1 книга каждую неделю
Текущие цены действуют для первых 50-ти подписчиков.
Новые подборки полезных материалов теперь будут публиковаться в закрытом канале, который будет доступен по подписке.
Оформить подписку можно через кнопки ниже:
1. Нажимаете на кнопку с выбранным тарифом
2. Бот Donate присылает ссылку на оплату
3. После оплаты вам будет предоставлен доступ к закрытому каналу. Ссылки на чаптер системных аналитиков и канал с тестовыми заданиями будут в описании закрытого канала.
Что будет входить в подписку:
Тарифы:
Что будет с текущим каналом?
Все уже опубликованные материалы в текущем канале (Системный Аналитик) останутся бесплатными. Однако новые материалы будут выходить реже:
— 2-3 полноценные подборки в месяц
— 1-2 конспекта по темам системного анализа еженедельно
— 1 книга каждую неделю
Текущие цены действуют для первых 50-ти подписчиков.
Please open Telegram to view this post
VIEW IN TELEGRAM
💩140👍45😢23👎15😁7🔥5🥱5😐4🎉2🤔1
💠 Микрофронтенды – разбираем, что это такое
Микрофронтенды – это применение принципов микросервисного подхода к разработке фронтенда, при котором монолитный фронт разбивается на независимые части.
Идея микрофронтендов заключается в том, что монолитный фронт разбивается на куски, которые разрабатывают отдельные команды. Каждый кусок отвечает за определенный функционал и представляет собой отдельное веб-приложение, которое находится в отдельном репозитории. Это позволяет выстроить полноценную вертикаль релиза от бэка до фронта разными командами и на разных технологиях. При этом внешне для конечного пользователя ничего не меняется: все части фронта интегрируется друг с другом через общий интерфейс.
✏️ Пример использования
Допустим, у вас есть монолитное веб-приложение для электронной коммерции, которое включает каталог товаров, корзину, профили пользователей и систему оплаты. Мы решаем перейти на микрофронтенд-архитектуру, чтобы повысить гибкость и ускорить разработку.
Разделяем функциональность приложения на несколько микрофронтендов:
➖ Каталог товаров: отвечает за отображение списка товаров, фильтрацию и сортировку.
➖ Корзина: обрабатывает добавление товаров в корзину и оформление заказа.
➖ Профили пользователей: Отображает персональную информацию и историю заказов.
➖ Система оплаты: обрабатывает оплату заказов.
✅ Преимущества микрофронтендов
💩 Сокращение времени до релиза (time-to-market). Так как команды могут релизить свои части независимо от других, это ускоряет процесс доставки нового функционала.
💩 Гибкость и скорость разработки. Команды могут выбирать технологии, которые лучше подходят для их задач, и не зависеть от ограничений монолита.
💩 Разделение ответственности. Каждая команда будет отвечать за один или несколько микрофронтендов. Каждый микрофронтенд будет находиться в отдельном репозитории, что позволят вести его независимую разработку, развёртывание и тестирование. Команды не будут завязаны на релизный цикл друг друга.
💩 Масштабируемость. Микрофронтенды позволяют оптимизировать загрузку и исполнение кода, так как каждая часть загружается и выполняется только тогда, когда нужна.
⛔️ Недостатки микрофронтендов
💩 Сложность и накладные расходы. Микрофронтенды требуют большего усилия и ресурсов для разработки и поддержки, так как необходимо обеспечить согласованность и совместимость между разными частями. Также они вводят дополнительную сложность в виде интеграции, координации и мониторинга частей.
💩 Необходимость согласования и совместимости между разными технологиями и командами. Если мы захотим в мире микрофронтендов поменять брендовый цвет с оранжевого на красный, то нам нужно будет попросить все команды изменить этот цвет у себя в компонентах, а в монолите на это ушло бы минут 20.
💩 Дублирование кода. В микрофронтендах сложнее переиспользовать код. Конечно, есть решения: сделать библиотеку компонентов, вынести все утилиты в одно место, написать шаблоны, Но всё равно встречаются места, которые идентичны во всех проектах (например, конфиг) и когда наступит время это править, может быть больно.
Подборка материалов по микрофронтендам доступна в базе знаний по системному анализу
#архитектура
Микрофронтенды – это применение принципов микросервисного подхода к разработке фронтенда, при котором монолитный фронт разбивается на независимые части.
Идея микрофронтендов заключается в том, что монолитный фронт разбивается на куски, которые разрабатывают отдельные команды. Каждый кусок отвечает за определенный функционал и представляет собой отдельное веб-приложение, которое находится в отдельном репозитории. Это позволяет выстроить полноценную вертикаль релиза от бэка до фронта разными командами и на разных технологиях. При этом внешне для конечного пользователя ничего не меняется: все части фронта интегрируется друг с другом через общий интерфейс.
✏️ Пример использования
Допустим, у вас есть монолитное веб-приложение для электронной коммерции, которое включает каталог товаров, корзину, профили пользователей и систему оплаты. Мы решаем перейти на микрофронтенд-архитектуру, чтобы повысить гибкость и ускорить разработку.
Разделяем функциональность приложения на несколько микрофронтендов:
✅ Преимущества микрофронтендов
⛔️ Недостатки микрофронтендов
Подборка материалов по микрофронтендам доступна в базе знаний по системному анализу
#архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
👍29🔥8💩7😐2
Forwarded from Библиотека Системного Аналитика
Designing_APIs_with_Swagger_and_OpenAPI_Ponelat_Rosenstock_Manning.pdf
17.7 MB
Designing APIs with Swagger and OpenAPI
✍️ Автор: Joshua S. Ponelat
🗓 Год издания: 2022
🔤 Язык: английский
📚 Объём: 424 стр.
Книга представляет подход, основанный на проектировании. Написанная для разработчиков, только начинающих проектировать API, она прослеживает жизненный цикл проекта API от концепции до производства. Вы получите практический опыт проектирования API для конкретных бизнес-потребностей, использования инструментов с открытым исходным кодом для создания документации и создания удобных для разработчиков компонентов, таких как макеты и клиентские SDK.
Если у кого вдруг есть на русском, поделитесь, пожалуйста)
#интеграции #api
✍️ Автор: Joshua S. Ponelat
🗓 Год издания: 2022
🔤 Язык: английский
📚 Объём: 424 стр.
Книга представляет подход, основанный на проектировании. Написанная для разработчиков, только начинающих проектировать API, она прослеживает жизненный цикл проекта API от концепции до производства. Вы получите практический опыт проектирования API для конкретных бизнес-потребностей, использования инструментов с открытым исходным кодом для создания документации и создания удобных для разработчиков компонентов, таких как макеты и клиентские SDK.
Если у кого вдруг есть на русском, поделитесь, пожалуйста)
#интеграции #api
🔥22👍14
Системный Аналитик pinned «Подписка на закрытый канал для системных аналитиков Новые подборки полезных материалов теперь будут публиковаться в закрытом канале, который будет доступен по подписке. Оформить подписку можно через кнопки ниже: 1. Нажимаете на кнопку с выбранным тарифом…»
🔎 Elasticsearch: краткое описание и подборка материалов
Elasticsearch (ES) — это распределенный поисковой и аналитический движок, построенный на основе Apache Lucene. Предоставляет открытый и гибкий интерфейс для хранения, поиска и анализа данных в реальном времени. Условно говоря, ES — это документоориентированная NoSQL БД и гугл одновременно.
Elasticsearch является частью стека ELK (Elasticsearch, Logstash и Kibana).
💩 Logstash собирает, обрабатывает и передает данные из различных источников в хранилище, такое как ES. Поддерживает различные источники данных и форматы логов.
💩 Elasticsearch индексирует и анализирует собранные данные и производит поиск в них.
💩 Kibana предназначена для работы с логами, поддерживает гибкий и сложный поиск по логам. Так же в Kibana можно строить дашборды, отчёты и визуализировать данные.
💩 Также есть Beats — легковесные агенты для отправки логов в ES. Они более примитивны, чем Logstash, т.к. только собирают и отправляют данные, без преобразований
Архитектура Elasticsearch распределенная:
1. Данные хранятся в виде JSON-документов
2. Эти документы индексируются для быстрого поиска
3. Каждый индекс разбивается на шарды для распределения их по узлам кластера, что позволяет балансировать нагрузку.
Кластер состоит из одного или нескольких узлов, объединенных в единое целое для совместной работы.
Как работает ES?
1. Данные отправляются в ES в виде документов JSON с помощью API или инструментов приема, например, Logstash.
2. ES автоматически сохраняет исходный документ и добавляет ссылку на него в индекс кластера, включая возможность поиска.
3. Следом можно найти и извлечь документ, используя API Elasticsearch.
4. Также для визуализации данных и создания интерактивных панелей управления можно задействовать Kibana.
🔨Применение ES
— Мониторинг и логирование. Хранение, поиск и анализ логов для отслеживания работы приложений, системы, серверов .
— Аналитика и BI. Поиск, фильтрация, агрегация, анализ больших объемов данных в реальном времени для выявления паттернов, создания отчетов. Например, компании в финансовой сфере используют ES для анализа данных о транзакциях, инвестициях и рынке
— Поисковые системы. Используется для быстрого и точного поиска. Например, платформы соцсетей используют ES для быстрого поиска, фильтрации и сортировки контента. Или интернет-магазины для поиска товаров. Также у ES есть возможность поиска и анализа данных на основе геолокации.
✅Преимущества ES
💩 Быстрый поиск и агрегация данных. Обеспечивает мгновенный доступ к данным и эффективный поиск за счет распределенной архитектуры, индексации и возможности добавлять новые узлы в кластер
💩 Отказоустойчивость. Достигается благодаря распределению данных и запросов между различными узлами кластера и шардами. В случае проблем ES автоматически восстанавливает реплики и данные.
💩 Масштабируемость и гибкость. ES можно масштабировать горизонтально без потери производительности. Кластеры ES могут расширяться и сжиматься в зависимости от потребностей с помощью добавления новых узлов.
💩 Экосистема ELK: входит в стек ELK, предоставляя комплексное решение для обработки, хранения и визуализации данных.
⛔️Недостатки ES
💩 Сложность конфигурации. Настройка и управление ES может быть сложным для новичков, т.к. содержит множество параметров и настроек.
💩 Управление ресурсами. Управление памятью, диском и другими ресурсами может быть сложным из-за использования обратных индексов Неоптимальная конфигурация может привести к недостаточной производительности.
⭐️ Подборка материалов по Elasticsearch доступна в базе знаний по системному анализу
#инструменты
Elasticsearch (ES) — это распределенный поисковой и аналитический движок, построенный на основе Apache Lucene. Предоставляет открытый и гибкий интерфейс для хранения, поиска и анализа данных в реальном времени. Условно говоря, ES — это документоориентированная NoSQL БД и гугл одновременно.
Elasticsearch является частью стека ELK (Elasticsearch, Logstash и Kibana).
Архитектура Elasticsearch распределенная:
1. Данные хранятся в виде JSON-документов
2. Эти документы индексируются для быстрого поиска
3. Каждый индекс разбивается на шарды для распределения их по узлам кластера, что позволяет балансировать нагрузку.
Кластер состоит из одного или нескольких узлов, объединенных в единое целое для совместной работы.
Как работает ES?
1. Данные отправляются в ES в виде документов JSON с помощью API или инструментов приема, например, Logstash.
2. ES автоматически сохраняет исходный документ и добавляет ссылку на него в индекс кластера, включая возможность поиска.
3. Следом можно найти и извлечь документ, используя API Elasticsearch.
4. Также для визуализации данных и создания интерактивных панелей управления можно задействовать Kibana.
🔨Применение ES
— Мониторинг и логирование. Хранение, поиск и анализ логов для отслеживания работы приложений, системы, серверов .
— Аналитика и BI. Поиск, фильтрация, агрегация, анализ больших объемов данных в реальном времени для выявления паттернов, создания отчетов. Например, компании в финансовой сфере используют ES для анализа данных о транзакциях, инвестициях и рынке
— Поисковые системы. Используется для быстрого и точного поиска. Например, платформы соцсетей используют ES для быстрого поиска, фильтрации и сортировки контента. Или интернет-магазины для поиска товаров. Также у ES есть возможность поиска и анализа данных на основе геолокации.
✅Преимущества ES
⛔️Недостатки ES
⭐️ Подборка материалов по Elasticsearch доступна в базе знаний по системному анализу
#инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
👍34🔥10❤9👎2
Forwarded from Библиотека Системного Аналитика
Please open Telegram to view this post
VIEW IN TELEGRAM