🛠 Ещё один рантайм для контейнеров, на этот раз, написанный на Rust - youki.

#containers #runtime #youki

== БИНОМ НЬЮТОНА ДЛЯ ЧАЙНИКОВ
https://youtu.be/VDW_E_zyd8M

== Шаблоны проектирования микросервисов на примере Авито
https://youtu.be/5_9x7czHJOM
- Null Object Pattern (создание заглушки в случае если пришло чтото не то)
- Circuit Breaker ()
- Health Check (для базового случая и для случая под нагрузкой)

мало. скорей про опыт компании по переходу на микросервисы рассказал, чем про паттерны

нарвался на шикарный доклад

== Успехи и провалы с Redis
https://youtu.be/JBIm4sglyQU
- ttl занимает дополнительную память
- удаление ключей происходит при обращении и случайным образом
- ОБЯЗАТЕЛЬНО задать max-memory и max-memory-policy

Persistence & replication
- diskless
- disk-based (default)
- in-memory (for enterprise)

- откличать надо TRANSPARENT_HUGE_PAGES
- vm.overcommmit = 1

не забываем про mem-Fragmentation

не забываем про дополнительные буфферы

Используйте структуру HASH

Используйте Sorted Set (ZSET)
- ограничитель скорости (rate-limiter)
- планировщик задач (scheduler)
- очередь повторов (retry)

не забываем про Транзакции

не забываем что есть LUA-скрипты
- Скрипты кэшируются на конкретных нодах при LOAD и EVAL
- есть проблема со сменой мастера

HA redis:
1) перегрузка мастера
- надо что бы было задержка рестарта ноды была меньше больше чем время фэйловера
- Sentiel динамически обновляют конфигурацию
- Sentiel не забывает реплики

Persistence
- RDB - снапшоты, компактный размер
- AOF - лог операций
- AOF + RDB = гарантии почти как Постгресе
- нужен свой backup noscript + check
- на мастере МОЖНО отклучить персистанс (но надо понимать что делаешь) - ЛУЧШЕ оставить только AOF

Sentinels
- мониторить снаружи (ОПАСНО, так как может резануть сеть от вотчеров)
- мониторить изнутри

Multi-az/rack cluster

Решение с двумя ДЦ
- Есть свой Active-Active без CRDT
- НЕ ДОВЕРЯЙТЕ НАДЕЖНОСТИ СЕТИ !!!!

Не забываем про Шардирование

Pub/Sub
- AT MOST ONCE !
- получат только активные клиенты
- нет гарантий когда произойдет событие

Streams
- Append only
- Body Hash-like
- Consumer Groups

Monitoring & redis_exporter
- сбор метрик = доп нагрузка !
- большинство можно получить из INFO
- Аккуратней с -check-keys = ПРОВЕРЯЕТ ВСЕ
- можно создать LUA скрипт и проверять только то чтонужно (ШИКАРНО!!!)

Редис уже не такой уж и однопоточный

== Карьера в IT: должность CTO
https://dou.ua/lenta/articles/cto-position/

в круг обязанностей CTO могут входить:
— Определение общих стратегий технического развития;
— Принятие глобальных технических решений;
— Внутренний технический арбитраж;
— Выбор технологий, которые будут использоваться в том или ином проекте;
— Оценка этих технологий в плане финансовых и временных затрат;
— Оценка длительности и трудоемкости проектов;
— Планирование и построение процессов разработки;
— Формирование команд разработчиков;
— Распределение задач между командами;
— Отслеживание продвижения проектов;
— Обеспечение темпа и качество разработки на максимально высоком уровне;
— Выбор и внедрение вспомогательных систем для разработки и администрации;
— Экспертные предложения по архитектуре или конкретным техническим решениям;
— Написание кода, обзоры кода, рефакторинг;
— Технический pre-sale ключевых проектов;
— Управление техническими рисками на проектах;
— Общение с другими отделами и топ-менеджерами компании (CEO, COO, CIO и др.);
— Координация работы департаментов;
— Технические собеседования с новыми сотрудниками;
— Оценка продуктивности сотрудников и решение об уровне их зарплат;
— Обучение сотрудников;
— Формирование рабочей атмосферы в коллективе, мотивация сотрудников;
— Разборы полетов с тимлидами:)

Короч шикарный ридЛист для понимания своих обязанностей

