Архив за 2022

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

Есть несколько каверзных вопросов, которые необходимо учитывать при внедрении ограничителя трафика:

• Где поставить ограничитель трафика: на стороне клиента, на стороне сервера, на шлюзе?
• Алгоритмы ограничения скорости. Есть много алгоритмов со своими плюсами и минусами: Token Bucket, Leaking Bucket, Fixed window counter, Sliding window log, Sliding window counter. Особенности вашего бизнеса определят правильный алгоритм.
• Как создаются правила ограничения трафика?
• Где хранятся правила?
• Как обрабатывать запросы, скорость которых ограничена?

Эти вопросы раскрыты в очень интересной главе 4 книги:

Четыре стандартных этапа собеседования по проектированию ИТ-систем. Однако я бы думал о них шире: как о четырех начальных шагах проектирования любого ПО.

• Шаг 1. Понимание проблемы и определение скоупа проектирования
• Шаг 2. Предложите дизайн высокого уровня и получите одобрение
• Шаг 3. Спроектируйте глубокое погружение
• Шаг 4. Завершение

Глава 3 книги раскрывает подробности о каждом шаге, хорошие вопросы, которые нужно задать (над которыми следует подумать), а также то, что НУЖНО и НЕЛЬЗЯ делать. Она также показывает хороший пример процесса разработки системы новостных лент в соц сетях.

Очень короткая глава 2 посвящена тому, как делать приблизительные оценки, чтобы начать с самых важных моментов при разработке программного обеспечения.

Концепции, которые должен знать КАЖДЫЙ разработчик программного обеспечения:

• “Сила двух”
• Стандартные цифры задержки! Насколько быстрой является память, насколько медленным является диск и т.д.
• Показатели доступности
• Про какие ключевые метрики стоит думать

Эти понятия и числа раскрыты во второй главе книги:

“System Design. Подготовка к сложному интервью” Алекса Сюй. Оригинал: “System Design Interview – An insider’s guide” by Alex Xu

Отличный общий план для масштабирования любого приложения с нуля до миллионов пользователей.

• Настройка одного сервера
• Выбор и использование базы данных
• Вертикальное масштабирование против горизонтального масштабирования подходов. И почему вы должны предпочесть горизонтальный
• Добавлен балансировщик нагрузки для горизонтального масштабирования
• Добавление репликации базы данных для горизонтального масштабирования
• Добавление кеша
• Добавление CDN
• Архитектура без сохранения состояния и с сохранением состояния и использование внешнего хранилища состояния
• Добавление дополнительных центров обработки данных
• Добавление очереди сообщений
• Добавление ведения журнала, метрик и автоматизации
• Масштабирование базы данных
• и дальнейшие шаги…

Все это тщательно, но кратко раскрыто в Главе 1 книги:

Принципы развертывания микросервисов Различия между непрерывной интеграцией (CI), непрерывной доставкой и непрерывным развертыванием. Шаблоны развертывания:

• Базовый шаблон полного развертывания
• Шаблон непрерывного обновления
• Паттерн изменения схемы прерывания: здесь два варианта - окончательная миграция и синхронизированная миграция.
• Сине-зеленый шаблон развертывания

Все это раскрыто в главе 16 книги:

“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Делюсь своей ментальной картой со всеми подробностями, как обычно:

Тестирование событийно-ориентированных решений — сложная задача. Это включает в себя:

• Общие принципы
• Модульное тестирование: без сохранения состояния и с сохранением состояния
• Тестирование топологии (держу пари, вы этого не делали! ;)
• Тестирование эволюции схемы и совместимости
• Интеграционное тестирование: локальное, удаленное и гибридное - набор соображений здравого смысла, о которых нельзя забывать.
• Выбор стратегии тестирования

Все это раскрыто в главе 15 книги:

“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

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

• Правила организации
• Документация, маркировка
• Квоты
• Схема реестра
• Управление смещением
• список контроля доступа
• Управление состоянием и сброс приложения
• Мониторинг задержки смещения потребителя
• Элементы управления контейнером
• Создание кластера и управление им
• Отслеживание зависимостей

Все это раскрыто в главе 14 книги:

“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Как интегрировать микросервисы, управляемые событиями, с API-интерфейсами типа «запрос-ответ»?

