4 принципа проектирования и 19 решений для микросервисов

Микросервисы Архитектура Эксплуатация и техническое обслуживание дизайн
4 принципа проектирования и 19 решений для микросервисов

При перепечатке этой статьи необходимо указывать источник: публичный аккаунт WeChat EAWorld, нарушители будут привлечены к ответственности.

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

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

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

содержание:

1. Процесс эволюции микросервисной архитектуры

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

3. Четыре принципа проектирования микросервисных приложений

В-четвертых, проблемы, вызванные микросервисной архитектурой

5. 19 лендинговых практик микросервисных платформ

6. Резюме и перспективы

1. Процесс эволюции микросервисной архитектуры

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

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

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

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

Мы резюмируем преимущества четырех аспектов, а именно:

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

  • Небольшая команда может нести ответственность более целенаправленно и профессионально, соответственно более эффективно и надежно.

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

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

Увидев это, все подумают, что микросервисная архитектура — это неплохо, но все равно будут некоторые вопросы, что за приложение такое приложение микросервисной архитектуры? Как разработать приложение с микросервисной архитектурой? Давайте рассмотрим рекомендуемые нами принципы разработки микросервисных приложений.

3. Четыре принципа проектирования микросервисных приложений

Мы обобщили четыре принципа, чтобы порекомендовать вам:

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

  • Переднее и заднее разделение

  • служба без гражданства

  • Спокойный стиль общения

1. Раздельный принцип AKF

Куб расширения AKF (см. «Искусство масштабирования») представляет собой абстрактный обзор трех измерений расширений приложений, составленный техническими экспертами из компании AKF. Теоретически, согласно этим трем режимам расширения, одна система может расширяться бесконечно.

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

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

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

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

2. Разделение переднего и заднего концов

Принцип разделения фронтенда и бэкенда — это просто разделение кода фронтенда и бэкэнда, то есть техническое разделение.Рекомендуемый режим — лучше всего развертывать напрямую в виде физического разделения, которое способствует более тщательному разделению. Не продолжайте использовать предыдущую технологию шаблонов на стороне сервера, такую ​​как JSP, укладку Java JS HTML CSS на одну страницу, и нельзя поддерживать несколько сложную страницу. Такой подход с раздельным режимом имеет несколько преимуществ:

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

  • В режиме разделения интерфейс взаимодействия между интерфейсом и сервером более понятен, оставляя только интерфейс и модель, а интерфейс на сервере лаконичен и прост в обслуживании.

  • Сценарии внешней многоканальной интеграции проще реализовать, а серверные службы не нужно менять. Унифицированные данные и модели можно использовать для поддержки внешнего веб-интерфейса\доступа к мобильным приложениям.

3. Службы без сохранения состояния

Для сервисов без сохранения состояния, прежде всего, что такое состояние: если данные должны быть разделены несколькими сервисами для выполнения транзакции, то эти данные называются состоянием. В свою очередь службы, которые полагаются на эти данные о состоянии, называются службами с отслеживанием состояния, и наоборот — службами без сохранения состояния.

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

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

4.Спокойный стиль общения

Как правило, это должен быть «принцип общения без сохранения состояния», здесь мы прямо рекомендуем предпочтительный стиль общения Restful, потому что он имеет много преимуществ:

  • Протокол HTTP без сохранения состояния имеет присущие ему преимущества и высокую масштабируемость. Например, потребность в безопасном шифровании заключается в наличии готового зрелого решения HTTPS.

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

  • Независимо от языка, все популярные языки предоставляют зрелые фреймворки Restful API, которые являются более полными, чем другие фреймворки RPC.

Конечно, в некоторых особых бизнес-сценариях также необходимо использовать другие инфраструктуры RPC, такие как thrift, avro-rpc и grpc. Но в большинстве случаев Restful достаточно.

В-четвертых, проблемы, вызванные микросервисной архитектурой

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

  • Изменения в зависимых сервисах трудно отследить.Что, если срок действия документов интерфейса сервисов других команд истек? Зависимые сервисы не готовы, как мне проверить разработанную мной функциональность.

  • Некоторые модули создаются повторно, и будет много повторяющихся конструкций в разных командах, системах и языках.

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

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

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

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

5. 19 лендинговых практик микросервисных платформ

1. Три основные среды для построения корпоративных ИТ

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

  • среда совместной работы в команде: в основном в области DevOps, отвечает за все: от требований до задач планирования, совместной работы в команде, управления качеством, непрерывной интеграции и выпуска.

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

  • ИТ-инфраструктура: Обычно мы говорим о реализации поддержки различных операционных сред, таких как IaaS (виртуализация виртуальных машин) и CaaS (виртуализация контейнеров).

