Зачем нужны зоны (zones) в микросервисной архитектуре?

Давай разжую эту тему про зоны, чтобы было понятно даже тому, кто только вчера узнал, что облако — это не только на небе.

Представь, что твои микросервисы — это общага. Если всех студентов-сервисов запихнуть в одну комнату, то при пожаре (отказе железа или сети) сгорит всё и сразу, ёпта. Зоны — это как разные корпуса или даже этажи. Пожар в одном — остальные пока стоят и могут работать, пока пожарных вызывают.

Зачем это всё, спросишь? Да похуй, спрашивай или нет, а я расскажу.

1. Чтобы не накрыться медным тазом. Это главная причина. Кладешь копии своего сервиса в разные физические зоны доступности (AZ). Одна зона — отрубилось электричество, сеть легла, хрен знает что. А твой сервис в другой зоне себе пыхтит дальше, и пользователи даже не заметят, если всё настроено правильно. В Kubernetes, например, можно так настроить, чтобы он сам раскидывал поды (это такие контейнеры) по разным зонам, как умный завхоз.

2. Чтобы не ждать ответа как дурак. Если два сервиса должны общаться быстро-быстро, их лучше поселить в одну зону. Тогда они друг другу «шепчут на ушко» по внутренней сети, а не «кричат через улицу» между дата-центрами. А пользователей из Питера можно сразу направлять в питерскую зону, а не гонять их запросы через Москву — задержка будет охуенно меньше.

3. Для хитрой жопы (читай: изоляции).

   • Безопасность: У тебя есть сервис, который с деньгами работает. Его, пидараса шерстяного, надо от всех остальных отгородить капитально. Сажаешь его в отдельную, максимально защищённую зону, где свои правила доступа — и спишь чуть спокойнее.
   • Важность: Критичный для бизнеса сервис (например, оплата) ты размножаешь по всем зонам, как кроликов. А какой-нибудь внутренний сервис отчётов, который раз в месяц запускается, может и в одной зоне сидеть — да похуй.
   • Закон: Если данные по закону должны из Европы не выезжать, то ты их и крутишь только в европейских зонах. Нарушишь — будет вам хиросима и нигерсраки от регуляторов.

Вот смотри, как это в кубере (Kubernetes) примерно выглядит:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cart-service
spec:
  replicas: 6 # Допустим, хотим 2 пода на каждую из 3-х зон
  selector:
    matchLabels:
      app: cart
  template:
    metadata:
      labels:
        app: cart
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - cart
              topologyKey: topology.kubernetes.io/zone # Вот эта штука — магия! Говорит куберу: «Раскидывай их по разным зонам!»
      containers:
      - name: cart
        image: my-registry/cart-service:v1.2.3
---
apiVersion: v1
kind: Service
metadata:
  name: cart-service
spec:
  selector:
    app: cart
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer
  externalTrafficPolicy: Local # Чтоб трафик не мотался туда-сюда между зонами, а обрабатывался там, где приняли

А есть ещё архитектурные финты:

• Active-Active: Все зоны работают одновременно, как пчёлы. Трафик между ними делится. Красота, отказоустойчивость овердохуища.
• Active-Passive (Тёплый запас): Основная нагрузка в одной зоне, а в другой тихонько дрыхнет минимальная копия на всякий пожарный. Если основная зона накрылась, резервную быстро будят и масштабируют. Дешевле, но переключение не мгновенное.

Короче, если не думать о зонах при проектировании, то можно получить пизда рулю в самый неподходящий момент. Это не просто модное слово, а базовый кирпич в постройке чего-то живучого в облаке. Э, бошка, думай!