Существует два типа внешних событий:

• Автономно генерируемые события (аналитические события)
• Реактивно генерируемые события (события от запроса-ответа)

Существует два подхода к обработке и обслуживанию запросов с использованием сервисов с отслеживанием состояния:

• использование внутренних хранилищ состояний (с глупой или умной маршрутизацией)
• использование внешних хранилищ состояний (с обычным или с составным микросервисом)

Способы обработки запросов в рамках управляемого событиями рабочего процесса:

• Работа с запросами напрямую
• Превращение запросов в события (большая задержка)
• Обработка событий для пользовательских интерфейсов (смесь двух способов)

Подходы для приложений запрос-ответ, их плюсы и минусы:

Четвертый шаблон для создания микросервисов — использование легковесных фреймворков.

Легковесные фреймворки предоставляют функциональность, аналогичную тяжеловесным фреймворкам, но они в значительной степени зависят от:

• брокера событий
• системы управления контейнерами (CMS)

Во многих случаях они превосходят тяжеловесные фреймворки.

Различные приложения могут использовать любые/разные ресурсы из кластера, которые лучше соответствуют их потребностям. При этом по-прежнему обеспечивают масштабирование и восстановление после сбоев (опять же, сильно полагаясь на брокера событий и CMS).

К сожалению, на данный момент есть только два полнофункциональных варианта:

Тяжеловесные фреймворки потоковой обработки — это еще одна основа/шаблон для создания микросервисов.

Эти фреймворки обладают высокой масштабируемостью и позволяют эффективно решать множество аналитических задач. Но они не всегда хороши для шаблонов приложений микрослужб с отслеживанием состояния, управляемых событиями.

Тяжеловесные фреймворки работают с использованием централизованных кластеров ресурсов, что может потребовать дополнительных операционных издержек, мониторинга и координации для успешной интеграции в среду микросервисов. Однако недавние инновации двигают эти фреймворки в сторону решений для управления контейнерами (CMS), таких как Kubernetes, которые должны сократить ваши усилия.

Базовой шаблон производителя и потребителя (BPC) — это простой шаблон для создания микросервисов. Он формирует основу сервисов без сохранения состояния и с сохранением состояния.

Вы можете использовать его для:

• реализации интерфейса взаимодействия между потоками событий и устаревшими системами
• использования внешних систем обработки потоков для расширения возможностей

Но это требует ваших дополнительных усилий для реализации:

• простой материализации состояния
• скедулинга событий
• принятия решений на основе временных меток

Все это раскрыто в главе 10 книги, которую мы сейчас изучаем:

Функция как сервис (FaaS) — это область облачных вычислений, которая быстро развивается.

Здесь необходимо рассмотреть следующие вопросы:

• Принципы FaaS
• Открытый исходный код и сторонние поставщики FaaS
• 4 компонента, которые следует учитывать при построении микросервисов как функций
• Холодный пуск против теплого пуска
• Различные триггеры, которые могут запускать FaaS: запуск на основе новых событий, запуск на основе задержки группы потребителей, запуск по расписанию, запуск с использованием веб-перехватчиков, запуск по событиям ресурсов.
• Поддержание состояния
• Два шаблона функций, вызывающих другие функции: управляемый событиями и прямой вызов.
• Прекращение и завершение работы
• Настройка и масштабирование

Все это раскрыто в главе 9 книги, которую мы сейчас изучаем:

Существует два шаблона построения микросервисов, управляемых событиями:

• Хореография (без централизованной координации)
• Оркестровка (с централизованной координацией)

У обоих есть плюсы и минусы (однако мне кажется, что оркестровка все-таки более удобный шаблон)

Как реализовать распределенные транзакции с хореографией и оркестровкой.

Как ИЗБЕЖАТЬ реализации распределенных транзакций — подход с компенсационным рабочим процессом.

Все это раскрыто в главе 8 книги, которую мы сейчас изучаем:

“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Микросервисы, управляемые событиями, должны материализовать состояния. И это связано с важными вещами для размышлений. Два подхода на выбор:

• Внутреннее хранилище состояний
• или внешнее хранилище состояний

У обоих есть плюсы и минусы. Оба имеют важные соображения о масштабируемости и восстановлении.

