Глубокое понимание микросервисной архитектуры

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

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

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

Хотя они также следуют модульной разработке, в конечном итоге они упаковываются и развертываются как монолитные приложения. Например, приложение Java будет упаковано как WAR и развернуто на Tomcat или Jetty.

Это монолитное приложение больше подходит для небольших проектов, его преимущества:

Простая и понятная разработка, централизованное управление
В основном нет повторного развития
Все функции являются локальными, без затрат на распределенное управление и вызовов.

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

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

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

Например, описанную ранее систему можно разложить на:

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

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

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

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

В-третьих, микросервисная архитектура позволяет развертывать каждый микросервис независимо. Разработчикам не нужно координировать развертывание обновлений или изменений служб. Эти изменения могут быть развернуты, как только пройдут тесты. Таким образом, микросервисная архитектура также делает возможным CI/CD.

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

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

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

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

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

Микросервисная архитектура также создает большие трудности для тестирования. Традиционные монолитные веб-приложения должны тестировать только один REST. API достаточно, а для тестирования микросервиса нужно запустить все остальные сервисы, от которых он зависит. Эту сложность нельзя недооценивать.

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

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

Вышеуказанные проблемы и задачи можно в общих чертах сформулировать следующим образом:

API Gateway
межсервисный вызов
обнаружение службы
Отказоустойчивость сервиса
Развертывание службы
вызов данных

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

Фреймворк микросервисов первого поколения

Spring Cloud

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

Spring Cloud Config: централизованная внешняя поддержка из управления конфигурацией репозитория Git. Выделение ресурсов напрямую сопоставляется с Spring Environment, но при необходимости может использоваться приложениями, отличными от Spring.
Spring Cloud Netflix: интеграция с различными компонентами Netflix OSS (Eureka, Hystrix, Zuul, Archaius и т. д.).
Spring Cloud Bus: шина событий для подключения служб и экземпляров служб с распределенным обменом сообщениями. Используется для распространения изменений состояния (например, событий изменения конфигурации) в кластере.
Spring Cloud для Cloudfoundry: интегрируйте свое приложение с Pivotal Cloudfoundry. Обеспечивает реализацию обнаружения службы, а также упрощает защиту ресурсов с помощью SSO и OAuth 2 и может создавать прокси службы Cloudfoundry.
Spring Cloud — Cloud Foundry Service Broker: предоставляет отправную точку для создания сервисных брокеров, которые управляют сервисом в Cloud Foundry.
Spring Cloud Cluster: выбор лидера и общая модель состояния (на основе абстракций и реализаций ZooKeeper, Redis, Hazelcast, Consul).
Spring Cloud Consul: совместите обнаружение сервисов и управление конфигурацией Hashicorp Consul
Spring Cloud Security: обеспечивает поддержку спящего клиента OAuth 2 с балансировкой нагрузки и ретрансляции заголовков аутентификации в прокси-сервере Zuul.
Spring Cloud Sleuth: распределенная трассировка для приложений Spring Cloud, совместимая с Zipkin, HTrace и трассировкой на основе журналов (например, ELK).
Spring Cloud Data Flow: облачная служба оркестрации для компонуемых микросервисных приложений в современных средах выполнения. Простой в использовании DSL, графический интерфейс с перетаскиванием и REST-API вместе упрощают общую оркестровку конвейеров данных на основе микросервисов.
Spring Cloud Stream: облегченная среда микросервисов, управляемая событиями, для быстрого создания приложений, которые могут подключаться к внешним системам. Простая декларативная модель для отправки и получения сообщений между приложениями Spring Boot с использованием Apache Kafka или RabbitMQ.
Стартовые приложения Spring Cloud Stream: стартовые приложения Spring Cloud Task — это приложения Spring Boot, которые могут быть любыми процессами, включая задания Spring Batch, которые не выполняются вечно и завершаются/останавливаются после обработки ограниченного объема данных.
Spring Cloud ZooKeeper: обнаружение сервисов и управление конфигурацией для ZooKeeper.
Spring Cloud для Amazon Web Services: простая интеграция с управляемыми сервисами Amazon Web Services. Он легко интегрируется с сервисами AWS, такими как API кэширования или обмена сообщениями, с помощью идиом и API Spring. Разработчики могут создавать приложения на основе управляемых сервисов, не заботясь об инфраструктуре.
Разъемы Spring Cloud: включают приложения PAAS на различных платформах, которые могут легко подключиться к бэкэнду, такие как базы данных и брокеры сообщений (проект, ранее известный как «облако весна»).
Spring Cloud Starters: как проект запуска на основе Spring Boot, он уменьшает управление зависимостями (после Angel.SR2 он больше не является независимым проектом).
Spring Cloud CLI: подключаемый модуль поддерживает быстрое создание компонентных приложений Spring Cloud на основе прогнозов Groovy.

Dubbo

Dubbo — это платформа распределенных служб с открытым исходным кодом от Alibaba, предназначенная для предоставления высокопроизводительных и прозрачных решений удаленного вызова служб RPC, а также решений для управления службами SOA. Его основные части включают в себя:

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

