«Это 9-й день моего участия в ноябрьском испытании обновлений, ознакомьтесь с подробностями события:Вызов последнего обновления 2021 г."

Привет, я смотрю на гору.

Преимуществ у микросервисов много, в настоящее время, если кто не слышал о микросервисной архитектуре, может поучиться уЧто такое микросервисыУзнать о. В этой статье в основном говорится о том, стоит ли тратить время на рефакторинг монолитной архитектуры в архитектуру микросервисов?

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

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

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

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

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

to be or not to be

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

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

Микросервисная архитектура

Что такое микросервисная архитектура? По словам Сэма Ньюмана: «Набор небольших автономных сервисов, которые работают вместе друг с другом и смоделированы на основе бизнес-домена».

Сервисы в микросервисной архитектуре — это бизнес-модули, извлекаемые в соответствии с бизнес-возможностями, которые разрабатываются и развертываются независимо друг от друга, но должны взаимодействовать друг с другом для выполнения всей бизнес-функции. Сервис — это не просто компонент хранения данных, это база данных. Это не простая логическая функциональная единица, это функция. Только если он включает в себя данные + логику одновременно, он может быть сервисом в истинном смысле.

граница обслуживания

Во время демонтажа службы можно использовать DDD (Domain Driven Design) в качестве руководства для микросервисной архитектуры. Поскольку микросервисы определяют сервисы вокруг бизнес-функций и определяют команды в соответствии с сервисами, это точно так же, как методология DDD по разделению бизнес-доменов на бизнес-поддомены и определению ограниченных контекстов.Поэтому DDD служит для микросервисов ориентиром для быстрого определения каждого компонента сервиса. Завершите миграцию с монолитной архитектуры на архитектуру микросервисов.

Альберто Брандолини предложил способ определения контекста службы под названием «Event Storming». Первый шаг — определить, что происходит в бизнес-сфере, то есть наше внимание сосредоточено на поведении, а не на структурах данных. Преимущество этого заключается в том, что различные службы в системе слабо связаны, и одна служба может быть автономной.

После определения границы службы необходимо определить границу транзакции. Раньше наша служба находилась в процессе, за которым стояла база данных, и транзакция могла выбрать строго непротиворечивую транзакцию, то есть ACID. Когда количество сервисов увеличивается и взаимодействует друг с другом, в это время можно использовать транзакцию окончательной согласованности, которая является BASE. В отличие от ACID, BASE является более гибким, если в конечном итоге данные могут быть непротиворечивыми. Этот окончательный диапазон времени, в зависимости от различных бизнес-сценариев, может составлять минуты, часы, дни или даже недели или месяцы.

Готов к работе

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

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

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

Эволюция или революция?

После определения границы сервиса остается решить проблему: то ли постепенно развивать и обновлять систему, то ли перестраивать всю систему, ломая лодку.

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

Transformation

Как постепенно перейти на микросервисную архитектуру? Ниже представлена пошаговая демонстрация:

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

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

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

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

Последним шагом является разделение слоя пользовательского представления.

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

критерий успеха

Когда мы закончим весь процесс обновления, пришло время проверить, получаем ли мы ожидаемые результаты. Цель внедрения микросервисов — улучшить процесс разработки в первую очередь, что мы можем измерить простыми метриками:

Цикл разработки: продолжительность от концепции до запуска
Эффективность разработки: функции или пользовательские истории, выполненные командами или отдельными лицами в единицу времени.
Масштабируемость системы
Среднее время ремонта: время, необходимое для поиска и устранения проблемы.

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

самое главное

Как осадные львы, мы гордимся тем, что можем решить или улучшить мир вокруг нас, и одержимы поиском решений. В то же время мы также должны понимать, что каждое приложенное нами усилие должно быть вознаграждено. Рефакторинг и обновление, не приносящие никакой отдачи, — пустая трата времени.

От монолитной архитектуры к микросервисной архитектуре