Как спроектировать микросервисную архитектуру на основе Golang

article - @дудулу- May/26/2018 18:35:30

Как спроектировать микросервисную архитектуру на основе Golang

Микросервисы (Microservices), мы часто слышим об этом в последние годы. Кроме того, на рынке есть много технологий микросервисной архитектуры, таких как более зрелые Spring Boot и Spring Cloud Family Bucket. Как реализовать микросервисную архитектуру в системе, отличной от Java?

После нескольких месяцев метаний поговорим о том, как Golang реализован в микросервисной архитектуре?

What are microservices?

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

микроВ узком смысле он имеет небольшие размеры.
СлужитьОтносительно небольшие и независимые функциональные единицы

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

Традиционное монолитное приложение

Давайте сначала посмотрим на традиционную монолитную архитектуру приложения:

Java-приложения упаковываются в файлы WAR и развертываются, например, на Tomcat. Их легко разрабатывать и развертывать, поскольку наша среда IDE и другие инструменты ориентированы на создание монолитных приложений. Этот простой подход имеет большие ограничения, давайте посмотрим на проблемы с этой монолитной архитектурой.

возрастающая сложность

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

проблема текучести кадров
Развертывание становится все медленнее

Чем больше кода, тем медленнее компиляция и тем медленнее развертывание.
препятствовать технологическим инновациям

Хочется что-то изменить, но бремя истории слишком тяжело
Невозможно масштабировать по запросу

Такие как интенсивные модули CPU, такие как модули памяти и другие большие

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

Для решения этой проблемы родилась новая концепция«Микросервисы»

Микросервисы — решение сложных задач

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

Монолитное приложение разделено на микросервисы

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

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

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

Разработка и поставка масштабируемой кубической

Архитектурный шаблон микросервисов эквивалентен координате Y этого куба масштабирования, а две другие оси — это координата X и координата Z балансировщиков нагрузки, запускающих несколько копий одного и того же приложения, где запрошенное свойство (например, row Первичный ключ записи или идентификатор клиента) используется для маршрутизации запросов на определенный сервер. Приложения обычно используют комбинацию этих трех типов координат. По оси Y приложение разбивается на микросервисы, а по оси X выполняется несколько экземпляров сервиса, каждый из которых имеет балансировщик нагрузки для обеспечения пропускной способности и доступности. Некоторые приложения также могут использовать ось Z для разделения сервисов.

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

Простота разработки и обслуживания
начать быстрее
Локальные модификации легко развернуть
Неограниченный стек технологий
Масштаб по запросу

Шаблон микросервисной архитектуры позволяет независимо развертывать и масштабировать каждый микросервис.

Архитектурные преимущества микросервисов

быстрый выпуск
Независимое расширение
быстрые пробы и ошибки
Быстрое применение новых технологий

быстрый выпуск

Простые функции, простое тестирование, отсутствие лишних зависимостей, простая настройка и простая публикация.

Быстрые пробы и ошибки - маленькие шаги

Быстрая разработка, быстрый запуск и быстрая настройка.

Недостатки микросервисов

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

Технология микросервисной архитектуры Golang

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

Поскольку это в основном Golang, мы должны максимально использовать техническую архитектуру golang.

Сначала нам нужно решить проблему!

Предполагая, что наше приложение является микросервисным, с какими проблемами мы столкнемся?

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

Как узнать об услугах
Как отслеживать сервисные ссылки
Как управлять конфигурациями
Как управлять API сервиса
Как развернуть (непрерывная доставка)

С этими проблемами мы ищем некоторые из этих решений с открытым исходным кодом.

Так как же использовать и комбинировать эти инструменты?

Давайте посмотрим, что это за инструменты? Какую роль он играет в архитектуре микросервисов?

Consul

Консул - это программное обеспечение для управления услугами. Его основные функции:

Service Discovery

Инструмент для обнаружения и настройки сервисов. Распределенная, высокодоступная и очень масштабируемая.
Failure Detection

Объединение обнаружения служб с проверками работоспособности предотвращает маршрутизацию запросов на неработоспособные хосты и позволяет службам легко предоставлять прерыватели цепи.
Multi Datacenter

Consul планирует работу с несколькими центрами обработки данных без сложной настройки. Найдите службы в других центрах обработки данных или оставляйте запросы на месте.
KV Storage

гибкийKey/ValueСохраняет динамическую конфигурацию, теги функций, координацию, выборы лидера и т. д. Изменения конфигурации и мгновенные уведомления.

Вы можете использовать Consul для достижения следующих функций

Распределенный ключ/значение, используемый как центр конфигурации.
Распределенный сеанс, используемый для решения проблемы сеанса.
Распределенные блокировки, ключ/значение которых также можно использовать для распределенных блокировок.
Ресурсный центр, динамически управляйте ресурсами, такими как Redis, DataSource, RabbitMQ

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