Два подхода к изменению структур данных:

• Перестраивать
• и Миграции

Транзакции и как их эмулировать для реализации обработки Ровно Один Раз.

Все это раскрыто в главе 7 книги, которую мы сейчас изучаем:

Детерминированная потоковая обработка — это основа для создания масштабируемых систем, управляемых событиями. Отсутствие детерминизма может быть очень болезненным для бизнеса (представьте себе потерю финансовых транзакций, пропущенные оповещения, неправильную агрегацию данных).

Существуют определенные советы и приемы реализации детерминизма. Ключевые слова здесь:

• Временные метки
• Планирование событий
• Водяные знаки
• Время потока

Вы должны понимать природу неупорядоченых и запоздалых событий. И стратегии их обработки.

Также необходимо поддерживать повторную обработку.

И нужно учитывать периодические сбои.

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

Обо всем этом рассказывается в Школе стартапов Y Combinator — Урок «Как разговаривать с пользователями».

Как обычно, вот моя сводная ментальная карта:

Скачать полную ментальную карту (PDF)

Основы событийно-управляемой обработки в архитектурах, управляемых событиями:

• Типовая структура микросервиса
• Типовые типы трансформации событий, 2 сценария ветвления, слияние потоков
• Перепартиционирование событий и когда это может быть полезно
• Сопартиционирование событий и когда это необходимо
• Назначение партиций конкретному микросервису занимающемуся обработкой данных. Три стратегии для этого.
• Восстановление после сбоев микросервисов обработки данных без поддержки состояния.

Эти темы раскрыты в главе 5 книги, которую мы сейчас изучаем:

“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Освобождение данных — это процесс перехода от монолита к микросервисам путем разделения систем с точки зрения зависимостей данных.

Существуют три паттерна для освобождения данных:

1. На основе запросов
2. На основе журнала
3. На основе таблиц

У каждого паттерна есть свои плюсы и минусы, а также другие важные соображения.

Изменения определения данных (миграция структуры данных) также должны поддерживаться выбранным подходом к освобождению данных.

Существуют различные фреймворки/инструменты, которые упрощают процесс освобождения данных. Обратите внимание, что инструменты CDC не являются конечным пунктом вашей архитектуры, а всего лишь начальным шагом ваших измерений.

Управляемая событиями модель, сильно зависит от КАЧЕСТВА событий.

События хорошего качества:

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

События хорошего качества реализуются с помощью правильных инструментов:

• используйте форматы Avro/Thrift/Protobuf и никогда не используйте JSON!
• используйте правильный брокер событий (например, Pulsar)

События хорошего качества проектируются так, чтобы:

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

Эти темы раскрыты в главе 3 книги, которую мы сейчас изучаем:

Я случайно познакомился с основателями Блокчейна EMPERA. Как вы знаете, несмотря на то, что я верю в будущее блокчейна, я немного скептически отношусь к новым проектам и идеям в этой области, так как есть много чистых мошенников и непрофессиональных энтузиастов.

Однако после прочтения всех статей и глубокого разговора с основателями я очень удивлен этим конкретным проектом. И я хочу поделиться с вами своими мыслями (а также несколькими скептическими неясностями, чтобы быть на 100% честным). Если вы видите некоторые проблемы в моем анализе, пожалуйста, дайте мне знать!

Введение в архитектуру микросервисов, управляемых событиями (EDM), состоит из следующих тем:

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

Эти темы раскрыты в главе 2 книги, которую мы сейчас изучаем:

“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Книжный клуб нашей компании выбрал книгу о микросервисах. Это “Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Глава 1 содержит вводную информацию:

Типы архитектур и различия между ними:

1. Традиционные монолитные архитектуры
2. Сервисно-ориентированные архитектуры (SOA)
3. Архитектуры управляемых событиями микросервисов (EDM)

Уровни коммуникативных структур и связанный с ними закон Конвея:

• бизнес
• реализация
• данные

Проблемы с традиционными архитектурами (монолит и SOA), когда вам нужно:

• добавить новое бизнес-требование
• вырастить команду и разделить ее на две команды

И как избежать этих проблем при использовании архитектуры EDM

Роды ребенка в Мексике имеют ряд преимуществ, среди которых:

