* Сервис-ориентированная архитектура - что это такое и зачем это нужно?
* Поиск сервисов: стандартные пути:
1) Хардкод endpoint'ов (IP:port).
+ работает
+ просто и топорно
- при росте числа сервисов начинается ад
- появляется документация, странички в вики, которые неактуальны, ночью изменения не внесешь
- при миграции серверов часто меняются эндпоинты, много лишней сопутствующей работы
2) DNS, плюсы, минусы.
+ работает
+ достаточно просто
- необходимо вносить изменения в днс
- асинхронность применения изменений
- лаг, даже при малом TTL
- при миграции серверов нужны ручные действия
- странички в вики и т.п. продолжают существовать и продолжают быть такими же неактуальными.
- при росте числа сервисов веселее не становится
* Появляются сотни сервисов. Потом тысячи. Что делать?
1) Системы управления конфигурацией.
* медленная скорость внесения изменений (минуты и часы вместо секунд)
* иногда затруднён бутстрап нового сервиса
* страничка в вики всё еще нужна
2) Системы service-discovering
* что это такое и как это работает? анонсы о сервисах, использование клиентских сервисов
+ почти реалтайм
+ не требуется страничка в документации
- сложновато для поднятия
- "а вдруг развалится?"
- в идеале требуется модификация приложения
3) Etcd + iptables/haproxy + confd
* Etcd - что это такое и как работает? Etcd vs Zookeeper
* iptables/haproxy - инкапсуляция связи между сервисами в отдельный сервис
* endpoint'ы с точки зрения приложения не меняются никогда. Приложение всегда идет в 127.0.х.y:Z, etcd+iptables+confd обеспечивают правильную связность сервисов
* если приложение хочет больше контроля, оно может ходить в etcd само
* оптимизация большого количества iptables-правил, автоматическое раскидывание правил по цепочкам в древовидном виде
4) выводы