Карьера в IT
- должность CTO
- должность Software Architect
- должность Project Manager
- Должность QA
- Должность QA Automation
- Должность BA
- Должность SYS-Admin
- Должность DS/ML Engineer
- Должность Delivery Manager
- Должность Product Manager
- Должность Fullstack Developer
- Должность Embedded Dev
- Должность Happiness Manager
- Должность UI/UX
- Должность Team Lead
- должность BizDev
- должность Sales Manager
- Должность Site Reliability Engineer
- должность Support Engineer
- должности HR-менеджер & рекрутер
- роль Scrum Master
- Должность NLP Engineer и NLP Researcher
- должность Technical Writer
- должность Program Manager
- специалист по кибербезопасности
- Должность AdOps Engineer
- должность Blockchain-разработчик
- Должность Продуктовый Аналитик
- Должность Program Manager
- Должность Верстальщик
- Должность DevOps engineer

== Про Kafka
https://youtu.be/-AZOi3kP9Js
- topic
- partition
- partition balancing
- storage: simple log files, segment
- DELETE NOT PERMITTED !
- ttl удаляет по сегментно
- partition replication
- partition Leader of replicas
- in-sync-replicas (ISR) - надежно! min.insync.replicas = 3
- producer: ack (0,1,-1) -1 означает что ждет подтверждения от всех ISR
- fetch metadata = SYNC operation
- Delivery semantics: AT MOST ONCE, AT LEAST ONCE, EXACTLY ONCE
- consumer: offset, re-balancing

why is it so fast:
- scalable arch
- sequential write and read
- no random read
- zero copy
- several semantics
- fine tuning !

короч можно было книгу не читать. просто посмотрев вовремя этот доклад 😂

== Безграничная память. Как запоминать информацию
https://youtu.be/diEkFaHklJ0

== распространенные ошибки изменения схемы данных в postgres
https://youtu.be/RDWz8_xuoWE

== postgres high load checklist
https://www.youtube.com/watch?v=0_CwH_lrPp0

== Изобретая синхронную репликацию
https://youtu.be/I8ijlHkMScY
- репликация
- RAFT

Резервная копия
балансировка запросов

Асинхронная
= для коммита транзакции достаточно что бы запись о ней попала в локальный журнал на мастере, потом сразу коммит, а репликация произойдет позже.
- если мастер отказывает - реплики не получат ничего. транзакция исчезает
- грязные чтения. = чтение данных до того как данные не зафиксированные
+ быстрая
+ высокая доступность
+ легко конфигурировать
+ есть мастер-мастер
- ненадежно. можно потерять данные

Синхронная репликиаця
= мастер записывает в локальный лог транзакцию и сразу раздает кворуму на подтверждение записи в их лог. и после этого коммит
- медленней
- хрупкая доступность
- трудно конфигурировать
- только мастер реплика
+ сложно потерять данные. надежно!

Raft
- каждая нода имеет одну из трех ролей (лидер, реплика, кандидат)
- лидер это тот кто принимает все запросы и отправляет репликам
- реплика это все остальные ноды, которые все скачивают и перенаправляеют все лидеру
- каждая нода изначально реплика
- если лидер не доступен, то реплики превращаются в кандидатов и пытаются выбрать из друг друга лидера
- все время жизни делится на ТЕРМ-ы (логические часы кластера)

синхронность транзакции гарантируется за счет четырех этапного коммита
- данные в журнал лидера
- данные в журнал реплик
- коммит в журнал лидера и ответ пользователю
- коммит в журналы реплик

ОТКАЗ на любом этапе любой ноыд НЕ ПРИВОДИТ К ПОТЕРЕ данных после коммита покаживо 50%+1 нода

Рафт накладывает органичение на журналы (что и как хранится)

У рафта есть и ОТКАТ транзакций

ReplicaID - ID узла создателя
LSN - монотонный счетчик
VClock это пара ReplicaID и LSN

== Серебряная пуля геораспределенных систем
https://youtu.be/1pSHI_4ICbY

и вновь про репликации

синхронная = плохо
асинхронная = плохо

смотрите в бизнеслогику а не в скорость!

по факту всегда есть стейтфулл система. стейтлесс очень редкий кейс
если стейтфул - есть проблема с роутингом

AnyCast это протокол роутинга. который транслирует

Автономная сеть

