То есть до Inbox этим никто не занимался?
Открыл таб Promotions в gmail. Первыми двумя строками идет реклама того, что я пару часов назад искал. А только потом мои письма, которые для меня важнее рекламы.
Inbox себе такого не позволял.
Не ясно тогда, чем этот компонент от сервиса саг отличается?
Он отличается тем, что вы, например, стресс-тестируете «целевые» сервисы, а не сервис саг, на который как раз в вашей реализации и приходится большая наргрузка.
Второй момент у каждого сервиса появляется +1 хранилище.
Так вы ж там про микросервисы писали:
с помощью паттерна Database per service
Почему вдруг тут сложнее? Кроме того, кто запрещает всем компонентам использовать одну БД?
У вас сервис саг должен обновляться при изменении контракта, например, сервиса Биллинга? Один и тот же инстанс сервиса саг может использоваться другими с другими сагами?
В нашей реализации — одно из требований соблюсти 100% консистентность
Так у всех такое требование, зачем иначе то огород городить? :)
Гарантию сохранности состояния обеспечивает сервис саг с синхронной репликацией (для исключения потери данных)
А что мешает компоненту, который отвечает за сагу, использовать хранилище с репликацией?
Мне просто кажется необоснованным введение специального сервиса PG Saga. Кроме того, «общение» инициатора саги с другими сервисами становится более сложным из-за посредника.
PG Saga сервис является очень ответственным и высоконагруженным звеном, поскольку в реальности он, а не владелец саги, выполняет все запросы. Как вариант, сага может быть реализована компонентом и все шаги выполняются в самом сервисе-инициаторе саги.
Имеет смысл однозначно: граматика, словарный запас. На месте нужно будет произвести корректировку на диалект и произношение. Если знаний 0 — то будет капитально туго. Сына в 3.5 года еще в Украине обучил читать по-немецки, готовились к переезду.
Единица параллелизма в Kafka – это partition, и если очередь создается со слишком маленьким количеством partitions, отмасштабироваться будет затруднительно
Насколько я понял, перепилить partitions в продакшине — очень тяжело, почти нереально. Мне кажется, это весьма серьезное ограничение на масштабируемость.
Архитектурные решения обусловлены функциональными и не функциональными требованиями.
Будет использоваться DI или нет — это выбор программиста, а не решение, которое принимает архитектор. Это, — использовать DI, как руки мыть перед едой, какая еще архитекрута...
зависит реализация минимум половины кода приложения
Вы серьезно? Я могу поменять один DI контейнер на другой и это вряд ли повлечет за собой изменение половины кода. Только сам код конфигурациии DI, а это далеко не половина.
Примеры архитектурных решений: нужна секьюрити/не нужна, используем БД/документную/реляционную/не используем, eventual-consistency/transactional-consistency, и т.п.
Да, я в курсе. Но все же, не просто рекомендаций на любой случай жизни, а для конкретной области. Возможно, я не так выразился первый раз… Я считаю, что SOLID, это принципы дизайна кода (который я просто назвал дизайном), но не архитектурные принципы.
На практике даже данные в пямяти могут быть повреждены с тем же печальным итогом
Поскольку упомянули в статье, есть еще бездисковый (вернее, «does not rely on stable storage») алгоритм выбора лидера. Когда-то писал его реализацию. Но, все ноги растут из Паксоса :)
Открыл таб Promotions в gmail. Первыми двумя строками идет реклама того, что я пару часов назад искал. А только потом мои письма, которые для меня важнее рекламы.
Inbox себе такого не позволял.
Так вы ж там про микросервисы писали: Почему вдруг тут сложнее? Кроме того, кто запрещает всем компонентам использовать одну БД?
У вас сервис саг должен обновляться при изменении контракта, например, сервиса Биллинга? Один и тот же инстанс сервиса саг может использоваться другими с другими сагами?
Так у всех такое требование, зачем иначе то огород городить? :)
А что мешает компоненту, который отвечает за сагу, использовать хранилище с репликацией?
Мне просто кажется необоснованным введение специального сервиса PG Saga. Кроме того, «общение» инициатора саги с другими сервисами становится более сложным из-за посредника.
Насколько я понял, перепилить partitions в продакшине — очень тяжело, почти нереально. Мне кажется, это весьма серьезное ограничение на масштабируемость.
Архитектурные решения обусловлены функциональными и не функциональными требованиями.
Будет использоваться DI или нет — это выбор программиста, а не решение, которое принимает архитектор. Это, — использовать DI, как руки мыть перед едой, какая еще архитекрута...
Вы серьезно? Я могу поменять один DI контейнер на другой и это вряд ли повлечет за собой изменение половины кода. Только сам код конфигурациии DI, а это далеко не половина.
Примеры архитектурных решений: нужна секьюрити/не нужна, используем БД/документную/реляционную/не используем, eventual-consistency/transactional-consistency, и т.п.
Да, я в курсе. Но все же, не просто рекомендаций на любой случай жизни, а для конкретной области. Возможно, я не так выразился первый раз… Я считаю, что SOLID, это принципы дизайна кода (который я просто назвал дизайном), но не архитектурные принципы.
SOLID — это Design. Мне кажется, архитектура приложения лежит на более высоком уровне.
Поскольку упомянули в статье, есть еще бездисковый (вернее, «does not rely on stable storage») алгоритм выбора лидера. Когда-то писал его реализацию. Но, все ноги растут из Паксоса :)
Конечно, это выбор отдельно взятого человека/команды. Но на мой вкус — это перебор.
То есть, Linq вообще не используют?
А вот это, ИМХО, перебор, 4 локальных функции…