В предыдущем посте мы рассказали , как облачные сервисы стали негласным стандартом предоставления ИТ-услуг.
Легко представить, что компании, которые хотят продолжать зарабатывать на пользовательских приложениях, должны адаптироваться и создавать новые продукты с учетом подхода Cloud-Native. Однако это определенно положительная новость для разработчиков, поскольку использование облачных технологий открывает для них огромные новые возможности.
Главное уметь ими правильно управлять.
Когда приложение заказывает среду
Если вы уже прочитали гид Что касается облачных технологий, вы наверняка помните, что одним из «источников волшебства» облаков являются технологии виртуализации.Благодаря этому разработчику практически не нужно думать о параметрах серверов, на которых будет работать его приложение.
Зачем тратить на это время, если правильно настроенный гипервизор или контейнер может настроить машину практически с любыми характеристиками, необходимыми для запуска приложения? Развитием этой идеи является подход «Инфраструктура как код» (IAC).
Его суть заключается в том, чтобы дать возможность разработчикам или эксплуатационным службам использовать те же подходы к обслуживанию инфраструктуры, которые используются на этапе разработки.
Это позволяет заранее подготовить общие программные блоки управления и легко интегрировать такие компоненты в новые проекты.
Возможности современных дата-центров уже позволяют перейти на декларативный язык управления инфраструктурой.
В идеале приложение должно само управлять пулом ресурсов, которые оно занимает в центре обработки данных.
Это позволит разработчику не быть привязанным к ограничениям инфраструктурного процесса при предварительном заказе и проектировании или при повторении одних и тех же компонентов инфраструктуры в разных проектах.
Фактически разработчик или инженер делает запрос на включение, который содержит конфигурацию виртуальной машины (ядро, память, сеть, шаблон и т. д.), затем менеджер виртуальной среды самостоятельно создает машину или создает новый экземпляр базы данных или запускает предустановленная служба в соответствии с настройками в файле.
Такой подход — настоящее спасение при работе с большими данными и нейронными сетями.
Приложения, связанные с этими технологиями, в некоторых случаях требуют динамически изменяющихся объемов памяти и вычислительной мощности.
Например, чтобы обучить сеть, необходимо «пропустить» через нее сотни гигабайт информации, а облака позволяют получать необходимую для этого мощность по требованию.
После завершения обучения ресурсы возвращаются в пул провайдеров, и разработчику не приходится думать о том, что с ними делать или как по-другому настроить приложение, чтобы оно продолжало работать с меньшим энергопотреблением.
Монолит против упорядоченного хаоса
Благодаря тому, что облака могут эластично подстраиваться под нужды разработчика, это теоретически упрощает другую проблему — проблему масштабирования приложений.Почему теоретически? К сожалению, проблема масштабирования приложений не является линейной.
Чтобы приложение могло справляться с огромными нагрузками в периоды пиковой нагрузки (или вычислений), недостаточно просто предоставить ему дополнительную память и вычислительную мощность.
Абсолютно каждое традиционное приложение имеет порог, после которого оно уже не способно «переваривать» новые ресурсы и демонстрировать прирост производительности.
Проблема в данном случае не в ресурсах, а в самой архитектуре большинства программ.
Особенно остро эта проблема стоит для приложений с монолитной архитектурой, которые, по сути, представляют собой отдельные бинарные файлы.
Преимущества такого подхода очевидны: монолитные приложения достаточно просты и линейны.
Все сценарии поведения пользователей можно предсказать, отследить и при необходимости отладить ошибку.
Однако за такую простоту приходится платить.
Во-первых, существуют уже упомянутые выше проблемы масштабирования.
В какой-то момент даже самое продуманное монолитное приложение перестает работать эффективнее из-за обновления конфигурации сервера, на котором оно работает. 
Во-вторых, монолитное приложение не так-то просто перенести на новые сервера и для этого может потребоваться полная перекомпиляция программы.
В-третьих, такое приложение сложно поддерживать и развивать.
Любое обновление требует полной пересборки всей программы, а ошибка в одном из блоков кода может привести к падению всей системы.
В поисках идей, как решить эти проблемы, была разработана еще одна концепция — сервис-ориентированная архитектура (SOA).
Это подразумевает, что приложение разделено на несколько модулей, каждый из которых предоставляет некоторую функциональность другим.
Модули взаимодействуют друг с другом через набор веб-сервисов и независимо друг от друга могут обращаться к одной базе данных или к собственным базам данных.
Такой подход действительно упрощает поддержку программы и не превращает ее обновление «в работу сапера», в которой нет права на ошибку; но у него есть и свои недостатки.
Ключевой из них — проблемы с масштабированием разработки таких приложений.
По мере роста программы новые функции становится все сложнее «втиснуть» в 5–10 пакетов, первоначально одобренных архитектором.
Их число растет, из-за чего возникают проблемы с поддержкой.
Микросервис как элемент эволюции приложения
Результатом эволюции SOA стала идея микросервисной архитектуры, которая используется при построении облачных приложений.Концептуально идеи обоих подходов чрезвычайно схожи, а некоторые архитекторы даже не выделяют микросервисную архитектуру в отдельную парадигму, считая ее частным случаем SOA. Микросервисная архитектура подразумевает, что приложение состоит не из небольшого количества крупных модулей, а из множества независимых друг от друга частей.
В отличие от монолита, микросервисное приложение может использовать разные способы взаимодействия компонентов друг с другом.
Система не имеет единого, заранее заданного состояния.
Вместо этого каждый компонент работает «ситуативно»: как только получено событие, он начинает работать.
Это обеспечивает очень гибкую и независимую архитектуру.
При этом количество сервисов в микросервисном приложении постоянно меняется — какие-то добавляются, какие-то удаляются.
В новом подходе вы можете заменить любой микросервис и построить вместо него цепочку микросервисов.
Остальные сервисы продолжают работать стабильно, поскольку напрямую друг с другом не связаны.
Это естественная эволюция программы.
Это дает разработчикам и архитекторам возможность быстро меняться, реагировать на меняющиеся требования бизнеса и оставаться впереди конкурентов.
Помимо увеличения скорости выпуска обновлений, использование микросервисной архитектуры позволяет децентрализовать управление.
Команда, отвечающая за разработку того или иного сервиса, имеет право определять его внутреннюю архитектуру и особенности.
Кстати, такой подход сейчас реализуется в Блоке «Технологии» Архитектурным советом Сбербанка.
В то же время, когда вы садитесь за разработку своего облачного приложения, не стоит спешить быстро разбивать его на составные элементы.
Главным противником этого бездумного подхода является Мартин Фаулер; он также является одним из авторов идеи микросервисной архитектуры.
Проще изначально использовать монолитный подход, а затем стимулировать развитие приложения «естественным путем», сосредоточившись на устранении узких мест и добавлении дополнительных функций.
В результате можно сформулировать следующее правило: задача программиста при работе с микросервисной архитектурой — не просто разбить приложение на максимальное количество составных частей, а грамотно разграничить их обязанности по получению и обработке данных.
Четыре части
Помимо множества очевидных преимуществ, микросервисная архитектура имеет свои особенности, которые необходимо учитывать при разработке своего облачного приложения.В частности, для поддержки работы такого приложения необходимо постоянно поддерживать повышенные требования к качеству управления внутренними API. Когда один из компонентов меняет свой интерфейс, он должен сохранять обратную совместимость для поддержки предыдущей версии собственного API. Если следовать этому правилу, вы сможете динамически переключаться со старой версии на новую без перерыва.
Если не будет развита поддержка предыдущей версии API, то это грозит в лучшем случае потерей части функциональности приложения, а в худшем — постоянными сбоями в его работе.
Вторая важная особенность микросервисных приложений — сложность поиска в них ошибок.
Если приложение, написанное на монолитной логике или SOA, дает сбой, найти источник проблемы не составит труда.
В приложении, состоящем из множества сервисов, поиск причины ошибки может занять длительное время из-за того, что данные от пользователя часто обрабатываются через несколько микросервисов, и сложно определить, какой из них дает сбой.
При этом процесс поиска ошибки необходимо проводить очень внимательно: любой неудачный рефакторинг может привести к поломке работающего модуля, и помимо первоначальной проблемы разработчик получит вторую.
Третья важная деталь, которую необходимо учитывать при разработке облачного приложения, — это способ взаимодействия его компонентов между собой.
Как и в SOA, сервисы используют веб-сервисы для обмена данными, но в микросервисной архитектуре появились шаблоны взаимодействия, например, потоковая передача, CQRS, Источник событий.
Обычно разработчики ожидают, что время ответа между запросом и ответом в приложении будет довольно быстрым.
В распределенной системе нельзя даже рассчитывать на то, что ответ вообще придет. Также в архитектуре облачных приложений микросервисы используют различные базы данных, наиболее оптимально подходящие для решения их конкретных задач.
Например, сетки могут быстро считываться, но с трудом справляются с большим количеством операций по изменению данных.
Эта база данных хорошо подходит для ведения депозитных счетов – они редко меняются.
Другой тип операции — обработка; в нем могут быть десятки изменений каждый день по каждой карте, а считываний данных наоборот мало.
Наконец, четвертый факт, который необходимо помнить при разработке облачного приложения, заключается в том, что микросервисная архитектура ориентирована в первую очередь на использование сервисов без сохранения состояния.
Однако не стоит впадать в крайности.
Некоторые службы по-прежнему могут поддерживать состояние при необходимости, если этого требует бизнес-логика, и их необходимо разрабатывать с особой тщательностью.
Например: если пользователь делает заявку на кредит, система, принимающая заявку, должна сохранить это состояние, чтобы передать его другим сервисам.
Но служба, отвечающая за поиск информации во внутренней картотеке кредитных историй, может не сохранить состояние и забыть о данных, по имени пользователя которых она искала пару минут назад – все равно через мгновение она получит новую запрос (хотя в этом процессе может быть разное поведение сервиса).
Все описанные выше примеры и практики уже активно используются лидерами мировой ИТ-индустрии.
Например, Netflix — пионер в разработке микросервисной архитектуры.
Компания выпустила множество приложений, библиотек и инфраструктур с открытым исходным кодом для мониторинга, балансировки и регистрации запуска микросервисных приложений.
Теги: #Популярная наука #облачные сервисы #Облачные вычисления #облачные технологии #cloudnative
-
Rss Более Эффективен, Чем Электронная Почта
19 Oct, 24 -
Плюсы И Минусы Разработки С Помощью Xamarin
19 Oct, 24 -
C++ Ide От Jetbrains: Когда?
19 Oct, 24 -
Рисование Графиков. Питон. Ткинтер
19 Oct, 24 -
Интеграция C++ С Qml
19 Oct, 24
