Введение

Соответствующие преимущества микрослужб и монолитных служб были объяснены в предыдущей статье. Эта статья не о том, какую сервисную архитектуру следует использовать. Вместо этого предполагается, что проект в конечном итоге примет микросервисную архитектуру, тогда будут две ситуации: в первом случае, когда проект стартует, он сначала использует один сервис, а затем постепенно преобразует его в микросервис в процессе разработки проекта. Один из них — начать с микросервисной архитектуры.

В этой статье будут обсуждаться причины обоих подходов.

Сначала монолиты, потом микросервисы

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

Поскольку использование самого Micro Service находится на расходы на управление услугами, эта стоимость замедлит скорость команды разработки. Так что для более простых приложений, использование одиночного обслуживания проще. Таким образом, сторонники этого подхода следует учитывать в начальных сборках новых приложений как единое приложение, даже если финал, вероятно, будет преобразован в Micro-Services.

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

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

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

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

Другой — полностью заменить монолитное приложение. Таким образом, вы можете полностью избавиться от архитектурного бремени, связанного с монолитом, и начать все сначала. Цена в том, что это требует больше сил и времени.

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

Начните напрямую с микросервисов

Конечно, есть и люди, придерживающиеся иного мнения, потому что они думают:

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

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

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

Теоретически вам не нужны микросервисы, если ваша программа следует определенным правилам и устанавливает четкую границу внутри монолитного приложения, но на практике эта граница всегда будет междоменной.

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

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

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

Суммировать

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

Эта статья была включена вWoohoo. Floyd press.com/10-micros и…

Самая популярная интерпретация, самая глубокая галантерея, самые краткие уроки и множество трюков, о которых вы не знаете, ждут вас!