Это вопрос должен решать архитектор. Или нет?

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

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

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

Основная идея проекта

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

Я предлагаю вам другой подход. Смотрите, вы идете ко мне на сайт, регистрируетесь, заполняете анкету. В анкете будет примерно следующее: хочу каждый день с понедельника по пятницу в 8:15 выйти из дома (пункт А) сесть в мерседес и доехать до работы (пункт Б). Потом вечером в 18:00 выйти из офиса (пункт Б) сесть в ауди и доехать до дома (пункт А). Там же еще можете пометить галочкой пункт: хочу иметь возможность уехать с работы раньше, машину готов ждать не более 8 минут.

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

За все удовольствие с вас попросят 150 у.е. в месяц. Звучит неплохо, не правда ли?

Естественно под капотом у этого сервиса будет много логики, т.к. надо много что учитывать. Например, мы должны быть конкурентоспособны, т.е. надо предложить людям вариант подешевле. Для этого можно предусмотреть совместные поездки. Мы можем посмотреть, что сосед нашего клиента, оказывается, тоже едет в ту же сторону, но на 5 минут позже. Может предложить им ездить вместе, а за это предложить скидку?

Наш сервис будет давать нам множество данных из которых мы можем добыть много интересной информации:

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

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

Для того, чтобы это было возможно нам надо предусмотреть возможность сбора и анализа информации.

В общем и целом речь идет о большом и сложном проекте, который можно назвать модным словом «cognitive solution» для бизнеса с элементами из мира Internet of Things.

Методология разработки и анализ требований

Естественно, сначала необходимо проанализировать все требования к проекту, решить какую методологию мы применим (waterfall, rup, scrum, …). Но в данном случае мы все эти этапы пропустим, т.к. практически все поднятые в этой статье вопросы возникнут в любом случае, независимо от выбранной методологии.

Язык, фреймворк, архитектура

Изначально я Java Developer, и потому имплементация будет на java. Не обессудьте.

Кстати вот сразу вопрос, является ли выбор языка программирования задачей архитектора или он «выше этого»?

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

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

А какой фреймворк возьмем? Если немного погуглить, то станет понятно, что особо вариантов нет, мы будем делать на Spring Framework. Причина проста, в Spring Cloud есть все, что нам потребуется.

Еще у нас будут всякие API Gateway’и, Config Service’ы, Message Broker’ы, Docker, Workflow, Rule Engine и много всяких других заумных слов по мелочи.

Давайте определимся, какие сервисы нам необходимы. Для этого мы посмотрим, какие доменные объекты нам точно нужны, а потом посмотрим по каким сервисам мы их распихаем.

Начнем с транспорта. Например с Car. Хотя просто Car не пойдет. Поясню. Например вдруг человеку будет удобно доехать на машине до вокзала, там пересесть на поезд, доехать до города, а потом последние два километра проехать на велосипеде? Мы ведь хотим с этого милого человека еще и за велосипед денег попросить? А вдруг кто то захочет эту самую последнюю милю на моноколесе проехать? Не обижать же человека, тем более, если у него на это деньги есть? Давайте сдадим ему в аренду моноколесо! Таким образом в будущем нам может потребоваться множество классов, описывающих разные транспортные средства.

Возьмем за стартовую точку некоторый абстрактный класс Vehicle

 public abstract class Vehicle {
….
   protected String model;
   protected int wheelNumber;
   protected Date manufactureYear;
   protected EngineType engineType; 
   protected Producer producer;
}

Как мы выяснили у нас будут разные Vehicle, давайте сделаем парочку:

public class Car extends Vehicle {
   public Car() {
       wheelNumber = 4;
   }
}

и еще один для бедных, но спортивных:

public class Bicycle extends Vehicle {
 
   public Bicycle() {
       wheelNumber = 2;
   }
}

Замечательно. Теперь нам нужен тот, ради кого мы все это делаем: наш клиент, он же источник нашего дохода. Назовем эту сущность Customer’ом

public class Customer {
   private String firstName;
   private String lastName;
   private Date birthDay;
}

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

public class Contract {
   private long customerId;
   private long vehicleId;
}

Итого мы имеем одну иерархию классов с Vehicle на вершине, Customer и Contract. Предлагаю сделать из них VehicleService, ContractService и CustomerService.

Рудиментарную имплементацию сервисов вы можете посмотреть тут.

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

Что бы засунуть наши сервисы в докер нам потребуется плагин для мавена (смотрите в pom.xml docker-maven-plugin) и dockerfile.

Все сервисы мы будем запускать через docker-compose, для этого в корне проекта лежит docker-compose.yml.

Обратите так же внимание на файл .env и его содержимое. Больше об этом файле найдете в документации . Без этого файла у меня на машине с Windows 7 не получилось инициализировать MySQL.

Что у меня получилось?

Начнем с плюсов:

• эта штука работает.

На этом плюсы к сожалению закончились

Минусы:

Их к сожалению очень много, поэтому рассмотрим только пару штук выборочно.

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

К сожалению, избыточность не гарантирует 100% доступность сервисов и поэтому, если есть другой разумный способ поддержания работоспособности системы, то его можно и нужно использовать.

Добавление нового типа транспорта в систему

Итак, для начала спросим себя, правильный ли подход к решению управления транспортными средствами мы применили? Поясню вопрос. Например мы хотим предложить нашим клиентам аренду скутера.