Будет очевидно, будь то Spring Dubbo или Облака применяются только к конкретным сценариям приложений и среде разработки, они не предназначены для поддержки общего назначения и многоязычия. И это только уровень разработки фреймворка, полное отсутствие решения DevOps (архитектура микросервисов требует внимания). А дальше будет рост Service Mesh.

Следующее поколение микросервисов: Service Mesh?

Service Mesh

Service Mesh также переводится как «сервисная сетка», как уровень инфраструктуры для связи между сервисами. Если вы используете одно предложение, чтобы объяснить, что такое Service Mesh, вы можете сравнить его с TCP/IP между приложениями или микросервисами, который отвечает за сетевые вызовы, ограничение тока, объединение и мониторинг между сервисами. При написании приложений, как правило, не нужно заботиться об уровне TCP/IP (например, RESTful-приложения через протокол HTTP), а при использовании Service Mesh также не нужно касаться вещей между службами, которые изначально были реализованы через приложения или другие приложения. фреймворков.Например, Spring Cloud, OSS, теперь нужно только сдать в Service Сетка подойдет.

Service Mesh имеет следующие характеристики:

Средний уровень связи между приложениями
Легкий веб-прокси
Приложение не имеет восприятия
Очеркнутые приложения повторные приложения / тайм-ауты, мониторинг, отслеживание и открытие услуг

Архитектура Service Mesh показана на следующем рисунке:

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

В настоящее время популярным программным обеспечением с открытым исходным кодом для Service Mesh являются Linkerd, Envoy и Istio, а недавно Buoyant (компания, открывшая Linkerd) выпустила Conduit, проект сервисной сетки с открытым исходным кодом, основанный на Kubernetes.

Linkerd

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

Linkerd предназначен для решения проблем, с которыми сталкиваются такие компании, как Twitter, Yahoo, Google и Microsoft, когда они запускают большие производственные системы. Как правило, источником самого сложного, неожиданного и неожиданного поведения часто являются не сами сервисы, а коммуникации между сервисами. Linkerd решает эти проблемы, не только контролируя механизм связи, но и предоставляя поверх него уровень абстракции.

Его основные функции:

Балансировка нагрузки: LinkerD предлагает различные алгоритмы балансировки нагрузки, которые используют метрики производительности в реальном времени для распределения нагрузки и уменьшения задержки хвоста всего приложения.
Прерыватели цепи: Linkerd включает в себя автоматические прерыватели цепи, которые останавливают отправку трафика на экземпляры, считающиеся неработоспособными, давая им возможность восстановиться и избежать каскадного сбоя.
Обнаружение служб: Linkerd интегрируется с различными механизмами обнаружения служб, чтобы помочь вам уменьшить сложность кода за счет удаления специальных реализаций обнаружения служб.
Динамическая маршрутизация запросов: Linkerd обеспечивает динамическую маршрутизацию и перемаршрутизацию запросов, позволяя вам настраивать промежуточные службы, канарейки, сине-зеленые развертывания, сбои между контроллерами домена с минимальной конфигурацией Handoffs и темным трафиком.
Количество повторных попыток и крайние сроки: Linkerd может автоматически повторять запросы при определенных сбоях и может прерывать запросы по истечении заданного периода времени.
TLS: Linkerd можно настроить для отправки и получения запросов с использованием TLS, который можно использовать для шифрования связи между хостами без изменения существующего кода приложения.
HTTP Proxy Integration: LinkerD может действовать как HTTP Proxy, почти все современные клиенты HTTP широкий спектр поддержки, что позволяет легко интегрироваться в существующие приложения.
Прозрачный прокси: вы можете использовать правила iptables на хосте, чтобы настроить прозрачный прокси через Linkerd.
gRPC: Linkerd поддерживает HTTP/2 и TLS, что позволяет ему маршрутизировать запросы gRPC, поддерживая расширенные механизмы RPC, такие как двунаправленная потоковая передача, управление потоком и полезная нагрузка структурированных данных.
Распределенная трассировка: Linkerd поддерживает распределенную трассировку и метрики, что может обеспечить единую наблюдаемость для всех служб.
Инструментарий: Linkerd поддерживает инструменты распределенного отслеживания и измерения, которые могут обеспечить единую наблюдаемость для всех сервисов.

Envoy

Envoy разработан как прокси-сервер L7 и коммуникационная шина для сервис-ориентированной архитектуры.Этот проект родился со следующими целями:

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

Посол предоставляет следующие особенности:

