Галантерея | Модульность бизнес-системы Ant Financial — модульное решение для изоляции

Архитектура
Галантерея | Модульность бизнес-системы Ant Financial — модульное решение для изоляции

Независимо от того, что это за бизнес-система, она будет выполнять некоторые модульные деления, горизонтальные или вертикальные, в различных положениях, но могут ли эти положения действительно помочь вам разделить хорошие модули? Может ли это помочь вам достичь высокой согласованности и низкой связанности между модулями? Какое влияние модульность оказывает на сервисизацию?

Автор этой статьи, Хуан Тинг, является старшим техническим экспертом Ant Financial и директором по открытому исходному коду распределенной архитектуры SOFA Ant Financial.

В настоящее время он отвечает за структуру приложений и работу, связанную с обслуживанием, в группе промежуточного программного обеспечения Ant Financial.

Сначала я проанализирую плюсы и минусы нескольких распространенных модульных решений и расскажу о роли SOFA, открытой платформы Ant Financial, в модульности.

Ловушки традиционной модульности

В простой системе Spring/SpringBoot мы часто видим, что модули системы располагаются следующим образом: как показано в левой части рисунка ниже, система просто делится на веб-уровень и сервисный уровень. слой ДАЛ.

Когда эта система предоставляет больше услуг, система может развиваться так, как показано справа на рисунке выше. В правой части приведенного выше рисунка система несет две службы, одна из которых — Кассир (кассир), а другая — Плата (оплата).Эти две службы могут иметь некоторые зависимости, и Кассиру необходимо вызвать Pay, чтобы предоставить возможность совершать платежи. .

Но в этом модульном решении контекст Spring все тот же, а классы не изолированы, что означает, что любой bean-компонент в модуле Pay Service может зависеть от модуля Cashier Service. В крайнем случае могут возникнуть следующие ситуации:

Cashier Service ошибочно назвал внутренний bean-компонент в Pay Service, что привело к тесной связи между двумя модулями.

Проблема с этой традиционной модульностью заключается в том, что модульность не является полной.Хотя во время разработки путем разделения модулей и помещения классов с определенными обязанностями в конкретные модули достигается связность «физического расположения» классов. Однако во время выполнения, поскольку нет средств изоляции, разработчик модуля не может четко знать, что такое внешний интерфейс, предоставляемый другим модулем, какие bean-компоненты я могу внедрить напрямую, а какие bean-компоненты — это ваш внутренний Bean-компонент. , я не могу его использовать. В долгосрочной перспективе связь между модулями будет становиться все более и более серьезной, и первоначальное разделение модулей бесполезно. Когда система становится все больше и больше, и, наконец, нужно выполнить разделение сервисов, ей нужно потратить много энергии, чтобы разобраться в отношениях между модулями.

Модульность OSGi

Когда дело доходит до модульности, мы должны упомянуть OSGi.Хотя OSGi не стал официальным стандартом модуляризации Java, поскольку у Java не было официального стандарта модульности до Java 9, OSGi уже является стандартом де-факто.

OSGi делает две основные вещи для модульности:

  1. Изоляция классов для OSGi

  2. Декларативные службы для OSGi

Нижеследующее кратко объясняет читателю эти два аспекта OSGi.

1. Изоляция классов для OSGi

OSGi полностью изолирует классы между модулями и модулями, расширяя механизм Java ClassLoader. Когда модулю необходимо сослаться на класс другого модуля, он объявляет экспорт и импорт класса в файле MANIFEST.MF в модуле. показано на следующем рисунке:

Таким образом, можно управлять определенными классами модуля, к которым должен обращаться другой модуль, достигая определенной степени изоляции модуля.

Однако недостаточно решить проблему ссылки на класс только путем экспорта и импорта класса. Нам также необходимо решить проблему ссылки на экземпляр. Мы часто надеемся напрямую использовать экземпляр класса, предоставленный другим модулем, вместо этого создать экземпляр самостоятельно, поэтому OSGi также предоставляет способ декларативных служб, так что модуль может ссылаться на службы, предоставляемые другим модулем.

2.Декларативные службы для OSGi

Декларативная служба OSGi предназначена для решения проблемы ссылки на экземпляр Мы можем добавить файл конфигурации XML в модуль OSGi (Bundle), чтобы объявить службу, как показано в следующем коде:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="ITodoService">
   <implementation class="com.example.e4.rcp.todo.service.internal.MyTodoServiceImpl"/>
   <service>
      <provide interface="com.example.e4.rcp.todo.model.ITodoService"/>
   </service>
</scr:component>
скопировать код

Также можно сослаться на службу, объявленную другим модулем, через файл конфигурации XML:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="XXXService">
    <reference name="ITodoService"
            interface="com.example.e4.rcp.todo.model.ITodoService"
            bind="setITodoService" cardinality="0..1" unbind="unsetITodoService"
            policy="dynamic" />
   <implementation class="com.example.e4.rcp.todo.service.internal.XXXServiceImpl"/>
</scr:component>
скопировать код

С помощью декларативных служб мы можем напрямую использовать экземпляры служб, предоставляемые в другом пакете в пакете OSGi.

Модульность OSGi

OSGi решает проблему изоляции классов между модулями через механизм изоляции классов, а затем решает проблему вызовов сервисов между модулями через декларативные сервисы.Похоже, он отлично решил проблемы, с которыми мы столкнулись при традиционной модуляризации.Благодаря этим двум механизмам, границы между модулями и модулями становятся четкими.

