- Технологическая разнородность
- Устойчивость
- Масштабирование
- Простота развертывания
- Решение организационных вопросов
- Компонуемость
- Кодовая база. Одна кодовая база, отслеживаемая в системе контроля версий, – множество развёртываний
- Зависимости. Явно объявляйте и изолируйте зависимости
- Конфигурация. Сохраняйте конфигурацию в среде выполнения
- Сторонние службы (Backing Services). Считайте сторонние службы (backing services) подключаемыми ресурсами
- Сборка, релиз, выполнение. Строго разделяйте стадии сборки и выполнения
- Процессы. Запускайте приложение как один или несколько процессов не сохраняющих внутреннее состояние (stateless)
- Привязка портов (Port binding). Экспортируйте сервисы через привязку портов
- Параллелизм. Масштабируйте приложение с помощью процессов
- Утилизируемость (Disposability). Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы
- Паритет разработки/работы приложения. Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими XI. Журналирование (Logs). Рассматривайте журнал как поток событий
- Задачи администрирования. Выполняйте задачи администрирования/управления с помощью разовых процессов
- Концепция. Следует обеспечить наличие четко воспринимаемой технической концепции системы, что поможет последней отвечать требованиям потребителей и вашей организации.
- Чуткость. Нужно чутко воспринимать влияние ваших решений на потребителей и коллег.
- Сотрудничество. Нужно взаимодействовать с как можно большим числом коллег и сотрудников, чтобы стало легче определять, уточнять и реализовывать положения концепции.
- Приспособляемость. Следует обеспечить внесение в техническую концепцию изменений в соответствии с требованиями, которые выдвигают потребители или организация.
- Автономность. Нужно найти разумный баланс между стандартизацией и возможностью автономности в работе ваших команд.
- Руководство. Следует обеспечить соответствие реализуемой системы технической концепции.
- Слабая связанность между микросервисами
- Сильное зацепление компонентов одного микросервиса
- Domain Driven Development
- Не использовать RPC так как существует привязка к языку
- Не использовать БД, так как увеличивается связность
- HTTP и REST подходят для интеграции
- AMQP и асинхронная модель идеальны, то сложны в поддержке (хореографический принцип)
- Закон Джона Постела «Будь консервативным к тому, что делаешь, будь либеральным к тому, что получаешь от других»
- Выделение микросервиса для пользовательского интерфейса
- Шаблон Дроссель (Strangler) перехватывает вызовы и направляет их в старое/новое API
- Перманентные сервисы разных версий - плохая идея
- Смело разрываем fk в базах
- Совместную статику выносим в отдельный сервис
- Совместноиспользуемые данные выносим в сервис
- Совместноиспользуемые таблицы разбиваем на таблицы для сервисов
- Распределенные транзакции (не существуют)
- Реплики для отчетов
- Никаких слепков системы
- Использовать механизмы виртуализации
+-------+ +---------+ +--------+
|Блочные| -> |Сервисные| -> |Сквозные|
+-------+ +---------+ +--------+
- Контракты, составленные на основе запросов потребителей вместо сквозных
- Дымовые тесты (на проде сразу после запуска, параллельно со старой версией)
- Канареечный выпуск (постепенно переводить запросы на новую версию)
- Сине-зеленый деплой
- Мониторинг на основе журнала событий (логи)
- Рабочие показатели сервисов
- Семантический мониторинг посредством искусственных транзакций
- отслеживайте как минимум возвращающееся время отклика. Затем займитесь частотой появления ошибок, после чего приступайте к работе над показателями на уровне приложения;
- отслеживайте приемлемость всех ответов от нижестоящих сервисов, включая как минимум время отклика при вызовах нижестоящих сервисов, а в лучшем случае — частоту появления ошибок. Помочь в этом могут такие библиотеки, как Hystrix;
- приведите к общему стандарту способ и место сбора показателей;
- помещайте регистрационные записи в стандартном месте и по возможности используйте для них стандартный формат. Если для каждого сервиса будут применяться разные форматы, объединение будет сильно затруднено;
- отслеживайте показатели исходной операционной системы, чтобы можно было выявлять отклоняющиеся от нормы процессы и планировать использование ресурсов. Для системы:
- объединяйте показатели на уровне хоста, например показатели загруженности центрального процессора с показателями на уровне приложения;
- выбирайте такие инструменты хранения показателей, которые позволяют выполнять их объединение на системном или сервисном уровне и извлекать их для отдельно взятых хостов;
- выбирайте такие инструменты хранения показателей, которые позволяют сохранять данные достаточно долго для того, чтобы можно было отследить тенденции в работе вашей системы;
- используйте для объединения и хранения регистрационных записей единое средство, поддерживающее обработку запросов;
- строго придерживайтесь стандартизации при использовании идентификаторов взаимосвязанности;
- разберитесь, чему для перехода к действию требуется вызов, и выстройте соответствующим образом структуру оповещения и вывода на панель отслеживания;
- исследуйте возможность унификации способов объединения всевозможных показателей, выяснив, пригодятся ли вам для этого такие средства, как Suro или Riemann.
- Закрытые контуры
- Авторизация в клиенских сервисах
- Шифрование
«Организации, проектирующие системы, неизбежно производят конструкцию, чья структура является копией структуры взаимодействия внутри самой организации
- Команды разработки функций
- Семейственный открытый код и кураторы
- Disaster Recovery Test
- Таймауты
- Предохранители - моментально отдает код для неработающего сервиса
- Переборки (Circuit Breaker)
- Идемпотентность
- Балансировка
- Реплики чтения для БД
- Фрагментация БД для записи
- Кэширование
- Обнаружение сервисов (например Consul)
- Swagger документация