Микросервисы и rpc

IPC

https://docs.python.org/3/library/ipc.html

Варианты разные: Web API (банально POST запросами отправляешь данные на обработку), Message Queue (например RabbitMQ, если у тебя твой 4 Гб блок данных можно на куски разбить и не нужно все вместе вставить), tcp сокеты.

https://pythonhosted.org/Pyro4/

и зачем в этой схеме тебе микросервисы?
то, что ты хочешь получить это вместо одного скрипта — два.
а сабж вообще про другое.

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

от того, что сервисы обмениваются данными, они не начинают называться базвордом микросервисы.
отказоустойчивость с возможностью деградации и прочие опердени не сделать с двумя скриптами и 4гб файлом.

Я понял твой посыл, спасибо.

Хотя бы добиться независимости.

независимости

как? у тебя всего один сервис.
нет файла, service_transform ничего не делает — ничего не заливается в базу.
упал service_transform — ничего не заливается в базу.
упал service_load — ничего не заливается в базу.
обмазаться кешированием и поднимать всё в подах k8s на CoreOS с проверкой работоспособности. ага, осталось ещё всё на AWS перенести.
ради скрипта, который парсит файл. после такого на твою должность будут искать человека за 150к просто чтобы парсить сраный файл в базу.

как? у тебя всего один сервис.

В том то и проблема, декомпозировать не получается. Хорошо, давай строго для академической цели я скажу что

service_transform - преобразует указанный файл в нужный формат тем самым просто изменяя файл.

service_load - получает название файла который следует залить в БД.

Тогда можно назвать эти два сервиса - сервисами в рамках ETL компонента?

Я согласен с тобой, мы все любим всегда все усложнять,но я хочу разобраться в этой теме так как даже люди которые получают 200к порой не могут толком обьяснить что и почему на тему микросервисов в питоне.

Действительно, спасибо. Забыл про сокеты.

сервисами в рамках ETL компонента

если тебе не в резюме хочется про это потом написать, я предлагаю такую штуку называть современным языком — data flow
как раз недавно упомянул apache nifi, вот представь, даже ничего не нужно изобретать или писать на питоне, такого рода программные комплексы уже очень широко распространены.
просто непрерывный поток данных из большого числа источников обрабатывается до нужной кондиции с возможностью ветвления и разных получателей.

Я слышал про Nifi, но тут дело не в том что бы реализовать и тем более не для резюме, тут скорее я для себя пытаюсь понять что делают микросервисы, как взаимодействуют, а выше пример из треда я привел как пример. Из твоего предпоследнего поста я понял лишь одно, отказаустойчивость (в теории CAP это «А») и меня интересует как добиться согласованности данных при возможности разделения этих двух независимых сервисов. Они то независимые! После Замечании что ты написал, теперь эти два сервиса решают каждый свою задачу. Ну как то так, тут я просто пытаюсь вкурить тонны прочитанных статей от умных людей, так что спасибо за любую помощь.

ок, у тебя есть некие файлы, которые ты изменяешь и потом изменённые данные нужно записать в БД.
не зависимо от того сколько у тебя файлов, очевидно, что будет не прикольно, если service_transform помрёт и начнёт парсить файл по новой.
значит что? кеширование, очередь, что угодно.
первое что приходит из простого — Elasticsearch, но это для примера.
service_transform или его треды, парсят файл и кладут в очередь\кеш Elasticsearch, при падении каким-то образом начинают с того места, где померли.
service_load читает из Elasticsearch и пишет в базу.
всё, эластик имеет несколько нод для высокой доступности.
вжух и у нас что-то отказоустойчивое просто добавлением очереди, не важно каким образом эту очередь реализовать.
осталось реализовать, чтобы сами python скрипты поднимались, какой нибудь гипервизор, например скрипт в кроне, не важно.

Для питона есть какой-то celery, который все хвалят

http://www.oreilly.com/programming/free/microservices-antipatterns-and-pitfal...

Держи, не нужны тебе микросервисы.

например очищенные данные записываешь рядом (или в /tmp) с именем «${path}/.${filename}.tidy» (или генерируешь новый файл во временном каталоге) и передаешь сервису

load

$ python -m load_service --daemon
$ python -m load_service --post "{\"data\": \"/tmp/<UNIQUE-FILE-NAME>.tmp\"}"

- вторую команду вызываешь из сервиса

transform

Да спасибо, но как то все замудренно у него.

Кстати, давно хочу спросить, а что за штуковину назвали «микросервисами», которой не было еще лет 15 назад? Что-то я не припомню такого модного словечка в те времена. Может кто популярно объяснить, что это привносит нового в сайтостроение?

философию юниксвея? непонятно-как работающий комбайн-монолит (джанго) разбивают на сеть слабосвязанных мелких сервисов каждый из которых делает свою работу и не более. обычно связанных продвинутой инфраструктурой вроде nosql хранилищ, кеш-таблиц и очередей сообщений в реальном времени (с асинхронными корутинами в иолупе)

ну, с чем-то похожим сталкивался, только там был кластер на основе akka, и мы не называли микросервисами

А зачем вместо одной тяжёлой операции ты хочешь сделать две?