Сейчас VehicleService выглядит вот так.

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

Мы напишем новый класс Scooter в VehicleService, протестим, скомпилим, задеплоим. А если у нас будут десятки типов транспортных средств? Будем каждый раз писать новый класс, тестить, компилить и т.д.? Есть ли другой способ?

Можно, например, сделать так. Сделаем класс VehicleType.

public class VehicleType {
    private String name;
    private List<VehicleProperty> properties;
    ….
}

Как видите у VehicleType есть VehicleProperty:

public class VehicleProperty<T> {
   private String name;
   private T value;
   private String description;
…..
}

Сделаем еще класс Vehicle:

public class Vehicle {
  private VehicleType vehicleType ;
  private List<VehicleProperty> customProperties;
   …...
}

Теперь, если хотим добавить скутер в систему, то мы создадим сначала VehicleType «Scooter»:

VehicleProperty wheelNumberProperty = new VehicleProperty<Integer>("wheelNumber", 2, "number of wheels");
…….
VehicleType scooterType = new VehicleType("Scooter");
 scooterType.addProperty( wheelNumberProperty);
……..

А если нам нужно создать экземпляр скутера:

Vehicle scooter1 = new Vehicle(scooterType);
….. 

Таким образом мы можем добавлять в систему сколько угодно новых типов не создавая новые классы в VehicleService.

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

Следующий момент. Смотрите, если наш VehicleService падает, то мы не можем ни создать новый экземпляр велосипеда в системе (например мы закупили новую партию велосипедов и хотим добавить их в систему), ни арендовать велосипед. Т.е. ни наши клиенты, ни наши сотрудники в офисе ничего сделать не могут. Было бы гораздо лучше, если бы даже в случае проблем в офисе наши клиенты могли бы делать заказы и приносить нам деньги. Как это можно сделать? Похоже надо делить наш VehicleService на два, один для клиентов и один для наших сотрудников.

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

Предположим, опять же, наш VehicleService упал. Это значит, что ни машины, ни велосипеды арендовать нельзя. Было бы не плохо, чтобы если сервис для машин не доступен, то сервис для велосипедов работал бы дальше. Как это можно сделать? Делить VehicleService на несколько сервисов по одному на каждый тип транспортного средства?

На самом деле последние два примера возможных проблем не совсем корректны, т.к. они могут быть решены через избыточность, т.е. должны работать несколько экземпляров сервиса. Но, как я говорил в начале, никакая избыточность не даст 100% доступности. Именно поэтому надо стараться решить вопрос доступности сервиса еще каким нибудь разумным альтернативным способом.

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

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

• Car
• Bicycle
• Scooter
• Traktor
• ……

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

А можно и по другому. При старте каждый сервис должен постучаться к VehicleTypesService сообщить ему о своем существовании. Это решение вроде хорошо выглядит, но не отвечает на вопрос что делать, если нам надо не добавить, а удалить вид транспортного средства. Например, через полгода мы поняли, что моноколесами никто не пользуется, мы хотим удалить его из системы. Как мы это сделаем?

А вот еще интересный вопрос. Как видите у Vehicle есть поле EngineType.

public abstract class Vehicle {
   …...
   protected EngineType engineType;
 

В моей рудиментарной имплементации EngineType имеет enum’ы:

• Gas
• Diesel
• Elektro

А теперь собственно сам вопрос: как мы создадим автомобиль с гибридной силовой установкой?

Сделаем вместо EngineType список EngineType’ов (и тогда у 99% машин вдруг появится список с одним элементом)?

public abstract class Vehicle {
   …...
   protected List<EngineType> engineTypes;
 

А может добавим новый тип в enum, что то вроде Gibrid?

Кто в этом случае принимает решение и, соответственно, несет за него ответственность?

Можно ли сказать, что здесь идет речь об архитектуре или это слишком «мелкий» вопрос?

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

На самом деле тип двигателя конечно же важен, но не для клиента, а для нас, компании, которая этот сервис предоставляет. Одна из причин — статистика (например по затратам на топливо или необходимому ремонту). Она будет сильно различаться для каждого типа двигателя. Отсюда возникает еще один вопрос: а не должны ли быть доменные объекты (или их представления) различными для нашего backend’a и frontend’a?

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

Сложные запросы

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

Как вы видите в таблице содержатся данные из трех микросервисов: CustomerService, VehicleService и ContractService. Как мы будем их собирать вместе? В случае монолита вопрос решается одним запросом в базу, а что делать когда у нас три базы?

Есть разные варианты решения этой маленькой проблемы и в следующий раз мы их обсудим.

История изменений

Однажды кому-нибудь умному захочется выяснить, почему клиенты расторгают или не продлевают договора и уходят к конкурентам? Может в последний раз машина не понравилась/опоздала? А может человек ездил раньше со своим коллегой, который перешел к нашим конкурентам и переманил своего попутчика к ним?

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

Как это можно сделать мы обсудим в следующей статье.

Проблемы с инфраструктурой

Микросервисная архитектура накладывает весьма определенные требования на инфраструктуру всего приложения, а именно, нам нужны

• единая точка входа, он же API Gateway
• поиск сервисов, он же Service Discovery
• одна точка конфигурации, он же Config Service
• центральная точка сбора и анализа логов
• мониторинг
• ……

Эти и другие вопросы в следующей части.

Автор: schroeder

Источник