OSCHINA-MIRROR/didiopensource-JuShaTa

Контейнер JuShaTa

JuShaTa — это Java-контейнер, который обеспечивает модульное разделение и возможность горячей загрузки модулей.

1. Введение

Большинство разработчиков Java знакомы с Tomcat, поскольку ранее основным методом развёртывания приложений было упаковка их в WAR-файлы и размещение в директории webapps вместе с Tomcat. В контексте Tomcat каждый веб-приложение имеет свой экземпляр загрузчика классов, что позволяет изолировать классы и JAR-файлы каждого приложения от конфликтов между ними.

Исправление ошибки в последнем слове:

1. Введение

Конечно, после того как Spring/SpringBoot стали фактическим стандартом Java, стало возможным интегрировать встроенные контейнеры веб-серверов, такие как Tomcat или Jetty, прямо в приложение, позволяя ему запуститься. Преимущества такого подхода очевидны: деплоймент сразу же можно использовать для эксплуатации, что полностью соответствует идеологии DevOps.Однако, когда в одном Java-приложении содержится несколько сервисов Spring Boot, эти сервисы могут обращаться к различным версиям JAR-файлов. Это может привести к возникновению исключений типа NoSuchMethodException во время запуска или выполнения программы. Особенно если некоторые JAR-файлы имеют различные версии, проблемы могут возникнуть в продакшене из-за различных порядков загрузки этих JAR-файлов, что затрудняет диагностику и воспроизведение ошибок. Также возможно, что в разных сервисах есть бины с одинаковым именем, что вызывает конфликты при запуске.Поэтому мы предлагаем Java-контейнер JuShaTa, аналогичный Tomcat. В контейнере JuShaTa каждый сервис Spring Boot является самостоятельным модулем. Разделение осуществляется за счёт использования пользовательского загрузчика классов, где каждый модуль использует свой загрузчик классов для решения проблем с конфликтами JAR-файлов; а также через изоляцию контекста Spring, где каждому модулю соответствует свой контекст, чтобы решить конфликты бинов.

2. Обзор

В повседневной разработке часто встречаются ситуации командной работы, когда одновременно работают несколько человек над одним или несколькими крупными проектами. Обычно практика состоит в том, чтобы разделить бизнес-функциональность на несколько подпроектов или микросервисов. При этом процесс разделения неизбежно сталкивается со следующими проблемами:* Размер сервисов слишком велик, что приводит к тому, что связанные слабо функции помещаются в один модуль, что противоречит принципу высокой внутренней связанности и низкой внешней связанности.

Размер сервисов слишком мал, что приводит к появлению большого количества модулей, некоторые из которых содержат лишь минимальное количество функций. После самостоятельного развёртывания и запуска таких модулей они получают низкий объём запросов, но всё равно требуют одного Java-процесса, что приводит к неэффективному использованию машинных ресурсов. Поэтому предпочтительно разрабатывать эти модули независимо, но объединять их для развёртывания. По крайней мере, в процессе разработки важно гарантировать независимость и декомпозицию модулей. Однако объединённое развёртывание также создаёт новые проблемы: сервисы нормально запускаются самостоятельно, но начинают сталкиваться с конфликтами при объединённом запуске.### 3. Решение проблемыНа основе вышеописанных проблем JuShaTa предлагает использовать контейнеризированное решение, аналогично тому, как это было сделано с Tomcat. В контейнер будут помещены модули, а сам контейнер будет отвечать за управление жизненным циклом этих модулей, обеспечивая их изоляцию и возможность динамической загрузки и выгрузки.

1. Прямое использование

Разработан на базе Spring Boot, совместим с нативными модулями Spring Boot Starter, что позволяет легко переключаться между различными конфигурациями.

2. Изоляция модулей

При размещении нескольких модулей внутри контейнера могут возникнуть следующие проблемы:

Конфликты JAR-пакетов: если модуль A зависит от fastjson-1.1.x, а модуль B — от fastjson-1.2.x, то при выполнении программы может возникнуть исключение NoSuchMethodException.
Конфликты бинов: если в модуле A и модуле B определены одинаковые сервисы xxxService, то возникают конфликты бинов (хотя можно решить эту проблему путём установки свойства allowBeanDefinitionOverriding, но это приведёт к новым проблемам).

Поэтому контейнер должен решать эти две проблемы:

Устранять конфликты JAR-пакетов, используя пользовательскую реализацию ClassLoader, где каждый модуль загружается отдельным экземпляром ClassLoader.
Изолировать конфликты бинов, используя контексты Spring, где каждому модулю соответствует свой контекст, а контексты могут иметь зависимости друг от друга.#### 3. Динамическая загрузка
Контейнер предоставляет возможность горячей загрузки, периодически проверяя наличие модулей в указанной директории или через API контейнера для управления модулями.

4. Общая архитектура:

Общая архитектура контейнера JuShaTa представлена ниже, где модули изолируются друг от друга с помощью ClassLoader и контекстов Spring.

5. Пример разработки:

1. Включите зависимость в файл `pom.xml` проекта, скомпилируйте ваш Spring Boot проект в fat-jar и поместите его в определенную директорию, затем установите значение параметра `"jushata.modules-file"` равным пути к этой директории для запуска проекта.

<dependency>
    <groupId>com.didiglobal.jushata</groupId>
    <artifactId>jushata-boot</artifactId>
    <version>1.0.0</version>
</dependency>

2. Предоставлены модули `jushata-samples` для демонстрации примеров использования (перед тестированием выполните `mvn package` для создания пакетов модулей):

jushata-sample-standard демонстрирует совместимость с нативными модулями Spring Boot Starter;
jushata-sample-child1 и jushata-sample-child2 демонстрируют изоляцию контекста и классов в fat-jar модулях;

Для получения более подробной информации о разработке см. Руководство разработчика.

6. Лицензия

JuShaTa распространяется и используется на условиях лицензии Apache-2.0, подробнее см. [Лицензионное соглашение](LICENSE).