Что такое регистрация услуг?

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

Что такое обнаружение службы?

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

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

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

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

Например, Zookeeper, Doozer, Etcd, проекты сильной согласованности, эти проекты в основном используются для координации между сервисами, а также могут использоваться для регистрации сервисов.

Регистрация службы, обнаружение, центр конфигурации, шлюз?

Why an API Gateway?

Следующая картинка может быть хорошим объяснением того, что такое шлюз

В настоящее время на рынке также есть много шлюзов с открытым исходным кодом, по сравнению с Zuul системы Java.

Среди множества шлюзовых сервисов мы выбрали шлюз на основе реализации Nginx OpenResty --> Kong

Why did choose Kong

Kong — это готовое решение Api Gateway.

Конг имеет следующие ключевые особенности:

Многочисленные плагины
На основе OpenResty
Визуальная конфигурация
Использовать с Консулом
Управление API, регулирование, авторизация, переход на более раннюю версию, загрузка, распределение запросов, журналы и т. д.
высокая производительность

Конечно, в Golang также есть несколько шлюзов с открытым исходным кодом, но они не идеальны. Мы выбрали Kong главным образом потому, что в нем уже поддерживается много вещей, и нам не нужно разрабатывать его снова. Конечно, есть еще одна причина, по которой мы будем использовать Ngx_lua~~

отслеживание ссылок-zipkin

Распределенная система трассировки, которая может помочь собрать данные о времени и решить проблему задержки в архитектуре микросервиса; она управляет сбором и поиском этих данных; каждое приложение передает данные о времени в Zipkin, а пользовательский интерфейс Zipkin представляет график зависимостей, чтобы показать, сколько Trace запросы по мере их прохождения через каждое приложение;

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

Зачем использовать Зипкин

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

Архитектура

Когда мы будем строить эту архитектуру, давайте взглянем на архитектуру этой сервисной системы.

На рисунке показан поток услуг по проектированию микроархитектуры.

Все приложения и услуги зарегистрированы в консул, когда они начинаются, а затем консул будет обнаруживать состояние здоровья вашего сервиса. Как видно из рисунка, этот набор микроверигов выглядит очень сложно.

Несмотря на сложность, он может реализовать основную идею микросервисов!

Тогда вот проблема

Для достижения вышеперечисленных функций нужно встроить в код много кода.

Ты хочешь?

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

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

Преимущества микросервисов очевидны, такие как масштабируемость, возможность обновления, простота обслуживания, изоляция сбоев и ресурсов и т. д.

Производство продукции и эффективность исследований и разработок были значительно улучшены.

Как управлять таким количеством микросервисов?

Нужно ли мне подавать заявку на одну или несколько виртуальных машин каждый раз, когда я развертываю микрослужбу? Разве это не означает, что для поддержки 100 микросервисов требуются сотни виртуальных машин?

Как опубликовать?

Какие инструменты можно использовать для простой и быстрой публикации каждого микросервиса?

Как контролировать?

Как просто отслеживать и оповещать каждую службу?

Имея в виду эти вопросы, мы попыталисьCloudNative + ServiceMeshявляется хорошим решением. Об этом у меня будет время поговорить позже.

Хвостик

В микросервисной архитектуре задействовано множество технологических стеков. Будьте осторожны, если хотите войти в яму или подготовиться к ней. На ранней стадии вы должны проделать большую подготовительную работу, и вы должны больше стараться, не бойтесь.

Старое приложение рекомендуется демонтировать медленно, по крупицам, и смело пробовать новый сервис.

Я обновлю позже, если у меня будет время:

Построение кластера Consul, как выполнить регистрацию службы, обнаружение службы и использование центра конфигурации
Кластер Kong построен с конфигурацией и использованием
Zipkin, построение кластера ES и как golang соединяется с ZipKin
Как мы решаем проблему вторжения сервисов и микросервисной архитектуры
Программа на облачности
Когда я вошел в Cloudnative, мы попали в еще одну глубокую яму.

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

Накопленного за последнее время опыта и подводных камней мне хватит на несколько месяцев поста.

Сказав все это, какую проблему мы решаем?

Какую проблему решают микросервисы?

Какую проблему решает CloudNative?

Оставьте эти вопросы на потом.

Наконец, благодаря литературе о великих богах в Интернете.

Спасибо за поддержку!

Ласковое нажатие, небольшая оценка, ваша оценка - моя мотивация для обновления.

Вознаграждайте тех, кто поддерживает блогеров

Этикетка , TAG , ла ла

Get in touch with

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

Социальный аккаунт

Credits

Не позволяйте своему сердцу быть слишком полным и оставьте место для солнца!

После превратностей жизни, это вопрос правильного и неправильного.

Heroes

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