ip4 адреса закончились =(

если у вас своя автономная сеть - обязательно работать с РосКомНадзором

лучше как то жить с асинхронной репликацией

== Разработка и проектирование высоконагруженных систем (часть 1)
https://youtu.be/KmIE5K6adus

облака не делает сразу HA все что в него положили! облако не избавляет от необходимости думать

кэши не всегда ускоряют
Если попадание 90% то сервис ускоряется в 3.3х
если в 60% то всего 1.7х
если 20% то не приносит пользы!!!
все что меньше 20% то уже ЗАМЕДЛЯЕТ

индексы
- замедляет вставку
- увеличивает РАМ
- усложняет работу планировщика запросов

принцип построения высоконагруженных систем
- максимальная независимость компонент
- отсутствие единой точки отказа (по функциональности, по данным)

Архитектура
1) Сервисно-ориентированная
2) монолитное приложение
3)

https://nolanlawson.com/2021/12/17/introducing-fuite-a-tool-for-finding-memory-leaks-in-web-apps/
Тула для поиска проблем с утечками в веб вкладках
Использует стандартное АПИ хрома

сверточная нейронная сеть - базовое обьяснение

== Микросервисная архитектура
https://youtu.be/18D3uoUlOEw

риски замены унаследованных систем
1) нигде не описаны
2) не понятно какой функционал впринципе используется
3) приложения продолжают развиваться а работы по их документированию жидает аналитический паралич
4) доп ценность для бизнеса приносит ТОЛЬКО новый функционал
5) сроки и бюджет замены существенно ниже первоначальных вложений

БЫСТРЫЙ РОСТ ЧИСЛА ПРИЛОЖЕНИЙ ПОРАЖДАЕТ ХАОС, но происходит это не потому что разрабы не знают как делать, а потому что к разным приложениям предъявляют разные требования и они работают в разных контекстах. повышается сложность всей системы

Первый закон ямы - ПЕРЕСТАНЬ КОПАТЬ

REST
1) starting with the NULL STYLE
2) client-server
3) stateless
4) cache
5) uniform interface
6) layered system
7) code-on-demand

Glory of REST
lvl 0) The swamp Of POX - если есть апи то уже Рестфул
lvl 1) Resource model
lvl 2) http verbs
lvl 3) hypermedia controls

Characteristics of a Microservice Arch:
1) Componentization via Services
2) Organized around Business Capabilities
3) Products not Projects
4) Smart endpoints and bumb pipes
5) Decentralized Governance
6) Decentralized Data Management
7) Infrastructure Automation
8) Design for failure
9) Evolutionary design

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

Сервис - это код исполняемый в отдельном процессе

Микросервис это сборка из всех необходимых сервисов

Эволюционный дизайн
- Новые ветви отрастают по мере необходимости
- Их реализация не ограничена используемыми инструментами и производительностью команды разработки

SAFe и LeSS
- не рекомендуют численность людей к команде, а лучше добавлять новые Команды!

Децентрализованность
заставляет нас думать подругому. лучше реализовывать изменения как поток данных.

Архитектура должна удовлетворять
- VISIBILITY - должна помогать выявлять некорректное поведение
- FAULT ISOLATION - если сбоит то только одна часть а не все приложение
- FAULT TOLERANCE - устойчивость всех остальных компонентов к сбою в одной части
- AUTOMATED RECOVERY

Не пихайте логику в среду а только в компоненты

надо меньше делать адаптеров

Реальные проблемы интеграции:
- Устаревшие программные интерфейсы
- Сложные цепочки взаимодействий
- необходимость проверки условий
- обработка ошибок и исключений


миросервис справочников это прекрасная идея

== Микросервисы. Концепция. Первый сервис
https://youtu.be/zeCZmJLILkc
Задача сделать сервисы слабосвязанными

разбиение по
- бизнес возможностям
- по проблемным областям

== Микросервисы. Контроль качества кода
https://youtu.be/P0z9P1eYw70
- работоспособность = юнит тесты, интеграционные тесты, тесты миграций...
- стиль = линтеры, чекеры, проверка бест практис,...
- документация = редми, доки...

Мутационное тестирование. подмена операторов и других штук перед запуском тестов. если тесты не упали = ПЛОХОЙ ТЕСТ

== Микросервисы. Взаимодействие между сервисами (Теория)
https://youtu.be/0VH6ybfmlQ4
- Синхронное = медленно, но устойчиво, предсказуемо и понятно
- Асинхронное = брокер сообщений

