Сообщение Re[6]: Микросервисы - в чем дебилизм от 13.11.2018 21:32
Изменено 13.11.2018 21:33 scf
Re[6]: Микросервисы - в чем дебилизм
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, Ночной Смотрящий, Вы писали:
scf>>>Исключительно из-за роста сложности или есть другие соображения?
НС>>Services form information barriers
scf>Вообще-то это считается преимуществом
НС>>Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
scf>Да, но эти затраты невелики и чувствительны исключительно для синхронного кода, когда запросы идут по очереди, а не параллельно.
НС>>Testing and deployment are more complicated
НС>>Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure
НС>>Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.
scf>да, сложно. да, при неправильном разбиении на микросервисы будет много боли
НС>>Ну и ссылочку еще добавлю. Оно всегда вылазит, когда мы от хипста-демок переходим к реальным энтерпрайз системам.
scf>я бы сказал, что в реальных системах consistency нужно для небольшого подмножества данных, которое и следует хранить в одной базе с транзакциями. На остальном можно сэкономить,
scf>значительно ускорив систему.
scf>Здравствуйте, Ночной Смотрящий, Вы писали:
scf>>>Исключительно из-за роста сложности или есть другие соображения?
НС>>Services form information barriers
scf>Вообще-то это считается преимуществом
НС>>Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
scf>Да, но эти затраты невелики и чувствительны исключительно для синхронного кода, когда запросы идут по очереди, а не параллельно.
НС>>Testing and deployment are more complicated
НС>>Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure
НС>>Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.
scf>да, сложно. да, при неправильном разбиении на микросервисы будет много боли
НС>>Ну и ссылочку еще добавлю. Оно всегда вылазит, когда мы от хипста-демок переходим к реальным энтерпрайз системам.
scf>я бы сказал, что в реальных системах consistency нужно для небольшого подмножества данных, которое и следует хранить в одной базе с транзакциями. На остальном можно сэкономить,
scf>значительно ускорив систему.
Re[6]: Микросервисы - в чем дебилизм
-