2. Общая архитектура платформы микросервисных приложений

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

  • интеграция развития: в основном некоторые инструменты и склады, необходимые для создания микросервисной платформы.

  • Время выполнения: Должна существовать платформа микросервисов, обеспечивающая некоторые базовые возможности и возможности распределенной поддержки, и наши работающие контейнеры микросервисов будут работать на этой платформе.

  • Мониторинг управления: Он стремится к возможности единообразного мониторинга и настройки управляемых микросервисов во время выполнения.

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

3. Оперативный вид платформы микросервисных приложений

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

4. Цели проектирования микросервисной платформы

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

5. Разработка микросервисов: front-end, back-end, гибрид

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

В предыдущих принципах проектирования упоминался принцип разделения фронтенда и бекенда, тогда наша среда разработки в настоящее время поддерживает создание фронтенд-проектов, бэкенд-проектов и смешанных проектов. Front-end проекты и back-end проекты соответствуют принципу разделения front-end и back-end.Инструменты и фреймворки, интегрированные в платформу, могут использоваться для разделения front-end и back-end разработки и непрерывной интеграции инструменты могут быть использованы для простой компиляции и упаковки внешних и внутренних проектов в независимые пакеты. Гибридные проекты зарезервированы для совместимости с традиционными моделями и предоставляют решения для перехода от корпоративных приложений к микросервисным архитектурам.

6. Контракт на обслуживание и управление API

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

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

7. Контракт на обслуживание и имитация обслуживания

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

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

8. Контракт на обслуживание и организация обслуживания

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

Роль и значение оркестровки сервисов велики: она позволяет быстро комбинировать и высвобождать предоставляемые возможности микросервисов, что очень подходит для быстрых бизнес-инноваций.

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

9. Контейнеры микросервисов

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

10. Описание интеграции трехсторонних возможностей

Наш API документации по контракту на управление API имитирует нашу цепочку инструментов с интегрированным Swagger. Основой платформы приложений микросервисов является SpringCloud, а его возможности используются для поддержки базовых решений от контейнерной инфраструктуры до регистрации и обнаружения до аутентификации безопасности. Ниже приведен краткий обзор некоторых фреймворков и инструментов с открытым исходным кодом, которые мы интегрировали.

SpringCloudПозиционирование на платформе микросервисов является базовой структурой.В этой статье основное внимание уделяется представлению некоторых принципов проектирования и решений для реализации платформы микросервисов корпоративного уровня. конкретныйSpring Cloud Связанные технологии не будут представлены в статье, вы можете просмотреть соответствующие статьи в нашем официальном аккаунте.

11. Маршрут обнаружения регистрации службы

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

Наши возможности обнаружения регистрации службы реализованы с использованием компонентов SpringCloud Eureka. Когда служба запускается, она регистрирует службу для публикации в реестре служб. Во время выполнения, если вам нужно вызвать интерфейс других микрослужб, вы должны сначала зайти в реестр, чтобы получить адрес поставщика службы. получение адреса. Он используется для маршрутизации через простой период балансировки нагрузки внутри контейнера микросервиса.

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

12. Унифицированная аутентификация и проверка подлинности

Что касается аутентификации безопасности, мы используем Spring Security в сочетании с Auth2 и JWT (веб-токен Json) в качестве токенов безопасности для достижения унифицированной аутентификации и аутентификации безопасности, чтобы микросервисы можно было изолировать и безопасно обмениваться данными по запросу. В будущем, с точки зрения унифицированной аутентификации и разрешений, наши продукты будут последовательно запускать относительно полные и масштабируемые микросервисные компоненты, которые можно будет использовать в качестве общедоступных сервисов аутентификации и аутентификации микросервисной платформы.Иными словами, аутентификация и аутентификация должны быть общедоступной услугой, а не созданием нескольких систем.

13. Лог и дизайн потока

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

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

14. Централизованное управление конфигурацией

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

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

  • Это разделение конфигурации и среды, которое необходимо контролировать путем формулирования спецификаций. Не помещайте конфигурацию в пакет Jar.

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

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

15. Единый портал управления

В микросервисной архитектуре большое приложение EAR и WAR разбивается на несколько небольших микросервисных программ, которые могут выполняться независимо. Обычно эти микросервисные программы больше не зависят от сервера приложений. Если они не полагаются на традиционный сервер приложений, сервер приложений обеспечивает управление. Консоль бесполезна, поэтому управление микросервисами во время выполнения должно поддерживаться единым порталом управления. Унифицированный и централизованный портал микросервисов, который мы запланировали, может поддерживать разработку приложений, бизнес-процессы, управление приложениями и мониторинг системы. На приведенном выше рисунке показана страница управления приложениями, которая предназначена для управления нашей бизнес-системой в традиционном смысле. Нажмите на бизнес-систему, и мы увидим, какие микрослужбы находятся в системе. Каждая микрослужба имеет несколько экземпляров узлов для запуска, которые можно Состояние дочерних узлов микрослужбы, а также управление конфигурацией и мониторинг микрослужбы.

