Автономные системы и микросервисы

Автономные системы (𝗦𝗲𝗹𝗳-𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗱 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 или 𝗦𝗖𝗦) представляют подход к архитектуре программного обеспечения, который отдает приоритет децентрализации приложений в независимые системы,
каждая из которых имеет свою доменную логику, пользовательский интерфейс и хранилище данных. В отличие от микросервисов, которые являются более мелкими сервисами, ориентированными исключительно на
бизнес-логику, SCS более значительна и охватывает более широкую область в пределах определенного домена.
SCS — это системы, представляющие автономные веб-приложения. Они включают веб-интерфейс, бизнес-логику и базу данных, а также могут иметь API-интерфейс сервиса. Обычно ими управляет одна команда.

Основными преимуществами таких систем являются:

𝟭. Автономность - Каждая SCS работает независимо со своей базой данных, бизнес-логикой и пользовательским интерфейсом.
𝟮. Упорядочение доменов - SCS структурирована вокруг конкретных бизнес-доменов, гарантируя, что каждое подразделение представляет собой согласованный и значимый набор функций.
𝟯. Децентрализованное управление данными - Отдельные базы данных в каждой SCS обеспечивают согласованность данных в пределах своих границ, снижая межсервисные зависимости.
𝟰. Технологическая разнородность - Позволяет использовать различные технологические стеки в других SCS, отвечая конкретным потребностям каждого домена.
𝟱. Общедоступный API - Четко определенные интерфейсы для взаимодействия с другими системами, поддерживающие четкий контракт и сохраняющие инкапсуляцию.
𝟲. Независимое развертывание - Каждую SCS можно развертывать, масштабировать и обновлять независимо, не влияя на другие системы.

Такие системы хорошо сочетаются с доменным дизайном (𝗗𝗼𝗺𝗮𝗶𝗻-𝗱𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝘀𝗶𝗴𝗻 или 𝗗𝗗𝗗).
Первым шагом в создании таких систем является анализ домена, который можно провести путем выявления ограниченных контекстов, соответствующих конкретным бизнес-доменам.
Каждый ограниченный контекст затем инкапсулируется в SCS, которая включает в себя собственное управление данными, бизнес-логику и пользовательский интерфейс, гарантируя, что каждая система является автономной, но при этом способна взаимодействовать с другими через четко определенные API при необходимости.

Почему автономные системы имеют преимущество перед микросервисами:

🔹 SCS имеет более широкую область применения, охватывающую пользовательский интерфейс, бизнес-логику и хранение данных в ограниченном контексте.
🔹 Снижение сложности управления: Микросервисы могут привести к высокой сложности эксплуатации из-за управления множеством более мелких, взаимозависимых сервисов, в то время как SCS более значим и автономен.
🔹 Последовательность данных. SCS управляет своими данными, что обеспечивает лучшую согласованность данных в каждой системе, в то время как микросервисы часто полагаются на общее хранилище данных.
🔹 Меньшая коммуникация между сервисами. SCS, инкапсулируя больше функциональности, требует меньше межсервисного взаимодействия, чем микросервисы.

(Иллюстрация к предыдущему посту - монолит vs микросервисы vs автономные системы)

Как работают каналы (pipes) в Linux #linux
Каналы осуществляюь межпроцессное взаимодействие путем отправки данных из вывода одного процесса (stdout) на ввод другого (stdin).
Существуют односторонние каналы, где данные передаются в одном направлении — от писателя (генератора данных) к читателю (потребителю данных).
Концептуальный поток: Процесс A (stdout) → [КАНАЛ] → (stdin) Процесс B

Некоторые типы каналов
1) Анонимные каналы
Представляют временный, односторонний канал связи между двумя связанными процессами.
Являются односторонними: Данные передаются в одном направлении.
Область видимости: Существует только во время выполнения процессов.
Создание: Создается программно с помощью системного вызова pipe() или неявно с помощью оператора | в командной строке.
Использование: Обычно используется для объединения команд в конвейер.

ПРимер создания канала:
$ cat file.txt | grep "keyword" | wc -l

Здесь cat читает файл. Вывод фильтруется grep.
Отфильтрованные строки подсчитываются с помощью wc.

