В этой статье мы представляем исчерпывающую статью о микросервисах для разработчиков Java: развертывание и оркестровка.
1. Введение
В наши дни все больше организаций полагаются на облачные вычисления и предложения управляемых услуг для размещения своих услуг. Эта стратегия имеет много преимуществ, но вам все равно придется выбирать лучший план развертывания игр для вашего парка микросервисов .
Использование некоторого вида PaaS , вероятно, является самым простым вариантом, но для многих он не является устойчивым в долгосрочной перспективе из-за унаследованных ограничений и ограничений, которые имеет такая модель. С другой стороны, использование IaaS облегчает затраты на управление и обслуживание инфраструктуры, но все же требует значительного объема работ по развертыванию приложений и сервисов и поддержанию их на плаву. И последнее, но не менее важное: многие организации по-прежнему предпочитают управлять своими программными стеками внутри компании, передавая только управление виртуальными (или «голыми») машинами поставщикам облачных услуг .
Задача решить, какая модель подходит для большинства организаций, оставалась нерешенной (в целом) достаточно долгое время, ожидая какого-то прорыва. И, к счастью, «большой взрыв» пришел в свое время.
Содержание
2. Контейнеры
Хотя семена были посеяны задолго до этого, революция была инициирована Docker и кардинально изменила наши подходы к распределению, развертыванию и разработке приложений и сервисов. Преобразователь игры появился в виде виртуализации на уровне операционной системы и контейнеров . Это исключительно легкая (по сравнению с традиционными виртуальными машинами ) архитектура, не накладывающая практически никаких накладных расходов, использующая одно и то же ядро операционной системы и не требующая специальной аппаратной поддержки для эффективной работы.
В настоящее время образы контейнеров стали фактическим планом упаковки и распространения, тогда как контейнеры служат основной моделью исполнения и изоляции. Можно много сказать о виртуализации на основе Docker и контейнеров , особенно в отношении приложений и сервисов на платформе JVM , но в этой части руководства мы сосредоточимся на аспектах развертывания и эксплуатации.
Инструментарий вокруг контейнеров доступен в основном для любого языка программирования и / или платформы, и в большинстве случаев его можно легко интегрировать в конвейеры сборки и развертывания. Например, что касается платформы JCG Car Rentals , служба поддержки клиентов создает образ контейнера, используя jib (точнее, jib-maven-plugin ), который собирает и публикует образ, не требуя демона Docker .
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
|
<plugin> <groupId>com.google.cloud.tools</groupId> <artifactId>jib-maven-plugin</artifactId> <version>1.3.0</version> <configuration> <to> <image>jcg-car-rentals/customer-service</image> <tags> <tag>${project.version}</tag> </tags> </to> <from> <image>openjdk:8</image> </from> <container> <user>1000</user> <mainClass>ws.ament.hammock.Bootstrap</mainClass> </container> </configuration></plugin> |
Так что же мы можем сделать с контейнером сейчас? Переход к основанным на контейнерах средам выполнения пород породил новую категорию компонентов инфраструктуры — оркестровку и управление контейнерами.
3. Apache Mesos
Мы начнем с Apache Mesos , одной из старейших и устоявшихся платформ с открытым исходным кодом для детального распределения ресурсов.
Apache Mesos абстрагирует ресурсы ЦП, памяти, хранилища и других вычислительных ресурсов от машин (физических или виртуальных), что позволяет легко создавать и эффективно эксплуатировать отказоустойчивые и гибкие распределенные системы. — http://mesos.apache.org/
Строго говоря, Apache Mesos не является оркестратором контейнеров, более похожим на платформу управления кластерами, но он также получил встроенную поддержку запуска контейнеров не так давно. Существуют определенные совпадения с традиционными структурами управления кластерами (такими как, например, Apache Helix ), поэтому Apache Mesos часто называют операционной системой для центров обработки данных, чтобы подчеркнуть ее большую площадь и объем.
4. Тит
Titus , еще один проект с открытым исходным кодом от Netflix , является примером специального решения для управления контейнерами.
Titus — это платформа управления контейнерами, которая обеспечивает масштабируемое и надежное выполнение контейнеров и облачную интеграцию с Amazon AWS. Titus был построен внутри Netflix и используется в производстве для поддержки потоковых, рекомендательных и контентных систем Netflix. — https://netflix.github.io/titus/
По сути, Titus — это фреймворк поверх Apache Mesos . Плавная интеграция с AWS, а также Spinnaker , Eureka и Archaius, в конце концов, делает его вполне подходящим.
5. Кочевник
Nomad , еще один продукт с открытым исходным кодом от HashiCorp , представляет собой оркестратор рабочей нагрузки, который подходит для развертывания различных микросервисов , пакетных заданий, контейнерных и неконтейнерных приложений.
Nomad — это высокодоступный распределенный планировщик кластеров и приложений с поддержкой центров обработки данных, разработанный для поддержки современного центра обработки данных с поддержкой долгосрочных служб, пакетных заданий и многого другого. — https://www.nomadproject.io/
Помимо того, что он действительно очень прост в использовании, он имеет выдающуюся встроенную интеграцию с Consul и Vault, чтобы дополнить обнаружение служб и секретное управление (которое мы представили в предыдущих частях руководства).
6. Докер Рой
Если вы опытный пользователь Docker , вы можете знать о swarm , особом режиме работы Docker для естественного управления кластером Docker Engines . Вероятно, это самый простой способ организовать контейнерные развертывания, но в то же время не получил широкого распространения.
7. Кубернетес
Настоящий драгоценный камень мы оставили до самого конца. Kubernetes , основанный на 15-летнем опыте управления производственными нагрузками в Google , является гиперпопулярным и производительным контейнерным оркестратором с открытым исходным кодом.
Kubernetes (K8s) — это система с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнерными приложениями. — https://kubernetes.io/
Несомненно, в настоящее время Kubernetes является доминирующей платформой управления контейнерами. Его можно запустить буквально в любой инфраструктуре, и, как мы скоро увидим, его предлагают все основные поставщики облачных услуг .
Платформа JCG Car Rentals собирается использовать возможности Kubernetes для работы всех своих микросервисов и вспомогательных компонентов (таких как шлюзы API и BFF ). Хотя мы могли бы начать создавать манифесты YAML сразу, есть еще одна вещь, о которой стоит поговорить.
Kubernetes — это платформа для строительных платформ. Это лучшее место для начала; не финал. — https://twitter.com/kelseyhightower/status/935252923721793536?lang=en
Это довольно интересное утверждение, которое уже воплощается в жизнь в наши дни такими платформами, как OpenShift и рядом коммерческих предложений.
8. Сервисные сетки
Платформы оркестровки контейнеров значительно упростили и улучшили методы развертывания и эксплуатации, особенно связанные с микросервисами . Тем не менее, существует ряд общих проблем, о которых должны позаботиться разработчики сервисов и приложений, таких как безопасная связь, отказоустойчивость, аутентификация и авторизация, отслеживание и мониторинг. Шлюзы API сняли часть этого бремени, но связь между сервисами все еще была затруднена. Поиски жизнеспособного решения привели к появлению сервисных сеток.
Сетка обслуживания — это инфраструктурный уровень, который управляет связью между сервисами, освобождая приложения от осознания сложной сети связи. Сетка предоставляет расширенные возможности, включая шифрование, аутентификацию и авторизацию, маршрутизацию, мониторинг и трассировку. — https://medium.com/solo-io/https-medium-com-solo-io-supergloo-ff2aae1fb96f
Честно говоря, сервисные сетки пришли как спасатели. Развернутые вдоль контейнерного оркестра по своему выбору, они позволили организациям сосредоточиться на реализации бизнес-задач и функций, тогда как сетка заботилась об остальном.
Сетка сервиса — это будущее облачных приложений — https://medium.com/solo-io/https-medium-com-solo-io-supergloo-ff2aae1fb96f
В дикой природе есть множество сервисных сеток, достаточно зрелых и проверенных в бою. Давайте кратко рассмотрим некоторые из них.
8.1. Linkerd
Мы начнем с Linkerd , одного из пионеров сервисных сеток с открытым исходным кодом. Он превратился в выделенный уровень для управления, контроля и мониторинга меж сервисной связи. С тех пор он был переписан и переориентирован на интеграцию в Kubernetes .
Linkerd — сверхлегкий сервисный меш для Kubernetes . Это дает вам наблюдаемость, надежность и безопасность без каких-либо изменений кода. — https://linkerd.io/
Значение «сверхлегкий» может показаться не значительным, но на самом деле это так. Вы можете быть удивлены тем, сколько ресурсов кластера может потреблять сетка службы, и, в зависимости от вашей модели развертывания, может потребовать существенных дополнительных затрат.
8.2. Istio
Если есть сервисная сетка, о которой все слышали, то, скорее всего, Istio .
Это сервисная сетка с полностью открытым исходным кодом, которая прозрачно размещается на существующих распределенных приложениях. Это также платформа, в том числе API-интерфейсы, позволяющие интегрироваться в любую платформу журналирования, телеметрию или систему политик. Разнообразный набор функций Istio позволяет успешно и эффективно запускать архитектуру распределенного микросервиса и предоставляет единый способ защиты, подключения и мониторинга микросервиса — https://istio.io/docs/concepts/what-is-istio /
Хотя Istio используется в основном с Kubernetes , он фактически независим от платформы. Например, на данный момент его можно запускать вместе с развертываниями на основе Consul (с Nomad или без него).
Экосистема вокруг Истио действительно процветает. Одним из заметных вкладов сообщества является Kiali , который визуализирует топологию сервисной сетки и обеспечивает обзор таких функций, как маршрутизация запросов, прерыватели цепи, частота запросов, задержка и многое другое.
Необходимость сервисной сетки для платформы JCG Car Rentals очевидна, и мы собираемся развернуть Istio, чтобы восполнить этот пробел. Вот упрощенный пример манифеста развертывания Kubernetes для службы поддержки клиентов с использованием Is t io и ранее созданного образа контейнера .
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
apiVersion: v1kind: Servicemetadata: name: customer-service labels: app: customer-servicespec: ports: - port: 18800 name: http selector: app: customer-service---apiVersion: apps/v1kind: Deploymentmetadata: name: customer-servicespec: replicas: 1 selector: matchLabels: app: customer-service template: metadata: labels: app: customer-service spec: containers: - name: customer-service image: jcg-car-rentals/customer-service:0.0.1-SNAPSHOT resources: requests: cpu: "200m" imagePullPolicy: IfNotPresent ports: - containerPort: 18800 volumeMounts: - name: config-volume mountPath: /app/resources/META-INF/microprofile-config.properties subPath: microprofile-config.properties volumes: - name: config-volume configMap: name: customer-service-config---apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata: name: customer-service-gatewayspec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"---apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: customer-servicespec: hosts: - "*" gateways: - customer-service-gateway http: - match: - uri: prefix: /api/customers route: - destination: host: customer-service port: number: 18800 |
8.3. Консул Коннект
Как мы знаем из предыдущей части учебного пособия, Консул начинал как обнаружение служб и хранилище конфигурации. Одним из недавних дополнений к Консулу является функция подключения, которая позволила ему войти в пространство служебных сеток.
Consul Connect обеспечивает авторизацию и шифрование соединений между сервисами с использованием взаимной безопасности транспортного уровня (TLS). Приложения могут использовать прокси-серверы боковой панели в конфигурации сервисной сетки для автоматического установления соединений TLS для входящих и исходящих соединений, даже не зная о Connect. — https://www.consul.io/docs/connect/index.html
Консул уже имел отличную основу для каждой сетки услуг, добавление отсутствующих функций было логичным шагом к адаптации к этому быстро меняющемуся ландшафту.
8.4. SuperGloo
Имея довольно много сервисных сеток, становится неясно, какой из них лучше всего подходит для ваших микросервисов , и как его развернуть и использовать? Если это проблема, с которой вы сталкиваетесь прямо сейчас, вы можете взглянуть на SuperGloo , платформу оркестровки сервисной сетки.
SuperGloo , проект с открытым исходным кодом для управления и организации сервисных сеток в масштабе. SuperGloo — это продуманный уровень абстракции, который упростит установку, управление и эксплуатацию вашей сервисной сетки, независимо от того, используете ли вы (или планируете использовать) технологию с одной сеткой или несколько сетей, на месте, в облаке или в любой топологии. это лучше всего подходит вам. — https://supergloo.solo.io/
С точки зрения сетки услуг SuperGloo в настоящее время поддерживает ( в некоторой степени ) Istio , Consul Connect , Linkerd и AWS App Mesh .
По той же теме недавно была объявлена более широкая спецификация интерфейса Service Mesh Interface ( SMI ), что является инициативой по согласованию различных реализаций сетки услуг, чтобы их можно было использовать взаимозаменяемо. ,
9. Облако
Отраслевой переход к развертыванию на основе контейнеров заставил облачных провайдеров предложить соответствующие предложения. На сегодняшний день каждый крупный игрок в облачном бизнесе управляет предложением Kubernetes вместе с сеткой услуг.
9.1. Google Kubernetes Engine (GKE)
Поскольку Kubernetes вышел из Google и из своего опыта управления крупнейшими в мире вычислительными кластерами, вполне естественно, что Google Cloud имеет отличную поддержку для него. И это действительно так, Google Kubernetes Engine ( GKE ) — это полностью управляемая платформа Kubernetes, размещенная в Google Cloud .
Kubernetes Engine — это управляемая, готовая к работе среда для развертывания контейнерных приложений. Он привносит наши последние инновации в производительность труда разработчиков, эффективность использования ресурсов, автоматизацию операций и гибкость открытого исходного кода, чтобы ускорить ваше время выхода на рынок. — https://cloud.google.com/kubernetes-engine/
Что касается сервисной сетки, Google Cloud обеспечивает поддержку Istio через Istio для надстройки GKE для Kubernetes Engine (в настоящее время в бета-версии ).
9.2. Амазон Эластик Кубернетес Сервис (EKS)
В течение долгого времени AWS предлагает поддержку для запуска контейнерных приложений в форме Amazon Elastic Container Service ( ECS ). Но с прошлого года AWS объявила о доступности сервиса Amazon Elastic Kubernetes ( EKS ).
Amazon EKS управляет инфраструктурой управления Kubernetes для вас в нескольких зонах доступности AWS, чтобы исключить единую точку отказа. — https://aws.amazon.com/eks/
Со стороны сервисной сетки вы находитесь в AWS App Mesh, которую можно использовать с сервисом Amazon Elastic Kubernetes . Под капотом работает сервисный прокси Envoy .
9.3. Azure Container Service (AKS)
Облако Microsoft Azure следовало аналогичному подходу AWS , предлагая сначала контейнерную службу Azure (которая, кстати, могла быть развернута с помощью Kubernetes или Docker Swarm ), а затем отказалась от нее в пользу службы Azure Kubernetes ( AKS ).
Полностью управляемая служба Azure Kubernetes ( AKS ) упрощает развертывание и управление контейнерными приложениями. Он предлагает Kubernetes без сервера, интегрированную непрерывную интеграцию и непрерывную доставку (CI / CD), а также безопасность и управление корпоративного уровня. — https://azure.microsoft.com/en-us/services/kubernetes-service/
Интересно отметить, что на момент написания этой статьи Microsoft Azure Cloud не связывал поддержку какой-либо сервисной сетки со своим предложением Azure Kubernetes Service, но можно установить компоненты Istio на AKS, следуя ручной процедуре.
9.4. фермер
Маловероятно, что ваш парк микросервисов будет развернут в одном кластере Kubernetes . По крайней мере, у вас могут быть постановочные и постановочные, и их лучше хранить отдельно. Если вы заботитесь о своих клиентах, вы, вероятно, задумаетесь о высокой доступности и аварийном восстановлении, которое, по сути, означает развертывание в нескольких регионах или в нескольких облаках. Управление многими кластерами Kubernetes в широком диапазоне сред может быть обременительным и сложным, если вы не знаете о Rancher .
Rancher — полный программный стек для команд, принимающих контейнеры. Он решает проблемы эксплуатации и безопасности при управлении несколькими кластерами Kubernetes в любой инфраструктуре, предоставляя командам DevOps интегрированные инструменты для выполнения контейнерных рабочих нагрузок. — https://rancher.com/what-is-rancher/overview/
В целом, Rancher становится единой платформой для управления кластерами Kubernetes , в том числе управляемыми облачными предложениями или даже простыми серверами.
10. Развертывание и оркестровка — Выводы
В этом разделе руководства мы поговорили о развертывании и оркестрации на основе контейнеров. Тем не менее, на столе есть несколько вариантов, и было бы справедливо сказать, что Kubernetes является де-факто выбором в настоящее время и по уважительным причинам. Хотя это и не является обязательным требованием, наличие сервисной сетки значительно облегчит некоторые проблемы, связанные с эксплуатацией микросервисов, и позволит вам сосредоточиться на том, что важно для бизнеса.
11. Что дальше
В следующем разделе руководства мы поговорим об управлении журналом, консолидации и агрегации.