Александр Трехлебов — Микросервисы — отказоустойчивость на основе сквозной модульности

Рассмотрим сразу case, когда на одном SPA (single page application) работает несколько независимых интерфейсных элементов (например internet-банк), когда каждый элемент не заваливает при падении соседний.
- Микросервисы появились не вчера. Как технологии для распределённых вычислений пошли в массы.
- Значение перехода от полной виртуализации к linux-контейнерам. И конечно Docker.
- Основные компоненты микросервисной архитектуры.
- Как это чаще всего делают на .net, nginx, java.
- Особая роль оркестрации контейнеров.
- 700Мб памяти только чтобы поднять небольшой CRUD для одной бизнес-сущности? Зачем всё это?
- mutable и immutable подход к обновлению функционала

Основные плюсы по моему мнению:
- раздельный deploy (полное избавление от релизного расписания - это миф, но кое-что возможно)
- масштабирование
- отказоустойчивость (автоматический запуск дополнительного экземпляра)
- простое разделение доступа для мобильного приложения, для интернет-портала, инТРАнет-портала, для системного взаимодействия
- независимость от среды (dev, test, stage, prod)
- одновременно могут работать модули на разных языках.

Взаимодействие между микросервисами:
- синхрон (Rest)
- асинхрон (очереди)
- комбинирование для circuitbreaker (автомат на электрощитке)

Облака:
- от Iaas к Paas (Kubernetes, CloudFoundry, Google Platform и др.

Системы мониторинга:
- ElasticSearch.

Когда монолит, всё же лучше.

---

Александр Трехлебов
Корпоративный архитектор, Промсвязьбанк

В банктехе с 2012 года. Начинал с большого проекта по интеграции в банке «Открытие». В Промсвязьбанк пришёл в 2014-ом, занимался BPM на базе open-source, потом SpringBoot, микросервисы, облака (OpenShift, CloudFoundry). Сейчас корпоративный архитектор.