Привет, хабр. Прямо сейчас в OTUS открыт набор на новый поток курса . В преддверии старта курса хочу поделиться с вами своей авторской статьёй.
परिचय
सूचना प्रणाली का निर्माण करते समय वास्तुशिल्प शैली का चुनाव मूलभूत तकनीकी निर्णयों में से एक है। लेखों की इस श्रृंखला में, मैं निर्माण अनुप्रयोगों के लिए सबसे लोकप्रिय वास्तुशिल्प शैलियों का विश्लेषण करने और इस सवाल का जवाब देने का प्रस्ताव करता हूं कि कब कौन सी वास्तुशिल्प शैली सबसे बेहतर है। प्रस्तुति की प्रक्रिया में, मैं एक तार्किक श्रृंखला खींचने की कोशिश करूंगा जो मोनोलिथ से माइक्रोसर्विसेज तक वास्तुशिल्प शैलियों के विकास की व्याख्या करती है।
एक छोटा सा इतिहास
Если вы попробуете задать вопрос разработчикам: «Зачем нужны микросервисы?», то вы получите самые различные ответы. Вы услышите, что микросервисы улучшают масштабирование, упрощают понимание кода, улучшают отказоустойчивость, иногда можно услышать, что они позволяют «очистить код». Давайте обратимся к истории, чтобы понять, какую цель приследовало появление микросервисов.
Если говорить вкратце, то микросервисы в нашем текущем понимании возникли следующим образом: в 2011 Джеймс Льюис, анализируя работы различных компаний, обратил внимание на появление нового паттерна «micro-app», который оптимизировал SOA с точки зрения ускорения развертывания сервисов. Несколько позже, в 2012 году, на архитектурном саммите паттерн был переименован в микросервис. Таким образом, первоначальной целью внедрения микросервисов было улучшение пресловутого बाजार का समय.
На «волне хайпа» микросервисы были в 2015 году. По некоторым исследованиям, ни одна конференция не обходилась без доклада на тему микросервисов. Более того, некоторые конференции были посвящены исключительно микросервисам. Сейчас же очень многие проекты начинаются с применением данного архитектурного стиля, а если проект содержит тонны legacy-кода, то наверняка активно осуществляется миграция на микросервисы.
Несмотря на все вышесказанное, до сих достаточно небольшое количество разработчиков может определить понятие «микросервис». Но об этом мы поговорим несколько позже…
एकाश्म
Архитектурным стилем, противопоставляемом микросервисному, является монолит (или «все в одном»). Что такое монолит рассказывать, наверное, не имеет смысла, поэтому я сразу перечислю недостатки этого архитектурного стиля, которые инициировали дальнейшее развитие архитектурных стилей: размер, связанность, развертывание, масштабируемость, надежность и косность. Ниже я предлагаю озномится с каждым из недостатков отдельно.
आकार
Монолит очень большой. И общается он как правило с очень большой базой данных. Приложение становится слишком большим, чтобы его мог понять один разработчик в принципе. С монолитом хорошо работать могут только те, кто провел за этим кодом достаточно много времени, тогда как новички потратят очень много времени на попытки разобраться с монолитом и не факт, что разберутся. Обычно при работе с монолитом всегда есть некоторый «условный» senior, который знает монолит более-менее хорошо и бьет по рукам в течении года-полутора других новых разработчиков. Естественно, что такой условный senior является единой точкой отказа, и его уход может привести к гибели монолита.
Связанность
Монолит представляет из себя «большой комок грязи» (big ball of mud), изменения в котором могут привести к непредсказуемым последствиям. Внося изменения в одном месте, можно повредить монолит в другом (то самое «ухо почесал, *@ отвалилась»). Связано это с тем, что компоненты в монолите имеют очень сложные и, главное, неочевидные взаимосвязи.
तैनाती
Развертывание монолита ввиду сложных взаимосвязей между его компонентами — это долгий процесс со своим ритуалом. Такой ритуал обычно не окончательно стандартизирован и передается «из уст в уста».
scalability
Модули монолита могут иметь конфликтующие потребности в ресурсах, из-за чего необходимо искать компромисс с точки зрения железа. Представьте себе, что у вас монолит состоит из сервисов A и B. Сервис A требователен к размеру жесткого диска, а сервис B — к оперативной памяти. В таком случае, либо машина, на которую ставится монолит, должна поддерживать требования обоих сервисов, либо придется руками, искуственно один из сервисов отключать.
Еще один пример (более классический): сервис A намного более популярен, чем сервис B, поэтому вы хотите, чтобы сервисов A было 100, а сервисов B было 10. Опять-таки два варианта: либо разворачиваем 100 полноценных монолитов, либо на каких-то из них руками сервисы B придется отключать.
विश्वसनीयता
Поскольку все сервисы находятся вместе, если монолит падает, то падают все сервисы сразу. На самом деле, возможно это не так уж и плохо, по крайней мере частичных отказов в распределенной системе не будет, но с другой стороны, из-за ошибки в функциональности, которую использует 0.001% пользователей, вы можете потерять всех пользователей вашей системы.
Косность
Ввиду размера монолита тяжело перейти на новые технологии. Как следствие, отдельной задачей вырисовывает удержание того самого условного senior’а. Выбранный на старте проекта технологический стек может стать блоком, препятствующим развитию продукта.
निष्कर्ष
В следующий раз мы поговорим о том, как люди попытались решить обозначенные проблемы, перейдя к компонентам и SOA.
अधिक पढ़ें:
स्रोत: www.habr.com