Почему стоит выбрать микросервисную архитектуру? 10 основных преимуществ микросервисной архитектуры.

1. Что такое микросервисы?

У нас нет четкого определения микросервисной архитектуры, но, проще говоря, микросервисная архитектура — это: Создайте приложение, используя набор Служить, Служить независимое развертывание в разных процессах, различные Служить взаимодействуют через некоторые легкие механизмы взаимодействия, такие как RPC、HTTP И т. д., сервисы можно расширять и масштабировать независимо, каждый сервис имеет четко определенные границы, а разные сервисы даже могут быть реализованы на разных языках программирования и поддерживаться независимыми командами.

2. Каковы характеристики микросервисной архитектуры?

1) Компонентизация через сервисы

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

2) Разделить сервисную и организационную команды по возможностям бизнеса.

Закон Конвея гласит:

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

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

В традиционном методе разработки мы разделяем инженеров на интерфейсный уровень, средний уровень и уровень данных в соответствии с их навыками и опытом. Роли, соответствующие интерфейсу, — это пользовательский интерфейс, создатель страниц и т. д., роли соответствуют Средний уровень — это инженеры по развитию бизнеса на стороне сервера, а соответствующие роли для уровня данных — играющий администратор базы данных и другие роли. Фактически, иерархическая структура традиционной архитектуры проектирования приложений отражает структуру связи различных ролей. Модель развития микросервисной архитектуры отличается от традиционного метода: она разделяет приложения на различные службы в соответствии с возможностями бизнеса. ь, каждый Служить требует полнофункциональной (от front-end до back-end) реализации программного обеспечения в соответствующей сфере бизнеса, от интерфейса до хранилища данных, сотрудничества с внешними коммуникациями и так далее. Таким образом, организация команды является межфункциональной и включает в себя весь спектр навыков, необходимых для ведения бизнеса. Появление фуллстек-инженеров в последние годы связано с изменениями в архитектуре и моделях разработки. Конечно, инженеров с фуллстек-возможностями на самом деле очень мало, но гораздо проще объединить инженеров из разных областей в фулл-стек. команда стека.

3) Услуга как продукт

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

You buidl it, you run it.

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

4) Интеллектуальные терминалы и тупые трубы

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

5) Децентрализация и унификация

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

6) Автоматизация инфраструктуры

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

7） Design for failure

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

8) Эволюционный дизайн

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

Be conservative in what you send, be liberal in what you accept.

Будьте консервативны при отправке, будьте открыты при получении.

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

3. Зачем использовать микросервисную архитектуру?

Разрабатывать монолитные приложения

Предположим, вы готовитесь к разработке программного обеспечения для диспетчеризации такси, чтобы конкурировать с Uber и Hailo. После предварительных встреч и анализа требований вы можете запустить этот новый проект вручную или использовать генератор на основе Rails, Spring Boot, Play или Maven. Это шестиугольная архитектура. — это модульное приложение, ядром которого является бизнес-логика, дополненная модулями, определяющими сервисы, объекты предметной области и события. Ядро окружают адаптеры для взаимодействия с внешним миром. Адаптеры включают в себя компоненты доступа к базе данных, компоненты сообщений, которые создают и обрабатывают сообщения, а также веб-модули, обеспечивающие поддержку доступа к API или пользовательскому интерфейсу и т. д.

Хотя это тоже модульная логика,Но со временем его упакуют и развернут как монолитное приложение. Точный формат зависит от языка и платформы приложения. Например,Многие приложения Java упакованы в формате WAR.,развернуть на Tomcat или Jetty,Другие приложения Java будут упакованы в автономный формат JAR.,такой же,Rails и Node.js будут упакованы в иерархические каталоги.

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

Недостатки монолитных приложений

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

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

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

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

Когда конфликты ресурсов возникают в разных модулях монолитного приложения,Масштабировать будет очень сложно. например,Один модуль реализует логику, чувствительную к ЦП.,долженразвертыватьсуществоватьAWS EC2 Compute Optimized экземпляров, а другой модуль базы данных в памяти больше подходит для EC2 Memory-optimized экземпляры. Однако,Так как эти модули развертываются вместе,Поэтому при выборе оборудования приходится идти на компромисс.

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

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

