Всем привет, мы снова встретились, я ваш друг Цюаньчжаньцзюнь.

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

Оглавление

сервис-ориентированная архитектура

1 Обзор SOA

1. Базовая структура услуги

2.Принципы проектирования SOA

3. Сервисные компоненты и традиционные компоненты

2 ключевые технологии SOA

1. UDDI

2.WSDL

3.SOAP

4.REST

3 метода реализации SOA

1.Web Service

2. Реестр услуг

3. Корпоративная сервисная шина

4 микросервиса

1. Преимущества микросервисов

2. Проблемы, с которыми сталкиваются микросервисы

3.Микросервисы и SOA

сервис-ориентированная архитектура

Пока что для сервис-ориентированной архитектура（Service-Oriented Архитектура, SOA) пока не имеет общепринятого определения. Многие организации сталкиваются с этим под разными углами и с разных сторон. SOA были описаны, наиболее типичными являются следующие три:

(1) Определение W3C: SOA — это архитектура приложения, в которой все функции определены как независимые сервисы с четко определенными вызываемыми интерфейсами, которые можно вызывать в определенном порядке для формирования бизнес-процессов.

(2) Определение Service-architecture.com: Сервис — это функция, которая точно определена, хорошо инкапсулирована и не зависит от среды и состояния других сервисов. SOA, по сути, представляет собой набор служб, которые взаимодействуют друг с другом. Это взаимодействие может быть простой передачей данных или может осуществляться двумя или более службами, координирующими определенные действия. Сервисам нужен какой-то способ соединения между собой.

（3）Gartner Определение: SOA это своего рода C/S программное обеспечение для архитектурыдизайнметод,Должно использоваться, состоящее из службы и посланников службы.,SOA Общее с большинством C/S Архитектурная модель отличается тем, что подчеркивает слабую связь компонентов и использует независимые стандартные интерфейсы.

1 SOA Обзор

SOA это своего Видсуществовать Методы разработки, разработки, развертывания и управления моделями дискретных логических единиц (сервисов) в вычислительной среде. SOA Это не новинка, а всего лишь альтернатива объектно-ориентированной модели. Хотя на основе SOA система не исключает использования OOD создать единый сервис, но его общая конструкция ориентирована на сервисы. потому что SOA Учитывая объекты внутри системы, хотя SOA Он объектно-ориентированный, но в целом не объектно-ориентированный.

Классическим примером прототипа системы SOA является CORBA, которая существует уже давно и определяет концепции, аналогичные SOA. SOA построена на новых технологиях, таких как XML. Используя языки на основе XML для описания интерфейсов, сервисы перешли к более динамичной и гибкой системе интерфейса, с которой IDL в CORBA не может сравниться. На рис. 9-13 изображена полная модель SOA.

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

1. Базовая структура услуги

Базовая структура независимого сервиса показана на рисунке 9-14.

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

2.Принципы проектирования SOA

существовать SOA В архитектуре наследуются различные принципы объектов и компонентов, такие как инкапсуляция и автономность. Те, которые обеспечивают гибкость, слабую связь и комплексные возможности сервисов. проектирования,верно SOA Архитектура также очень важна. Что касается услуг, некоторые общие принципы проектированияследующее：

(1) Четко определенный интерфейс. Запрашивающие службы полагаются на спецификации служб для вызова служб. Таким образом, определения служб должны быть стабильными в течение длительного времени и не могут быть изменены по желанию после публикации. Определение служб должно быть максимально ясным, чтобы уменьшить неправомерное использование со стороны запрашивающих. запрашивающие видят внутренние личные данные сервиса.

(2) Автономный и модульный. Услуги инкапсулируют эти стабильные и повторяющиеся действия и компоненты бизнеса.,Функциональные объекты, реализующие услуги, полностью независимы и автономны.,Действуйте самостоятельноразвертывать、контроль версий、Самоуправление и восстановление.

(3) Крупнозернистый. Количество сервисов не должно быть слишком большим, полагаясь на взаимодействие сообщений, а не на удаленные вызовы процедур. Обычно объем сообщений относительно велик, но частота взаимодействия между сервисами низкая.

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

(5) Функциональная совместимость, совместимость и заявление о политике. Чтобы гарантировать, что соглашение об обслуживании является всеобъемлющим и ясным,Стратегия становится все более важным аспектом. Это может быть контент, связанный с технологиями.,Например,Требования безопасности услуги также могут быть семантическим контентом, связанным с бизнесом;,Например,Требования к вознаграждению или уровню обслуживания, которые необходимо соблюдать,Эти политики очень важны при взаимодействии с существующими сервисами.