Внешняя архитектура процессов: может работать с приложениями, разработанными на любом языке, быстро модернизируется.
На основе нового кодирования C++11: способно обеспечить эффективную производительность.
Фильтр L3/L4: Ядром является сетевой прокси-сервер L3/L4, который можно использовать в качестве программируемого фильтра для реализации различных задач TCP-прокси и подключения к основной службе. Поддержка различных задач путем написания фильтров, таких как необработанный прокси-сервер TCP, прокси-сервер HTTP, аутентификация сертификата клиента TLS и т. д.
Фильтр HTTP L7: поддерживает дополнительный уровень фильтрации HTTP L7. Фильтр HTTP действует как плагин, который подключается к подсистеме управления ссылками HTTP для выполнения различных задач, таких как буферизация, ограничение скорости, маршрутизация/переадресация, прослушивание DynamoDB Amazon и многое другое.
Поддержка HTTP/2: в режиме HTTP поддерживается HTTP/1.1, HTTP/2 и поддержка двунаправленного прокси-сервера HTTP/1.1, HTTP/2. Это означает, что HTTP/1.1 и HTTP/2 в любой комбинации клиента и целевого сервера могут быть соединены мостом.
Маршрутизация HTTP L7: при работе в режиме HTTP поддерживается маршрутизация и перенаправление на основе пути в соответствии с типом контента, значениями времени выполнения и т. д. Для сервиса доступны интерфейсные/пограничные прокси.
Поддержка gRPC: gRPC — это платформа RPC от Google, которая использует HTTP/2 в качестве базового мультиплексора. Как запросы gRPC, так и ответы, передаваемые по протоколу HTTP/2, могут использовать возможности маршрутизации и LB Envoy.
Поддержка MongoDB L7: Поддержка получения статистики и записей о соединениях и другой информации.
Поддержка DynamoDB L7: поддержка получения статистики и информации о подключении.
Обнаружение служб: поддерживает несколько методов обнаружения служб, включая асинхронное разрешение DNS и обнаружение служб с помощью запросов REST.
Проверка работоспособности: содержит подсистему проверки работоспособности, которая может активно проверять вышестоящий сервисный кластер. Также поддерживаются пассивные проверки работоспособности.
Расширенный LB: включая автоматические повторные попытки, автоматические выключатели, глобальное регулирование, блокировку запросов, обнаружение аномалий. Поддержка контроля скорости запросов также планируется в будущем.
Внешний прокси: в качестве внешнего прокси, включая маршрут TLS, HTTP/1.1, HTTP/2 и HTTP L7.
Отличная наблюдаемость: все подсистемы обеспечивают надежные статистические возможности. В настоящее время поддерживаются Statsd и совместимые статистические библиотеки. Вы также можете просмотреть статистику, управляющими портами и поддерживающую сторонние распределенные механизмы отслеживания.
Динамическая конфигурация: Предоставляет многоуровневый API динамической конфигурации, который пользователи могут использовать для создания сложных развертываний централизованного управления.

Istio

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

В настоящее время Istio поддерживает развертывание сервисов только в Kubernetes, но другие среды будут поддерживаться в будущих выпусках.

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

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

Сервисная сетка Istio логически разделена на плоскость данных и плоскость управления:

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

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

Conduit

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

Сервисная сетка Conduit также состоит из плоскости данных и плоскости управления. Плоскость данных несет фактический сетевой трафик приложения. Панель управления управляет панелью данных и обеспечивает северные интерфейсы.

В сравнении

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

Istio, с другой стороны, стоит под более высоким углом и делит Service Mesh на Data Plane и Control. Самолет. Плоскость данных отвечает за всю сетевую связь между микросервисами, а плоскость управления отвечает за управление прокси-сервером плоскости данных:

И Istio, естественно, поддерживает Kubernetes, который также связывает структуру планирования приложений и Service. Зазор между сетками.

Меньше информации о Conduit, и посмотрите на него из официального описания, расположение и функции аналогичны Istio.

Kubernetes + Service Mesh = Полная платформа микросервисов

Kubernetes стал стандартом де-факто для планирования и оркестрации контейнеров, а контейнеры можно использовать как наименьшую единицу работы для микрослужб, таким образом используя все преимущества архитектуры микрослужб. Поэтому я думаю, что будущая микросервисная архитектура будет вращаться вокруг Kubernetes. Service Meshes, такие как Istio и Conduit, по своей природе предназначены для Kubernetes, и их внешний вид дополняет недостатки Kubernetes в сервисном взаимодействии между микросервисами. Хотя Dubbo, Spring Cloud и т. д. являются зрелыми микросервисными фреймворками, они более или менее привязаны к конкретным языкам или сценариям приложений и решают проблемы микросервисов только на уровне Dev. Для решения проблем Ops им также необходимо работать с такими компаниями, как Cloud. Комбинация сред планирования ресурсов, таких как Foundry, Mesos, Docker Swarm или Kubernetes:

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

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

Поэтому я думаю, что будущая микросервисная архитектура и технологический стек могут иметь форму:

Коммудиологические возможности ресурсов платформы Micro Service (вычисление, хранение и сеть и т. Д.), Поскольку контейнер - наименьшая единица работы запланированных и планирования Kubernetes, -Service Mesh Micro Communication Service Management Management и Services, и, наконец, открытый сервисный интерфейс API Gateway Service через Micro наружу.

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

использованная литература

Introduction to Microservices
Pattern: Microservice Architecture
Spring Cloud for Microservices Compared to Kubernetes
Istio
Envoy
Linkerd
Кое-что о микросервисах
Документация Istio на китайском языке
Документация Linkerd на китайском языке

Оригинальная ссылка:Предварительное изучение микросервисной архитектуры(Автор: Сюй Бэй)