> For the complete documentation index, see [llms.txt](https://folko.gitbook.io/podgotovka-k-sobesedovaniyu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://folko.gitbook.io/podgotovka-k-sobesedovaniyu/arkhitekturnye-voprosy/kak-izbavitsya-ot-monolitnosti-prilozheniya.md).

# Как избавиться от монолитности приложения?

Способы разделения монолитного приложения:

1. Переход к модульной / сервис-ориентированной архитектуре **(SOA,** [**англ.**](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA) **service-oriented architecture)** \
   Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор [веб-служб](https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%B1-%D1%81%D0%BB%D1%83%D0%B6%D0%B1%D0%B0), взаимодействующих по протоколу [SOAP](https://ru.wikipedia.org/wiki/SOAP), но существуют и другие реализации (например, на базе [jini](https://ru.wikipedia.org/wiki/Jini), [CORBA](https://ru.wikipedia.org/wiki/CORBA), на основе [REST](https://ru.wikipedia.org/wiki/REST)).\
   Главное, что отличает SOA — это использование независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.

   SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, [WSDL](https://ru.wikipedia.org/wiki/WSDL)). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

   Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как [Java](https://ru.wikipedia.org/wiki/Java), [.NET](https://ru.wikipedia.org/wiki/Microsoft_.NET) и т. д.). К примеру, сервисы, написанные на [C#](https://ru.wikipedia.org/wiki/C_Sharp), работающие на платформах .Net и сервисы на Java, работающие на платформах [Java EE](https://ru.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition), могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.<br>
2. Переход к микросервисной архитектуре\
   **Микросервисная архитектура** — вариант [сервис-ориентированной архитектуры](https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B2%D0%B8%D1%81-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0) программного обеспечения, направленный на взаимодействие насколько это возможно небольших, слабо связанных и легко изменяемых модулей — **микросервисов**, получивший распространение в середине 2010-х годов в связи с развитием практик [гибкой разработки](https://ru.wikipedia.org/wiki/%D0%93%D0%B8%D0%B1%D0%BA%D0%B0%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F) и [DevOps](https://ru.wikipedia.org/wiki/DevOps)[\[1\]](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0#cite_note-martinfowler-1)[\[2\]](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0#cite_note-2)[\[3\]](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0#cite_note-3).

   Если в традиционных вариантах сервис-ориентированной архитектуры модули могут быть сами по себе достаточно сложными программными системами, а взаимодействие между ними зачастую полагается на стандартизованные тяжеловесные протоколы (такие, как [SOAP](https://ru.wikipedia.org/wiki/SOAP), [XML-RPC](https://ru.wikipedia.org/wiki/XML-RPC)), в микросервисной архитектуре системы выстраиваются из компонентов, выполняющих относительно элементарные функции, и взаимодействующие с использованием экономичных сетевых коммуникационных протоколов (в стиле [REST](https://ru.wikipedia.org/wiki/REST) с использованием, например, [JSON](https://ru.wikipedia.org/wiki/JSON), [Protocol Buffers](https://ru.wikipedia.org/wiki/Protocol_Buffers), [Thrift](https://ru.wikipedia.org/wiki/Thrift)).  Философия микросервисов фактически копирует [философию Unix](https://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%BB%D0%BE%D1%81%D0%BE%D1%84%D0%B8%D1%8F_UNIX), согласно которой каждая программа должна «делать что-то одно, и делать это хорошо» и взаимодействовать с другими программами простыми средствами: микросервисы минимальны и предназначаются для единственной функции. Основные изменения в связи с этим налагаются на организационную культуру, которая должна включать автоматизацию разработки и тестирования, а также культуру проектирования, от которой требуется предусматривать обход прежних ошибок, исключение по возможности унаследованного кода (микросервисы часто заменяют целиком, поскольку их функции элементарны).