Привет, хабр. Прямо сейчас в OTUS открыт набор на новый поток курса . В преддверии старта курса хочу поделиться с вами своей авторской статьёй.
導入
アーキテクチャ スタイルの選択は、情報システムを構築する際の基本的な技術的決定の XNUMX つです。 この一連の記事では、建築用途で最も一般的な建築スタイルを分析し、どのような建築スタイルが最も好ましいかという質問に答えることを提案します。 プレゼンテーションの過程で、モノリスからマイクロサービスに至るアーキテクチャ スタイルの発展を説明する論理的な連鎖を描こうとします。
歴史を少し
Если вы попробуете задать вопрос разработчикам: «Зачем нужны микросервисы?», то вы получите самые различные ответы. Вы услышите, что микросервисы улучшают масштабирование, упрощают понимание кода, улучшают отказоустойчивость, иногда можно услышать, что они позволяют «очистить код». Давайте обратимся к истории, чтобы понять, какую цель приследовало появление микросервисов.
Если говорить вкратце, то микросервисы в нашем текущем понимании возникли следующим образом: в 2011 Джеймс Льюис, анализируя работы различных компаний, обратил внимание на появление нового паттерна «micro-app», который оптимизировал SOA с точки зрения ускорения развертывания сервисов. Несколько позже, в 2012 году, на архитектурном саммите паттерн был переименован в микросервис. Таким образом, первоначальной целью внедрения микросервисов было улучшение пресловутого 市場投入までの時間.
На «волне хайпа» микросервисы были в 2015 году. По некоторым исследованиям, ни одна конференция не обходилась без доклада на тему микросервисов. Более того, некоторые конференции были посвящены исключительно микросервисам. Сейчас же очень многие проекты начинаются с применением данного архитектурного стиля, а если проект содержит тонны legacy-кода, то наверняка активно осуществляется миграция на микросервисы.
Несмотря на все вышесказанное, до сих достаточно небольшое количество разработчиков может определить понятие «микросервис». Но об этом мы поговорим несколько позже…
モノリス
Архитектурным стилем, противопоставляемом микросервисному, является монолит (или «все в одном»). Что такое монолит рассказывать, наверное, не имеет смысла, поэтому я сразу перечислю недостатки этого архитектурного стиля, которые инициировали дальнейшее развитие архитектурных стилей: размер, связанность, развертывание, масштабируемость, надежность и косность. Ниже я предлагаю озномится с каждым из недостатков отдельно.
サイズ
Монолит очень большой. И общается он как правило с очень большой базой данных. Приложение становится слишком большим, чтобы его мог понять один разработчик в принципе. С монолитом хорошо работать могут только те, кто провел за этим кодом достаточно много времени, тогда как новички потратят очень много времени на попытки разобраться с монолитом и не факт, что разберутся. Обычно при работе с монолитом всегда есть некоторый «условный» senior, который знает монолит более-менее хорошо и бьет по рукам в течении года-полутора других новых разработчиков. Естественно, что такой условный senior является единой точкой отказа, и его уход может привести к гибели монолита.
Связанность
Монолит представляет из себя «большой комок грязи» (big ball of mud), изменения в котором могут привести к непредсказуемым последствиям. Внося изменения в одном месте, можно повредить монолит в другом (то самое «ухо почесал, *@ отвалилась»). Связано это с тем, что компоненты в монолите имеют очень сложные и, главное, неочевидные взаимосвязи.
配備
Развертывание монолита ввиду сложных взаимосвязей между его компонентами — это долгий процесс со своим ритуалом. Такой ритуал обычно не окончательно стандартизирован и передается «из уст в уста».
スケーラビリティ
Модули монолита могут иметь конфликтующие потребности в ресурсах, из-за чего необходимо искать компромисс с точки зрения железа. Представьте себе, что у вас монолит состоит из сервисов A и B. Сервис A требователен к размеру жесткого диска, а сервис B — к оперативной памяти. В таком случае, либо машина, на которую ставится монолит, должна поддерживать требования обоих сервисов, либо придется руками, искуственно один из сервисов отключать.
Еще один пример (более классический): сервис A намного более популярен, чем сервис B, поэтому вы хотите, чтобы сервисов A было 100, а сервисов B было 10. Опять-таки два варианта: либо разворачиваем 100 полноценных монолитов, либо на каких-то из них руками сервисы B придется отключать.
信頼性
Поскольку все сервисы находятся вместе, если монолит падает, то падают все сервисы сразу. На самом деле, возможно это не так уж и плохо, по крайней мере частичных отказов в распределенной системе не будет, но с другой стороны, из-за ошибки в функциональности, которую использует 0.001% пользователей, вы можете потерять всех пользователей вашей системы.
Косность
Ввиду размера монолита тяжело перейти на новые технологии. Как следствие, отдельной задачей вырисовывает удержание того самого условного senior’а. Выбранный на старте проекта технологический стек может стать блоком, препятствующим развитию продукта.
まとめ
В следующий раз мы поговорим о том, как люди попытались решить обозначенные проблемы, перейдя к компонентам и SOA.
続きを読む：
出所： habr.com