2)Именованные каналы или Named Pipes (Также известны как FIFO (First In, First Out))
Представляют постоянный канал связи, который существует как специальный файл в файловой системе, позволяющий несвязанным процессам общаться.
Являются односторонними: Как в анонимных каналах, данные передаются в одном направлении.
Постоянство: Остается в файловой системе до явного удаления.
Создание: Создается с помощью команд mkfifo или mknod.
Область видимости: Может быть доступен через разные сеансы или несвязанные процессы.

Создание именованного канала:
$ mkfifo my_pipe

Запись в канал:
$ echo "Hello, World!" > my_pipe &

Считывание из канала:
$ cat < my_pipe


Важные примечания:
Анонимные каналы идеальны для простых, временных задач, таких как объединение команд.
Именованные каналы лучше подходят для сложных рабочих процессов, требующих межпроцессного взаимодействия между несвязанными процессами или сеансами.

(Иллюстрация к предыдущему посту - Как работают каналы в Linux)

Зависимости основных сетевых протоколов

Дорожная карта для изучения технологий по работе с данными #database

Компоненты MAC-адреса

15 апреля 2025 года состоялся релиз Fedora Linux 42 (c GNOME 48/KDE Plasma 6.3, ядро Linux 6.14, Golang 1.24, LLVM 20, GCC 15, PHP 8.4, Ruby 3.4, GNU Binutils 2.44, GNU C Library 2.41, GDB 15, Tcl/Tk 9.0, IBus 1.5.32, Haskell GHC 9.8, Stackage 23, Django 5.x и Ansible 11), включая сборки Server и Workstation для архитектуры x86_64, Power64 и ARM64 (AArch64).
Сборка Fedora Workstation теперь включает долгожданный установщик Anaconda WebUI по умолчанию, а сборка Fedora KDE Plasma Desktop получила статуса базовой редакции дистрибутива, идентичной по уровню поддержки с Fedora Workstation
Рабочий стол в Fedora Workstation обновлён до ветки GNOME 48. Обновлены рабочие столы Xfce 4.20 и LXQt 2.1. Объединено содержимое каталогов /usr/bin и /usr/sbin. Добавлены новые группы flatpak и diskadmin для обеспечения доступа непривилегированных пользователей к функциям управления системными пакетами
Подробнее все изменения: https://fedoramagazine.org/announcing-fedora-linux-42/

Начато добавление материалов про созданию графических приложений на Vulkan на языке программирования С++
https://metanit.com/cpp/vulkan/1.1.php
#cpp

Шпаргалка по сегментации памяти

Краткая шпаргалка по наиболее распространенным командам в Linux #linux

Наглядно процесс разрешения DNS

Вышла новая версия Ubuntu - 25.04 "Plucky Puffin" (перевод - Отважный Тупик) на базе ядра Linux 6.14 и рабочего окружения GNOME 48.
Эта версия является промежуточной (не LTS) и будет поддерживаться до января 2026 года.
В новой версии разработчики найдут новые версии технологий и языков прогарммирования - GCC 15 (снапшот будущего релиза), LLVM 20, Python 3.13.3, Go 1.24, Rust 1.84,.NET 9.0, PHP 8.4, Ruby 3.3, OpenJDK 24, PostgreSQL 17, Valkey (форк Redis) 8.0.2, MySQL 8.4.4, Qt 6.8.3
Ряд других изменений:
ядро Linux обновлено до выпуска 6.14;
рабочий стол обновлён до выпуска GNOME 48
обновлены приложения: GIMP 3.0, LibreOffice 25.2, Firefox 137, Thunderbird 128;
обновлены серверные пакеты: Nginx 1.26.3, Apache httpd 2.4.63, OpenSSH 9.9, cloud‑init 25.1.1, Docker 27.5.1, Containerd 2.0.2, libvirt 10.10.0, ClamAV 1.4.2, OpenLDAP 2.6, QEMU 9.2.0 и т.д;
задействован пакетный менеджер APT 3.0;

Все изменения и дополнительная информация по релизу https://discourse.ubuntu.com/t/plucky-puffin-release-notes/48687

Искусственный интеллект способен заменить половину чиновников, считает глава Минцифры РФ Максут Шадаев. При этом он уточнил, что человека, особенно врачей и учителей, нейросети все же не заменят. Это заявление Шадаев сделал в ходе профильного мероприятия First Russian Data Forum.
«Человека, надеемся, он не заменит, особенно врачей и учителей. Считаю, что половину чиновников точно может заменить. Может, чуть больше», — пояснил Шадаев.
https://tass.ru/ekonomika/23708211