Так как же справиться с вышеперечисленными проблемами?

Решение: микропроцессорная архитектура — обработка сложных транзакций

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

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

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

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

Немного ОТДЫХА API также открыт для мобильных приложений, которые могут использовать пассажиры и водители. Эти приложения получают доступ к фоновым службам не напрямую, а через API. Шлюз для доставки промежуточных сообщений. API Шлюз отвечает за балансировку нагрузки, кэширование, контроль доступа и API. Такие задачи, как выставление счетов и другие задачи, можно легко реализовать с помощью NGINX. В последующих статьях будет представлен этот API. Gateway。

Шаблон микросервисной архитектуры на приведенном выше рисунке соответствует оси Y, представляющей масштабируемый Scale Cube, который представляет собой трехмерную модель масштабирования, описанную в книге «Искусство масштабируемости». Две другие оси масштабируемости: ось X состоит из нескольких реплик приложений, работающих на серверной части балансировщика нагрузки, а ось Z направляет требования к соответствующим службам.

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

время выполнения,Управление маршрутами Служить состоит из нескольких экземпляров Служить. Каждый экземпляр Служить представляет собой Docker-контейнер. Чтобы обеспечить высокую доступность,Эти контейнеры обычно работают на нескольких облачных виртуальных машинах. Перед экземпляром «Служить» находится уровень балансировщика нагрузки, например NGINX.,Они отвечают за распределение запросов между различными инстанциями. Балансировщик нагрузки также одновременно обрабатывает другие запросы.,Например, кэширование、Контроль разрешений、API Статистика и монитор.

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

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

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

4. В чем разница между микросервисной архитектурой и SOA?

SOA и микросервисы применяют многие из одних и тех же принципов, но они применяются на разных уровнях организации. SOA фокусируется на организации «больших сервисов», но эти крупные сервисы также можно реализовать путем объединения ряда микросервисов. Размер службы не является хорошим способом определения микрослужбы.

На первый взгляд шаблон архитектуры микросервисов немного похож на SOA. Они состоят из нескольких сервисов. Если посмотреть на это с другой точки зрения, шаблон архитектуры микросервисов представляет собой SOA, который не включает веб-сервисы (WS-) и сервисы ESB.

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

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

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

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

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

Более того, различные подсистемы не используют централизованное хранилище, как исходные корпоративные вычисления, которые используют дорогостоящий Oracle для хранения данных всей системы. Во-вторых, используются базы данных NOSQL, такие как MongoDB, HBase и Cassandra, а также распределенные кэши, такие как Redis и memcache. .

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

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

5. Каковы преимущества микросервисной архитектуры?

Шаблон архитектуры микросервисов имеет множество преимуществ.

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

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

третий,Шаблон «Архитектура микросервисов» представляет собой независимое развертывание для каждого микросервиса. Улучшить больше не нужно координировать влияние других Служитьразвертывать на эту Служить. Это изменение может ускорить развертывание. Команды пользовательского интерфейса могут использовать ABtest,Быстрая развертывание изменений. Шаблон микросервисной архитектуры позволяет поддерживать развертывание.

наконец,Режим «Микросервисы Архитектура» позволяет расширять каждую Служить независимо. Вы можете развернуть каждый Служить в соответствии с размером, чтобы удовлетворить ваши потребности. даже,Вы можете использовать оборудование, которое больше соответствует требованиям к ресурсам Служить. например,ты можешьсуществоватьEC2 Compute Optimized экземпляры на развертыватьCPU-sensitivity Служить, находясь на EC2 memory-optimized База данных в памяти для развертывания экземпляров.

6. Каковы недостатки микросервисной архитектуры?

Как и любая другая технология, микросервисная архитектура имеет свои недостатки. Один из них похож на его название, «Микросервисы», и подчеркивает размер сервиса. Фактически, некоторые разработчики выступают за создание сервисов немного большего размера, 10-100. LOCСлужить Группа。Хоть и маленький Служитьболее охотно быть усыновленным,Но не забывайте, что это всего лишь конечный выбор, а не конечная цель. микросервисы предназначены для эффективного разделения приложений,Будьте гибкимиразвиватьиразвертывать。

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

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