3. Сервисные компоненты и традиционные компоненты

Архитектура сервисных компонентов (Service Component Архитектура (SCA) основана на SOA Идея описания спецификации композиции и взаимодействия между сервисами, описывающей использование SOA Создавайте модели приложений и систем. это упрощает использование SOA Выполнены работы по разработке и внедрению приложения. СКА Предоставляет механизмы для создания крупнозернистых компонентов, которые собираются из мелкозернистых компонентов. СКА Отделяет традиционное программирование промежуточного программного обеспечения от бизнес-логики, освобождая программистов от ее сложности. Это позволяет разработчикам сосредоточиться на написании бизнес-логики, не тратя много времени на техническую реализацию более низкого уровня.

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

2 ключевые технологии SOA

SOA Наряду с повсеместным стандартом, он повышает сложность существующих активов или инвестиций предприятий. СОА Он может создавать приложения поверх новейших и существующих систем, создавать новые сервисы с помощью существующих приложений и предоставлять предприятиям большую гибкость при построении систем и бизнес-процессов. СОА это своего Новая архитектура, для поддержки ее различных функций постоянно вводятся соответствующие технические характеристики. и SOA Тесно связанные технологии в основном включают в себя UDDI、WSDL、SOAP и REST и т. д., и все эти технологии основаны на XML разработано за основу.

1. UDDI

UDDI（Universal DescriptionDiscovery and Интеграция (унифицированное описание, обнаружение и интеграция) обеспечивает метод публикации, поиска и позиционирования сервиса. Это спецификация регистрации информации о сервисе, чтобы ее могли обнаружить и использовать пользователи, которым нужна услуга. УДДИ Спецификация описывает концепцию сервисов, а также определяет интерфейс программирования. проходить UDDI Благодаря предоставленному стандартному интерфейсу предприятия могут публиковать свои собственные службы, чтобы другие предприятия могли их использовать, или они могут запрашивать информацию об описании конкретной службы и динамически привязывать ее к службе.

существовать UDDI Технические характеристики в основном включают в себя следующие три части:

(1) Модель данных. УДДИ Модель данных — это модель, описывающая бизнес-организацию и услуги. XML Schema。

(2) API. API UDDI — это набор методов для поиска или публикации данных UDDI. API UDDI основан на SOAP.

(3) Служба регистрации. Служба регистрации UDDI — это инфраструктура в SOA, соответствующая роли центра регистрации службы.

2.WSDL

WSDL（Web ServiceDescription Language,Web Язык описания услуг) — язык описания услуг. Имеет набор. XML грамматическое определение. WSDL В центре описания находится служба, которая включает в себя определение реализации службы и определение интерфейса службы, как показано на рисунке. 9-15 показано.

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

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

3.SOAP

SOAP（Simple ObjectAccess Протокол (простой протокол доступа к объектам) определяет спецификацию передачи сообщений между запросчиками услуг и поставщиками услуг. МЫЛО использовать XML чтобы отформатировать сообщение, используйте HTTP нести сообщение. проходить SOAP, прикладная программа может осуществлять обмен данными в сети и удаленную отладку процедур (Remote Procedure Call, RPC）。SOAP В основном он включает в себя следующие четыре части:

(1) Инкапсуляция. МЫЛО Инкапсуляция определяет общую структуру для представления того, что включено в сообщение, кто его обрабатывает, а также является ли оно необязательным или обязательным.

(2) Правила кодирования. МЫЛО Правила кодирования определяют механизм сериализации для обмена экземплярами типов данных, определенных системой.

（3）RPC выражать. МЫЛО RPC Указывает, что ause определен для представления протокола ответа на вызов удаленной процедуры.

(4) Привязка. МЫЛО Привязка определяет базовый транспортный протокол, который использует use для завершения обмена между узлами. SOAP Соглашение об инкапсуляции.

SOAP Сообщения, по сути, представляют собой одностороннюю передачу от отправителя к получателю, но они часто объединяются для выполнения шаблона, подобного запросу/ответу. все SOAP Новости делаютиспользовать XML Кодировать. МЫЛО Сообщение состоит из следующих трех частей:

(1) Инкапсуляция (конверт). Имя инкапсулированного элемента: Envelope,существоватьвыражая новости XML В документе инкапсуляция является элементом верхнего уровня, существующим SOAP Должно появиться в сообщении.

（2）SOAP голова. МЫЛО Имя элемента заголовка: Заголовок, обеспечивает SOAP Добавить сообщение об этом SOAP Механизм определенных элементов сообщения. МЫЛО Определено небольшое количество атрибутов, указывающих, является ли этот элемент необязательным и кто должен его обрабатывать. МЫЛО головасуществовать SOAP Оно может появиться или не появиться в сообщении. Если он присутствует, он должен быть SOAP Первый прямой дочерний элемент инкапсулирующего элемента.

（3）SOAP тело. МЫЛО Имя элемента тела Тело — это контейнер, содержащий информацию,предназначенную конечному получателю сообщения. МЫЛО телосуществовать SOAP должно появиться в сообщении и должно быть SOAP Прямой дочерний элемент инкапсулирующего элемента. Если есть элемент заголовка, SOAP С телом должен непосредственно контактировать существующий SOAP после элемента head, если элемента head нет, то SOAP тело должно быть SOAP Первый прямой дочерний элемент инкапсулирующего элемента.

4.REST

REST（RepresentationalState Трансфер, представительский государственный трансфер)это своего родаиспользовать толькоиспользовать HTTP и XML на основе Web Коммуникационные технологии могут снизить сложность разработки и улучшить масштабируемость системы. Его простота и отсутствие строго профилированных функций отличают его от SOAP Хорошая изоляция, ОТДЫХ По сути, поддерживаются только несколько операций (POST, GET, PUT). и DELETE), эти операции применяются ко всем сообщениям. ОТДЫХ Предлагаются следующие понятия и критерии дизайна:

