Форум PHP программистов > Микросервисная архитектура

[ Поиск ] - [ Пользователи ] - [ Календарь ]

Полная Версия: Микросервисная архитектура

Страницы: 1, 2

AllesKlar

22.11.2017 - 20:48

Ща еще более страшную вещь скажу:
Человеческая психология такова, что, когда мы говорим "Человеческая психология такова", то имеем ввиду именно свою психологию, т.к. в общечеловеческой мы дилетанты.

В подтверждении к сему, мы имеем уже 3 (три) чисто субъективных мнения, от VeRTak, от
AllesKlar и от Ron, каждый из которых продемонстрировал, как он воспринимает информацию будучи в той или иной области новичком.

Я вот, ныне, закопался в микросервисы. Серьёзно так закопался. Читаю умные книги от дядюшки Сэма Ньюмена, смотрю конференции, поглядываю на форумы.
Так вот для меня, как новичка в данной теме, именно Сэм Ньюмен и докладчик по имени Вадим Мадисон из компании М-Тех на конференции HighLoad++ https://www.youtube.com/watch?v=MBZtcNgDXzU были экспертами.

Но так же, я перечитал, пересмотрел укучу материала под девизом: Как быстро и легко развернуть микросервисную архетектуру (тесты - потом. Мониториг - может быть, пока в логи пишем, автоматическое развертывание - ой, да руками делов полчаса и т.д.). Да, быстро, да легко, но мне не нужно ни быстро, ни легко, мне нужно стабильно и легко-масштабируемо.

P.S. кстати, есть у кого опыт? У меня пара сотен вопросов по теме

_____________
[продано копирайтерам]

AllesKlar

27.11.2017 - 05:54

Santehnick Ничесе ты неосторожно так сказал
Я ж теперь тебя по ip вычислю и не отсосусь, пока весь наш монолит не распилю, в кошмарах ночных приходить буду

Цитата (Santehnick @ 27.11.2017 - 03:22)

Вроде на той же конференции был доклад из hh какую боль они испытали с микросервисами.

Это? https://www.youtube.com/watch?v=7WT_Rl6m2DU
Пошел смотреть.
Открою позже тему, там начну с общей картины, что есть и что планируется, и стОит ли это вообще делать.

_____________
[продано копирайтерам]

twin

28.11.2017 - 09:45

Цитата (Santehnick @ 27.11.2017 - 20:24)

Если делать так как описывал микросервисы Фаулер, то каждый сервис должен иметь свою БД.

Разве? Как я понял не должен, а должен иметь возможность использовать свою БД. это как бы немного разные вещи.

Цитата

Of course, just because you can do something, doesn't mean you should - but partitioning your system in this way means you have the option

Отсюда.

Цитата

Microservices prefer letting each service manage its own database, either different instances of the same database technology

Здесь.

И он даже картинку нарисовал:

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image

AllesKlar

28.11.2017 - 13:35

Santehnick Нет, shared-db - это не наш путь.
Спасибо за ссыль, вечером посмотрю

twin Нет четкого понятия микросервисов. Есть путь проб и ошибок и деления опытом. так вот shared-db - это самый фиговый путь, т.к. сама идея микросервиса - самодостаточность.

Если сервис A и сервис B используют одну таблицу, и разработчик сервиса A изменил структуру таблицы, то нет никакой гарантии, что сервис B сможет дальше работать.
А это уже тот же монолит, только в профиль

_____________
[продано копирайтерам]

twin

28.11.2017 - 15:35

Цитата (AllesKlar @ 28.11.2017 - 09:35)

Если сервис A и сервис B используют одну таблицу, и разработчик сервиса A изменил структуру таблицы, то нет никакой гарантии, что сервис B сможет дальше работать.

Не думаю, что в этом дело. Сервисы так или иначе взаимодействуют друг с другом. Базу тоже можно представить как микросервис.

Какая разница, изменишь ты таблицу в базе, или что то в API сервиса, все равно все поплывет. Без соглашений и обратной совместимости никуда не денешься. Тут причина другая. Скорее всего чисто идейная.

Что я успел почитать про микросервисы, у меня особого восторга не вызвало. Из-за радикализма.

Не люблю крайностей. Хотя SOA в общем виде мне давно импонирует, я об этом говорил неоднократно.

Но это так, имхо, мысли вслух.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image

AllesKlar

29.11.2017 - 01:53

Цитата (Santehnick @ 28.11.2017 - 19:45)

Сохраняем сущность вместе с её событиями как единый документ

Да, такой подход я встречал в продакшене у кого-то, смотрел конференцию, не могу пока найти. Поищу.

