העלא, האבר. הייַנט איך פאָרזעצן אַ סעריע פון אויסגאבעס וואָס איך געשריבן ספּאַסיפיקלי פֿאַר די אָנהייב פון אַ נייַע שטראָם פון דעם קורס. .
הקדמה
די ברירה פון אַרקאַטעקטשעראַל סטיל איז איינער פון די פונדאַמענטאַל טעכניש דיסיזשאַנז ווען איר בויען אַן אינפֿאָרמאַציע סיסטעם. אין דעם סעריע פון אַרטיקלען, איך פאָרשלאָגן צו פונאַנדערקלייַבן די מערסט פאָלקס אַרקאַטעקטשעראַל סטיילז פֿאַר בנין אַפּלאַקיישאַנז און ענטפֿערן די קשיא פון ווען וואָס אַרקאַטעקטשעראַל סטיל איז מערסט בילכער. אין דעם פּראָצעס פון פּרעזענטירונג, איך וועל פּרובירן צו ציען אַ לאַדזשיקאַל קייט וואָס דערקלערט די אַנטוויקלונג פון אַרקאַטעקטשעראַל סטיילז פון מאַנאַליטס צו מיקראָ באַדינונגס.
В мы разобрались с монолитом и пришли к тому, что монолит имеет ряд проблем: размер, связанность, развертывание, масштабируемость, надежность и косность.
В этот раз я предлагаю поговорить о возможностях организации системы в виде набора модулей/библиотек (компонентно-ориентированная архитектура) или сервисов (сервис-ориентированная архитектура).
Компонентно-ориентированная архитектура
Компонентно-ориентированная архитектура предполагает выполнение системы в виде набора компонентов, которые можно использовать как в текущем, так и в будущих проектах. При разбиении системы на компоненты учитываются: пригодность их для повторного использования, их замещаемость, независимость от контекста, расширяемость, инкапсуляцию и независимость.
При грамотном использовании компонентов решается проблема «большого кома грязи» (большой размер + высокая связанность), а сами компоненты могут представлять из себя как единицы сборки (модули, библиотеки), так и единицы развертывания (сервисы). Единицы развертывания не всегда отображаются на выполняемый процесс: например, веб-приложение и база данных развертываются совместно.
Наиболее часто монолиты разрабатываются в виде набора модулей. Такой подход приводит к обеспечению независимости разработки, но при этом проблемы независимых масштабирования и развертывания, отказоустойчивости и независимости от общего технологического стека остаются. Именно поэтому модуль — частично независимая компонента.
Самая главная проблема такого монолита заключается в том, что разделение на модули является чисто логическим и может быть легко нарушено разработчиками. Может появиться модуль core, который постепенно превращается в помойку, может расти граф зависимостей между модулями и так далее. Для избежания таких проблем разработка должна вестить либо очень зрелой командой, либо под руководством «архитектора», который на full time занимается code review и бьет нарушающих логическую структуру разработчиков по рукам.
«Идеальный» монолит представляет из себя набор логически разделенных модулей, каждый из которых смотрит в свою базу данных.
Сервис-ориентированная архитектура
Если все-таки предполагается организация системы в виде набора сервисов, то речь идет о сервис-ориентированной архитектуре. Ее принципы: сочетаемость приложений, ориентированных на пользователей, многократное использование бизнес-сервисов, независимость от набора технологий и автономность (независимые эволюция, масштабируемость и развертываемость).
Сервис-ориентированная архитектура (SOA = service oriented architecture) решает все обозначенные проблемы монолита: при изменении затрагивается только одна служба, а четко определенный API поддерживает хорошую инкапсуляцию компонент.
Но не все так гладко: SOA приводит к возникновению новых проблем. Удаленные вызовы дороже локальных, а перераспределение обязанностей между компонентами стало существенно дороже.
Кстати говоря, возможность независимого развертывания — это очень важная особенность сервиса. Если сервисы должны развертываться совместно или, тем более, в определенной последовательности, то система не может считаться сервис-ориентированной. В таком случае говорят о распределенном монолите (считается антипаттерном не только с точки зрения SOA, но и микросервисной архитектуры).
Сервис-ориентированная архитектура неплохо поддерживается архитектурным коммьюнити и вендорами. Отсюда следует наличие множества курсов и сертификаций, хорошо проработанных паттернов. К последним относится, например, не безызвестная сервисная шина предприятия (ESB = enterprise service bus). При этом ESB — это багаж от вендоров, она не обязательно должна использоваться в SOA.
Пик популярности сервис-ориентированной архитектуры приходился примерно на 2008 год, после чего она пошла на спад, который стал существенно более резким после появления микросервисов (~2015 год).
סאָף
После того, как мы обсудили возможности организации информационных систем в виде сервисов и модулей, я предлагаю наконец-то перейти к принципам микросервисной архитектуры и уделить особое внимание отличию микросервисной архитектуры от сервис-ориентированной в следующей части.
מקור: www.habr.com