Команда - запрос на некое действие
Ответ - ответное сообщение на запрос
Событие - информирование о случившемся факте

Шаблон SAGA
- обеспечивает согласованность между сервисами, используя последовательность локальных транзакцй, которые координируются с помощью асинхронных сообщений

Координация повествований
- Хореография - сервисы равноправны, обмениваются сообщениями без координатора = ПРОСТОТА, СЛАБАЯ СВЯЗАННОСТЬ. НО СЛОЖНО ДЛЯ ПОНИМАНИЯ. ЦИКЛЫ ВОЗМОЖНЫ !!!
- Оркестрация - оркестратор отправляет участникам сообщения с инструкциями, какие операции нужно выполнить = УПРОЩЕННЫЕ ЗАВИСИМОСТИ. УЛУЧШЕННОЕ РАЗДЕЛЕНИЕ ОТВЕТСТВЕННОСТИ, УПРОЩЕННАЯ БИЗНЕС ЛОГКИ. НО РИСК БУТЫЛОЧНОГО ГОРЛЫШКА

== Микросервисы. Согласованность данных
https://youtu.be/-5UoDalFEmo
ACID
- Атомарность - надо продумывать откаты
- Согласованность - надо продумывать переходы между состояниями данных
- Изолированность - надо продумывать блокировки
- Долговечность - надо продумывать где и как хранится

В микросервисах куда сложней
- долговечность = легко
- изолированность = надо вводить промежуточные статусы и блокировка записей. каждый сервис гарантирует блокировки конкретных записей
- согласованность НА СОВЕСТИ РАЗРАБОТЧИКОВ. НАДО ДУМАТЬ
- атомарность - надо все всегда в транзакциях использовать и обрабатывать фэйлы

== Микросервисы. Практикум. Задача
https://youtu.be/hQKu6GKMl7E
аля-брокерская система покупки акций
- участники
- счета
- акции
- запросы на покупку
- история платежей
- Gateway (Api-composer)
- Broker (кафка)

== Микросервисы. Практикум. Видео 1. Оркестрация
https://youtu.be/5s-yqnfwmP4
почему Оркестрация а не хореография - потому что в одном месте смотришь флоу + можно заюзать параллельные запросы

== Микросервисы. Практикум. Видео 2. Транзакции
https://youtu.be/pYIz1D5x0u8
Семантическая блокировка = статусы и блокировка

Идемпотентность для блокировок: ID запроса = блокировка

Атомарность надо реализовывать РУКАМИ ВСЕГДА

== Микросервисы. Практикум. Видео 3. CQRS-представление
https://youtu.be/EwS_C7TXxS8
сервис который ловит все события

каждый сервис пушит лог всего ВАЖНОГО что произошло

каждый ивент который изменяет структуру - обязан быть залоган

== Микросервисы. Практикум. Видео 4. Объединение API
https://youtu.be/na2pCNYmCEg

http 1 = коннекшн один
http 1.1 = кип элайв
http 2+ = конвеер ! одно подключение

всегда надо ограничивать время на запрос !!!

== Что такое IoC, DI, IoC container?
https://youtu.be/k4y2TlKcPUk

IoC = инверсия управления. это принцип для реализации слабосвязанной системы. Переносит ответственность за выполнение части функционала с кода приложения на фрэмворк

DIP = Принцип Инверсии Зависимости. НЕ ПУТАТЬ!

DI = Иньекция зависимостей. Это механизм передачи зависимости. Ты хочешь зависимоть, а приложение в определенной среде и с определенными настройками дает эту зависимость тебе. Это частный случай реализации IoC
- через конструктор
- через метод
- через свойство

IoC Container = приложение реализующее принцип IoC

== Kafka. Знакомство
https://youtu.be/vewm-ZaFTF4
Поддерживает транзакции

никогда бы не подумал что Джава может быть интересной для меня. чот даже захотелось поизучать Spring 😅 как то сильно красиво все, допиленно что ли.а реально выглядит как фреймворк для создания всего и вся

== Architecture Kata #1 - Analysis with an expert [How does a real Solution Architect work]
https://youtu.be/6MDKKuqn07A

ВАУ.... ПРОСТО ВАУ
такого контента нету в интернетах... не видел вообще