Главная

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

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

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

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

• используйте форматы 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”…

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

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