(1) Все в сети абстрагировано на ресурсы.

(2) Каждому ресурсу соответствует уникальный идентификатор ресурса.

(3) Управляйте ресурсами через интерфейс соединителя через использование.

(4) Различные операции с ресурсами не изменят идентификацию ресурса.

(5) Все операции не имеют состояния.

3 метода реализации SOA

SOA Толькоэто своего Подобные концепции и идеи необходимо реализовывать с помощью конкретных технологий и методов. По сути, SOA Это модель локальных вычислений для реализации приложений с распределенными вычислениями. Некоторые люди также называют этот метод «моделью локализации, распределенной работы». и EJB и т. д. все относятся к этому решению, то есть SOA Наконец-то ты можешь на основе Эти стандарты реализованы. Знания об этих стандартах существуют. 13.1.1 Подробное введение в разделе. Кроме того, эти стандарты соответственно делаютиспользовать ORB、RPC и RMI（Remote Method Вызов, удаленный вызов метода (использовать) и другие технологии будут существовать. 17.1.2 Оно представлено в разделе и здесь повторяться не будет.

С точки зрения логической и высокоуровневой абстракции, в настоящее время реализация SOA Существует также множество методов, среди которых основными являются методы. Web Service、служебный автобус предприятияи Реестр услуг。

1.Web Service

существовать Web Service（Web Service) существует три должностные роли, среди которых требуются поставщик услуг и заказчик услуг, а центр регистрации услуг является дополнительной ролью. Взаимодействие и операции между ними составляют SOA Архитектура реализации, как показано на рисунке. 9-16 показано.

(1) Поставщик услуг. Поставщик услуг является владельцем сервиса. Эта роль отвечает за определение и реализацию сервиса для его использования. WSDL Опишите услугу подробно, точно и стандартно и опубликуйте описание в центре регистрации услуги, чтобы заказчики услуги могли найти и привязать услугу.

(2) Запросчик услуги. Запрашивающая услугу является пользователем услуги. Хотя услуга ориентирована на программу, конечным пользователем программы по-прежнему является пользователь. С точки зрения архитектуры запрашивающая служба — это приложение, которое находит, связывает и вызывает службу или взаимодействует с ней. Роль запросчика службы может выполнять браузер, управляемый человеком или программой (например, другой службой).

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

Web Service Операции модели включают публикацию, поиск и привязку. Эти операции могут выполняться один раз или неоднократно.

(1) Выпуск. Чтобы пользователи могли получить доступ к сервису, поставщику услуг необходимо опубликовать описание сервиса, чтобы инициаторы запроса могли его найти.

(2) Поиск. В операции поиска существования инициатор запроса услуги непосредственно извлекает описание услуги, или центр регистрации услуги запрашивает запрошенный тип услуги. Для заказчиков услуг операции поиска могут включать два различных этапа жизненного цикла существования. Первый — это этап существованиядизайна, на котором осуществляется поиск описания интерфейса сервиса для разработки программы, второй — этап существования, на котором осуществляется поиск; описание интерфейса службы для целей отладки. Описание местоположения.

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

