Не пишите ваш микросервис как монолит, оставляйте его поддерживаемым и не избыточным.

Вы будете использовать ружьё для того  чтобы застрелить муху? Разумеется нет. Тот же принцип следует использовать когда вы пишете приложение микросервиса, размер которого не будет превышать 10К строк кода. Не делайте код избыточным. Допустим у вас есть большой код который вы поддерживаете. Это может быть 100К+ строк кода, но вам следует изменить вашим привычкам и начать думать по-другому. Эта публикация позволит вам приобщится к магии написания простого кода для микросервисов, который легко поддерживать. Предложения могут оказаться самоуверенными, но на практике это происходит в бизенесе за миллионы доларов.

TL;DR

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

Зачем писать микросервисы в первую очередь

Архитектура микросервисов, по моему мнению, призвана разбить один или несколько монолитов на множество небольших систем. Они более гибки в поддержке, разрабатываются независимо и в строгом соответствии с со своим предназначением. Эти маленькие системы ( поэтому из и называют «микро») должны фокусироваться только на своей бизнес задаче и делать это хорошо. Ключевым моментом здесь является «микро» - код не должен превышать 10К строк.

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

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

Вам нужен MVC?

С паттерном Модель-Представление-Контроллер (MVC) я познакомился в 2007 или может чуть раньше. С тех пор я думал что это серебрянная пуля для любой архитектуры программного обеспечения. Но больше я не придерживаюсь такого мнения. Да вы привыкли работать с Java или PHP и там любой фреймворк построен на 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
	}

Вы можете посмотреть полное приложение здесь, и обратите внимание, это точно не MVC.

Поэтому вместо того, что бы следовать каждой букве M-V-C, пишите тесты, реализуйте непрерывную интеграцию. Добавьте лог и прочие средства для мониторнига приложения. Пишите максимально простой код, который легко поддерживать.

Не переусердствуйте с ORM

Когда я впервые познакомился с ORM (Object Relation Mapping), я сказал сам себе что это самая крутая штука для программистов которую я видел. Спустя более чем 10 лет, я бы остерегался предлагать использовать ORM для любых случаев. Недавно я занимался рефакторингом и заменял реализацию полной ORM в чистыми вызовами SQL запросов. В результате я получил 20% прироста производительности. В дополнение к этому я начал непосредственно использовать транзакции и сделал код намного чище и понятней.

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

Вот просто попробуйте объяснить молодому специалисту как ORM добавляет данные и как данные добавляются с помощью INSERT SQL. Вы уже пожалели что используете ORM. И особенно в контексте микросервисов ORM выглядит чрезмерной. Микросервисы должны быть не более 10К строк кода, и использовать как максимум с десяток таблиц, поэтому не используйте ORM. Точка.

Паттерны проектирования могут быть обузой

Я ни в коем случае не говорю не изучать паттерны проектирования. Вы должы знать о SOLID, закона Деметры, паттерне фабрики, стратегии, синглтона, адаптера и прочих. Все это полезно если вы имеете дело с объектно –ориентированным программированием, верно? А что если вы пишете микросервис с помощью Node.js когда 1К сток кода разбиты на 7 файлов. Код просто решает некую бизнес задачу. Все эти паттерны для данного случая становятся не более чем полезной ерундой.

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

Выводы

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

Источник: https://hackernoon.com/dont-code-your-microservice-like-a-monolith-keep-it-maintainable-not-over-engineered-19f9d5d70f79

Успешный переход к микросервисам: зачем, когда и как

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

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

Архитектура микросервисов (MSA) – это ответ на проблемы связанные с традиционным монолитом, когд его сложность начинает порождать проблемы но требует дальнейшего масштабирования.

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

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

Почему: Роль микросервисов в разработке корпоративных систем

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

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

Преимущества и сложности микросервисов

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

Преимущества:

 - Независимые элементы. Система может работать без наличия одного или нескольких составных элементов.

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

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

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

 Недостатки:

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

 - Тестирование. Архитектура монолита использует сторонний WAR. QA специалисту нужно лишь запустить файл и подтвержить соединение монолита и базы данных. В микросервисах необходимо выполнять подобную проверку для каждого микросервиса.

Когда: Правильное время для перехода к архитектуре микросервисов

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

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

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

Как: Способы перехода к микросервисам

Как интегрировать микросервисы в монолитное приложение? Есть два фундаментальных подхода:

1. Разбить монолит на микросервисы

Это сложый и дорогой вариант. Полная переделка приложения потребует до года изнурительной работы. Такой проект требует талантливых и опытных специалистов поскольку микросервисы – это не простая архитектура и MSA экпертиза сложна сама по себе.

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

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

2. Сохранить монолит и строить микросервисы вокруг него

Поскольку ваша изначальная архитектура работает хорошо, то зачем ее ломать?

Когда ваша команда становиться слишком большая для того что бы поддерживать монолит и добавлять новую функциональность, возможный вариант дальнейшего развития продукта – это микросервисы. Таким образом, новые сотрудники работают как подкоманды, в то время как основные ~25 разработчиков продолжают трудится над монолитом. Монолит становится большим макросервисом, и собирает вокруг себя прочие микросервисы.

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

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

Завершение

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

Источник: https://dzone.com/articles/successful-migration-to-microservices-why-when-and