Под WSL не работает механизм font-fallback, а ваш дефолтный шрифт не поддерживает используемые символы. У майкрософта есть issue на этот счет. Пока что можно попробовать поменять шрифт на Courier New, как предлагают пользователи
Почему риторический? Клик мышкой выделяет компонент, далее для изменения размеров или перемещения — стрелками. Можно обрабатывать еще больше кликов (выделение пунктов меню, перетаскивание элементов). Но мне показалось это не слишком полезно для консольной утилиты, клавишами все равно привычнее и удобнее
Триггеры срабатывают при выполнении условия (например превышение некоторого значения) и могут выполнять произвольный скрипт — например слать алерты по email или pushover
Для go существует немало библиотек для отрисовки в терминале. Я выбрал termui — обертку над более низкоуровневой termbox-go. В какой-то момент стало понятно, что заиспользовать готовые компоненты оттуда мне не подходит — чтобы сделать хорошо и красиво, все графики и компоненты для семплера пришлось реализовывать самому, используя тот же низкоуровневый API (рисуй из этой точки в эту, таким-то цветом). Так что я уже некоторое время думаю над тем чтобы отказаться от обертки и использовать просто termbox-go, или например gocui
К слову о сплите монолита на сервисы — существует ли какой-то формальный способ доказать, что разделив монолит на несколько частей, мы получим более масштабируемую систему? Набросать концепт и сделать сравнительный нагрузочный тест не всегда возможно сделать быстро и дешево. Интересуют именно методики формальной оценки
Тоже пользуемся ELK стеком. У меня на гитхабе есть докер-компоуз конфигурация с ELK и куратором (для регулярного удаления устаревших индексов, выполнения optimize итп), автоматической настройкой темплейтов Логстеша для Эластиксерча (по всем битсам) — может кому пригодится.
На текущем проекте в проде используем именно такую конфигурацию с небольшой кастомизацией. На наших объемах все работает хорошо.
Почему вы решили весь ELK стек положить в один контейнер? Это ведь противоречит одной из главных идей Докера — один процесс на контейнер, со всеми вытекающими плюсами.
Теперь понял о чем вы. Проблема встает если выставлять Service Discovery наружу из докер нетворка и регистрировать сервисы извне (не делал так). Решается очевидно тем же способом, кстати в gliderlabs/registrator, о котором вы говорите, я вижу свежий пулл-реквест для поддержки Eureka. Кроме того, во всем этом стеке Eureka можно заменить на Consul достаточно безболезненно. Ну и если докер соберется сделать вот этот тикет, проблема будет решена окончательно.
Спасибо за отзыв, но кажется вы не понимаете ряд важных моментов.
В .yml файлах из конфиг-сервиса ничего не захардкожено — там указаны порты, на которых должны подниматься спринговые приложения (это никак не связано с портами, которые торчат наружу). Порты здесь указаны они для удобства, ибо по умолчанию порт один — 8080 и если вы решите запустить их на одном хосте (из IDE, например) — будет конфликт. Но при запуске в контейнерах это вообще не важно — можете поменять их на стандартные, если хочется. Каждый контейнер со спринговым приложением будет экспоузить 8080, каждый со своего хоста внутри докер-нетворка.
В продакшн моде наружу из докер нетворка выставляется только часть служебных сервисов (типа rabbitmq managment, eureka dashboard, мониторинг и конечно gateway на 80 порту), чем меньше тем лучше. Смотрите докер-компоуз файлы.
Когда поднимается какой-нибудь account-service, он понятия не имеет где находится notification-serice — это нигде не прописано и ему предстоит узнать адрес у Eureka. Вы можете провести простой эксперимент — после запуска всей системы сделайте docker-compose scale notification-service=2. Поднимется еще один инстанс notification-service, зарегистрируется в Eureka и клиентские балансировщики у всех остальных сервисов будут раунд робином стучать в два имеющихся notification-service. Просто смотрите логи docker-compose logs notification-service и стучите в него через gateway: curl -X GET -H "Authorization: Bearer XXXX" http://127.0.0.1/notifications/recipients/current
Часть служебных сервисов являются фиксированными точками. Такие точки каждый из сервисов знает наизусть (без Service Discovery):
Конфиг сервер — http://config:8888. Этот адрес прописан прямо в bootstrap.yml каждого из микросервисов, ибо это первое, куда им нужно обратиться при старте — "Config First" mode. См. документацию.
Авторизационный сервер — http://auth-service:5000. Вот его хотелось бы регистрировать в Service Discovery, но пока это невозможно из коробки. См. тикет на гитхабе.
Как видно, ко всем ним можно обращаться по алиасам внутри докер нетворка, что делается с помощью встроенного dns-сервера (компоуз запускает контейнеры с командой --net-alias, в результате имя в сети = имени сервиса) — см. документацию
Спасибо за совет! Дэйв сказал, что как раз для таких случаев Джош Лонг каждую неделю собирает сторонние публикации в посте This Week in Spring, видимо пока это единственный вариант. Сегодня появился свежий пост с упоминанием о статье.
Механизмы оркестрации контейнеров, Continuous Delivery и Service Discovery призваны автоматизировать вопросы администрирования (что конечно никак не уменьшает сложности на этапе возведения).
А single point of failure — о другом, это грех классического монолита или расшаренной между сервисами базой данных. Выдуманный пример: в некоторый момент на вход начинают поступать данные, вызывающие критическую ошибку в Statistics Service, приводящую к падению всего приложения. В случае монолита это последовательно уронит все инстансы, пользователи не смогут доступится к приложению вообще. В случае микросервисов нет единой точки отказа — Account Service и Notification Service продолжают фунционировать (все загружается и сохраняется, разве что на UI не работает график про статистику), а после исправления дефекта поднятые инстансы Statistics Service разберут накопившиеся очереди.
Расчет был на то, что красивая картинка сподвигнет интересующихся разобраться и самостоятельно стартовать систему, по дороге узнавая что-нибудь новое. Но если хочется просто потыкать UI времен раннего студенческого творчества, на rhcloud доступна старая версия.
У нас пока не стояло задачи скейлить инстансы автоматически, и это точно выходит за рамки данной статьи. Но оркестрация большого числа контейнеров и автомасштабирование — большая и крайне интересная тема. Есть инструмент от самого докера — Docker Swarm, есть Google Kubernetes. Облачные провайдеры предоставляют специальные сервисы.
Спасибо за отзыв. Пока не проводил сколько-нибудь серьезных тестов на этот счет, будет интересно заняться этим отдельно. Если я правильно понял ваш вопрос: при падении Докер рестартует инстанс достаточно быстро, загрузка Spring Boot приложения занимает менее 30 сек, сразу происходит запрос в Service Discovery. На дефолтных настройках Eureka может потребоваться до полутора минут, чтобы клиент увидел инстанс. Эти настройки можно изменить, но именно их Netflix рекомендует для продакшена.
Кроме того, одним из самых сложных моментов является разбиение монолита. И если требуется цепочка из пяти непременно синхронных запросов, возможно стоит пересмотреть гранулярность такой микросервисной системы.
Как можно делать быстрые приложения на микросервисах с синхронными внутренними запросами?
Мне не известны способы сделать цепочку синхронных запросов быстрой, ведь оверхэд на сеть будет всегда.
Другой вопрос, что все стремятся сделать взаимодействие максимально асинхронным. В случае, если для страницы UI вам необходимо дернуть 5 сервисов для сбора контента — есть возможность распараллелить такой запрос сразу в API Gateway, это одна из его основных задач. Существует стремительно развивающаяся дисциплина — реактивное программирование (посмотрите Akka, RxJava). Есть немало материала на этот счет, в том числе на хабре. Короткая статья Netflix как раз на эту тему.
С другой стороны, стоит помнить, что существует два разных подхода к взаимодействию — оркестрация и хореография:
Последний позволяет решить много проблем в распределенной системе, делая узлы менее связанными, со всеми вытекающими плюсами.
Статья на английском сейчас в процессе модерации на DZone.com, но я обязательно изучу возможность публикации в блоге Cпринга (мне казалось там пишет только сама команда).
Кирилл, спасибо за отзыв! Очень жду ваших докладов на JPoint.
На айпаде постоянно пользуюсь тройным нажатием на кнопку Home (мгновенно инвертирует цвета, функция включается в настройках). Причем это удобно не только в браузере, а в любом приложении.
Могу посоветовать поискать что-то подобное на вашем планшете
Под WSL не работает механизм font-fallback, а ваш дефолтный шрифт не поддерживает используемые символы. У майкрософта есть issue на этот счет. Пока что можно попробовать поменять шрифт на Courier New, как предлагают пользователи
Почему риторический? Клик мышкой выделяет компонент, далее для изменения размеров или перемещения — стрелками. Можно обрабатывать еще больше кликов (выделение пунктов меню, перетаскивание элементов). Но мне показалось это не слишком полезно для консольной утилиты, клавишами все равно привычнее и удобнее
Триггеры срабатывают при выполнении условия (например превышение некоторого значения) и могут выполнять произвольный скрипт — например слать алерты по email или pushover
Если речь только о группировке разных компонентов в одну рамку под некоторым заголовком — это можно сделать сейчас
Если же речь о табах как в tmux, то пока не планировалось. Двигать компоненты можно прямо из UI, их размеры и положение относительны размеру окна.
Спасибо. Пока такой конфигурации нет, но если сделаете сами — не стесняйтесь отписаться на гитхабе (issue, или PR в README)
Для go существует немало библиотек для отрисовки в терминале. Я выбрал termui — обертку над более низкоуровневой termbox-go. В какой-то момент стало понятно, что заиспользовать готовые компоненты оттуда мне не подходит — чтобы сделать хорошо и красиво, все графики и компоненты для семплера пришлось реализовывать самому, используя тот же низкоуровневый API (рисуй из этой точки в эту, таким-то цветом). Так что я уже некоторое время думаю над тем чтобы отказаться от обертки и использовать просто termbox-go, или например gocui
К слову о сплите монолита на сервисы — существует ли какой-то формальный способ доказать, что разделив монолит на несколько частей, мы получим более масштабируемую систему? Набросать концепт и сделать сравнительный нагрузочный тест не всегда возможно сделать быстро и дешево. Интересуют именно методики формальной оценки
Тоже пользуемся ELK стеком. У меня на гитхабе есть докер-компоуз конфигурация с ELK и куратором (для регулярного удаления устаревших индексов, выполнения optimize итп), автоматической настройкой темплейтов Логстеша для Эластиксерча (по всем битсам) — может кому пригодится.
На текущем проекте в проде используем именно такую конфигурацию с небольшой кастомизацией. На наших объемах все работает хорошо.
Почему вы решили весь ELK стек положить в один контейнер? Это ведь противоречит одной из главных идей Докера — один процесс на контейнер, со всеми вытекающими плюсами.
Теперь понял о чем вы. Проблема встает если выставлять Service Discovery наружу из докер нетворка и регистрировать сервисы извне (не делал так). Решается очевидно тем же способом, кстати в gliderlabs/registrator, о котором вы говорите, я вижу свежий пулл-реквест для поддержки Eureka. Кроме того, во всем этом стеке Eureka можно заменить на Consul достаточно безболезненно. Ну и если докер соберется сделать вот этот тикет, проблема будет решена окончательно.
Спасибо за отзыв, но кажется вы не понимаете ряд важных моментов.
В .yml файлах из конфиг-сервиса ничего не захардкожено — там указаны порты, на которых должны подниматься спринговые приложения (это никак не связано с портами, которые торчат наружу). Порты здесь указаны они для удобства, ибо по умолчанию порт один — 8080 и если вы решите запустить их на одном хосте (из IDE, например) — будет конфликт. Но при запуске в контейнерах это вообще не важно — можете поменять их на стандартные, если хочется. Каждый контейнер со спринговым приложением будет экспоузить 8080, каждый со своего хоста внутри докер-нетворка.
В продакшн моде наружу из докер нетворка выставляется только часть служебных сервисов (типа rabbitmq managment, eureka dashboard, мониторинг и конечно gateway на 80 порту), чем меньше тем лучше. Смотрите докер-компоуз файлы.
Когда поднимается какой-нибудь account-service, он понятия не имеет где находится notification-serice — это нигде не прописано и ему предстоит узнать адрес у Eureka. Вы можете провести простой эксперимент — после запуска всей системы сделайте
docker-compose scale notification-service=2. Поднимется еще один инстанс notification-service, зарегистрируется в Eureka и клиентские балансировщики у всех остальных сервисов будут раунд робином стучать в два имеющихся notification-service. Просто смотрите логиdocker-compose logs notification-serviceи стучите в него через gateway:curl -X GET -H "Authorization: Bearer XXXX" http://127.0.0.1/notifications/recipients/currentКак видно, ко всем ним можно обращаться по алиасам внутри докер нетворка, что делается с помощью встроенного dns-сервера (компоуз запускает контейнеры с командой --net-alias, в результате имя в сети = имени сервиса) — см. документацию
А single point of failure — о другом, это грех классического монолита или расшаренной между сервисами базой данных. Выдуманный пример: в некоторый момент на вход начинают поступать данные, вызывающие критическую ошибку в Statistics Service, приводящую к падению всего приложения. В случае монолита это последовательно уронит все инстансы, пользователи не смогут доступится к приложению вообще. В случае микросервисов нет единой точки отказа — Account Service и Notification Service продолжают фунционировать (все загружается и сохраняется, разве что на UI не работает график про статистику), а после исправления дефекта поднятые инстансы Statistics Service разберут накопившиеся очереди.
Мне не известны способы сделать цепочку синхронных запросов быстрой, ведь оверхэд на сеть будет всегда.
Другой вопрос, что все стремятся сделать взаимодействие максимально асинхронным. В случае, если для страницы UI вам необходимо дернуть 5 сервисов для сбора контента — есть возможность распараллелить такой запрос сразу в API Gateway, это одна из его основных задач. Существует стремительно развивающаяся дисциплина — реактивное программирование (посмотрите Akka, RxJava). Есть немало материала на этот счет, в том числе на хабре. Короткая статья Netflix как раз на эту тему.
С другой стороны, стоит помнить, что существует два разных подхода к взаимодействию — оркестрация и хореография:
Последний позволяет решить много проблем в распределенной системе, делая узлы менее связанными, со всеми вытекающими плюсами.
Кирилл, спасибо за отзыв! Очень жду ваших докладов на JPoint.
Могу посоветовать поискать что-то подобное на вашем планшете