Позвольте задать вам вопрос - как вы подходите к сложной проблеме?
Если ваш ответ - «разбейте на более мелкие проблемы и решайте каждую проблему индивидуально», то, по-видимому, мы думаем так же!
Мы можем использовать эту технику решения проблем для создания сложных систем и даже заставить их работать (в конечном итоге).
Прежде чем говорить об архитектуре микросервисов, важно сначала определить, что такое архитектура микросервисов:
Архитектурный стиль микросервисов - это подход к разработке одного приложения как набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует с легковесными механизмами - Мартин Фаулер
Теперь, когда у нас есть определение, я хотел бы поделиться историей, которая объяснит, почему я решил реализовать его в своих собственных системах.
Я бэкэнд-разработчик в WSC Sports - мы помогаем правообладателям увеличивать объем своего контента с помощью автоматизированных, почти в реальном времени, автоматических * автоматических * выделений. В рамках своей работы я проектирую и создаю масштабируемые системы реального времени. И давайте посмотрим правде в глаза, это огромная проблема - подумать о будущем вашей новой системы, прежде чем вы напишете хоть одну строчку кода.
Когда я начал разрабатывать архитектуру своей системы, я задал себе три вопроса:
1. Нужно ли поддерживать большие масштабы?
2. Нужно ли быстро?
3. Легко ли будет поддерживать?
Иногда вы просто не знаете, как сразу ответить на эти вопросы, поэтому я решил построить монолитную систему.
Я выбрал монолит, потому что его можно было быстро программировать, легко контролировать и даже он работал довольно быстро. Система работала нормально, пока однажды ночью система не начала выполнять огромное количество заданий. Хуже того, было не только больше рабочих мест, чем ожидалось, но и каждая работа была больше и сложнее, чем у нас было раньше. В конце концов, в ту ночь из-за этого система работала очень медленно, и нам пришлось решать проблему как можно скорее. Быстрое решение заключалось в том, чтобы масштабировать нашу систему, чтобы она могла обрабатывать большое количество запросов и обрабатывать их в приличное количество времени.
Проблема с масштабированием системы заключалась в том, что нам пришлось запускать ее на дорогих машинах, чтобы убедиться, что она сможет справиться с таким масштабом в ближайшем будущем (даже если большую часть времени нам нужно выполнять только небольшие задания. , в меньшем масштабе).
В ту ночь я понял, что что-то нужно изменить, поэтому я начал думать о новой архитектуре для моей системы.
Да, вы правильно угадали, я выбрал архитектуру микросервисов, и вот некоторые из причин, почему:
- Он может обрабатывать большие масштабы (масштабирование при необходимости)
- В случае сбоя системы можно быстро исправить проблему и развернуть обновленный микросервис вместо всей системы.
- По прошествии времени системы часто требуют рефакторинга, и это была прекрасная возможность отделить компоненты системы и упростить их тестирование.
Я начал разбивать мою монолитную систему на небольшие логические блоки. Каждый логический блок несет единственную ответственность, он не связан и не имеет состояния, и все эти логические блоки взаимодействуют с помощью очередей.
Этот процесс изменения архитектуры научил меня не усложнять задачу! Это значительно упрощает процесс отладки и решение проблем, а также упрощает чтение вашего кода. Еще одна вещь, которая мне очень помогла, - это хорошо спланированный поток CI \ CD, который облегчил мне жизнь, когда мне нужно было обновить или исправить некоторые ошибки (даже если мой код совсем не содержит ошибок!) В одном или нескольких код микросервисов.
И последнее: мониторинг производительности вашей системы имеет решающее значение и прост при использовании микросервисов (с использованием журналов, отчетов бизнес-аналитики, предупреждений о резервных ресурсах и т. Д.), Поэтому убедитесь, что вы это делаете. Вы сразу узнаете, какие микросервисы являются узким местом в вашей системе, и сможете их исправить.
В конце концов, изменение архитектуры с монолитной на ориентированную на микросервисы оказалось не так быстро и легко, как я ожидал. Но переход на архитектуру микросервисов помог нашей команде разработчиков решить проблемы, с которыми мы часто сталкивались раньше, например, избежать единой точки отказа, чтобы мы могли исправить этот сценарий до того, как он когда-либо случился. Масштабирование больше не было проблемой, и производительность системы стала лучше даже с более дешевыми серверами, чем требовалась монолитная система.
Я хочу подчеркнуть один важный момент: хотя микросервисная архитектура становится все более и более популярной среди разработчиков программного обеспечения, возможно, вы не захотите прыгать с пистолета и реализовать свою систему так, чтобы она была ориентирована на микросервисы. Если ваша система не должна быть сложной, большой и поддерживать крупномасштабную, то монолитный или другие подходы все же могут быть лучше подходящими для вашей системы.
Удачи!