Однако на практике модульность OSGi сталкивается с очень серьезной проблемой.Это сложность, вызванная изоляцией классов OSGi.OSGi загружает каждый модуль через независимый ClassLoader, так что при разработке модулей в то время студенты, занимающиеся исследованиями и разработками должны четко определить, какие классы должны быть экспортированы, а какие импортированы.Если экспорт меньше или экспорт неправильный, будут возникать различные ошибки, такие как LinkageError, NoSuchMethodError и т. д., и для устранения этих ошибок студенты R&D должны четко понимать всю систему загрузки классов OSGi и всю систему загрузки классов Java, что действительно является высоким требованием для обычных студентов, изучающих исследования и разработки. Так что этот метод очень дорог в реализации, OSGi Не очень подходит для развития бизнеса.

ДИВАН Модульный

Чтобы решить проблему неполной модуляризации традиционной схемы модульности и сложности полной модульности OSGi, SOFA на раннем этапе начала внедрять скомпрометированную схему модульности.

Общая схема модуляризации SOFA выглядит следующим образом:

Модульное решение SOFA предоставляет отдельный контекст Spring для каждого модуля.Благодаря изоляции контекста Spring ссылка на bean-компонент между модулями не может выполняться напрямую, и модуль может быть изолирован во время выполнения. Когда модулю необходимо вызвать bean-компонент в другом модуле, SOFA использует декларативный метод службы, аналогичный OSGi.Модуль, предоставляющий службу, может быть объявлен в его файле конфигурации (или объявлен с помощью аннотации).Служба SOFA:

                                                
<sofa:service ref="sampleBean" interface="com.alipay.sofaboot.SampleBean"/>

                                                скопировать код

Модули, использующие службы, могут объявить ссылку SOFA в своем файле конфигурации (который также можно использовать через аннотацию):

<sofa:reference id="sampleBean" interface="com.alipay.sofaboot.SampleBean"/>
скопировать код

Таким образом, модуль может четко знать, какие службы он предоставляет, на какие службы ссылаются, и связь с другими модулями также очень ясна.

Тем не менее, модульное решение SOFA не представляет собой решение для изоляции классов, которое также позволяет студентам, занимающимся исследованиями и разработками, решать проблему слишком сложной загрузки классов и упрощать затраты на исследования и разработки.

Быстрое обслуживание благодаря модульности SOFA

Как упоминалось выше, благодаря модульному решению SOFA мы можем очень четко знать, где находятся границы модуля, от каких сервисов он зависит и какие сервисы он публикует. Когда ваше приложение разбухает до такой степени, что его необходимо обслуживать, его очень легко разделить.

И SOFA на самом деле сделал нечто более удобное для всех, чтобы разделить службы на этом, то есть публикация службы и ссылка на службу между модулями SOFA, а модель программирования и интерфейс публикации службы и ссылка между приложениями SOFA: согласованы.

Как показано на рисунке выше, когда исходную систему, содержащую возможности Cashier и Pay, необходимо разделить на две системы, необходимо добавить объявление протокола только там, где изначально были объявлены SOFA Service и SOFA Reference, например Исходная опубликованная служба составляет:

<sofa:service ref="sampleBean" interface="com.alipay.sofaboot.SampleBean"/>
скопировать код

Просто измените его на:

<sofa:service ref="sampleBean" interface="com.alipay.sofaboot.SampleBean">
    <sofa:binding.bolt/>
</sofa:service>
скопировать код

Исходный справочный сервис выглядит следующим образом:

<sofa:reference id="sampleBean" interface="com.alipay.sofaboot.SampleBean"/>
скопировать код

Просто измените его на:

<sofa:reference id="sampleBean" interface="com.alipay.sofaboot.SampleBean">
    <sofa:binding.bolt/>
</sofa:reference>
скопировать код

На самом деле, это быстрое сервисно-ориентированное разделение также обеспечивает большое удобство в процессе преобразования всей структуры Ant Financial в сервисно-ориентированную.

Суммировать

В этой статье в основном анализируются недостатки традиционной модульности и схемы модульности OSGi на практике, а затем вводится схема модульности SOFA и вводится модульная схема SOFA в процессе обслуживания.

   Пополнить

Промежуточное ПО SOFA – это распределенное промежуточное ПО финансового уровня, независимо разработанное Ant Financial. Оно включает в себя различные компоненты, необходимые для построения облачной архитектуры финансового уровня, включая среду исследований и разработок микросервисов, структуру RPC, реестр служб, распределенные задачи синхронизации, ограниченную потоковую передачу/слияние. Framework, динамическая отправка конфигурации, распределенное отслеживание ссылок, показатели мониторинга показателей, распределенная очередь сообщений высокой доступности, распределенная структура транзакций, уровень прокси-сервера распределенной базы данных и другие компоненты также являются передовыми методами, ограниченными в финансовых сценариях.

  • Эта статья основана на некоторых материалах, опубликованных автором на Пекинском салоне технологий с открытым исходным кодом Ele.me. PPT и видео, размещенные на месте, можно просмотреть по адресу https://www.itdks.com/eventlist/detail/ 2341;

  • Подробную документацию и демонстрацию модуляризации SOFA можно найти по адресу:

    http://wuwuwu.sofa stack.specialty/sofa-boot/docs/modular-development;

  • Исходный код модульных возможностей SOFA:

    https://github.com/alipay/sofa-boot

    -> isle-sofa-boot-starter 

  • В настоящее время почти 2000 систем SOFA компании Ant используют описанное выше модульное решение для разделения модулей;

Нажмите и удерживайте кнопку «Подписаться», чтобы получить новейшие галантерейные товары с распределенной архитектурой.

Добро пожаловать на сборку SOFAStack вместе https://github.com/alipay

Категории