Обзор книги “Software Architecture: The Hard Parts” — Part 5

Это пятая статья из серии обзоров книги “Software Architecture”, в которой мы продолжаем обсуждение второй части книги “Putting Things Back Together” с глав десять, одиннадцать и двенадцать: “Distributed Data Access”, “Managing Distributed Workflows” и “Transactional Sagas” соответственно. Перед чтением этой статьи я рекомендую прочесть части 1, 2, 3 и 4. Ну а эту статью мы начнем с рассмотрения получения доступа к распределенным данным, но отдельно объясню обложку, на которой пример хорошей хореографии, про которую мы поговорим в середине статьи:)

Distributed Data Access

Авторы предлагают следующую классификацию вариантов доступа к распределенным данным, выделяя 4 варианта:

  • Interservice Communication Pattern — запросы данных у сервиса-владельца через его API
  • Column Schema Replication Pattern — репликация части данных (нужных колонок из чужой модели данных) в свою базу
  • Replicated Caching Pattern — репликация всех данных в локальный кеш, который наполняется на старте сервиса-консьюмера, используя данные из сервиса-провайдера
  • Data Domain Pattern — просто shared база данных для нескольких сервисов

Дальше на рисунке можно посмотреть на плюсы и минусы предложенных решений.

Managing Distributed Workflows

В начале этой главы авторы вспоминаю про размерности динамического coupling, которые включают в себя 3C:

  • Communication — взаимодействие синхронное/асинхронное
  • Coordination — координация оркестрируемая/хореографируемая
  • Consistency — консистентность atomic/eventual

Визуально это можно изобразить так

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

Дальше авторы показывают, что по мере роста сложности workflow повышается полезность оркестрации.

Transactional Sagas

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

  • Осью X стала Communication, где sync=0, async=1
  • Осью Y стала Consistency, где atomic=0, eventual=1
  • Осью Z стала Coordination, где orchestration=0, choreography=1

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

Ну и напоследок авторы говорят про RSM (Replicated State Machine) как способ предсказуемой работы с eventual consistency и рассматривают его плюсы и минусы. Мне же показалось, что правильнее рассмотреть и сравнить два подхода atomic distributed transactions и replicated state machine, что я и сделал на рисунке ниже. А хорошо про модели взаимодействия и консистентность можно почитать в книге “Database Internals” и конкретно во второй части Distributed Systems, на которую я написал обзор.

P.S.

Запись обсуждения этой части книги в нашем книжном клубе Code of Architecture представлена ниже.

--

--

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store