• отличный климат и превосходное настроение для мамы и ребенка
• ребенок сразу получает Мексиканское гражданство и может без виз путешествовать в многие страны
• ближние родственники ребенка могут получить Мексиканский ПМЖ

Есть ряд бизнесов и бизнес-задач когда необходимо визуально проектировать, изменять и контролировать исполнение бизнес-процессов.

Крупные компании уровня SAP, IBM, Oracle играют на этом рынке и предлагают свои тяжелые и дорогие решения.

Но есть и более легковесное и дешевое решение на этой поляне.

Знаете ли вы, что проиграть 1000 долларов, а затем выиграть 900 долларов (т.е. получить результат -100 долларов в сумме) приятнее, чем выиграть 1000 долларов, а затем проиграть 900 долларов (т.е. получить результат +100 долларов)!??

То, что произошло в НЕДАВНЕМ ПРОШЛОМ, влияет на нашу эмоциональную реакцию гораздо больше, чем на нам общий результат! Это проблема, если вы делаете важный прогноз.

Есть способы решить эту проблему:

Это продолжение моего предыдущего поста Реальные проекты с Ethereum) — о том, как настроить инфраструктуру разработки вокруг реального смарт-контракта.

Я уже рассказывал о группе поиска правды (Система напарников) как об отличном способе улучшить процесс принятия решений.

Как делиться информацией внутри такой группы и как эффективно не соглашаться (чтобы находить хорошее решение)? И как общаться вне такой эффективной группы?

Для этого можно использовать правила “CUDOS”…

Люди не готовы считать себя источником проблемы, с которой они столкнулись (свои навыки), они винят в этом других людей/обстоятельства (везение). Как побороть эту проблему?

Одним из решений является создание «группы правды» с вашими коллегами/друзьями/партнерами/«напарниками». И такая группа должна следовать определенным правилам, повышающим рациональность…

Девиз Y Combinator — “Делайте то, чего НУЖНО ЛЮДЯМ”. Но как найти то, что нужно людям? Есть семь шагов/соображений, чтобы постепенно приблизиться к ответу…

Как построить сложный смарт-контракт на блокчейне? С какими стандартными проблемами вы столкнетесь с массивами, газом, различными типами переменных, развертыванием контрактов и т.д.? И как их решить?

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

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

Какие качества важны, чтобы стать отличным коммуникатором? Это харизма или искренность? Или что-то другое? Как определить свои сильные и слабые стороны? И как их использовать?

Как отвечать на неудобные вопросы - вопросы, на которые вам трудно ответить? Есть 8 стратегий и 5 вещей, которые вам НЕЛЬЗЯ делать.

Какой набор инструментов подходит для разработки под блокчейн? Вот некоторые ключевые слова: nodejs, npm, web3, solc, ganache, mocha, metamask, rinkeby, infura, remix…

Люди должны учиться, наблюдая за результатами, но почему они не учатся?

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

Также нас искажают наши предвзятости:

• корыстное предубеждение по отношению к себе
• и инвертированное корыстное предубеждение по отношению к другим

Как преодолеть наши предвзятости и учиться лучше?

Игроки в покер принимают решения делая ставки. Почему и всем нам нужно принимать решения, используя ставки?

Существует ловушка предвзятости «мотивированных рассуждений». И, к счастью, есть фасилитирующие вопросы, которые направляют наш мозг в правильном направлении.

Мы также должны отказаться от использования шкалы уверенности «все или ничего». Вместо этого мы должны научиться измерять нашу уверенность в процентах. Это не только поможет нам выигрывать больше, но также сделает нас более заслуживающими доверия собеседниками и повысит эффективность командной работы вокруг нас.

Первоначальные вопросы, с которыми сталкивается любой фаундер:

• Как найти идею для стартапа?
• Как найти свой «икигай» (смысл существования)?
• Как видеть большие возможности везде и каждый день?
• Как оценить свои идеи и выбрать лучшую?

Почему нужно задавать вопросы во время общения? Какие ошибки мы совершаем в общении? Два типа вопросов. Три характеристики хорошего слушателя. Структура хорошего вопроса. Структура идеального вопроса.

Невозможно жить без конфликтов. Но как сделать конфликт конструктивным?

