При микросервисном построении больших систем система будет разделена на множество модулей. Эти модули отвечают за разные функции, объединенные в систему, которая в конечном итоге может предоставить богатые функции. В этой форме построения разработчики обычно сосредотачиваются на максимально возможном разделении функций модулей, чтобы снизить дополнительные затраты на разработку, вызванные связью между модулями. В то же время перед микросервисами встают новые проблемы, например, как развернуть эти массивные сервисные системы и как эксплуатировать и обслуживать эти системы.
Материал этой статьи основан на некоторых из наших передовых практических примеров в разработке и знакомит с нашим опытом создания микросервисов на основе стека технологий Go с точки зрения разработки, мониторинга и ведения журналов.
разработка
При разработке микросервисов разные разработчики отвечают за разные модули, а четко определенные интерфейсы помогают определить задачи разработчиков. В конечной системе бизнес-запрос может включать в себя вызовы нескольких интерфейсов, а как точно и четко вызывать удаленный интерфейс, также является большой проблемой. Для этих проблем мы используем gRPC, который отвечает за формулировку и вызов протокола.
Традиционные микросервисы обычно вызывают вызовы между модулями на основе протокола http, но в нашей конструкции микросервиса мы используем платформу gRPC, запущенную Google, для совершения вызовов. В следующей краткой таблице сравниваются функции http rpc framework и gRPC:
Интерфейс gRPC должен быть определен с использованием Protobuf3 и может быть успешно вызван после статической компиляции. Эта функция снижает затраты на связь за счет изменения интерфейса. Если используется http rpc, при изменении интерфейса сначала необходимо изменить документ интерфейса, а затем информировать вызывающую сторону.Если вызывающая сторона не изменит его вовремя, ошибка может быть не обнаружена до тех пор, пока служба не будет запущена. В этом режиме gRPC ошибки, вызванные изменениями интерфейса, гарантированно устраняются во время компиляции.
С точки зрения производительности GRPC имеет очень большое преимущество по сравнению с традиционными протоколами HTTP RPC (согласно этой оценке, GRPC в 10 раз быстрее). GRPC использует протокол HTTP 2 для передачи, сравнения HTTP 1.1, мультиплексированного TCP-соединения HTTP 2, уменьшает накладные расходы каждого запроса на установление TCP-соединения. Следует отметить, что если речь идет исключительно о производительности, в отрасли обычно выбирают протокол RPC, основанный на протоколе TCP (THRIFT и т. д.), но четырехуровневый протокол не сможет обеспечить некоторое управление передачей. В отличие от этого, GRPC может поместить поле управления в заголовок HTTP с Nginx и другими прокси-серверами, которые можно легко перенаправлять/оттенки серого.
Далее мы сосредоточимся на том, как мы используем некоторые функции gRPC на практике, чтобы упростить соответствующий процесс разработки.
1. Используйте контекст для управления жизненным циклом запроса
В реализации gRPC на языке go первым параметром каждого запроса rpc является контекст. Протокол http2 поместит контекст в HEADER и передаст его вместе со ссылкой, поэтому для каждого запроса может быть установлено время истечения срока действия.По истечении времени ожидания инициатор завершит ожидание и вернет ошибку.
ctx := context.Background() // blank context
ctx, cancel = context.WithTimeout(ctx, 5*time.Second)
defer cancel( )
grpc.CallServiveX(ctx, arg1)
В приведенном выше коде инициатор устанавливает время ожидания около 5 с. Если удаленный вызов не возвращается в течение 5 с, инициатор сообщит об ошибке.
В дополнение к добавлению тайм-аутов, контекст также может добавлять другой контент.Мы увидим еще одно замечательное использование контекста ниже.
2. Используйте TLS для реализации контроля доступа
gRPC интегрирует функцию сертификата TLS и предоставляет нам полную схему управления разрешениями. На практике предположим, что в нашей системе есть служба A. Поскольку она отвечает за работу с конфиденциальным контентом пользователя, она должна гарантировать, что A не будет использоваться другими службами в системе. Чтобы избежать злоупотреблений, мы разработали систему самозаверяющих вторичных сертификатов. Служба А освоила самозаверяющий корневой сертификат и выдала вторичный сертификат для каждой службы, вызывающей А. Таким образом, все службы, которые вызывают A, должны быть авторизованы A, и A также может идентифицировать вызывающую сторону каждого запроса, что может легко выполнять некоторые операции, такие как ведение журнала и управление потоком.
3. Используйте трассировку для отслеживания онлайн-запросов
gRPC имеет встроенную систему трассировки для отслеживания запросов, которая может не только отслеживать подробную информацию журнала о последних 10 запросах, но и записывать статистическую информацию обо всех запросах.
Когда мы добавим журнал трассировки в запрос, система трассировки запишет для нас журналы последних 10 запросов.Пример, показанный на рисунке ниже, — это добавление трассировки бизнес-данных в журнал трассировки.
На макроуровне система трассировки записывает для нас статистическую информацию о запросах, такую как количество запросов и распределение статистики по разным временам запросов.
Следует отметить, что эта система предоставляет службу http, которую мы можем включать или выключать по мере необходимости во время выполнения с помощью переключателя отладки, чтобы уменьшить потребление ресурсов.
монитор
1. Определить показатели мониторинга
Когда мы получили задание построить систему мониторинга всей системы, первый вопрос, который перед нами встал, — что мониторить. На этот вопрос книга GoogleSRE дает очень подробный ответ: мы можем отслеживать четыре золотых показателя, а именно задержку, трафик, ошибки и насыщение.
- Задержка измеряет, сколько времени занимает запрос. Следует отметить, что, учитывая эффект длинного хвоста, недостаточно использовать среднюю задержку как единую метрику с точки зрения задержки. Соответственно, нам нужны медианные значения задержки 90%, 95% и 99%, чтобы помочь нам понять распределение задержки.Лучше использовать гистограмму для подсчета распределения задержки.
- Трафик измеряет давление запросов, с которым сталкивается служба. Статистика трафика для каждого API может сообщить нам путь точки доступа в системе и помочь оптимизировать его.
- Мониторинг ошибок относится к статистике некорректных результатов запроса. Точно так же каждый запрос имеет разный код ошибки, и нам нужно вести статистику по разным кодам ошибок. В сочетании с системой сигнализации этот тип мониторинга позволяет нам обнаруживать ошибки как можно раньше и вмешиваться.
- Насыщение в основном относится к мониторингу загрузки системного ЦП и памяти. Этот тип мониторинга может дать информацию о наших решениях о масштабировании.
2. Выбор мониторинга
При выборе решения для мониторинга мы сталкиваемся с двумя основными вариантами: одним из них является собственная система мониторинга компании, а другим — использовать для сборки систему Prometheus с открытым исходным кодом. Различия между двумя системами перечислены в таблице ниже.
Учитывая, что вся наша система имеет около 100 контейнеров, разбросанных по 30 ВМ, одномашинное хранилище Prometheus для нас не является узким местом. Нам не нужно полностью хранить исторические данные, и самого большого преимущества самодельной системы недостаточно, чтобы привлечь нас к ее использованию. Напротив, удобный DSL Prometheus может значительно упростить разработку нашего индикатора, потому что мы хотим иметь возможность подсчитывать множество индикаторов, полученных из четырех золотых индикаторов.
В итоге мы выбрали Prometheus для построения системы мониторинга. Каркас всей системы мониторинга показан на рисунке ниже.
Каждый сервис прописывает в консуле свой адрес, и Prometheus автоматически подтягивает целевой адрес для мониторинга из консула, а затем вытягивает данные мониторинга из этих сервисов и сохраняет их в локальном хранилище. В веб-интерфейсе, который поставляется с Prometheus, вы можете быстро использовать оператор запроса PromQL для получения статистической информации.В то же время вы также можете ввести оператор запроса в grafana и исправить индикаторы мониторинга для мониторинга.
Кроме того, с помощью плагина AlertManager мы можем написать правила тревоги и, когда система ненормальна, отправить тревогу на мобильный телефон/электронную почту/почтовый ящик.
журнал
1. Журнал формата
Часто упущенная проблема заключается в том, как выбрать формат записей журнала. Формат Well-log облегчает последующую режущую инструмент для контента журнала, простой индекс хранения журнала. Мы используем Logrus для печати журнала в формат пакета файла журнала, Logrus Tool поддерживает одноразовую линейку формата Space-delimited, формат JSON и т. Д.
текстовый формат
time=”2015-03-26T01:27:38-04:00″ level=debug g=”Начал наблюдать за пляжем” animal=worrus number=8
time="2015-03-26T01:27:38-04:00" level=info msg="Группа моржей выходит из океана" animal=walrus size=10формат JSON
{"животное":"морж","уровень":"информация","msg":"Группа моржей выходит из океана","размер":10,"время":"10.03.2014 19:57 :38.562264131 -04:00 по восточноевропейскому времени»}
{"level":"warning","msg":"Число группы сильно увеличилось!","number":122,"omg":true,"time":"2014-03-10 19:57:38.562471297 - 04:00 по восточноевропейскому времени»}
2. Сбор журнала вызовов по сквозной ссылке
В микросервисной архитектуре бизнес-запрос будет проходить через несколько служб, и сбор журналов сквозной связи может помочь нам определить конкретное место ошибки. В этой системе мы генерируем глобальный идентификатор в записи запроса и передаем идентификатор по ссылке через контекст в gRPC. Журналы различных сервисов собираются в Graylog, а журналы по всей ссылке можно запрашивать через идентификатор во время запроса.
На приведенном выше рисунке использование идентификатора сеанса в качестве идентификатора всей цепочки вызовов может выполнять извлечение полной ссылки.
резюме
В системе, построенной на основе микросервисов, возникают проблемы с развертыванием, планированием, обнаружением сервисов, согласованностью и т. д. В стеке технологий Go есть лучшие практики в этих аспектах (docker, k8s, consul и т. д. и т. д.). В Интернете уже есть полные учебники для конкретного контента, здесь нет необходимости делать шаг, вы можете проверить это самостоятельно, если вам это нужно.