Arxitektura uslubini tanlash (1-qism)

Привет, хабр. Прямо сейчас в OTUS открыт набор на новый поток курса "Dasturiy ta'minot arxitektori". В преддверии старта курса хочу поделиться с вами своей авторской статьёй.

kirish

Arxitektura uslubini tanlash axborot tizimini qurishda asosiy texnik qarorlardan biridir. Ushbu maqolalar turkumida men ilovalarni qurish uchun eng mashhur me'moriy uslublarni tahlil qilishni va qaysi me'moriy uslub qachon afzalroq ekanligi haqidagi savolga javob berishni taklif qilaman. Taqdimot jarayonida men monolitlardan mikroservislarga qadar me'moriy uslublarning rivojlanishini tushuntiruvchi mantiqiy zanjirni chizishga harakat qilaman.

Biroz tarix

Если вы попробуете задать вопрос разработчикам: «Зачем нужны микросервисы?», то вы получите самые различные ответы. Вы услышите, что микросервисы улучшают масштабирование, упрощают понимание кода, улучшают отказоустойчивость, иногда можно услышать, что они позволяют «очистить код». Давайте обратимся к истории, чтобы понять, какую цель приследовало появление микросервисов.

Если говорить вкратце, то микросервисы в нашем текущем понимании возникли следующим образом: в 2011 Джеймс Льюис, анализируя работы различных компаний, обратил внимание на появление нового паттерна «micro-app», который оптимизировал SOA с точки зрения ускорения развертывания сервисов. Несколько позже, в 2012 году, на архитектурном саммите паттерн был переименован в микросервис. Таким образом, первоначальной целью внедрения микросервисов было улучшение пресловутого bozorga chiqish vaqti.

На «волне хайпа» микросервисы были в 2015 году. По некоторым исследованиям, ни одна конференция не обходилась без доклада на тему микросервисов. Более того, некоторые конференции были посвящены исключительно микросервисам. Сейчас же очень многие проекты начинаются с применением данного архитектурного стиля, а если проект содержит тонны legacy-кода, то наверняка активно осуществляется миграция на микросервисы.

Несмотря на все вышесказанное, до сих достаточно небольшое количество разработчиков может определить понятие «микросервис». Но об этом мы поговорим несколько позже…

Монолит

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

hajmi

Монолит очень большой. И общается он как правило с очень большой базой данных. Приложение становится слишком большим, чтобы его мог понять один разработчик в принципе. С монолитом хорошо работать могут только те, кто провел за этим кодом достаточно много времени, тогда как новички потратят очень много времени на попытки разобраться с монолитом и не факт, что разберутся. Обычно при работе с монолитом всегда есть некоторый «условный» senior, который знает монолит более-менее хорошо и бьет по рукам в течении года-полутора других новых разработчиков. Естественно, что такой условный senior является единой точкой отказа, и его уход может привести к гибели монолита.

Связанность

Монолит представляет из себя «большой комок грязи» (big ball of mud), изменения в котором могут привести к непредсказуемым последствиям. Внося изменения в одном месте, можно повредить монолит в другом (то самое «ухо почесал, *@ отвалилась»). Связано это с тем, что компоненты в монолите имеют очень сложные и, главное, неочевидные взаимосвязи.

Joylashtirish

Развертывание монолита ввиду сложных взаимосвязей между его компонентами — это долгий процесс со своим ритуалом. Такой ритуал обычно не окончательно стандартизирован и передается «из уст в уста».

Miqyosi

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

Еще один пример (более классический): сервис A намного более популярен, чем сервис B, поэтому вы хотите, чтобы сервисов A было 100, а сервисов B было 10. Опять-таки два варианта: либо разворачиваем 100 полноценных монолитов, либо на каких-то из них руками сервисы B придется отключать.

Ishonchlilik

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

Косность

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

xulosa

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

Ko'proq o'qish:

• Почему SQL Server не гарантирует сортировку результатов без ORDER BY
• Архитектура для разработчиков и админов: кому какие навыки нужны?

Manba: www.habr.com