Процесс работы архитектуры микросервисов:

🔹 Клиентский уровень: веб-приложения, мобильные приложения или приложения для настольных компьютеров инициируют запросы пользователей.

🔹 CDN + Статический контент: быстрее доставляет статические ресурсы, такие как HTML, CSS и JS, кэшируя их ближе к пользователям.

🔹 Балансировщик нагрузки: равномерно распределяет трафик между несколькими экземплярами, чтобы обеспечить доступность и предотвратить перегрузки.

🔹 API-шлюз (API Gateway): действует как центральная точка входа, обеспечивая маршрутизацию, аутентификацию и ограничение скорости клиентских запросов.

🔹 Поставщик удостоверений (Identity Provider): аутентифицирует пользователей и выдает защищенные токены (например, OAuth или JWT) для управления доступом.

🔹 Микросервисы: Независимые сервисы, каждый из которых обрабатывает отдельную бизнес-функцию, организованную по домену. Их можно создавать, масштабировать и развертывать независимо.

🔹 Реестр сервисов : отслеживает микросервисы и их сетевое расположение, чтобы они могли беспрепятственно взаимодействовать друг с другом.

🔹 Координация сервисов: поддерживает синхронизацию между сервисами и управляет распределенными конфигурациями (такие инструменты, как Zookeeper).

🔹 Брокер сообщений: обеспечивает асинхронную связь между сервисами с использованием очередей, таких как Kafka или RabbitMQ, — идеально подходит для разделения рабочих процессов.

🔹 Базы данных: каждый домен или сервис использует собственную базу данных, что обеспечивает изоляцию данных и устойчивость системы.

Анимация к предыдущему посту

Как работают почтовые протоколы

Компании «Группа Астра», Axiom JDK и Haulmont представили OpenIDE — новую среду разработки с открытым исходным кодом. Решение ориентировано на госсектор и крупный бизнес. Для вывода платформы на рынок учредили совместную компанию — ООО «Открытая среда разработки».
Платформа основана на IntelliJ IDEA Community Edition. Первая версия сейчас находится на финальной стадии бета‑тестирования. В состав OpenIDE входит Axiom JDK — российская реализация JDK, доступная для промышленного использования. Также в решение добавлен бесплатный плагин Amplicode от Haulmont, предоставляющий базовую поддержку Spring. «Группа Астра» планирует добавить в OpenIDE интеграцию с платформой GitFlic.
В платформе нет проприетарных компонентов, а сервера с дистрибутивами и исходным кодом, как и команда, которая занимается ее сборкой, развитием и сопровождением, находятся в России. Также планируется добавить в платформу открытый маркетплейс, где будет поддержка российских плагинов.
https://astra.ru/about/press-center/news/openide-novaya-otechestvennaya-sreda-razrabotki-dlya-nadezhnykh-i-bezopasnykh-it-proektov/

Семантическое управление версиями (SemVer) — это схема управления версиями программного обеспечения, цель которой — передать смысл основных изменений в выпуске.

🔹 SemVer использует трехкомпонентный номер версии: MAJOR.MINOR.PATCH.

- Старшая версия (MAJOR): увеличивается при наличии несовместимых изменений API.
- Младшая версия (MINOR): увеличивается при добавлении функциональности с сохранением обратной совместимости.
- Версия патчей (PATCH): увеличивается при внесении обратно совместимых исправлений ошибок.

🔹 Пример рабочего процесса
1 — Начальная фаза разработки
Начинаем с версии 0.1.0.

2 - Первый стабильный релиз
Выпуск стабильной версии: 1.0.0.

3 - Последующие изменения
Выпуск патча: Требуется исправление ошибки для 1.0.0. Обновите до 1.0.1.
Второстепенный релиз (увеличиваем младшую версию): новая, обратно совместимая функция добавлена ​​в 1.0.3. Обновление до 1.1.0.
Основной релиз (увеличиваем старшую версию): В версии 1.2.2 введено существенное изменение, несовместимое с предыдущими версиями. Обновление до версии 2.0.0.

4 - Специальные версии и предварительные релизы
Предварительные версии: 1.0.0-alpha, 1.0.0-beta, 1.0.0-rc.1.
Метаданные сборки: 1.0.0+20130313144700.

Иллюстрация к предыдущему посту про сематическое версионирование

Краткая шпаргалка по регулярным выражениям