16. Проблемы с распределенными транзакциями

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

Существует три рекомендуемых схемы согласованности транзакций:

  • надежный шаблон событий: То есть отправка и получение событий обеспечивают высокую надежность для достижения согласованности транзакций.

  • Режим компенсации: Подтвердить Отмена , если подтверждение не удалось, все будет отменено в обратном порядке.

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

17. Проблема вызова распределенной синхронизации

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

Мы рекомендуем архитектуру SEDA для решения этой проблемы.

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

18. Непрерывная интеграция и проектирование непрерывной доставки

С точки зрения эксплуатации и обслуживания, первое, что нам нужно решить, — это непрерывная интеграция и непрерывная доставка, и в настоящее время в сферу ответственности платформы приложений микросервиса планируется только непрерывная интеграция, которая может легко использовать среду непрерывной интеграции для компиляции. программы в пакеты носителей и пакеты развертывания. (В настоящее время непрерывное развертывание планируется обеспечить платформой DevOps, а микросервисная платформа может быть интегрирована с платформой DevOps)

Вот концепция для пояснения: медиа — это продукт компиляции исходного кода, независимый от среды, и он должен совместно использоваться в нескольких средах, таких как: jar, dockerfile; конфигурация: информация, относящаяся к среде.config + media = пакет развертывания.

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

19. Взаимосвязь между микросервисной платформой, контейнерным облаком и DevOps

Что касается самой платформы микросервисных приложений, то она не зависит от DevOps и облаков контейнеров, разработанный пакет развертывания может работать на физических машинах, виртуальных машинах или контейнерах.

Однако, когда платформа приложений микросервисов объединяет DevOps и облако контейнеров, мы обнаружим, что непрерывная интеграция и доставка становятся очень простым, удобным и надежным процессом.

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

6. Резюме и перспективы

Давайте рассмотрим взаимосвязь между тремя основными средами. Платформа микросервисных приложений отвечает за разработку, эксплуатацию и управление приложениями; DevOps отвечает за управление проектами, управление планами, CI, CD, взаимодействие и совместную работу в команде; облачная платформа контейнеров отвечает за управление базовыми настройками и защиту от сложности окружающая среда.

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

Наконец, давайте взглянем на платформу нового поколения, которую разрабатывает Puyuan.

Содержимое в красной рамке выше — это часть, связанная с платформой приложений микросервисов, которой мы поделились сегодня. Вся платформа The Platform с точки зрения планирования общей архитектуры предприятия, начиная с нескольких измерений, направлена ​​на создание устойчивой экологической ИТ-среды для предприятия и ускорение цифровизации предприятия.

Об авторе

Хао Яньфэн

В настоящее время он является архитектором продукта в отделе продуктов SOA и облачных вычислений Puyuan. Он в основном отвечает за проектирование основной архитектуры и планирование разработки версии продукта для продуктов процесса Puyuan, а также последовательно участвовал в создании и реализации крупномасштабных проектов платформы, таких как State Grid BPM, платформа BAM и новое поколение Shanghai Pudong Development Bank. технологическая платформа.

О EAWorld

Микросервисы, DevOps, метаданные, обмен оригинальными технологиями в архитектуре предприятия,EAii (Институт инноваций в архитектуре предприятия) — это официальный аккаунт Института инноваций в архитектуре предприятия в WeChat.

WeChat ID: eaworld, нажмите и удерживайте QR-код, чтобы перейти

С августа по сентябрь продолжится серия технологических вечеринок PWorld. В настоящее время PWorld MeetUP состоится в Шанхае 24 сентября. «Специальная сессия по оркестровке, настройке и 12 элементам микросервисов» начала регистрацию, нажмите «прочитать исходный текст», чтобы перейти непосредственно на страницу регистрации и узнать больше деталей ~

Конференция PWorld Software Architecture & Platform Innovation: крупнейшее национальное технологическое мероприятие, инициированное и организованное Puyuan для обсуждения продвижения «изменений корпоративного программного обеспечения и инноваций в цифровую эпоху».Успешная трансформация китайских предприятий в эпоху цифровых технологий, Активно разрабатывать различные темы для CTO, CIO, архитекторов, технических менеджеров, инженеров-разработчиков и другого технического персонала, связанного с ними,Спикеры делятся своими техническими знаниями и передовым опытом по таким актуальным темам, как корпоративное программное обеспечение, искусственный интеллект, блокчейн, облачные вычисления, большие данные, бизнес-процессы, разработка мобильных устройств и многое другое. В то же время PWorld стала пионером в области «интерактивного опыта» на технических конференциях корпоративного уровня, проявляя к участникам величайшее уважение и предоставляя локальным и онлайн-аудиториям совершенно новый опыт.

Категории