Привет, хабр. Прямо сейчас в OTUS открыт набор на новый поток курса . В преддверии старта курса хочу поделиться с вами своей авторской статьёй.
Introduzzjoni
L-għażla tal-istil arkitettoniku hija waħda mid-deċiżjonijiet tekniċi fundamentali meta tinbena sistema ta 'informazzjoni. F'din is-serje ta 'artikoli, nipproponi li tanalizza l-aktar stili arkitettoniċi popolari għall-applikazzjonijiet tal-bini u nwieġeb il-mistoqsija ta' meta liema stil arkitettoniku huwa l-aktar preferibbli. Fil-proċess tal-preżentazzjoni, se nipprova nfassal katina loġika li tispjega l-iżvilupp ta 'stili arkitettoniċi minn monoliti għal mikroservizzi.
Ftit storja
Если вы попробуете задать вопрос разработчикам: «Зачем нужны микросервисы?», то вы получите самые различные ответы. Вы услышите, что микросервисы улучшают масштабирование, упрощают понимание кода, улучшают отказоустойчивость, иногда можно услышать, что они позволяют «очистить код». Давайте обратимся к истории, чтобы понять, какую цель приследовало появление микросервисов.
Если говорить вкратце, то микросервисы в нашем текущем понимании возникли следующим образом: в 2011 Джеймс Льюис, анализируя работы различных компаний, обратил внимание на появление нового паттерна «micro-app», который оптимизировал SOA с точки зрения ускорения развертывания сервисов. Несколько позже, в 2012 году, на архитектурном саммите паттерн был переименован в микросервис. Таким образом, первоначальной целью внедрения микросервисов было улучшение пресловутого ħin biex tqiegħed fis-suq.
На «волне хайпа» микросервисы были в 2015 году. По некоторым исследованиям, ни одна конференция не обходилась без доклада на тему микросервисов. Более того, некоторые конференции были посвящены исключительно микросервисам. Сейчас же очень многие проекты начинаются с применением данного архитектурного стиля, а если проект содержит тонны legacy-кода, то наверняка активно осуществляется миграция на микросервисы.
Несмотря на все вышесказанное, до сих достаточно небольшое количество разработчиков может определить понятие «микросервис». Но об этом мы поговорим несколько позже…
Монолит
Архитектурным стилем, противопоставляемом микросервисному, является монолит (или «все в одном»). Что такое монолит рассказывать, наверное, не имеет смысла, поэтому я сразу перечислю недостатки этого архитектурного стиля, которые инициировали дальнейшее развитие архитектурных стилей: размер, связанность, развертывание, масштабируемость, надежность и косность. Ниже я предлагаю озномится с каждым из недостатков отдельно.
Daqs
Монолит очень большой. И общается он как правило с очень большой базой данных. Приложение становится слишком большим, чтобы его мог понять один разработчик в принципе. С монолитом хорошо работать могут только те, кто провел за этим кодом достаточно много времени, тогда как новички потратят очень много времени на попытки разобраться с монолитом и не факт, что разберутся. Обычно при работе с монолитом всегда есть некоторый «условный» senior, который знает монолит более-менее хорошо и бьет по рукам в течении года-полутора других новых разработчиков. Естественно, что такой условный senior является единой точкой отказа, и его уход может привести к гибели монолита.
Связанность
Монолит представляет из себя «большой комок грязи» (big ball of mud), изменения в котором могут привести к непредсказуемым последствиям. Внося изменения в одном месте, можно повредить монолит в другом (то самое «ухо почесал, *@ отвалилась»). Связано это с тем, что компоненты в монолите имеют очень сложные и, главное, неочевидные взаимосвязи.
Skjerament
Развертывание монолита ввиду сложных взаимосвязей между его компонентами — это долгий процесс со своим ритуалом. Такой ритуал обычно не окончательно стандартизирован и передается «из уст в уста».
Skalabbiltà
Модули монолита могут иметь конфликтующие потребности в ресурсах, из-за чего необходимо искать компромисс с точки зрения железа. Представьте себе, что у вас монолит состоит из сервисов A и B. Сервис A требователен к размеру жесткого диска, а сервис B — к оперативной памяти. В таком случае, либо машина, на которую ставится монолит, должна поддерживать требования обоих сервисов, либо придется руками, искуственно один из сервисов отключать.
Еще один пример (более классический): сервис A намного более популярен, чем сервис B, поэтому вы хотите, чтобы сервисов A было 100, а сервисов B было 10. Опять-таки два варианта: либо разворачиваем 100 полноценных монолитов, либо на каких-то из них руками сервисы B придется отключать.
Affidabilità
Поскольку все сервисы находятся вместе, если монолит падает, то падают все сервисы сразу. На самом деле, возможно это не так уж и плохо, по крайней мере частичных отказов в распределенной системе не будет, но с другой стороны, из-за ошибки в функциональности, которую использует 0.001% пользователей, вы можете потерять всех пользователей вашей системы.
Косность
Ввиду размера монолита тяжело перейти на новые технологии. Как следствие, отдельной задачей вырисовывает удержание того самого условного senior’а. Выбранный на старте проекта технологический стек может стать блоком, препятствующим развитию продукта.
Konklużjoni
В следующий раз мы поговорим о том, как люди попытались решить обозначенные проблемы, перейдя к компонентам и SOA.
Aqra iktar:
Sors: www.habr.com