тестодин на основемикросервисы Архитектура Приложение также является очень сложной задачей.。например,принять популярныйSpring Boot Архитектура, для монолитного веб-приложения, протестируйте его REST. API,Это очень легко. по очереди,такой жеиз Служитьтест Нужно начатьиэто примерноизвсе Служить（По крайней мере, они нужны Служитьизstubs）。снова,Сложность, связанную с внедрением микросервисной архитектуры, нельзя недооценивать.

кроме тоговызовсуществовать В,Изменения в применении режима микросервисы Архитектура коснутся нескольких Служить. например,Предположим, вы завершаете дело,Необходимо изменить СлужитьA, B, C,А А зависит от Б,Б зависит от С. В монолитном приложении,Вам просто нужно изменить соответствующие модули,Интегрируйте изменения,Просто развернуть. В отличие,Модель микросервисной архитектуры должна учитывать влияние соответствующих изменений на различные службы. например,Вам необходимо обновить СлужитьC,Тогда Б,Последний — А,к счастью,Многие изменения обычно затрагивают только одно Служить,А изменений, которые требуют координации многих Служить, немного.

развернуть Приложение микросервисы тоже сложное,Распределенному приложению просто необходимо иметь собственный эквалайзер позади сложного эквалайзера. Для каждого экземпляра приложения необходимо настроить базовые компоненты, такие как база данных и промежуточное программное обеспечение для сообщений. относительное сравнение,Приложение микросервисы обычно состоит из большого количества Служить. Например,По словам Адриана Кокрофта,В Hailo 160 различных композиций.,У NetFlix около 600 Служить. Существует несколько экземпляров каждого варианта Служить. При этом создается множество частей, требующих настройки, развертывания, расширений и монитора.,кроме,Вам также необходимо выполнить механизм обнаружения Служить.,Чтобы узнать адрес взаимодействующего с ним Служить (включая адрес и порт сервера Служить). Традиционные методы решения проблем не могут быть использованы для решения таких сложных задач. приходить один за другим,Успешная развертывание приложения микросервиса требует, чтобы производитель имел адекватный контроль над методом развертывания.,и высокоавтоматизированный.

Один из способов автоматизировать это — использовать службу PaaS, например Cloud. Foundry。PaaSДаватьразвиватьпровайдер предоставляетразвертыватьиуправлятьмикросервисыизпростой метод,Он решает все эти проблемы в одном пакете. в то же время,КонфигурацияPaaSизсистемаи Сетевые эксперты могут перенять лучшие практикии Стратегии упрощения этих проблем。кроме тогоавтоматическийразвертыватьмикросервисыприложениеиз Методразвивать对В你来说最基础изPaaSсистема。типичныйиз Отправная точкаиспользовать Решение для кластеризации,например СотрудничатьDockerиспользоватьMesosилиKubernetes。

7. Какова организационная структура микросервисной архитектуры?

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

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

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

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

8. Почему микросервисы — это продукт, а не перспективный проект?

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

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

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

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

9. Как микросервисы создают структуры связи между различными процессами?

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

Сообщество микросервисов склонно использовать другой метод реализации: интеллектуальные конечные точки и надежные процессы. Приложения, использующие архитектуру микросервисов, стремятся быть максимально развязанными и ассоциативными — каждое из них имеет свою собственную логику предметной области и работает скорее как механизм фильтрации в классическом сценарии Unix — получая запросы, применяя соответствующую логику и генерируя ответ. Все это организуется с помощью простого протокола, подобного REST, а не с помощью сложных протоколов, таких как WS-Choreography или BPEL, и инструментов центральной оркестровки.

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

Опирайтесь на Интернет, а не за Интернет.

– Ian Robinson

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

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

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

10. Какие аспекты следует учитывать при реализации микросервисной архитектуры?

Моделирование

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

сотрудничество

После перехода в режим «Микросервисы Архитектура» изменятся как режим развития, так и режим текущего сотрудничества.

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

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

-API, техническое описание доступа к API конкретных интерфейсов.

- Возможности, описание возможностей сервиса.

- Контракт, предусматривающий некоторые ограничения на эти возможности.

- Поддерживается версия, последняя и историческая версии.

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

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

тест

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

развертывать

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

монитор

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

Подвести итог：

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

Заключение

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