Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Как владельцам облачных сервисов выйти на рынок Drupal? (Антон Шлома)DrupalYug
В своём докладе Антон Шлома рассматривает следующие вопросы:
1. Что такое облачные сервисы?
2. Микросервисная архитектура
3. API
4. Какой интерес у сервиса?
5. Целевая аудитория
6. Почему Drupal идеально подходит?
7. Семь шагов к выходу на рынок Drupal.
8. Пример работы с клиентом облачного сервиса, обзор работ и продуктов.
------------------------------------------------------------------------------------------------------------------------------
[[ О КОНФЕРЕНЦИИ ]]
DrupalCamp Краснодар 2016
Время: 9-11 сентября 2016 г.
Место: Кубанский государственный университет. Россия, г. Краснодар, ул. Ставропольская, д. 149
Сайт конференции: http://2016.drupalyug.ru
Сайт Южного Drupal-сообщества: http://drupalyug.ru
------------------------------------------------------------------------------------------------------------------------------
[[ ОРГАНИЗАТОРЫ ]]
* Кубанский государственный университет - https://www.kubsu.ru
* Агентство "SelfinPro" - http://selfin.pro
* Компания "ИнитЛаб" - https://initlab.ru
* и Команда поддержки - http://2016.drupalyug.ru/community/organizers
------------------------------------------------------------------------------------------------------------------------------
[[ СПОНСОРЫ ]]
__Золотой спонсор__
*** PAYANYWAY ***
Прием оплаты на сайте, интернет-эквайринг
Сайт: https://www.payanyway.ru
__Серебряные спонсоры__
* ГРУППА КОМПАНИЙ I20 - http://i20.biz
* EGEEK’S CONTENT - https://www.egeeks.co
__Бронзовые спонсоры__
* Z-Wolves Development
* Vakorin
* ООО "РаДон"
* Компания Портал-Юг
* Веб-студия Voodoo
* Toptal
Подробнее о спонсорах на сайте http://2016.drupalyug.ru/sponsors
Как владельцам облачных сервисов выйти на рынок Drupal? (Антон Шлома)DrupalYug
В своём докладе Антон Шлома рассматривает следующие вопросы:
1. Что такое облачные сервисы?
2. Микросервисная архитектура
3. API
4. Какой интерес у сервиса?
5. Целевая аудитория
6. Почему Drupal идеально подходит?
7. Семь шагов к выходу на рынок Drupal.
8. Пример работы с клиентом облачного сервиса, обзор работ и продуктов.
------------------------------------------------------------------------------------------------------------------------------
[[ О КОНФЕРЕНЦИИ ]]
DrupalCamp Краснодар 2016
Время: 9-11 сентября 2016 г.
Место: Кубанский государственный университет. Россия, г. Краснодар, ул. Ставропольская, д. 149
Сайт конференции: http://2016.drupalyug.ru
Сайт Южного Drupal-сообщества: http://drupalyug.ru
------------------------------------------------------------------------------------------------------------------------------
[[ ОРГАНИЗАТОРЫ ]]
* Кубанский государственный университет - https://www.kubsu.ru
* Агентство "SelfinPro" - http://selfin.pro
* Компания "ИнитЛаб" - https://initlab.ru
* и Команда поддержки - http://2016.drupalyug.ru/community/organizers
------------------------------------------------------------------------------------------------------------------------------
[[ СПОНСОРЫ ]]
__Золотой спонсор__
*** PAYANYWAY ***
Прием оплаты на сайте, интернет-эквайринг
Сайт: https://www.payanyway.ru
__Серебряные спонсоры__
* ГРУППА КОМПАНИЙ I20 - http://i20.biz
* EGEEK’S CONTENT - https://www.egeeks.co
__Бронзовые спонсоры__
* Z-Wolves Development
* Vakorin
* ООО "РаДон"
* Компания Портал-Юг
* Веб-студия Voodoo
* Toptal
Подробнее о спонсорах на сайте http://2016.drupalyug.ru/sponsors
4. Почему AngularJS, а не 1С?
Во-первых, это круто
Умные 1С-программисты — дорогие
Масштабировать 1С можно, но плохо
1С в браузере можно, но плохо
1С — очень некрасивый
5.
6.
7.
8. Что легко в 1С и сложно в AngularJS?
Таблицы и фильтрация (справочники и всё такое)
CRUD
Загрузка и выгрузка Excel
Контроль доступа
Блокировки
Промышленное оборудование
9. Как мы это делаем
Стандартные компоненты для фильтрации и таблиц
Стандартные компоненты для CRUD*
Стандартный сервис для загрузки/выгрузки Excel
Стандартный сервис аутентификации
Стандартный сервис блокировок
Творческое переосмысление работы с оборудованием
* - ещё нет
10. Распространяем через bower
Пока нет своего bower-репозитория
Собираем на teamcity, кладём в папку и раздаём по http
"dependencies": {
…
"everada-auth": "http://bower.everada.ru/ev-auth-0.1.5.zip"
}
19. Загрузка из Excel
1. Отправка файла на /excel/headers
2. Получение заголовков и разметка на модель
3. Отправка разметки и файла на /excel/map. Сервер возвращает json
4. Отправка json’а в API
20.
21.
22.
23. Пессимистичные блокировки
Блокируем на 10 минут.
Если заблокировалось:
1. Продляем при редактировании
2. Снимаем при выходе
Если не заблокировалось:
1. Пингуем блокировку каждые 10
секунд
2. Администратор всегда может
снять