И вот еще один интересный вариант с очередями. Мне очень нравится. Единственное, чего я там не увидел (возможно, плохо смотрел), что если транзакция так и не смогла закончится, то где "хранилище событий, которые не могут быть завершены". Дабы, после восстановления/фикса дать волшебного пинка и перезапустить их.
https://youtu.be/HDq1KQT51kM?t=1450

Ну, и так же, не плохо сказал Сэм Ньюмен в своей книге "Создание микросервисов" (глава 5, Распределенные транзакции) (слегка утопически, но направление, на мой взгляд верное).
Транзакции - плохо, сделай всё, чтобы в транзакциях не возникла необходимость

Свернутый текст

Все эти решения усложняют систему. Как видите, разобраться в распределенных
транзакциях довольно трудно и фактически они могут воспрепятствовать мас-
штабированию. О системах, которые в конечном итоге сводятся к компенсацион-
ной логике повторов, труднее рассуждать, и для устранения несогласованности
данных они могут нуждаться в ином компенсационном поведении.
Когда вам встречаются бизнес-операции, проводимые в данный момент в рамках
единой транзакции, задайте себе вопрос, действительно ли они должны это делать.
Не могут ли они проводиться в различных локальных транзакциях и полагаться на концепцию возможной согласованности? Создавать такие системы и занимать-
ся их масштабированием намного проще (более подробно этот вопрос рассматри-
вается в главе 11).
Если попадется такое состояние, необходимость в согласованности которого
не вызывает никаких сомнений, то в первую очередь сделайте все возможное,
чтобы избежать разбиения. Приложите для этого все усилия. Если же разбиения
будет не избежать, подумайте об изменении чисто технического взгляда на про-
цесс (например, транзакции в базе данных) и создайте конкретные понятия,
представляющие саму транзакцию. Это даст вам возможность зацепиться за
запуск других операций, подобных компенсационным транзакциям, а также за
способ отслеживания этих более сложных понятий в вашей системе и управления
ими. Например, можно прийти к идее незавершенного заказа, которая даст вам
реальное место для концентрации всей логики вокруг сквозной обработки зака-
за (и работы с исключениями).

А вообще, ты мне слишком рано задаешь вопросы

Я еще ни строчки кода про микросервисы не написал, пока только изучаю,
Более того, никто на фирме ими заниматься не хочет, более того, запрещают

Я революцию готовлю, медленно, но верно.

_____________
[продано копирайтерам]

AllesKlar

29.11.2017 - 02:03

Цитата (Santehnick @ 28.11.2017 - 23:27)

Цитата (twin @ 28.11.2017 - 11:35)

Какая разница, изменишь ты таблицу в базе, или что то в API сервиса, все равно все поплывет.

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

<pre class="sh_sourceCode" rel="php">
OrderService.getQuery('SELECT ...');
</pre>

Если начинать с домена, такого не будет. Спрятавшись за интерфейсом теперь можно делать что угодно не боясь кому-то что-то поломать. С shared database так не получится.

Добавлю. (опять же, пока из теории)

В API микросервиса стоИт версия его схемы (интефейса).
И, когда хочется изменить API сервиса, то проходим 3 этапа:

// имеем схему API v.1.1.0
{
  "response": {
     "id": 123,
     "name": "Ivan"
  },
  "shema": "v.1.1.0"
}


//выпускаем  расширенную версию схемы API v.1.2.0
{
  "response": {
     "id": 123,
     "name": "Ivan",
     "firstName": "Ivan",
     "lastName": "Petrov"
  },
  "shema": "v.1.2.0"
}


//после того, как отвалился последний потребитель схемы v.1.1.0 выпиливаем ее из v.1.2.0  и переименовываем в v.2.0.0
{
  "response": {
     "id": 123,
     "firstName": "Ivan",
     "lastName": "Petrov"
  },
  "shema": "v.2.0.0"
}

Либо еще один интересный вариант, встреченный мной:

Стандартный (полный/переходный) ответ сервиса:

{
  "response": {
     "id": 123,
     "name": "Ivan",
     "firstName": "Ivan",
     "lastName": "Petrov"
  }
}

В запросе к сервису передается схема

{
  "request": {
    "id": 123
  },
  "shema": ["id","name"]
}

Ответ сервиса:

{
  "response": {
     "id": 123,
     "name": "Ivan",
  }
}

Таким образом, команда, которая занимается конкретным сервисом, больше не привязана к командам, разрабатывающим потребителей этого сервиса, и может дальше деплоить новые фичи.
И т.к. сама идея микро-сервиса, это именно МИКРО, то перепилить его API это дело нескольких часов.
Если это дело нескольких дней, значит пересматриваем архитектуру.

_____________
[продано копирайтерам]

Быстрый ответ:

Здесь расположена полная версия этой страницы.