Сегодня мы поговорим о модульности SOFA, сначала взглянем на введение в SOFA:
SOFABoot — это среда исследований и разработок Ant Financial на основе Spring Boot с открытым исходным кодом, основанная на Spring Boot и предоставляющая такие возможности, как проверка готовности, изоляция классов и изоляция пространства журналов. Усовершенствуя Spring Boot, SOFABoot предоставляет пользователям возможность легко использовать промежуточное ПО SOFA в Spring Boot.
До того, как я столкнулся с модульной концепцией SOFA, мое понимание модульности серверной разработки оставалось на уровне "модульности". Обычно я организую код приложения, за которое отвечаю, в соответствии со структурой, показанной на рисунке ниже. .
Модули в системе Spring управляют bean-компонентами в своих соответствующих модулях через разные контексты Spring и достигают модульности во время разработки и компиляции, но все приложение все еще находится в контексте Spring во время выполнения, и эти коды все еще загружаются загрузчиком классов.
На рисунке 1 на bean-компонент, который я определил в модуле менеджера, можно ссылаться в любое время в службе, не обращая внимания на то, является ли эта ссылка разумной; такая модель разработки не представляет проблемы, когда приложение еще маленькое, но с развитием бизнеса С обновлением приложения эталонные отношения между этими модулями будут становиться все более и более сложными и неуправляемыми (в это время приложение превратится в «большой ком грязи»). службы, требуется много усилий, чтобы разобраться в связях и справочных отношениях между различными модулями. Модульность SOFA предназначена для решения этой проблемы.Эта особенность может заставить разработчиков тщательно продумывать и продумывать добавление эталонной связи между двумя модулями.
Модульность SOFA
Модуль SOFA — это исполняемый модуль, а модуль в обычном проекте Spring — это обычный Jar. Есть два отличия между полным модулем SOFA и обычным пакетом Jar:
- Модуль SOFA содержит
sofa-module.propertiesфайл, который определяет имя модуля SOFA и зависимости между модулями. - ДИВАН модуль
META-INF/springВ каталоге вы можете разместить столько файлов конфигурации Spring, сколько хотите, и SOFA автоматически загрузит их как конфигурацию Spring этого модуля.
После использования модульных характеристик Sofa компонент между двумя модулями не может взаимодействовать напрямую, и для связи требуется протокол связи Sofa. SOFA поддерживает два протокола связи:
- вызовы JVM, два модуля работают на одной и той же виртуальной машине JVM без сетевых вызовов.
- rpc, два модуля не работают на одной и той же виртуальной машине JVM, даже на одной машине, и им нужно выполнить сетевой вызов.
SOFA предоставляет разработчикам три формы услуг публикации и ссылок: xml, аннотации и программирование. Я все еще больше использую метод xml, потому что SofaService и SofaReference поддерживают только публикацию и ссылку на службу jvm, тогда как метод xml может поддерживать две формы вызова.
Влияние модульности SOFA на режим разработки
Модульное решение, предоставляемое SOFA, которое обеспечивает истинную модульность времени выполнения без чрезмерного введения сложности OSGI, является эффективным компромиссом. Процесс от обращения к SOFA до знакомства с SOFA оказал большое влияние на мои идеи разработки, но после ознакомления с модульной идеей SOFA я обнаружил, что эта функция имеет несколько преимуществ для моей обычной работы по разработке.
Безопасная ближняя и удаленная архитектура
Чтобы уменьшить нагрузку на сервер, нам нужно предоставить SDK для поставщика услуг.В системе Spring эта архитектура также является исполняемой, но есть класс приложения SDK с недостатком и пакет JAR для приложения бизнеса. Это также видно, и в некоторых случаях будут конфликты или потенциальные ошибки.
Используя модульность SOFA, несмотря на то, что пакет ближнего конца, который мы предоставляем, по-прежнему использует JVM совместно с приложением бизнес-стороны, он обеспечивает изоляцию на уровне загрузчика классов.Для бизнес-стороны им нужно только знать, какие из наших приложений используемый интерфейс, не обращая внимания на то, сколько сторонних пакетов JAR представлено нашим SDK.
лучшее совместное использование кода
Используя модульность SOFA, добиться совместного использования кода не так просто, как в системе Spring — можно напрямую сослаться на модуль. В SOFA для совместного использования кода обычно есть два случая: (1) почти дальнее совместное использование кода (2) время управления и совместное использование кода во время выполнения.
Взяв случай (1) в качестве примера, компонент один и тот же вблизи и далеко Чтобы избежать дублирования кода, как мы можем добиться совместного использования кода? Мой текущий подход таков: определить интерфейсы и классы реализации, которые необходимо совместно использовать в общем модуле тестового ядра; этот модуль тестового ядра не может быть определен как модуль SOFA, но может быть определен только как общий пакет JAR; а затем используйте модуль SOFA (модуль ближнего и дальнего конца) интерфейса, общий компонент объявляется и ссылается соответственно.Пример диаграммы показан ниже.
Дело вот в чем:
- Модуль javaadu-core — это обычный JAR-модуль, только определение и реализация интерфейса, в этом модуле нет объявления бина
- Модуль javaadu-remote — это модуль SOFA, который относится к интерфейсу и реализации в javaadu-core.Здесь bean-компонент необходимо объявить (объявление bean-компонента) и опубликовать (sofa-service).Если другие модули текущего приложения хотят чтобы использовать этот интерфейс, вам нужно только обратиться к javaadu-core и javaadu-remote, а затем использовать диван-ссылку для ссылки на интерфейс, который обычно вызывается jvm; если другие приложения хотят использовать этот интерфейс и не имеют рядом -end, они должны ссылаться на javaadu-core и javaadu-remote и использовать ссылку на диван-ссылку. Можно видеть, что SOFA размывает концепции вызовов между приложениями и вызовов внутри приложения, а модульность очень тщательная.
- Модуль javaadu-client — это модуль SOFA и модуль ближнего конца.Здесь вам также необходимо определить и использовать интерфейсы и реализации в javaadu-core.
Суммировать
В этой статье в основном представлена наиболее очевидная разница между средой разработки SOFA и системой Spring: модульность SOFA, которая реализует реальную изоляцию времени выполнения в форме контекста Spring для каждого модуля.
Исходя из моего личного опыта, влияние модульности SOFA на серверную разработку лучше, чем ее недостатки: в процессе сопровождения кода я буду тщательно рассматривать, разумна ли модульная структура зависимостей текущего приложения, может быть безопаснее предоставить SDK для использования деловыми сторонами; при реализации совместного использования кода вам также необходимо тщательно продумать, какой код стоит использовать, а какой нет.
использованная литература
- Sofaboot — Обзор модульной разработки
- Модульное решение для изоляции модульности бизнес-системы Ant Financial
- Руководство по разработке Java для Alibaba (издание Huashan).pdf
- Выпуск службы JVM и справочник
В этом выпуске основное внимание уделяется таким темам, как серверные технологии, устранение неполадок и оптимизация JVM, вопросы на собеседованиях по Java, личностный рост и самоуправление, а читателям предлагается опыт работы и роста передовых разработчиков. .