лонгрид

Привет!

Я наконец то прочитал и даже порисовал на бумаге. Понятное дело, что вся эта монструозная бизнес логика для меня пока остается блэк боксом ни и хер бы с ним. На данном этапе это сейчас совершенно не важно. Ибо, как ты правильно написал, микросервисная архитектура позволяет инкапсулировать логику внутри одного сервиса с фиксированным интерфейсом и как раз его уже воспринимать как блэк бокс.

Раз уже кусок логики написан на C#, то это очень круто. Никто никогда не предлагал и предлагать не будет пилить это на другом стэке технологий. В терминологии kubernetes это можно сделать external-service (что плохо, ибо зоопарк и единая точка отказа, но не смертельно) либо попробовать получить pod с контейнером на винде (хз, можно ли это, тут надо делать отдельный рисерч и собственно устраивать танцы с бубном, ибо они полюбому будут, все таки левая резьба).

Один из вариантов тупо быстро переписать эту логику (это реально быстро, если уже все сделано) на что то подходящее. Но я еще раз повторюсь, только после рисерча надо принимать решение. 

Теперь стоит поговорить, как проводить этот рисерч.

Любую бизнес логику можно реализовать, с любым стеком технологий.

Основной вопрос - локальные копии БД и их синхронизация. Что хранить (вопрос открытый и опять же таки про бизнес логику, поэтому я тут ничего говорить не буду) и как изолировать транзакции (бизнес логика) не так критичен. Тут надо решать из двух зол - rsync или async db. Это сейчас условные обозначения. Сейчас расскажу что я имею в виду.

Первое - синхронизация срезов БД с подписями (немного криптографии) чтобы мы могли гарантировать консистентность данных (вот тут мы вынуждены будем знать что мы храним и как) - плохо. Решение конфликтов крайне не тривиально и как следствие никакой изолированной микросервисной архитектуры. То есть мы сможем только БД выделить как отдельный единый слой, вот нам и точка отказа и все к херам бессмысленно.

Второе - локальные копии у всех и всегда и общий комит в итоговую “ветку”. Примерно как биткойн, только нам не надо делать proof of work и у нас закрытая сеть, так что ключи меньше и все легче само по себе. Тут другая проблема, надо строить нормальную форму данных, чтобы не гонять все настройки между нодами. Но думать в эту сторону намного перспективнее.

Еще раз, это не окончательные решения, тут надо сидеть и совместно проектировать. Критиковать и нещадно материться.

По поводу распила на микросервисы - тут все просто. Надо пилить логику по данным (изолированным) для каждого сервиса. Из описания отличным примером может быть сервис авторизации клиента и получения токенов для обращения к другим - все просто, своя хранилка, своя логика токенов, своя очередь для revoke access. Ни разу не рокет-сайнс, что вообще прекрасно.

Если решить вопрос с БД, то локальные копии и облако - ровно одно и тоже. На рабочей станции (я бы все таки думал в сторону rich-client, но можно на первых порах реплицировать всю архитектуру) это minikube, реплика в “завод” - локальный kubernetes кластер. Облако - еще один kubernetes кластер. Конфигурация одна, катится все одинаково, вообще как будто бы огонь!

Тут важно что, фиксировать взаимодействие между сервисами (протокол), лучше всего думать в сторону gRPC или jsonRPC. Стандарт де-факто везде.

Важно фиксировать обработку ошибок и метрик. Тут есть тоже стандартные решения - td-agent + capped collection mongodb + stats.d + brubeck + grafana. Легко и просто, надо только написать общую библиотеку для использования везде и всегда.

Важно фиксировать единый механихм синхронизации данных. Честно, я пока больше думаю либо про персистентные очереди или про redis. Но тут правда надо очень хорошо построить картину мира. В рамках архитектуры это будет default namespace kubernetes кластера.

Поэтому план такой.

Садимся и пишем boilerplate для микросервисов в который заворачиваем работу с HTTP, поддержку протокола (jsonRPC или gRPC) с валидацией (это важно, ибо это по сути автоматическая документация API), работу с логами, работу с метриками. Логируем все по-умолчанию (время ответа, ошибка, контекст запроса и т.д.). Метрики собираем базовые (тайминги ответов, обстук heart beat, мониторинг внешних зависимостей).

В этот же boilerplate заворачиваем шаблоны для kubernetes и для helm (пакетный менеджер для k8s, что очень упростит жизнь)

Выбор языка. Вот тут вопрос открытый. Из того, что я прочитал, нам очень нужен будет годный async i/o + параллельные вычисления. Тут два варианта из тех радаров современности: Python (отличный async i/o, нет параллельных вычислений) и Golang (для задач топчик, но больше кода, раза в полтора).

Мой выбор: golang -он строготипизированный и вообще няшный ). Вот ссылка на доку: https://golang.org/ (собирается, кстати под все платформы, и мало того, еще и в нативный код с рантаймом. Огонь!)

После того, как мы получим скелет архитектуры (логи + мониторинг + шаблон для сервисов), можно будет садиться и писать саму логику. Что круто. Выкатка тут будет в два клика, ибо все уже готово. И как следствие - быстрое тестирование и хороший QA.

Вот это все с меня. То, что я должен сделать. Плюс еще документация. Плюс еще код-ревью. Дальше - надо обсуждать. Ибо тут нет общих библиотек для работы с БД (какая она?), нет логики работы с клиентом (GUI - какой он?)

Но вот это - основа основ. Без этого и начинать не стоит, себе дороже.