Резюме
Основываясь на непрерывном технологическом развитии JAVA и широкой поддержке сообщества, во многих сферах бизнеса использование JAVA для создания бизнес-систем по-прежнему остается основным. Для финансовой платежной системы, с которой я знаком, за последние несколько лет, хотя основной язык разработки не изменился, она по-прежнему в основном построена на JAVA, но ее системная архитектура постоянно обновляется с появлением новых технологий. В этой статье в качестве примера используется система платежных транзакций, с которой я знаком (не ограничиваясь системой платежных транзакций, для справки можно использовать все бизнес-системы на основе JAVA).Описать новую техническую архитектуру, особенно практическое применение и опыт микросервиса. связанная архитектура.
В качестве отступления, с точки зрения технических решений, я всегда выступал за то, что «технология — это продукт», или это можно понимать так: только технология, которая может решать проблемы, как продукт, является хорошей технологией. (В какой-то период многие друзья использовали непрактичные методы для решения простых задач, и я их оспорил, ха-ха) На самом деле, я не один так думаю. Полезное нововведение, правда же.
В этой статье основное внимание уделяется не тому, как спроектировать определенную систему, поэтому я не буду рисовать какие-либо схемы системной архитектуры, а каждый продукт, каждая команда и даже разные этапы продукта требуют разных архитектур. В этой статье я рассказываю о концепциях, методах и опыте некоторых основных технологий.Может быть, в следующей статье мы поговорим о том, как структурировать или модернизировать текущую технологию на основе реальных случаев.
Представление микросервисной архитектуры
В прошлый раз я разговаривал с другом о бизнес-системе некоего банка, которая тоже была разработана на JAVA.Вся бизнес-логика написана в огромном WAR-пакете и работает под огромным WebLogic.Запуск каждый раз занимает больше десяти минут Не говоря уже о быстрой итерации, даже каждое небольшое изменение в системе очень страшно для разработки или эксплуатации и обслуживания, потому что, как только требуется небольшое изменение, необходимо изменить весь WAR-пакет, а каждое изменение занимает много времени.
Поэтому для многих старых системных архитектур фактически дошло до уровня демонтажа. Использование представления микросервисной архитектуры — лучший способ решить эту проблему.Здесь мне нужно подчеркнуть один момент: я не имею в виду использование различных инструментов микросервисов, а понимание концепции микросервисной архитектуры, которая поможет нам решать практические проблемы.Ряд инструментов микросервисов зависит от того, насколько гибко вы их используете.
Прежде чем говорить о микросервисах, мы должны сначала поговорить о сервисах SOA.Если говорить о разнице между SOA и микросервисами в одном предложении, то микросервисы больше не подчеркивают тяжелую корпоративную сервисную шину ESB в традиционной архитектуре SOA, а идею SOA входит Чтобы добиться истинной компонентизации в рамках единой бизнес-системы.
Идея микросервисов очень проста: вместо разработки огромного монолитного приложения приложение разбивается на небольшие взаимосвязанные микросервисы. Преимущества этого очевидны.В дополнение к избежанию вышеуказанной проблемы, есть много преимуществ: во-первых, для достижения разделения развертывания приложения с большой нагрузкой развертываются на лучше сконфигурированных машинах, и запускается больше экземпляров; во-вторых, каждый микросервис развертываются независимо, а обновления и итерации не влияют на всю систему, поэтому можно ускорить итерацию; в-третьих, у каждой службы или службы с аналогичной технологией есть выделенная команда для разработки, что также очень хорошо для технических менеджеров и разработчиков. , Например, в финансовой бизнес-системе некоторые из них представляют собой группы разработчиков с большим объемом бизнес-процессов (например, службы системы управления рисками), а некоторые — более технически сложные группы (например, службы шифрования безопасности), поэтому здесь предъявляются совершенно другие требования к team, так что поставьте Разные команды очень разумны. Кроме того, у менеджера, заботящегося о безопасности, есть дополнительное преимущество, заключающееся в облегчении контроля над кодом.Один человек не получит весь код, если только ваша команда не состоит из одного человека, хе-хе.
Поэтому первым шагом по оптимизации старой архитектуры я считаю демонтаж.
Принцип разделения микросервисов
Принцип расщепления, несколько моментов более критичны:
1. Единственная ответственность
Микросервис фокусируется на чем-то одном, что легко понять: если сервис делает много вещей, он не называется микросервисом.
2. Различные технические области или области бизнеса должны быть разделены
Например, в услугах, которые мы предоставляем пользователям, включая платежные услуги и консультационные услуги, это две принципиально разные области бизнеса, и техническая реализация также отличается, поэтому они решительно разделены.
3. Разделить детализацию
Дело не в том, что чем тоньше, тем лучше, единого стандарта нет, мой опыт таков:
Если есть сервисы с высокой степенью повторного использования, например, у нас есть некоторые модули обработки данных для получения рыночных условий и модулей обработки учета платежей, они решительно демонтируются;
Некоторые предприятия включают гарантию согласованности транзакций (включая несколько записей в таблице базы данных, и гарантия согласованности достигается через базу данных).Если она разделена, гарантия согласованности должна быть реализована на уровне службы, что является другой темой. Я предполагаю, что ресурсы команды ограничены, так что не разбирайте ее сначала, если с ресурсами все в порядке, решите ее раз и навсегда.
Безгражданство микросервисов
Изначально я собирался сначала рассказать о выборе микросервисного фреймворка, учитывая, что важной целью использования микросервисов является параллельная экспансия, нам в первую очередь нужно сделать сервисы без состояния, то есть сервисы не должны быть привязаны к сессиям пользователей. Это обязательное условие. На самом деле это не только микросервисы, но даже если вы хотите добиться балансировки нагрузки Load Balance, вам также необходимо выполнить это предварительное условие.
Бизнес-система, построенная на традиционной JAVA, часто хранит информацию о пользователе и статусе в объекте Session в памяти сервера.Когда мы используем распределенную архитектуру с несколькими узлами, служба входа и бизнес-служба могут быть разбросаны по разным экземплярам узла, что затрудняет работу бизнеса. недоступен (сеанс не может найти информацию о пользователе).
Решение, которое я предлагаю, состоит в том, чтобы использовать независимый кеш сеанса, В этом решении необходимо учитывать два момента: один — носитель данных, а другой — механизм реализации.
В настоящее время наиболее зрелым и широко распространенным носителем данных является Redis, который обладает высокой производительностью, поддерживает сохраняемость и развертывание кластера.У нас также есть отдельная глава для Redis.
С точки зрения механизма реализации, я думаю, есть два варианта на выбор. Первый вариант — использовать SpringSession напрямую. SpringSession имеет много функций, но не обязательно все из них. это еще один вариант.Обратитесь к концепции SpringSession и реализуйте ее самостоятельно. Конкретный механизм реализации состоит в том, чтобы использовать SessionFilter для перехвата пользовательских запросов, а затем взять на себя управление сеансом сервера приложений через класс-оболочку Request. Переопределите метод getSession в классе оболочки запроса. Пусть пользователи переходят в Redis для работы при чтении и записи сеансов, а метод использования сеансов такой же, как и в прошлом, что делает схему управления прозрачной для пользователей.
Вышеупомянутая схема независимого кэширования сеанса закончена.Стоит отметить, что на ранней стадии системной архитектуры очень важно разделить базовые службы и экземпляры бизнес-служб, такие как служба аутентификации и служба кэширования сеансов.Чем больше вы избегаете делать, тем больше вы меняетесь.
Выбор микросервисного фреймворка
Когда мы завершили разделение сервисов и сформировали микросервисы, нам, естественно, потребуются вспомогательные фреймворки, такие как управление регистрацией сервисов, обнаружение сервисов, механизм исключений, мониторинг сервисов и т. д. На данный момент нам нужно выбрать надежный микросервисный фреймворк. В настоящее время существует два основных варианта фреймворка: Spring Cloud или Dubbo.
Dubbo является основной структурой сервисно-ориентированного управления Alibaba и широко используется на различных сайтах-членах Alibaba Group, а также очень популярен в Китае. Spring Cloud является продуктом Spring Source. Можно сказать, что сообщество Spring является самой влиятельной организацией в корпоративном мире Java. В дополнение к Spring Source, Pivotal и Netfix являются его сильной поддержкой и техническими результатами. Среди них весь набор микросервисной архитектуры с открытым исходным кодом от Netflix является ядром Spring Cloud. Для получения подробной информации см. следующую картинку:
Более подробное сравнение двух фреймворков смотрите в этой статье:Базовый выбор фреймворка для микросервисной архитектуры: Spring Cloud или Dubbo?
Здесь нам нужно объяснить Spring Boot, продукт с открытым исходным кодом, предоставленный командой Pivotal, предназначенный для упрощения первоначальной настройки и разработки новых приложений Spring. Использование Spring Boot — это решение, о котором вся команда не пожалеет.Разработка быстрая, упаковка и публикация очень удобны (упакованы в банку), поэтому это может помочь команде быстро разработать набор веб-приложений в спокойном стиле. А для команд, которые раньше использовали среду Spring, перенос не имел большого значения.
Для нас мы собираемся выбрать Spring Cloud. Причина очень проста, потому что мы используем SpringBoot в качестве основного фреймворка для разработки, SpringBoot и Spring Cloud естественным образом интегрированы, а проект SpringBoot легко может стать сервисом регистрации SpringCloud.
Для большинства разработчиков, независимо от того, используют ли они Spring Cloud или Dubbo, это требует времени и затрат на обучение.В настоящее время вам необходимо учитывать, насколько сложен ваш бизнес или насколько тонко разделены микросервисы.Конечно, во многих случаях на самом деле можно рассмотреть следующие альтернативы.
Шлюз API + решение для балансировки нагрузки
Простое решение для обнаружения сервисов — использовать LoadBalancer. Вы можете использовать NGINX или использовать аппаратные устройства LB.Конечно, если вы пользуетесь услугами облачных вычислений, такими как Alibaba Cloud, использование LB будет самым дешевым вариантом. Конечно, должны быть недостатки, потому что это не режим распределенной обработки, который вызовет узкие места в производительности или единые точки отказа, и не может использоваться в качестве мелкозернистого контроля (например, контроль разрешений и т. д.), но в любом случае это хорошая сценическая схема, мы ею давно пользуемся.
Следует упомянуть способ предоставления услуг внешнему миру — API-шлюз. В качестве входа в систему шлюз API имеет такие функции, как переадресация услуг, проверка авторизации и балансировка нагрузки, а также может быстро инкапсулировать ряд API-интерфейсов в стиле HTTP Rest. Поставщики облачных услуг, такие как Alibaba Cloud и AWS, предоставили полные сервисные продукты API Gateway, которые также можно использоватьSpring Integration Gatewayпостроить свой собственный шлюз.
Вообще говоря, вызывающая сторона API исходит из своего собственного приложения или стороннего приложения, а каналом может быть веб-сайт для ПК, мобильный клиент и т. д. Использование API Gateway — лучший выбор для открытых бизнес-сервисов.
Короче говоря, если API Gateway можно использовать в качестве простого продукта для реализации микросервисной инфраструктуры с балансировкой нагрузки, можно построить хорошую микросервисную архитектуру.
Высокопроизводительное RPC-решение
После определения микросервисной архитектуры необходимо рассмотреть эффективную структуру RPC между внутренними сервисами, т.е.АрхитектураМикросервисыЭто может значительно снизить стоимость микросервисной архитектуры, повысить эффективность вызовов вызывающих абонентов и поставщиков услуг, а также скрыть различные сложные детали межпроцессных вызовов функций (сервисов).
Структура RPC логически разделена на два уровня: один — транспортный уровень, который отвечает за сетевое взаимодействие, а другой — уровень протокола, который упаковывает и распаковывает данные в соответствии с определенным форматом протокола.
Ниже приведены межъязыковые RPC-фреймворки, которые использовались или рекомендовались несколькими друзьями. Сообщите нам о них.
Thrift — это эффективная RPC-инфраструктура с открытым исходным кодом для Facebook.Его основные функции — межъязыковая и эффективная передача бинарных файлов (разумеется, помимо бинарных, она также поддерживает распространенные механизмы сериализации, такие как json).Адрес официального сайта:Apache Thrift - Home
Hessian — это фреймворк RPC, основанный на протоколе HTTP, который использует двоичный протокол RPC, очень легкий и быстрый. Его коммуникационная эффективность выше, чем сериализация, которая идет с WebService и Java.
Avro Welcome to Apache Avro!Подпроект знаменитого Hadoop. Это сама структура сериализации, а также реализующая функции RPC. Возможности сериализации Avro: поддержка межъязыковой реализации и По сравнению с Apache Thrift и Google Protocol Buffers преимущество Avro в том, что он поддерживает динамический режим, то есть не может генерировать код и избегать навязчивости.DTO (Data Transfer Object) как POJO не подходит для генерации кода. Кроме того, поскольку Avro не нуждается в идентификаторах полей для маркировки при сериализации, данные, генерируемые при сериализации с его использованием, невелики (они должны быть наиболее упорядоченными в существующей системе сериализации), и, наконец, его производительность также очень хороша.
Кроме того, отечественный nfs-rpc представляет собой инфраструктуру RPC с открытым исходным кодом от Taobao Niuren, а Dubbo — инфраструктуру распределенных услуг с открытым исходным кодом от Alibaba, которая также обеспечивает высокую производительность и прозрачность.RPCСценарии удаленного вызова службы. Дополнительную информацию можно найти в Интернете.
Также представьте Protocol Buffers: язык описания интерфейса, основанный на бинарном формате соединения, созданном Google. Буферы протоколов очень эффективны при синтаксическом анализе и передаче по сети и были протестированы в среде Google с высокой нагрузкой.
С точки зрения сериализации Apache Thrift, протокольные буферы Google и Avro должны принадлежать к одному и тому же уровню фреймворков, которые могут быть кросс-языковыми, с отличной производительностью и сокращением данных, но динамический режим Avro (без генерации кода, а производительность очень хорошо)) Эта функция очень популярна и больше подходит для обмена данными RPC.
Давайте напишем так много в последней статье, а некоторые темы будут позже, такие как построение асинхронной системной среды с помощью очередей сообщений, реализация оптимизации производительности с помощью Redis, решения непрерывной интеграции, преимущества гибридного облака и некоторые практические примеры, которые нужно довести до вам за обсуждение, спасибо!
Автор: Сяо Мин
Введение: финансовые/платежные ИТ, продолжайте уделять внимание платежам/трансграничным платежам/инновационным финтех-блокчейну, работал с данными UnionPay, крупными внутренними платежными учреждениями и начинающими финтех-компаниями, специализирующимися на иностранной валюте.
WeChat: wx1489968049
Знать: Сяо Мин ФИНТЕХ