Несмотря на ажиотаж вокруг микросервисов, высока вероятность, что вы их не приняли. Мы знаем преимущества. Но препятствия для начала работы слишком высоки.
Дело в том, что создавать масштабные приложения сложно. Вы должны выбрать правильную базу данных, правильные фреймворки и, во многих случаях, правильный язык программирования.
На этом все не заканчивается. Нам тоже нужно сосредоточиться на поставщиках облачных услуг, верно? Выберите правильную стратегию развертывания. Это тяжелая работа.
Дизайн Монолита (Одинокий воин)
Традиционно проектируем монолиты. Здесь у нас одна огромная кодовая база. Все построено на одном языке и на одной платформе.
Плюсы
Это упрощает создание приложения. Все просто на расстоянии вызова функции. Фреймворк выполняет тяжелую работу по созданию API. Мы привыкли к доступным ORM. Развитие находится под нашим контролем.
Все круто, пока не надо масштабировать.
Минусы
Масштабировать монолит сложно. За простоту разработки мы платим гибкость. Размещение обновлений и новых функций в монолитном дизайне - вот где все ломается. Небольшая ошибка может вывести из строя все приложение.
Микросервисы (Хаотичная команда)
Войдите в микросервисы.
Микросервисы решают проблему гибкости при масштабировании, разбивая большой жирный монолит на более мелкие модульные аналоги. По сути, каждая функция или функциональность вашего приложения теперь работает как совершенно другой микросервис. Каждый микросервис - это отдельный сервер, работающий в отдельном процессе.
Плюсы
Наиболее очевидным преимуществом микросервисов является то, что цикл развертывания каждого микросервиса теперь независим.
Это означает, что вы можете настроить отдельную платформу доставки для каждого микросервиса, настроенного в соответствии с его потребностями.
Еще одно преимущество заключается в том, что вам больше не нужно придерживаться одного языка или структуры. Это открывает двери для создания микросервисов на языке, который лучше всего подходит для работы. Вы можете использовать python для науки о данных и что-то вроде golang или elixir для рабочих нагрузок, связанных с io.
Минусы
Как убедиться, что все микросервисы гармонично работают вместе? Могут ли они даже найти друг друга? А как насчет нарушения изменений API?
Думать в терминах микросервисов сложно. Решить, как разделить приложение, тоже непростая задача. Требуется некоторый опыт, чтобы понять это правильно. И если вы думаете, что овладели этим искусством, попробуйте отладить свои микросервисы. Это кошмар.
Возможности работы.
Отчасти проблему отладки можно решить с помощью мощной системы мониторинга. Здесь вам может помочь что-то вроде Istio.io или Linkerd. Они также позволяют настроить плоскость управления для реализации жесткого контроля доступа в среде с нулевым доверием.
Эти сервисные сетки дают вам отличный контроль и наблюдаемость для микросервисов. Теперь вы можете выбрать именно те ссылки, которые не работают. Другие полезные показатели, такие как задержка и количество запросов, также отслеживаются.
Но для работы этих сервисных сеток нужен какой-то инструмент развертывания, такой как кубернетес.
Итак, со сколькими вещами нам нужно работать сейчас? Чуть меньше миллиона.
Подождите! Я немного заблудился
Я тоже. Давайте вернемся к тому, с чего мы начали, гибкости в масштабе.
Все, что мы хотели, - это разбить наш монолит на более мелкие части. Вот и все. Кажется, что микросервисы воплощают эту мечту в реальность.
Что, если бы у нас был способ получить гибкость микросервисов без необходимости справляться с хаосом, который с этим связан? Можем ли мы упростить жизнь?
Чтобы упростить понимание, я перечислю необходимые нам функции.
- Более простой способ сломать монолит. Может быть, начать с одного и при необходимости разбить его.
- Все должно быть просто вызовом функции. Никто не хочет тратить время на создание правильных сетей.
- Возможность развернуть каждую деталь независимо. Возможно, они будут на разных языках, связанные вместе с помощью единого API.
Сетка функций (организованный хаос)
Что, если бы мы могли разбить каждую операцию в наших сервисах на функции? Нет, я не говорю о функции как услуге (например, AWS Lambda). Мы по-прежнему говорим о микросервисах.
Независимо от того, какой язык или фреймворк вы используете, каждая конечная точка обрабатывается функцией, верно? Так почему бы не раскрыть эти функции напрямую как функции !?
Что все это значит?
Вам не нужно инициировать HTTP-запросы для использования API, представленных в ваших микросервисах. Все, что вам нужно сделать, это вызвать функцию микросервиса прямо из вашего кода. Все сетевые функции, такие как балансировка нагрузки и обнаружение сервисов, полностью позаботятся.
Поскольку вы раскрываете функциональность через раскрытие функций, вы можете начать с монолита и в конечном итоге легко сломать вещи. Это так же просто, как перемещение функций из одного каталога в другой.
Звучит невероятно, правда?
Это то, что мы называем сеткой функций. Все ваши функции, локальные или удаленные, теперь просто вызов функции.
Космическое облако
Мы запекли сетку функций в ядро Космического Облака. Вы можете регистрировать и вызывать функции и службы, используя библиотеку Space Api, доступную на python, java, javascript и golang.
Поскольку Space Cloud не зависит от производителя, вы можете настроить сетку функций в любой среде. Вы можете запустить его в Kubernetes, на виртуальной машине или даже на голом железе.
Space Cloud также предлагает сверхмощный модуль безопасности для точной настройки контроля доступа к этим функциям.
Поскольку все сетевые функции управляются Space Cloud, вы даже можете заставить ваш интерфейс вызывать эти функции так же, как и ваши серверные службы. Добавьте к этому уровень доступа к данным в реальном времени, и вы получите унифицированный API для обработки большинства возможных вариантов использования.
Если вы думали, что это все, подумайте еще раз. Space Cloud полностью открыт! Вы можете сразу же приступить к созданию своей собственной сетки функций!
Заключение
Микросервисы никуда не денутся в ближайшее время. Есть много случаев использования, когда установка FaaS просто не может решить ту же проблему, что и микросервисы.
Это оставило огромные возможности для улучшения. Специально вокруг того, как общаются микросервисы. Мы считаем, что опыт построения архитектуры на основе микросервисов не должен отличаться от традиционного.
Сетка функций, похоже, решает многие операционные проблемы, связанные с микросервисами. Он сочетает в себе простоту FaaS с гибкостью и контролем среды микросервиса.
Попробуйте Space Cloud. Я хотел бы знать, как вы используете функциональную сетку.
Если вам нравится то, что мы делаем, отметьте нас на GitHub. Мы также будем рады принять вас на борт! Вы можете начать с сообщения об ошибке или предложения улучшений. Также вы можете присоединиться к нашему серверу раздора, чтобы связаться с нами напрямую. Добро пожаловать в новый способ написания микросервисов!
Первоначально опубликовано на https://spaceuptech.com.
