Дао и техника микросервисов с оплатой по факту использования

Цель микросервисов — повысить скорость отклика, снизить сложность и децентрализовать все — это высшая цель микросервисов.

задний план

С увеличением количества проектных работ в команде НИОКР, увеличением объема кода и ростом персонала недостатки традиционной монолитной архитектуры становятся все более и более заметными, что серьезно влияет на быстрые инновации и гибкую доставку бизнес. Чтобы решить проблемы, с которыми столкнулась традиционная монолитная архитектура в конце 2015 года, Suihangfu успешно испытала монолитную архитектуру, разделение системных модулей и текущие микросервисы.

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

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

Причины микросервиса

Зачем микросервисы? Мы можем понять, почему мы занимаемся микросервисами, из следующих трех аспектов.

Разделяй и властвуй: уменьшай сложность
Разделяй и повторно используй: улучшай возможность повторного использования
Делайте это отдельно: повышайте эффективность разработки

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

Более 10 лет назад, когда оно пришло к архитектуре, большинство людей подумают, что архитектура = производительность + высокая доступность. Благодаря постоянному обновлению текущих технологий (Docker, искусственный интеллект, блокчан и другие технологии), появление различных программных программ с открытым исходным кодом, популярность концепций DevOps, Agile Development, ставшее режимом развития, и т. Д., Производительность и высокая доступность не являются дольше так сложно. Проблема. Как приложения могут быть устойчивыми? Как продукт может быть запущен / итерацией? Пригодность, масштабируемость и стоимость постепенно становятся в центре внимания многих архитекторов. Фундаментальная цель архитектуры микросервисов состоит в том, чтобы уменьшить сложность.

Требования к микросервису

разделение бизнеса

Первая проблема с внедрением микросервисной архитектуры заключается в том, что просто не существует четко определенного алгоритма для разделения сервисов. Как и сама разработка программного обеспечения, разделение и определение сервисов — это скорее искусство. Что еще хуже, если вы отклонитесь от разделения системы на службы, вы, вероятно, создадите «распределенный монолит», систему тесно связанных служб, которые должны быть развернуты вместе. Это объединит недостатки как монолитной, так и микросервисной архитектуры.

автоматическое тестирование

Очевидным проявлением микросервисов является то, что с увеличением количества сервисов, если вы продолжите использовать традиционный режим тестирования, вы столкнетесь с узкими местами.Чтобы обеспечить эффективную итерацию, попробуйте автоматизировать тестирование. Благодаря автоматизации тесты также можно «написать один раз, запускать везде», что делает регрессионное тестирование рутинным.

Автоматическая работа и обслуживание

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

Многомерный мониторинг

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

Дорога

Принципы микросервисной архитектуры

Унификация стека технологий

Обязательно используйте зрелые технологии и полностью учитывайте экономическую эффективность, которую обеспечивают новые технологии. Так называемая зрелость — это не только хорошая активность сообщества, стабильность, экономия затрат на разработку и повышение эффективности разработки. Больше относится к технической популярности сопутствующего платежа, грубо говоря, к тому, сколько людей его знают и сколько людей могут его удержать, когда возникает проблема.

Возможная согласованность данных

Сбалансируйте, какие услуги в конечном итоге будут согласованными, а какие должны быть строго согласованными. И каков механизм гарантии строгой согласованности? Уровень инфраструктуры и уровень приложения дополняют друг друга, чтобы совместно обеспечить согласованность данных.

Служба не имеет гражданства

Для служб без сохранения состояния давайте сначала поговорим о том, что такое состояние. Если данные должны использоваться несколькими службами для выполнения транзакции, эти данные называются состоянием. Служба, которая, в свою очередь, зависит от этих данных о состоянии, называется службой с отслеживанием состояния, и наоборот, называется службой без сохранения состояния. Тогда этот принцип службы без сохранения состояния не означает, что состояние не разрешено в архитектуре микрослужбы, но реальный смысл выражения состоит в том, чтобы изменить бизнес-службу с отслеживанием состояния на вычислительную службу без сохранения состояния, после чего данные о состоянии будут перенесены в соответствующий сервис. соответствующая «Служба данных с отслеживанием состояния».

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

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

Протокол HTTP без сохранения состояния имеет присущие ему преимущества и высокую масштабируемость.
Сериализация сообщений JSON, легкая и простая, читаемая как людьми, так и машинами, низкая стоимость обучения и дружественная поисковая система.
Независимо от языка, все популярные языки предоставляют зрелые фреймворки Restful API, которые являются более полными, чем другие фреймворки RPC.

Принцип разделения AKF

AKF Extended Cube — масштабируемая модель, предложенная в книге «Архитектура — это будущее». Теоретически, согласно этим трем режимам расширения, одна система может расширяться бесконечно.

