Микросервисная архитектура - способ разграничения ответственности между компонентами системы за определённые функции. Во первых, попробуем разобраться что это такое и когда стоит вообще с этим связываться. А потом рассмотрим особенности разработки микросервисов на PHP.

2. Привет!
Меня зовут Николай
Паламарчук
Senior PHP developer
at Upwork
Больше 10 лет опыта
разработки на разных
языках и платформах

3. 1.
Микросервисы
Что это?

4. Монолит

5. Микросервисы

6. Микросервисы: определение
◎Service Oriented Architecture (SOA)
◎Процессы, которые связываются друг с
другом через сеть
◎Сервисы - маленькие
◎Протокол связи - легковесный

7. 2.
Кому нужны
микросервисы

8. Преимущества
◎Модульность
◎Масштабируемость
◎Отказоустойчивость
◎Независимость разработки
◎Continuous delivery
◎… и многое другое

9. Нужны ли Вам микросервисы?
Посмотрите на лица этих успешных людей! Разве вы
можете усомниться теперь в том, что Вам нужны
микросервисы?

10. На самом деле...
◎Микросервисы - это сложно
◎Микросервисы требуют гораздо больше
ресурсов
◎Это совершенно другая, непривычная
архитектура

11. В итоге: нет никакой разницы!

12. Не нужны!
У многих все прекрасно работает и БЕЗ микросервисов

13. Мы любим решать
сложные проблемы!
Зачем мы вообще с
этим связываемся?

14. “
И что же нам поможет?

15. Ну конечно же...

16. Или не совсем?..

17. Прямые руки
Адекватная оценка
На самом деле нам
нужна...

18. Что нам нужно понимать?
◎Чем действительно нам поможет
микросервисная архитектура
◎Какие проблемы нам придется решать
◎Хватит ли у нас ресурсов
○Денег
○Людей
○Терпения

19. В чем основные преимущества микросервисов?
◎Разделение ответственности
◎Независимость от платформы
◎Индивидуальный подход к failsafe

20. “
Микросервисная архитекрута
упростит вам поиск виновных в
падении системы
(на самом деле нет)

21. 3.
Мы используем
PHP!
Как выглядят микросервисы на
PHP?

22. Разделене сайта на подсайты
http://example.com/
Требование: скорость
http://example.com/user
Требование: отказоустойчивость
http://example.com/enterprise
Требование: отказоустойчивость и особый
защищенный функционал

23. Распределение логики
◎Вынесение общих кусков логики в
отдельные сервисы
◎Ограничение области ответственности
Например: автентификация, авторизация,
общие виджеты, получение данных и т.д.

24. Использование альтернативных платформ
◎Возможность писать отдельные сервисы
на других языках
◎Оставить на PHP то, с чем он отлично
справляетя

25. 4.
Юзкейсы,
инструменты и
их применение в
PHP
От теории - к практике!

26. Logging and
profiling

27. Logging
◎Собираем логи со всех сервисов в одном
месте
◎Отправка логов должна быть
легковесной и стабильной операцией!
◎Особенность: не нужен realtime

28. Logging: пишем в файл!
Не забываем: logrotate
Доставка логов в общее хранилище: logstash
и аналоги
Важно: общая структура полей в логах со
всех сервисов

29. Kibana!

30. Profiling
◎Собираем качественную информацию о
работе сервиса
○Количество операций
○Тайминги
○Специфические метрики
◎Особенность: realtime
◎Пишем в statsd

31. Tracing
Отслеживание цепочки
запросов

32. Tracing
Trace - граф запросов
Span - атомарная часть графа запросов
S1 S2 S3

33. Tracing
1.Генерируем уникальный trace-id (=span-
id) для первого запроса
2.Генерируем уникальные идентификаторы
span-id для каждого запроса на клиенте
3.Передаем trace-id, span-id, parent-span-
id в хедерах запроса

34. Tracing: access log
Service Trace ID Span ID Parent Span ID Message
S1 uuid1 uuid1
Incoming
request
S1 uuid1 uuid2 uuid1
Sub-request
to S2
S2 uuid1 uuid2 uuid1
Received
request
from S1
S2 uuid1 uuid3 uuid2
Sub-request
to S3
S3 uuid1 uuid3 uuid2
Received
request
from S2

35. Tracing: Zipkin

36. Context
Общая информация
для всех сервисов

37. Context
◎Аттрибуты инициатора запроса
○Remote IP
○Session ID, cookies
○trace-id
◎Аттрибуты суб-запросов
○Автентификация
○span-id, parent-span-id

38. Context: как мы это делаем
◎Пробрасываем данные в хедерах
◎Защищаем хедеры от спуфинга
○Фильтрация на фронт-балансере
○Цифровая подпись чувствительных хедеров
Для подписи хорошо подходит JSON Web
Tokens (https://jwt.io)

39. Service
discovery
Что это такое?

40. Service discovery
◎Возможность обратиться к сервису по
имени (вместо указания конкретного
инстанса)
◎Днамическое изменение списка
инстансов в зависимости от доступности
◎Балансировка запросов между
инстансами

41. Service discovery: Consul

42. Service discovery: Consul
Кроме service-discovery в consul есть:
◎REST API
◎web-интерфейс
◎key-value хранилище
◎Consul-template - динамическая
генерации файлов конфигурации
◎Использование nginx plus или haproxy в
качестве балансировщика

43. Альтернатива: Netflix-стек
◎Netflix/eureka - service discovery
◎Netflix/ribbon - load balancer
◎Netflix/archaius - аналог key-value
storage
◎Netflix/Prana - клиент всех
вышеперечисленных сервисов и “прокси”
для запросов

44. Failsafe

45. Что делать, если сервис недоступен?
◎Retry
◎Cache
◎Fallback
◎Зачем отсылать запросы на упавший
сервис? => circuit-breaker

46. Phystrix
https://github.com/odesk/phystrix
◎Inspired by Netflix/Hystrix
◎Command pattern
◎Fallback
◎Request cache
◎Request log and metrics

47. Phystrix

48. 5.
Опыт Upwork
3-й год микросервисов

49. Технологии
◎PHP: Symfony (-Zend)
◎Другие сервисы: Java, Perl, nodejs, ...
◎Consul
◎Netflix stack (Eureka, Prana, ...)
◎Nginx, Apache
◎AWS (Amazon Web Services), OpsWorks
◎Docker для разработки

50. Интересные проблемы
◎Транзакции
◎Унификация логов
◎Анализ производительности
◎Мониторинг “свежести” сервисов
◎Апгрейд глобальных фич и версии
◎Development environment

51. Спасибо!
Вопросы?
lividgreen@gmail.com
codegyre.com
Twitter: @lividgreen