существовать Выбиратьиспользовать Web Service как SOA При реализации технологии прикладную систему можно условно разделить на шесть уровней, а именно: базовый транспортный уровень, уровень протокола связи службы, уровень описания службы и т. д. Уровень обслуживания, уровень бизнес-процессов и уровень регистрации услуг.

(1) Нижний транспортный уровень. Базовый транспортный уровень в основном отвечает за механизм передачи сообщений, HTTP, JMS (Java Messaging Service,Java Служба обмена сообщениями)и SMTP как протокол передачи служебных сообщений, где HTTP делатьиспользовать Самый широкий。

(2) Уровень протокола связи служб. Основная функция уровня протокола связи служб заключается в описании и определении технических стандартов, необходимых для передачи сообщений между службами. Стандарт общего использования — это. SOAP и REST протокол.

(3) Уровень описания услуги. Уровень описания сервиса в основном описывает интерфейс сервиса и метод обмена сообщениями. Соответствующим стандартом является WSDL.

(4) Уровень обслуживания. Основная функция уровня обслуживания — упаковать устаревшую систему и WSDL Описание интерфейса находится в файле use.

(5) Уровень бизнес-процессов. Основная функция уровня бизнес-процессов — поддержка обнаружения сервисов, развертывания сервисов и двухточечного развертывания сервисов, а также перенос бизнес-процессов с нижнего уровня сервиса на абстрактный публичный уровень. заявить.

(6) Основная функция уровня регистрации услуг состоит в том, чтобы позволить поставщикам услуг публиковать определения услуг через WSDL и поддерживать запрашивающих услуги в поиске необходимой информации об услугах. Соответствующим стандартом является UDDI.

2. Реестр услуг

Реестр услуг（service Хотя реестр также имеет функции времени выполнения, в основном SOAдизайниспользовать. Он обеспечивает точку применения политики (Policy Enforcement Точка, PEP), существование В этой точке услуга может существовать SOA Зарегистрируйтесь, чтобы вас можно было найти. Реестр услуги могут включать файлы конфигурации, соответствия и ограничений для служб и связанных компонентов. Теоретически реестром может считаться любой репозиторий, база данных, база данных или другой узел, который помогает регистрировать службы, обнаруживать и искать контракты на обслуживание, метаданные и политики. Большинство продуктов регистрации услуг торговцев поддерживают регистрацию услуг, определение местоположения услуг и функции привязки услуг.

(1) Регистрация услуги. Регистрация услуги означает, что поставщик услуги подает запрос в Реестр. услуг публикует функцию услуги (контракт на обслуживание), включая описательные атрибуты, такие как идентификатор услуги, местоположение, метод, привязка, конфигурация, схема и стратегия. makeuseРеестр реализация услуг SOA При этом необходимо ограничить, какие новые услуги могут быть опубликованы в реестре, кто их публикует, кто их утверждает и при каких условиях, чтобы услуги могли быть зарегистрированы в установленном порядке.

(2) Место обслуживания. Местоположение службы относится к пользователям службы, которые помогают им запрашивать зарегистрированные службы и находить службы, соответствующие их собственным требованиям. Этот поиск в основном достигается за счет получения контракта на обслуживание, существующего makeuseReestr. реализация услуг SOA Когда необходимо указать, какие пользователи могут получить доступ к Реестру услуг, и какие атрибуты услуги может передавать Реестр услуги проводят разоблачение и т. д., чтобы услугу можно было использовать эффективно и разрешено использовать.

（3）Служитьобязательность。Служитьделатьиспользовать Те, кому это выгодноиспользоватьнайденный Служить Контракт приходитразвиватькод,Разработанный код будет привязан к зарегистрированному сервису.,Сервис для настройкииспользования регистрации,и взаимодействовать с ними。Может принести пользуиспользоватьинтегрированныйразвивать Среда автоматически изменится на новуюразвиватьиз Служить与不同из新协议、плани Другие интерфейсы, необходимые для межпрограммной связиобязательностьсуществовать Вместе。

3. Корпоративная сервисная шина

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

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

ESB Реализовано и поддерживается технологией промежуточного программного обеспечения. Набор инфраструктуры для SOA представляет собой комбинацию традиционных технологий промежуточного программного обеспечения и XML、 Web Service Продуктом сочетания таких технологий, как существование, является сервис-ориентированный механизм интеграции корпоративных приложений в рамках всей архитектуры интеграции предприятия. В частности, ЕСБ Имеет следующие функции:

