Не кодируйте свой микросервис как монолит, сделайте его восстанавливаемым и не перегруженным
Будете ли вы использовать пистолет, чтобы убить муху? Ответ - нет. То же самое происходит, когда вы хотите написать приложение для микросервиса, которое будет содержать не более 10 тыс. строк кода. Не переусердствуйте. Хорошо, вы пишете и поддерживаете большие базы кода. Некоторые могут составлять более 100 тыс. строк кода, но вам нужно преодолеть свои привычки и подумать по-другому. Этот пост поможет вам разгадать тайны написания небольших и обслуживаемых микросервисов. Предложения построены самоуверенно, но они основаны на практике в бизнесе на миллион долларов.
TLDR;
Микросервисы - это небольшие программные системы. Вы можете безопасно протолкнуть MVC. Скажите «нет» ORM, а также не принимайте дизайн шаблона для микросервисов. Сосредоточьтесь на производительности, читаемости и восстанавливаемости кода, а не на некоторых старых правилах и шаблонах. Эти шаблоны были сделаны, когда люди не занимались микросервисами.
Зачем писать микросервисы в первую очередь?
Архитектура микросервисов способна, разбить один или несколько монолитов на несколько меньших систем. Это более удобные, независимо разработанные и развернутые части программного обеспечения на основе бизнес-функций. Эти меньшие (предположительно «микро») системы должны сосредоточиться только на одной бизнес-функции и делать это хорошо. Выгода здесь заключена в «микро», эти части в идеале должны быть под 10 тыс. строк кода.
Поскольку они независимы, это помогает бизнесу быстрее выпускать функции. Команда отгрузки не зависит от команды проверки. То, что развернуто в приложении для доставки, никогда не будет нарушать проверку. Он становится очень развязанным. Радиус поражающего действия каждого изменения контролируется. Это является причиной быстрого принятия микросервисов.
Теперь давайте посмотрим, как вы привыкли к тому, что делаете, и почему это имеет меньше смысла в эпоху микросервисов.
Нужен ли вам MVC?
Model-View-Controller знаком многим из нас уже более 10 лет. И многим из нас он казался серебряной пулей для всех проблем с архитектурой программного обеспечения. Пора посмотреть на него с другой стороны. Да, вы использовали для работы с Java или PHP, и каждая другая структура была основана на MVC. Теперь вам больше не нужно быть строгим в отношении MVC. Сосредоточьтесь на ясности и результате.
Используйте контроллеры, если хотите, и если это все еще имеет смысл. Подумайте, как приложение получает HTTP-запрос и дает ответ HTTP. Подумайте, есть ли API-интерфейс бэкэнд и интерфейсы, потребляющие его. Проверьте код ниже, это, конечно, не MVC:
|
async function get(params) { |
|
|
const today = new Date().toISOString().split('T')[0]; |
|
|
const {fromCurrency='AUD', toCurrency='USD', onDate=today} = params; |
|
|
|
|
|
let exchangeRates = await db.query( |
|
|
`SELECT rate, created_at FROM exchange_rates WHERE from_currency = ? AND to_currency = ? AND on_date = ?`, |
|
|
[fromCurrency, toCurrency, onDate] |
|
|
); |
|
|
|
|
|
if (exchangeRates.length) { |
|
|
const rate = Number(exchangeRates[0].rate); |
|
|
console.log(`Found exchange rate of ${rate} for ${fromCurrency} to ${toCurrency} of ${onDate} in the db`); |
|
|
return {fromCurrency, toCurrency, onDate, rate}; |
|
|
} |
|
|
return getExternal(fromCurrency, toCurrency, onDate); |
|
|
} |
|
|
|
|
|
module.exports = { |
|
|
get |
|
|
} |
Поэтому вместо того, чтобы делать точные строки M-V-C, пишите тесты и осуществляйте непрерывную интеграцию. Добавьте в приложение несколько журналов и мониторинг. Сделайте код удобным, сохраняйте его как можно в более простом состоянии.
Не берите на себя накладные расходы ОРМ
Object Relation Mapping (ORM) когда-то считалась одной из лучших вещей, когда-либо известных программистам. Спустя 10 лет следует быть осторожным, чтобы предложить ORM какому-либо программисту.
Data Mapper или Active record привносят свои собственные мнения, способы делать вещи и лишний вес. Это не только вызывает проблемы с производительностью, но и читаемость кода. Подумайте о событиях и перехватах, которые имеет слушатель Doctrine до и после, они работают как магия, а магию всегда сложно понять.
Просто попробуйте это, объясните, как связанный с ORM код вставки работает VS, как простой и прямой INSERT SQL-запрос работает с новичком или младшим инженером-программистом. Вы уже пожалеете об использовании этой ORM. Особенно в контексте микросервисов ORM - это накладные расходы. Предполагается, что микросервис будет иметь максимум 10 тыс. строк кода и вряд ли повлияет на 10 таблиц, поэтому просто не используйте период ОРМ.
Шаблоны проектирования могут быть багажом
Мы не имеем ввиду, что вам не нужно изучать шаблоны разработки программного обеспечения. Вы должны знать о SOLID, законе Деметры, шаблоне “фабрики”, стратегической модели, singleton, шаблоне “адаптера” и т. д. Ну, большинство из них имеет смысл, если вы делаете объектно-ориентированное программирование правильно? Что делать, если вы пишете микросервис в Node JS, который составляет 1 тыс. строк кода, распространяемых через ~ 7 файлов. Он делает один небольшой кусок бизнес-функции. Все эти шаблоны хороши, когда ими правильно пользуешься.
Шаблоны проектирования имеют отношение к кодовой базе, которая уже и так большая, а в ближайшие 6-12 месяцев будет еще больше. Они могут оказаться «лишним багажом» для услуги, которая составляет сотни строк кода, а в ближайшие 6-12 месяцев станут тысячами строк кода. Мы никогда не предвидим, что она будет больше, потому что для этой другой части у нас будет еще один микросервис. Поэтому держите ваш код микросервиса без лишнего жира и хорошо протестированным.
Заключение
Если вы все еще хотите закодировать свой микросервис, как последний монолит, над которым вы работали, возможно, вы делаете что-то неправильно. Подумайте об этом еще раз, как если бы вы отправились на однодневную поездку, вы же не упаковываете и не переносите вещи, как если бы вы собираетесь на 2-недельный отпуск. Подумайте о производительности кода и его восстанавливаемости, пусть данные говорят за вас и нарушают правила. Успешной разработки программного обеспечения!