Ось X: горизонтальная копия. Например, одна система запускает еще несколько экземпляров, чтобы быть кластером и режимом балансировки нагрузки.

AXIS Z: раздел данных, такой как региона, запрошенный пользовательский раздел данных, Пекин, Шанхай, Сычуань и другие построить несколько кластеров.

Ось Y: это режим разделения микросервисов, который разделен на основе разных предприятий.

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

Принцип разделения услуг

единственная ответственность

Разделить по возможностям бизнеса. Любой, кто знаком с объектной ориентацией, слышал о «принципе единой ответственности», то есть у каждого класса есть одна обязанность. Например, класс по перемещению кирпичей может либо строить дом, либо стрелять в людей.В настоящее время у переноса кирпичей есть две обязанности, поэтому мы должны разделить класс на два. Микросервисы также являются причиной того, что мы должны использовать сервис для выполнения одной задачи.

Свободная муфта, высокая сплоченность

Тщательно связанные вещи должны быть объединены, каждая служба представляет собой инкапсулирование бизнес-возможностей на одну ответственность, сосредоточив внимание на том, чтобы сделать одно хорошо. (Есть только одна причина изменить его за раз).

DDD

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

Если рассматривать горизонтальную перспективу, то сейчас мы можем разделить ее по сферам деятельности, а как насчет вертикальной? Мы можем разделить по уровням, таким как нижний уровень данных, уровень инфраструктуры и push-уведомления, электронная почта, SMS и т. д., которые не связаны с бизнесом. Мы также можем выполнять экстракцию и осаждение в соответствии с функциями безопасности, производительности и другими функциями, требующими особого внимания, и общими функциями.

Освоение этого доменно-ориентированного дизайна не только соответствует высокой связности, слабой связанности, но и принципу единой ответственности, почему бы вам не разобрать его?

Эволюционный раскол

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

Принципы развития сервиса

Развитие микросервиса столкнутся с проблемами с опорой. В архитектуре мономеров, что вам нужно, часто нравится то, что вы пишете, это на самом деле не слишком серьезно. Однако Micro Service - это команда или группа. На этот раз нет способа предоставить все услуги одновременно, «Реализация спроса» неизбежно.

Например: А должен выполнить проверку по черному списку продавцов и полагается на поставщика услуг Б. И у B есть другие более важные задачи, что приводит к относительно низкому приоритету разработки услуги, неспособной уложиться в срок поставки A. A столкнется либо с ожиданием, либо с реализацией службы самостоятельно.

Стратегия передовой практики — интерфейс в первую очередь, контрактная и нейтральная к языку. Поставщики услуг и потребители отделены друг от друга и развиваются параллельно для повышения производительности. Независимо от того, сколько существует сервисов, во-первых, интерфейс должен быть идентифицирован и определен, а затем две стороны осуществляют разработку на основе контракта на основе интерфейса и используют мок-провайдеров и потребителей услуг, чтобы отделить друг друга, разрабатывать параллельно и добиться разделения зависимостей.

При разработке на основе контрактов, если требования нестабильны или часто меняются, вы столкнетесь с проблемой частых изменений в контракте интерфейса. Что касается поставщиков услуг, они не должны откладывать предоставление интерфейсов, потому что они обеспокоены изменениями интерфейса, а потребители должны принять изменения, а не жаловаться и сопротивляться. Чтобы решить эту проблему, лучше всего объединить управление + технологии:

Код сканируется Sonar (208 пользовательских правил в Sonar)
Имеет более 80% сложности модульного теста
Разрешить изменения интерфейса, но строго контролировать частоту изменений
Предоставление полностью онлайновых сервисов документирования API (таких как Swagger UI) и преобразование автономной документации API в интерактивные интерактивные сервисы документирования API.
Активный механизм уведомления об изменениях API, чтобы все потребители, использующие API, могли своевременно узнавать об изменениях API.
Контрактное тестирование для регрессионного тестирования на совместимость

техника

Платформа микросервисов Paypal основана на концепции DevOps, основанной на Spring Boot, Spring Cloud, React, React Native, технологии контейнеров, искусственном интеллекте и т. д., и представляет собой платформу PaaS для микросервисных приложений. Реализуйте облачную инфраструктуру, модернизацию архитектуры приложений и гибкость процесса разработки.

Введение в ядро платформы и функции

Диаграмма экологической последовательности Spring Cloud

Как показано на рисунке, мы расширили множество функций вокруг Spring Boot и Spring Cloud, чтобы экосистема Spring могла выращивать больше «плодов» для решения практических задач на ходу, а не слепо строить колеса. Из-за длины статьи в серии статей будет представлен дополнительный контент технической статьи, а технологическая экосистема Paypal Fintech будет представлена из промежуточного программного обеспечения.

本分类文章，与「随行付研究院」微信号文章同步，第一时间接收公众号推送，请关注「随行付研究院」公众号。