1. Что такое облако
1.1 Организация CNCF
Прежде чем говорить о нативном облаке, давайте сначала разберемся с CNCF, а именно с Фондом облачных вычислений, который был создан Google в 2015 году. В настоящее время членами фонда являются более 100 предприятий и учреждений, включая Amazon и Microsoft. гиганты вроде Cisco.
В настоящее время CNCF размещает приложения 14. На следующем рисунке показан выпущенный им Cloud Native Landscape, который дает эталонную систему облачной экологии.
1.2 Облачная среда
CNCF дает три характеристики облачных приложений:
- Контейнерная упаковка: на основе контейнеров улучшите общий уровень разработки, сформируйте код и повторное использование компонентов и упростите обслуживание облачных приложений. Запускайте приложения и процессы в контейнерах и развертывайте их как независимые единицы приложения, обеспечивая высокий уровень изоляции ресурсов.
- Динамическое управление: динамическое управление и планирование с помощью централизованной системы оркестровки и планирования.
- Ориентация на микросервисы: проясните зависимости между сервисами и отделите их друг от друга.
Cloud Native включает в себя набор прикладных шаблонов, помогающих предприятиям быстро, непрерывно, надежно и в нужном масштабе предоставлять программное обеспечение для бизнеса. Нативное облако состоит из микросервисной архитектуры, DevOps и гибкой инфраструктуры, представленной контейнерами.
Вот краткое изложение возможностей и функций, необходимых для работы в облаке в Интернете, как показано на следующем рисунке.
1.3 The Twelve Factors
12-Factors часто буквально переводится как 12 факторов, также известных как 12 принципов. 12 принципов были предложены Heroku, пионером общедоступного облака PaaS, в 2012 году (https://12factor.net/), цель состоит в том, чтобы рассказать как использовать преимущества облачных платформ для разработчиков Обеспечивает удобство разработки облачных приложений, которые являются более надежными, масштабируемыми и простыми в обслуживании. детали следующим образом:
- эталонный код
- Явно объявить зависимости
- Хранить конфигурацию в среде
- Относитесь к серверным службам как к дополнительным ресурсам
- Строгое разделение сборки, выпуска и запуска
- процесс без гражданства
- Обслуживание через привязку к порту
- Масштабирование модели процесса
- Быстрый запуск и изящное завершение
- Среда разработки эквивалентна онлайн-среде
- Журнал как поток событий
- процесс управления
Есть три дополнительных момента:
- Управление претензиями API
- Аутентификация и авторизация
- Мониторинг и оповещение
Прошло более пяти лет с тех пор, как были предложены Принципы 12, и некоторые детали Принципов 12 могут не соответствовать времени.Некоторые люди критикуют Принципы 12 за их тенденцию слишком полагаться на собственные характеристики Героку из самое начало. Но несмотря ни на что, 12 принципов по-прежнему являются наиболее систематическим руководством в отрасли по разработке облачных приложений.
2. Контейнерная упаковка
В последние годы технология контейнеризации докеров стала очень популярной, и мы часто слышим о совместном использовании докеров по разным поводам. Docker позволяет разработчикам упаковывать свои приложения и зависимости в переносимый контейнер. Идея Docker заключается в создании портативных, легких контейнеров для программ, которые могут работать на любом компьютере с установленным Docker, независимо от базовой операционной системы.
Docker может решить проблемы, которые могут решить виртуальные машины, а также решить проблемы, которые виртуальные машины не могут решить из-за чрезмерных требований к ресурсам. К его преимуществам относятся:
- Изоляция зависимостей приложений
- Создайте образ приложения и скопируйте его
- Создавайте готовые приложения, которые легко распространять
- Позволяет легко и быстро масштабировать экземпляры
- Тестируйте приложения и уничтожайте их позже
Автоматизированные средства эксплуатации и обслуживания могут снизить сложность построения среды, но они все еще не могут коренным образом решить экологические проблемы. В кажущихся стабильными и зрелыми сценариях преимущества использования Docker возрастают.
3. Сервисная оркестровка
Автор видитJimmy SongКраткий обзор использования оркестрации служб в облачных архитектурах:
Kubernetes — Внедрение контейнерных приложений в крупномасштабное промышленное производство.
Это резюме действительно уместно. Существуют также компоненты с открытым исходным кодом для оркестровки и планирования: Kubernetes, Mesos и Docker swarm.
Kubernetes в настоящее время является самым заинтересованным проектом с открытым исходным кодом в мире, и это отличная система оркестрации контейнеров. Kubernetes создан Google, гигантом интернет-индустрии. Он опирается на концепцию сотен инженеров, потративших более десяти лет на создание системы Borg. Он обеспечивает универсальное обслуживание благодаря чрезвычайно простой установке и гибким методам стыковки на сетевом уровне.
Mesos лучше подходит для создания надежной платформы для запуска многозадачных критически важных рабочих нагрузок, включая контейнеры Docker, устаревшие приложения (например, Java) и службы распределенных данных (например, Spark, Kafka, Cassandra, Elastic). Mesos использует двухуровневую архитектуру планирования, и разработчики могут легко настраивать MesosFramework в сочетании с бизнес-сценариями компании.
Они обеспечивают мощные возможности оркестрации и планирования для облачных приложений, которые представляют собой распределенные операционные системы на облачных платформах. Запуск контейнера на одном компьютере не может полностью реализовать его максимальную производительность. Только формирование кластера может максимально использовать преимущества хорошей изоляции, распределения ресурсов и управления оркестрацией контейнеров.Война между Swarm, Mesos и Kubernetes в основном закончился, и kubernetes — бесспорный победитель.
4. Микросервисная архитектура
Традиционный метод веб-разработки обычно называется монолитным, все функции упакованы в пакет WAR, практически без внешних зависимостей (кроме контейнеров), и развернуты в контейнере JEE (Tomcat, JBoss, WebLogic), включая всю логику DO /DAO, сервис, пользовательский интерфейс и т. д. Его архитектура показана на рисунке ниже.
После эволюции и модернизации монолитной архитектуры происходит переход к архитектуре SOA, то есть к сервис-ориентированной архитектуре. В последние годы микросервисная архитектура (Micro-Service Architecture) является наиболее популярным архитектурным стилем, целью которого является достижение развязки путем разложения функциональных модулей на независимые подсистемы проектирования. Микросервисная архитектура является наследием SOA и особого практического метода SOA. В микросервисной архитектуре каждый микросервисный модуль обрабатывает только простые, независимые и понятные задачи, а результаты обработки возвращает наружу через REST API. С точки зрения практики продвижения микросервисов, микросервисы разбивают всю систему на более мелкие детали, обеспечивают независимую работу этих сервисов и применяют технологию контейнеризации для независимого запуска микросервисов в контейнерах. В прошлом при проектировании архитектур гранулярность достигалась в виде параметров или объектов в памяти. Микросервисы используют идею отдельных модулей управления субсервисами вместо шин. В соответствии с различными бизнес-требованиями модуль управления службами включает, по крайней мере, функции публикации службы, регистрации, маршрутизации и прокси.
Появление контейнеризации в определенной степени повлияло на архитектуру микросервисов. Архитектура эволюционирует от монолитных приложений к распределенным архитектурам, а затем от распределенных архитектур к облачным архитектурам, в которых микросервисы играют незаменимую роль. Микросервисы дают нам большую гибкость и техническое разнообразие при разработке и развертывании, но также увеличивают накладные расходы на вызовы сервисов, распределенные системные транзакции, проблемы отладки и управления сервисами.
Из архитектуры компонентов Spring Cloud на приведенном выше рисунке мы можем видеть необходимые компоненты в архитектуре микросервиса, в том числе: обнаружение и регистрация сервисов, прерыватель цепи, маршрутизация, глобальная блокировка, центральное управление конфигурацией, шина управления, кампания по принятию решений. , распределенный сеанс и базовые компоненты, такие как управление состоянием кластера.
Spring Cloud и Kubernetes очень разные Spring Cloud и Kubernetes имеют дело с разным набором технических моментов архитектуры микросервисов и по-разному. Подход Spring Cloud пытается решить проблему архитектуры микросервисов в JVM, в то время как подход Kubernetes пытается устранить проблему и решить ее на уровне платформы для разработчиков. Spring Cloud очень мощен в JVM, а Kubernetes очень мощен в управлении этими JVM. Кажется, что каждый из них имеет свои сильные стороны, и естественной тенденцией является полное использование преимуществ обоих.
5. Резюме
Эволюция технической архитектуры идет очень быстро, и одно за другим появляются различные новые термины. Эта статья в основном представляет собой обзор облачных технологий. Три характеристики облачных приложений: контейнерная упаковка, динамическое управление и ориентация на микросервисы. Концепция облачных технологий впервые представлена CNCF, а затем подробно описаны три характеристики. Нативная облачная архитектура — это горячая тема для обсуждения на данный момент, это собрание различных идей и кульминация различных популярных технологий.
Напоследок поздравляю всех с Рождеством😆!