Томас Гордон, автор книги «Курс эффективного родителя», изобрел «Я-сообщение», которое сейчас преподается во многих программах бизнес-образования.

В уроке 8 курса Гений общения подробно описывается Я-сообщение:

• Что НЕЛЬЗЯ говорить во время конфликтов
• Что такое Я-сообщение
• Какова структура Я-сообщения

Наш книжный клуб Rational Answer выбрал книгу на февраль. Это - “Принцип ставок” Энни Дьюк: https://www.litres.ru/enni-duk-18510608/princip-stavok/chitat-onlayn/

“Thinking in Bets” by Annie Duke: https://www.amazon.com/Thinking-Bets-Making-Smarter-Decisions-ebook/dp/B074DG9LQF

Эта книга написана победителем покерных турниров на миллионы долларров (и ее брат тоже многократный победитель покерных турниров на миллионы долларов - так что это у них семейный бизнес ;))

Она учит применять покерное мышление для принятия решений для финансовых рынков, стратегического планирования, человеческих ресурсов, права, предпринимательства…

В наши дни существует довольно высокий спрос на разработку блокчейна. У нас, как у компании, есть опыт работы с ним (один комплексный многолетний проект), но лично у меня были только высокоуровневые знания, и я хотел их улучшить…

Итак, я и несколько моих коллег начали курс “Ethereum and Solidity: The Complete Developer’s Guide” (https://www.udemy.com/course/ethereum-and-solidity-the-complete-developers-guide/)

Как влиять на людей с помощью ярких историй?

Урок 6 Гения Общения охватывает следующие темы:

• Что нам нравится в историях?
• Что должно быть в истории?
• Типичные ошибки
• Алгоритм Pixar “Как рассказать историю”! 🤩

Почему и как делать комплименты?

Урок 5 курса Гений Общения охватывает эти темы:

• Как обращаться к незнакомой аудитории?
• Формула идеального комплимента
• Облегчающие вопросы, чтобы подобрать хороший комплимент
• Хорошее и плохое содержимое для комплимента

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

Урок 4 из курса Гений Общения раскрывает эти темы:

• Что НИКОГДА не следует делать во время светской беседы?
• Что вы ДОЛЖНЫ делать во время светской беседы?
• Несколько дополнительных рекомендаций для светских бесед.

Как измерить шум в наших повседневных решениях?

Что лучше — экспертная оценка или механическое предсказание с использованием очень простых моделей/правил? Удивительно, но модель вас лучше вас! Даже простая регрессионная модель, основанная на ваших прошлых решениях!

Как сделать правила/модели еще менее шумными? Как правила/модели могут иногда становиться более предвзятыми?

Почему люди не всегда используют модели (если они так хороши) и по-прежнему полагаются на свои неверные суждения?

Когда нам не нужны модели?

Продолжаю делиться свои впечатлением и знаниями из курса Гений Общения, который я начал проходить в январе 2022 года. В третьем уроке вы найдете много полезной информации о ТОСТАХ. Там содержатся конкретные подсказки о том, что сказать, чтобы вас запомнили, и полезные фразы, которые прозвучат уместно в неформальной обстановке за столом.

В январе 2022 года я начал курс Гений Общения от одного из лучших тренеров по публичным выступлениям. Во втором уроке вы найдете подсказки, необходимые для общения в стрессовых ситуациях, когда время на исходе (ELEVATOR PITCH). Там конкретные инструкции о том, что говорить в таких ситуациях, а о чем лучше не упоминать.

Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:

Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения

Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design

👍

Часть VI подрывает некоторые устои 😀:

• Вы знаете, что База Данных - это “деталь”? Неважная второстепенная низкоуровневая необязательная функция, которой можно пренебречь при проектировании архитектуры!
• Вы знаете про Веб тоже самое? Это просто неважное устройство ввода-вывода, которым также следует пренебречь при проектировании архитектуры!
• А как насчет фреймворков? То же самое. Не женитесь на своём фреймворке. Используйте безопасный, а еще лучше - удаленный секс. 🤣
• Несколько примеров того, как похожие архитектуры могут приводить или не приводить к проблемам. И что использовать, чтобы избежать проблем (спойлер: Инкапсуляцию)
• Все вышеперечисленное и краткий недостающий совет…

Вобщем, отличная информация! Все подробности в моих ментальных картах:

В январе 2022 года я начал курс Гений Общения от одного из лучших тренеров по публичным выступлениям — чтобы быть чуть менее токсичным и более эффективным 🙂

Урок 1 рассказывает:

• Какова цель коммуникации?
• Какие две половинки для успеха?
• Почему вы должны четко определить и записать свою настоящую цель?
• Как учесть вашу аудиторию?
• Что такое Формат и его элементы: Время, Место, Дресс-код и Жанр и как их использовать?
• Как правильно выбрать Момент? Примеры хороших и плохих моментов?

Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:

Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения

Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design

👍

Пятая часть книги содержит МНОГО полезной информации:

Что такое архитектура ПО? Какие типы взаимозависимостей могут существовать? Как провести границы между компонентами? Какие типы границ существуют? Как распределить политики по уровням? Что такое бизнес-правила, сущности и варианты использования? Что архитектура может и должна “кричать”? Описание Чистой Архитектуры.

Интересно узнать, как наш разум принимает решения. Два типа решений: прогнозные и оценочные. Как измерить ошибки от предвзятости и шума. Как измерить стоимость шума. И как бороться с катастрофическими последствиями.

Детализация шума до трех компонентов: системный шум, шум уровня и шаблонный шум. Как измерить (и компенсировать) шумы. Случайный шум как часть шаблонного шума. Как компенсировать случайный шум: эффект мудрости толпы, эффект толпа-в-одном, эффект второго ответа и инструмент диалектической самонастройки.

Как групповая работа влияет на шум. Информационный каскад и каскад социального давления. Как с ними бороться. Эффект групповой поляризации.

Вы осознаете, насколько серьезно на вашу организацию влияют неверные решения? В человеческих суждениях есть два типа ошибок: предвзятость и шум. Предвзятость - очень широко известная проблема, и вы наверняка слышали о ней. А шум не так широко известен. Тем не менее, он влияет на МНОГИЕ решения во ВСЕХ отраслях.

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

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

Ранее книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

Глава 12 - это саммари книги и визионерский взгляд на будущее.

• Интеграция данных.
  • Обзор способов интеграции данных.
  • Причинность и зачем нам нужен тотальный порядок и идемпотентность.
  • Транзакции и линеаризуемость
  • Ограничения тотального порядка.
  • Лямбда-архитектура и унификация пакетной и потоковой обработки как наиболее перспективный подход.
• Разделение баз данных.
  • Обзор выстраиваний композиции из хранилищ данных вместе.
  • Разработка приложений вокруг потока данных.
  • Использование производных состояний.
• Стремление к правильности: какие проблемы учитывать и как с ними бороться.
  • Жетон сквозного прохода.
  • Как обрабатывать многораздельные запросы.
  • Вопросы своевременности и целостности. Извинения в бизнесе.
  • Мета-подход: доверяй, но проверяй.
• Делать правильные вещи.
  • Предиктивная аналитика дискриминирует людей! Мы несем ответственность и подотчетность.
  • Конфиденциальность противоречит отслеживанию. Тотальный надзор должен быть законодательным и саморегулируемым.

Скачать всю майнд-мапу в PDF

Ранее книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

Глава 11 раскрывает все аспекты потоковой обработки. Если вашей системе необходимо обрабатывать некоторые данные на лету, ваша команда разработчиков должна изучить эту информацию.

• Подходы для передачи событий: прямой обмен сообщениями, системы обмена сообщениями и партиционированные журналы. Их реализации, плюсы и минусы.
• Как использовать потоки для баз данных. Синхронизация баз данных, Change Data Capture (CDC), Event Sourcing. Состояние, потоки и иммутабельность.
• Нюансы обработки потоков. Полезные варианты использования, рассуждения о времени, 3 типа потоковых joins, отказоустойчивость.

Скачать всю майнд-мапу в PDF

Ранее книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

Глава 10 раскрывает все аспекты пакетной обработки больших данных. Если вашей системе необходимо обрабатывать данные, ваша команда разработчиков должна изучить это.

• Инструменты Unix для пакетной обработки и блестящей концепции пайпов.
• MapReduce и распределенные файловые системы. Как этот подход решает проблемы пайпов Unix. Отказоустойчивость и партиционирование. Использование и реализация Joins, Grouping, Mapping. Доступные инструменты и проблемы этого подхода.
• Что выходит за рамки MapReduce. Движки обработки данных, обработка графов, высокоуровневые API и базы данных MPP. Работа с отказоустойчивостью и партиционированием. Реализации, проблемы, что и когда использовать.

Скачать всю майнд-мапу в PDF

Ранее книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

В главе 9 рассказывается о согласованности и консенсусе в распределенных системах. Она охватывает следующие темы:

• Что такое согласованность и согласованность в конечном счете.
• Линеаризуемость. Зачем это нужно. Отличие от сериализуемости. Как реализовать линеаризуемость. Стоимость линеаризуемости. Теорема CAP.
• Гарантии определения порядка. Что такое порядок и причинность. Их отношение к линеаризуемости. Sequence Number Ordering и как его реализовать. Total Order Broadcast и как его реализовать.
• Распределенные транзакции и консенсус. Зачем нужны консенсус и распределенные транзакции. Как их реализовать, связанные с ними проблемы и программное обеспечение, которое помогает.

Резюме:

Ранее книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

В главе 8 раскрываются проблемы распределенных систем, не связанные с базами данных. Команды разработчиков должны учитывать их при разработке распределенного программного обеспечения.

• Неисправности и частичные отказы. Необходимость строить надежную систему из ненадежных компонентов.
• Проблема 1: ненадежные сети. Почему такое случается. Как это обнаружить. Как с этим бороться. Синхронные и асинхронные сети. Гибридные сети и эмуляция гибридных сетей.
• Проблема 2: ненадежные часы. Монотонные часы и часы времени суток. Что использовать, а что не использовать в разных случаях. Хорошие практики.
• Проблема 3: знание, правда и ложь. Что такое правда в распределенных системах. Проблема византийских генералов. Модель системы и реальность: что использовать в каких случаях.

Скачать всю майнд-мапу в PDF

Ранее книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

Глава 7 - это все, что ваша команда разработчиков должна знать о транзакциях:

• Предназначение транзакций
• Концепция транзакций: ACID, BASE, одно-объектные и много-объектные транзакции.
• Уровни слабой изоляции: Read Committed, Snapshot Isolation и Repeatable Read. Проблемы и их предотвращение: утерянные обновления, перекосы при записи и фантомы
• Serializability и три подхода: фактическое последовательное выполнение, двухфазная блокировка (2PL), изоляция сериализуемых снэпшотов (SSI). Возможные проблемы и производительность.

Скачать всю майнд-мапу в PDF

Ранее книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

Глава 6 содержит все, что следует учитывать команде разработчиков при проектировании хранилища для больших данных:

• Партиция, она же шард, она же регион, он же tablet, она же vNode, она же vBucket. Это еще один подход к хранению данных в дополнение к Репликации (рассмотренной в предыдущей главе).
• Как партиционировать данные со структурой ключ-значение (первичный индекс). Проблемы с партиционированием - skew и hotspot. Подходы: диапазон ключа и хэш ключа.
• Партиционирование для вторичных индексов: локальный индекс и глобальный индекс
• Ребалансировка партиций по мере роста. Плохие и хорошие подходы, проблемы и способы их решения. Ручная и автоматическая перебалансировка.
• Маршрутизация запросов. Разные подходы, проблемы и решения.

Скачать всю майнд-мапу в PDF

Ранее книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

Глава 5:

• Вступление. Как масштабировать приложения. Репликация и партиционирование.
• Три алгоритма репликации
• Репликация с одним лидером
  • Лидеры и последователи
  • Синхроная и асинхронная репликация
  • Добавление новых последователей
  • Обработка перебоев в работе узлов
  • Технические реализации и все возможные проблемы
• Многолидерная репликация
  • Случаи использования, когда это хорошо
  • Обработка конфликтов на запись
  • Три топологии и потенциальные проблемы
• Репликация без лидера
  • Запись в базу данных, когда узел не работает
  • Кворумы и проблемы с ними
  • Обнаружение одновременных записей и способы разрешения конфликтов

Скачать всю майнд-мапу в PDF