(1) Поддержка услуг и сообщений гетерогенной среды. на основе взаимодействия событий с соответствующими уровнями обслуживания и управляемости.

(2) С помощью использования ESB может предоставить существующим системам новый сервисный интерфейс плавным и неинтрузивным способом практически без изменений кода и поддерживать любой стандарт в среде развертывания.

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

(4) существуют более высокий уровень, ESB Также предусмотрены такие функции, как прокси-сервер службы и преобразование протокола. Позволяет существовать в различных формах, таких как HTTP, SOAP. и JMS Различные методы передачи данных по шине, в основном в форме сетевых сервисов, обеспечивают инфраструктуру для публикации, регистрации и обнаружения корпоративных сервисов или интерфейсов.

(5) Обеспечить настраиваемый механизм преобразования и перевода сообщений. основа Служба маршрутизации сообщений для содержимого сообщений, передающая сообщения по разным адресатам.

(6) Обеспечить механизм безопасности и владельца для обеспечения аутентификации, авторизации и целостности пользователей сообщений и услуг.

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

(1) Расширенные возможности подключения на основе стандартов. ЭСБ сформировать на На основе стандартного информационного скелета обеспечивается возможность легкого асинхронного или синхронного обмена данными внутри существующей системы и по всей цепочке создания стоимости. ЭСБ проходитьделатьиспользовать XML、SOAP и другие стандарты, обеспечивающие более мощные возможности подключения системы.

(2) Гибкий портфель сервис-ориентированных приложений. на основе SOA,ESB Позволяет сложным распределенным системам (включая решения по интеграции нескольких приложений, систем и межсетевых экранов) состоять из ранее разработанных и протестированных сервисов, что обеспечивает высокую масштабируемость системы.

(3) Увеличение скорости восстановления и снижение затрат. в соответствии с SOA Конструкция метода должна быть использована, что повышает скорость репликации, упрощает работу по обслуживанию и, таким образом, снижает общую стоимость системы.

(4) Сократить время реакции рынка и повысить производительность. ЭСБ По компоненту и сервису репликации следуйте SOA Мысль об упрощении следует сочетать с использованием, т. на основе стандартной связи, преобразования и подключения для достижения этих преимуществ.

4 микросервиса

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

С профессиональной точки зрения микросервисы Архитектура — это своего Тип архитектурной модели, которая предполагает разделение одной прикладной программы на набор небольших сервисов. Сервисы координируются и взаимодействуют друг с другом, чтобы обеспечить максимальную ценность для пользователей. Каждая служба выполняется в своем собственном независимом процессе, и службы взаимодействуют друг с другом, используя упрощенный механизм связи (обычно основе HTTP согласованный RESTful API). Каждая услуга построена вокруг конкретного бизнеса и может быть независимо развернута в производственных средах, средах, подобных производственным, и т. д. Кроме того, следует максимально избегать унифицированного и централизованного механизма управления сервисами. Для конкретного сервиса следует выбирать подходящие языки и инструменты для его построения с учетом бизнес-контекста.

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

1. Преимущества микросервисов

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

(1) Техническая неоднородность

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

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

(2) Гибкость

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

(3) Расширение

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

(4) Упрощение развертывания

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

(5) Соответствуйте структуре переплетения

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

(6) Компонуемость

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

(7) Оптимизация заменяемости

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

2. Проблемы, с которыми сталкиваются микросервисы

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

(1) Сложность распределенных систем

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

(2) Затраты на эксплуатацию и техническое обслуживание

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

(3) Автоматизация развертывания

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

(4) DevOps и организационная структура

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

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

(5) Тестирование межсервисных зависимостей

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

(6) Управление межсервисными зависимостями

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

3.Микросервисы и SOA

микросервисы можно назвать SOA Один вид, но после тщательного анализа и изучения мы можем найти между ними некоторые различия. Эта разница проявляется во многих аспектах, как показано в таблице. 9-8 показано.

Эти различия естественным образом влияют на его реализацию. Основные различия в реализации существования заключаются в следующем: 9-9 показано.

——————— Автор: hu19930613 Источник: ЦСДН Исходный текст: https://blog.csdn.net/hu19930613/article/details/82749534. Заявление об авторских правах: Эта статья является оригинальной статьей блоггера. При перепечатке прикрепите ссылку на сообщение в блоге!

Издатель: Full stack программист и руководитель стека, укажите источник для перепечатки: https://javaforall.cn/164074.html Исходная ссылка: https://javaforall.cn