xharbor

API gateway (switch)

TODO:

1. В отношении бизнес-операций добавить к Netty информацию о количестве полученных и отправленных байт, а также о трафике (количество байт в одном событии). Реализовать идею следующим образом: после получения соответствующей информации через Handler передать её через Channel или Ctx's Attribute в Flow, а затем отобразить в BizMemo.

2. Увеличить количество JMX MBean элементов мониторинга, включая BytesPool и HttpStack.

3. Рассмотреть возможность добавления пользовательских HTTP-заголовков, например «X-Client-Type: Test», для определения адреса пересылки. Уже добавлено как «X-Route-Code».

4. Основываясь на наличии или отсутствии действительных правил переадресации, запускать или останавливать экземпляр HttpGatewayServer.

5. Для клиентов без совпадений в адресах переадресации необходимо увеличить показатели JMX MBean для мониторинга таких запросов.

6. Перенести логику расчёта маршрута из HttpGatewayServer в RelayFlow. Для вычислений в маршрутизаторе использовать асинхронные события из пула потоков, что позволит снизить нагрузку на Netty, управляющий клиентскими соединениями. 2015-01-18 уже реализовано.

7. Добавить JMX ConnectServer с использованием протокола jmxmp.

// TODO

8. Можно ли сделать маршрутизацию асинхронной? Это осуществимо, если улучшить интерфейс Router, чтобы разрешить более длительные действия по маршрутизации в асинхронном режиме. В RelayFlow добавлен статус «ROUTING» для обозначения этапа асинхронных вычислений маршрута. 2017-01 уже реализовано, см. код в org.jocean.xharbor.api.TradeReactor и его реализациях.

9. После ограниченного числа неудачных попыток переадресации временно блокировать определённые маршруты, достигшие верхнего предела количества неудачных переадресаций. Сейчас после однократной неудачной попытки переадресации (соединение не установлено) система маркируется как down.

10. Добавить белый и чёрный списки URI, которые обрабатываются в пуле потоков Netty. Все URI, соответствующие регулярному выражению чёрного списка, отклоняются, или только те, которые соответствуют регулярному выражению белого списка, обрабатываются. Записывать общее количество отклонённых URI.

11. На основе результатов переадресации оценивать в реальном времени целевые URI; при выборе маршрута учитывать текущую оценку при определении маршрута. Если результат переадресации — CONNECT_FAILURE, то маркер URI down должен быть общим (сделано).

12. Для запросов переадресации с ошибками увеличивать количество повторных пересылок, включая повторную отправку полного содержимого HttpContent(s). Записывать количество повторных попыток пересылки (сделано, записывается как RELAY_RETRY result).

13. Если пересылка успешна, но возвращённый ответ имеет статус ошибки (4XX, 5XX), следует ли уменьшить вес маршрута или пометить конкретный API как недействительный? (сделано, добавлены результаты Result(HTTP_CLIENT_ERROR/HTTP_SERVER_ERROR), и на основе этих результатов помечается конкретный API как недействительный, и предпринимается попытка повторной пересылки, также добавлена опция включения/выключения этой функции проверки).

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

15. Увеличить гибкость управления xharbor во время выполнения через BeanShell через JMX.

16. Не регистрировать отдельную группу MBean для запросов NO_ROUTING, вместо этого объединять их в один MBean, который записывает NoRouting, в виде строки или карты, для уменьшения объёма бесполезной информации в MBean (сделано).

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

18. Начать отсчёт времени (StopWatch) сразу после получения HTTP-запроса, приближаясь к начальной точке отсчёта времени для ROUTING.

19. Адаптироваться к jocean-http, FullMessage like.

20. Извлечь реализацию RulesZKUpdater & AUPZKUpdater в общий Updater с CopyOnWrite. (сделано)

21. Обрабатывать сигналы проверки работоспособности отдельно в RelayFlow, включая совпадающие методы/пути, возвращаемые коды состояния и тела сообщений. (сделано)

22. Статистически отображать информацию о IP-адресе источника для NOROUTING.

23. В manifest/MANIFEST.MF указать ClassPath на внешние пути, реализовать сохранение logback.xml и файлов *.properties в общем расположении, чтобы при обновлении AppServer не приходилось копировать и переносить файлы конфигурации (см. confluence и jira). (сделано, 2015-02-04 в MANIFEST.MF, согласно текущей модели развёртывания в сети, Class-Path был изменён на ../../etc/) (сделано).

