После посещения микросервисных переговоров Сэма Ньюмана на Geecon на прошлой неделе я начал больше думать о том, что, скорее всего, является важной особенностью сервис-ориентированных / микросервисных платформ для мониторинга, отчетности и диагностики: идентификаторы корреляции. Идентификаторы корреляции позволяют распределенную трассировку в сложных сервис-ориентированных платформах, где один запрос к приложению часто может быть обработан множеством нисходящих сервисов. Без возможности коррелировать запросы на нисходящие сервисы может быть очень сложно понять, как запросы обрабатываются на вашей платформе.
Я видел преимущества идентификаторов корреляции в нескольких недавних проектах SOA, над которыми я работал, но, как Сэм упоминал в своих выступлениях, часто очень легко думать, что этот тип трассировки не понадобится при создании начальной версии приложения. , но тогда очень сложно внедрить приложение, когда вы понимаете преимущества (и необходимость!). Я еще не нашел идеальный способ реализовать корреляционные идентификаторы в приложении на основе Java / Spring, но после общения с Сэмом по электронной почте он сделал несколько предложений, которые я теперь превратил в простой проект с использованием Spring Boot, чтобы продемонстрировать, как это может быть реализованным.
Зачем?
Во время обеих бесед Сэма с Geecon он упомянул, что в его опыте идентификаторы корреляции были очень полезны для диагностических целей. Идентификаторы корреляции — это, по сути, идентификатор, который генерируется и связывается с одним (обычно управляемым пользователем) запросом в приложении, которое передается через стек и на зависимые сервисы. В SOA или микросервисных платформах этот тип идентификатора очень полезен, так как запросы в приложение обычно «разветвляются» или обрабатываются несколькими нисходящими сервисами, а идентификатор корреляции позволяет всем нисходящим запросам (от начальной точки запроса) быть сопоставлены или сгруппированы на основе идентификатора.Затем можно выполнить так называемую «распределенную трассировку» с использованием идентификаторов корреляции, объединив все журналы сервисов в нисходящем направлении и сопоставив требуемый идентификатор, чтобы увидеть трассировку запроса по всему стеку приложений (что очень легко, если вы используете централизованное ведение журнала). рамки, такие как logstash )
Крупные игроки в сервис-ориентированной области уже довольно давно говорят о необходимости распределенной трассировки и корреляции запросов, и поэтому Twitter создал свою среду с открытым исходным кодом Zipkin (которая часто подключается к их RPC-инфраструктуре Finagle ) и Netflix. открыла исходный код своей веб / микросервисной платформы Karyon, которая обеспечивает распределенную трассировку. Есть, конечно, коммерческие предложения в этой области, одним из таких продуктов является AppDynamics , который очень классный, но имеет довольно высокую цену.
Создание подтверждения концепции в Spring Boot
Как бы ни были Зипкин и Кэрион, они оба относительно инвазивны, так как вы должны строить свои сервисы поверх (часто самоуверенного) фреймворков. Это может быть хорошо для некоторых случаев использования, но не так много для других, особенно когда вы создаете микросервисы. В последнее время я с удовольствием экспериментировал с Spring Boot , и этот фреймворк основан на широко известном и любимом (по крайней мере, мне :-)) Spring фреймворке, предоставляя множество предварительно настроенных разумных значений по умолчанию. Это позволяет очень быстро создавать микросервисы (особенно те, которые взаимодействуют через интерфейсы RESTful). В оставшейся части этого блога объясняется, как я реализовал (надеюсь) неинвазивный способ реализации корреляционных идентификаторов.
цели
- Разрешить создание идентификатора корреляции для первоначального запроса в приложение
- Разрешить передачу идентификатора корреляции в нисходящие сервисы, используя как метод, который является неинвазивным в коде, насколько это возможно
Реализация
Я создал два проекта на GitHub, один из которых содержит реализацию, в которой все запросы обрабатываются в синхронном стиле (т. Е. Традиционный подход Spring для обработки всех запросов в одном потоке), а также один для асинхронных (неблокирующих) ) используется стиль связи (т. е. используется асинхронная поддержка Servlet 3 в сочетании с Spring DeferredResult и Java Futures / Callables). Большая часть этой статьи описывает асинхронную реализацию, так как это более интересно:
Основная работа в обеих базах кода выполняется CorrelationHeaderFilter, который является стандартным фильтром Java EE, который проверяет заголовок HttpServletRequest на наличие атрибута correlationId. Если он найден, мы устанавливаем переменную ThreadLocal в классе RequestCorrelation (будет обсуждаться позже). Если идентификатор корреляции не найден, он генерируется и добавляется в класс RequestCorrelation:
public class CorrelationHeaderFilter implements Filter {
//...
@Override
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain)
throws IOException, ServletException {
final HttpServletRequest httpServletRequest = (HttpServletRequest) servletRequest;
String currentCorrId = httpServletRequest.getHeader(RequestCorrelation.CORRELATION_ID_HEADER);
if (!currentRequestIsAsyncDispatcher(httpServletRequest)) {
if (currentCorrId == null) {
currentCorrId = UUID.randomUUID().toString();
LOGGER.info("No correlationId found in Header. Generated : " + currentCorrId);
} else {
LOGGER.info("Found correlationId in Header : " + currentCorrId);
}
RequestCorrelation.setId(currentCorrId);
}
filterChain.doFilter(httpServletRequest, servletResponse);
}
//...
private boolean currentRequestIsAsyncDispatcher(HttpServletRequest httpServletRequest) {
return httpServletRequest.getDispatcherType().equals(DispatcherType.ASYNC);
}
Единственное, что этот код, который может быть не сразу очевиден, — это условная проверка currentRequestIsAsyncDispatcher (httpServletRequest) , но это здесь для защиты от кода id корреляции, который выполняется, когда выполняется поток Async Dispatcher, чтобы вернуть результаты (это интересно обратите внимание, поскольку я изначально не ожидал, что Async Dispatcher снова запустит выполнение фильтра?)
Вот класс RequestCorrelation, который содержит простую статическую переменную ThreadLocal <String> для хранения идентификатора корреляции для текущего потока выполнения (установленного через CorrelationHeaderFilter выше)
public class RequestCorrelation {
public static final String CORRELATION_ID = "correlationId";
private static final ThreadLocal<String> id = new ThreadLocal<String>();
public static String getId() { return id.get(); }
public static void setId(String correlationId) { id.set(correlationId); }
}
@Component
public class CorrelatingRestClient implements RestClient {
private RestTemplate restTemplate = new RestTemplate();
@Override
public String getForString(String uri) {
String correlationId = RequestCorrelation.getId();
HttpHeaders httpHeaders = new HttpHeaders();
httpHeaders.set(RequestCorrelation.CORRELATION_ID, correlationId);
LOGGER.info("start REST request to {} with correlationId {}", uri, correlationId);
//TODO: error-handling and fault-tolerance in production
ResponseEntity<String> response = restTemplate.exchange(uri, HttpMethod.GET,
new HttpEntity<String>(httpHeaders), String.class);
LOGGER.info("completed REST request to {} with correlationId {}", uri, correlationId);
return response.getBody();
}
}
//... calling Class
public String exampleMethod() {
RestClient restClient = new CorrelatingRestClient();
return restClient.getForString(URI_LOCATION); //correlation id handling completely abstracted to RestClient impl
}
Приведенный выше код прекрасно работает, когда вы обрабатываете все ваши запросы синхронно, но на платформе SOA / microservice часто неплохо обрабатывать запросы неблокирующим асинхронным образом. Весной этого можно достичь с помощью класса DeferredResult в сочетании с асинхронной поддержкой Servlet 3. Проблема с использованием переменных ThreadLocal в асинхронном подходе заключается в том, что поток, который первоначально обрабатывает запрос (и создает DeferredResult / Future), не будет потоком, выполняющим фактическую обработку.
Соответственно, требуется немного связующего кода, чтобы гарантировать, что идентификатор корреляции распространяется по потокам. Это может быть достигнуто путем расширения Callable с необходимой функциональностью: (не беспокойтесь, если пример кода вызывающего класса не выглядит интуитивно понятным — эта адаптация между DeferredResults и Futures является необходимым злом в Spring, а полный код, включая шаблон ListenableFutureAdapter, в моем репозитории GitHub):
public class CorrelationCallable<V> implements Callable<V> {
private String correlationId;
private Callable<V> callable;
public CorrelationCallable(Callable<V> targetCallable) {
correlationId = RequestCorrelation.getId();
callable = targetCallable;
}
@Override
public V call() throws Exception {
RequestCorrelation.setId(correlationId);
return callable.call();
}
}
//... Calling Class
@RequestMapping("externalNews")
public DeferredResult<String> externalNews() {
return new ListenableFutureAdapter<>(service.submit(new CorrelationCallable<>(externalNewsService::getNews)));
}
Вы можете клонировать отчет Github, содержащий мой асинхронный пример, и запустить приложение, запустив mvn spring-boot: run в командной строке. Если вы откроете http: // localhost: 8080 / externalNews в своем браузере (или с помощью curl), вы увидите нечто похожее на следующее в консоли Spring Boot, которое четко демонстрирует идентификатор корреляции, сгенерированный при первоначальном запросе, а затем это передается через имитированный внешний вызов (загляните в класс ExternalNewsServiceRest, чтобы увидеть, как это было реализовано):
[nio-8080-exec-1] u.c.t.e.c.w.f.CorrelationHeaderFilter : No correlationId found in Header. Generated : d205991b-c613-4acd-97b8-97112b2b2ad0 [pool-1-thread-1] u.c.t.e.c.w.c.CorrelatingRestClient : start REST request to http://localhost:8080/news with correlationId d205991b-c613-4acd-97b8-97112b2b2ad0 [nio-8080-exec-2] u.c.t.e.c.w.f.CorrelationHeaderFilter : Found correlationId in Header : d205991b-c613-4acd-97b8-97112b2b2ad0 [pool-1-thread-1] u.c.t.e.c.w.c.CorrelatingRestClient : completed REST request to http://localhost:8080/news with correlationId d205991b-c613-4acd-97b8-97112b2b2ad0
Я очень доволен этим простым прототипом, и он отвечает двум целям, которые я перечислил выше. Будущая работа будет включать в себя написание некоторых тестов для этого кода (позор мне, что я не использую TDD!), А также расширение этой функциональности до более реалистичного примера.
Я хотел бы выразить огромную благодарность Сэму не только за то, что он поделился своими знаниями на великих переговорах в Geecon, но и за то, что нашел время ответить на мои электронные письма. Если вы интересуетесь микросервисами и связанной с ними работой, я настоятельно рекомендую книгу Микросервиса Сэма, которая доступна в разделе «Ранний доступ» в O’Reilly . Я с удовольствием прочитал доступные на данный момент главы, и, реализовав довольно много SOA-проектов в последнее время, я могу сослаться на множество полезных советов, содержащихся в нем. Я буду следить за развитием этой книги с большим интересом!
Если у вас есть какие-либо комментарии или мысли, пожалуйста, поделитесь ими через комментарий ниже, или не стесняйтесь связаться через обычные механизмы!
Рекомендации
Я использовал превосходный блог Томаша Нуркевича несколько раз, чтобы узнать, как лучше всего связать весь код DeferredResult / Future весной:
http://www.nurkiewicz.com/2013/03/deferredresult-asynchronous-processing.html