24. Через JMX команды можно использовать частичное сопоставление ObjectName для запроса MBean с определёнными полями.

25. Объединить статистическую информацию Mbean для различных уровней переадресации в одном или нескольких MBean, используя формат, подобный карте (OpenMBean TabularData), и выводить данные в формате Excel / CSV.

26. Упростить вывод журнала переадресации до одной записи журнала для каждой успешной переадресации. (сделано, 2015-02-05)

27. Использовать «hostname/username» для различения запущенных JVM-экземпляров. Используется для различения экземпляров в дереве конфигурации ZK.

28. Структура свойств в дереве конфигурации ZK может объединять общие конфигурации и специфические для экземпляра конфигурации. Например: -----+------------- | +------------(общая конфигурация) | +------------ host1/user1 +----------- | +----------(специфическая для экземпляра конфигурация)

29. Создание relayAgent аналогично HttpGateServer, настраивается через ZK и может динамически создаваться и уничтожаться во время работы. Может динамически сопоставляться с HttpGatewayServer через имена?

30. Оба, relayAgent и HttpGatewayServer, могут контролироваться через MBean для наблюдения за параметрами конфигурации и состоянием во время работы.

31. Уточнение подробной информации WARN-журнала для недопустимых сигналов, включая HTTP-заголовки и т. д. (сделано)

32. Во время пересылки можно удалить часть пути, внести определённые изменения в HttpRequest. (сделано, 2015-02)

33. Установить аутентификацию на этапе пересылки, чтобы проверять законность доступа пользователей при начале пересылки. (сделано, 2015-02-11), включая белые и чёрные списки.

34. Подтвердить, будет ли FullHttpRequest отправлять содержимое HttpContent дважды?

35. Переименовать RelayAgent в BusinessAgent и обернуть ChannelHandlerContext в интерфейсе пакета в createRelayTask(final ChannelHandlerContext channelCtx, final HttpRequest httpRequest) в RelayFlow, чтобы бизнес-обработка могла адаптироваться к HTTP и TCP мультиплексированию.

36. В параметрах RelayFlow: final RelayMemo.Builder memoBuilder, final ServiceMemo serviceMemo, final GuideBuilder guideBuilder, final boolean checkResponseStatus, final boolean showInfoLog Финальный HttpRequestTransformer.Builder transformerBuilder Рассмотреть возможность передачи RelayFlow способом, указанным в target. Это позволит проводить настройку в Data ZK-узла. Сначала рассмотреть возможность настройки checkResponseStatus и showInfoLog в ZK.

37. Конфигурацию портов jmxmp и jmxhtml запустить с использованием способа запуска через ZK, удалив настройки портов jmxmp.port и jmxhtml.port из конфигурационного файла.

38. Создать функциональный блок (Unit), используя способ построения Spring Context для ZK. Повторно использовать существующий шаблон j2se. (Готово)

39. Реализовать древовидную структуру построения функциональных блоков, где дочерние функциональные блоки могут наследовать информацию о Bean от родительских функциональных блоков. Например: relay unit +--> acceptor unit: 6572 | +--> acceptor unit: 8888 (Готово)

40. Загрузить AUP (ApplyUrlencode4Post) в систему с помощью Spring, исключив AUPOperator. Рассмотреть возможность загрузки по схеме: relay unit +--> acceptor unit: 6572 | +--> acceptor unit: 8888 | +--> AUPunit (Готово)

41. Реализовать использование RouteRules с помощью отдельного Spring Ctx. Заменить RouteRulesOperator.

42. Реализовать режим ссылки на свойства ZK Spring. Можно ссылаться на уже существующие определения Unit с помощью специальных меток.

43. Объединить с пунктом 42 для упрощения реализации требования 28.

44. Проанализировать отдельный Java-файл RelayFlow. Собрать вместе HttpRequest/request's HttpContent и связанные методы и т. д. (Готово).

45. Использовать Mock или Hamcrest для создания Unit TestCase. (Готово).

46. В BizStep реализовать функцию отложенной инициализации. Инициализировать полный экземпляр только при вызове интерфейса. Уменьшить время и потребление памяти, затрачиваемые на инициализацию Flow. В некоторых сценариях некоторые состояния в графе состояний не будут достигнуты в одном процессе. Отложенная инициализация может эффективно сократить общее время процесса и потребление памяти.

47. Исправить ошибку: httpRequestTransform выполняется несколько раз при повторных попытках. Количество выполнений равно количеству попыток.