А когда это получение значения из hashmap имеет сложность o(n)? Или что значит фраза " Вставка и получение элементов имеют имеют сложность O(1) или О(n), или O(logN)"?
Хм, похоже, вы просто не понимаете, что такое POS. Он не отправляет никакой информации об оплате. Процесс оплаты вообще происходит довольно далеко от POS. Лучше не использовать примеры из областей, в которых не разбираетесь.
Я не очень понимаю, откуда взялось противопоставление "сообщений" и "формата". Сообщения - всегда в каком-то конкретном протоколе, в конкретном формате и содержат конкретную семантику. И ООП, в том числе, и об этом. И как раз про это и пишут основатели ООП.
Pos терминал имеет дело с конкретным форматом записи на карте (чип), поддерживает сложный протокол для работы с этим чипом (ISO 8583, загрузка ключей, работа с сеансами и так далее). И без этой жесткой логики, описывающей сообщения как от эквайера к POS, так и взаимодействие POS и карты - никакие платежи по карте невозможны. При этом весь обмен от банковской карты и до банка-эмитента жестко описаны документацией в несколько тысяч страниц. И, в рамках ООП, карта, POS, софт эквайера, софт эмитента, софт ПС - как раз объекты, обменивающиеся сообщениями. При этом форматы (типы) сообщений жестко описаны, а вот сама логика - да, может быть очень гибкой. Собственно, в этом и есть смысл ООП 2. Кажется, вы не понимаете не только принципы работы POSов, но и ООП и процессы передачи сообщений. Благо уж по ООП много литературы и там описано и что такое сообщение и что такое объект. Собственно, о том, что вы не очень разбираетесь в ООП - уже написало довольно много человек.
В теории - да, в Redis Cluster есть шардинг. Но в реальном использовании там все не так просто и масштабирование нужно делать очень аккуратно, при этом еще и справляясь с кучей ограничений кластера. Внутренний на хазелкасте - масштабируется примерно так же, чуть сложнее для программиста, чуть проще для админа, разница не принципиальна.
Но, в любом случае, горизонтальное масштабирование не зависит от того, внутренний или внешний кэш.
Медианный latency внутреннего кэша примерно на два-четыре десятичных порядка меньше, чем доступ через сеть, хотя реальные значения зависят от множества параметров (как ни странно, нигде не увидел актуальных данных по latency доступа к современной серверной памяти и сетевых задержек внутри современного ДЦ). На надо помнить, что для сети какой-нибудь 99.99 персентиль будет много выше медианы и может легко доходить до десятков ms, а время доступа к локальной памяти гораздо меньше подвержено флуктуациям.
Нет никакой произвольности на POS-терминале. Там есть очень жесткий протокол, все возможные обработки которого (для VISA/MC/etc) жестко описаны. Нет возможности в POSе использовать вместо банковской карты - какую-то другую (например, телефонную). В реальном мире (и в проектировании) как раз сообщения, которые может обработать объект - всегда жестко специфицированы. И ООП - как раз про это.
Очень странная идея. Идея как раз в том, что для объекта известно, какие именно сообщения он может обрабатывать, но не известно, как именно. Если структура сообщения неизвестна получателю, то как он может его обработать?
Вообще для отправки сообщений не нужны никакие очереди, сообщения могут отправляться (и обрабатываться) и мгновенно (как в http или в том же Smalltalk). ООП никак не противоречит системам реального времени, более того, активно в них используется.
Хм, вообще в ООП как раз тип сообщения - известен. ООП (еще со времен smalltalk) про объединение данных и методов с ними работы. Методы работы - да, можно описывать как отправку сообщений. Важно, что у конкретного объекта известно, какие сообщения он может принимать и при отправке - не важно и даже не известно, как именно они будут обрабатываться. IoC - это поздний паттерн, ООП может быть и без IoC.
А почему "внутренний кэш" мешает горизонтальному масштабированию, а внешний - "легко горизонтально масштабируется"? Это совершенно не верно, тип кэша никак не связан с простотой масштабирования. Более того, все приведенные примеры для внешних кэшей (Тарантул, Редис) не масштабируются горизонтально. А вот вполне себе внутренний Хазелкаст - как раз масштабируется.
И подобных неточностей в статье довольно много, кажется, что автор не очень хорошо понимает, как и для чего нужно кэширование и просто пересказывает википедию. Для студента или стажера - достаточно. Для миддла - уже категорически недостаточно информации и понимания. К сожалению, в статье нигде не указано, что она для студентов.
В статье очень много как опечаток и неточностей, так и фактических ошибок и неверных советов. Для практической работы - статья скорее вредная. Для прохождения собеседований - может помочь, если собеседующий тоже никогда не занимался системным дизайном.
Такой нет и быть, увы, не может. Системный дизайн - не какая-то дисциплина, а просто тип собеседований в некоторых компаниях. Есть литература по архитектуре, есть много разных практик по конкретным направлениям, но все это недостаточно для даже очень базовой практики.
Тебе для проектирования или для прохождения интервью? Обычно книжки, пригодные для одного - не пригодны для другого. Фундаментальных книг, увы, нет, так как нет фундамента. Есть множество книжек по архитектуре, но все они бесполезны без реального практического опыта (да и с ним далеко не все полезны). Для собеседований - надо читать ту книжку, которую читал конкретный интервьюер. Обычно это Алекс Чу. Для реальной работы книжки по интервью - бесполезны (скорее даже вредны)
Хм, очень странная мыль, что у компании-владельца нет изолированных процессов ) Вот у банка эмиссия и эквайринг - чем связаны? Вот внутри T-банка продукт "доступ к бизнес-залам" как связан с остальными продуктами? Там общих данных - clientId и все.
Я не увидел там аргументации за МСА. Поправь, но я видел следующий набор утверждений 1) Проблемы легаси в процессах и людях 2) При внедрении МСА придется перестраивать и процессы и людей 3) Поэтому в МСА лучше с частотой выкладки.
Первое и второе утверждение - верны. Но вот пункт 3 никак и неоткуда не следует. И ниоткуда не следует, что переписать проект на модульный монолит или другой арх.стиль не решит тех же проблем с людьми и сервисами.
Хм, а где тут "один продукт"? И, заметим, тут все равно ты пишешь про примерно 100 человек, которые занимались этим софтом.
И да, я проводил довольно много разных арх.рефакторингов в очень разных окружениях. Да, это сложно. Но вполне реализуемо и внутри монолита. Но да, проблемы - не инженерные, а процессные в первую очередь. И решаются на этом уровне. А МСА - не при чем.
Так переписывание на другой монолит решит ровно те же проблемы (или не решит, так как менеджеры те же самые и разработчики те же самые и архитекторы те же самые - откуда изменение-то будет?) В любом случае для решения проблемы "релиз занимает 3 года" нужно перестраивать всю компанию (начиная от бизнеса, кстати). И какой там будет арх.стиль внутри - пофиг.
Хм, почему-то у меня были монолиты, в которых автотесты покрывали все бизнес-функции и отрабатывали за единицы часов. Тестировать монолит - проще, нежели распределенную систему. И если почему-то не справились даже с тестами для монолита - то тем более не справятся с тестом распределенной системы.
А когда это получение значения из hashmap имеет сложность o(n)?
Или что значит фраза " Вставка и получение элементов имеют имеют сложность O(1) или О(n), или O(logN)"?
Вы описали скорее Канбан. К Скраму указанный подход не имеет никакого отношения (благодаря чему, скорее всего, и удалось получить пользу).
Не совсем понятно, каким образом формат противоречит гибкости? Ровно наоборот...
Хм, похоже, вы просто не понимаете, что такое POS. Он не отправляет никакой информации об оплате. Процесс оплаты вообще происходит довольно далеко от POS. Лучше не использовать примеры из областей, в которых не разбираетесь.
Я не очень понимаю, откуда взялось противопоставление "сообщений" и "формата". Сообщения - всегда в каком-то конкретном протоколе, в конкретном формате и содержат конкретную семантику. И ООП, в том числе, и об этом. И как раз про это и пишут основатели ООП.
Pos терминал имеет дело с конкретным форматом записи на карте (чип), поддерживает сложный протокол для работы с этим чипом (ISO 8583, загрузка ключей, работа с сеансами и так далее). И без этой жесткой логики, описывающей сообщения как от эквайера к POS, так и взаимодействие POS и карты - никакие платежи по карте невозможны. При этом весь обмен от банковской карты и до банка-эмитента жестко описаны документацией в несколько тысяч страниц.
И, в рамках ООП, карта, POS, софт эквайера, софт эмитента, софт ПС - как раз объекты, обменивающиеся сообщениями. При этом форматы (типы) сообщений жестко описаны, а вот сама логика - да, может быть очень гибкой. Собственно, в этом и есть смысл ООП
2. Кажется, вы не понимаете не только принципы работы POSов, но и ООП и процессы передачи сообщений. Благо уж по ООП много литературы и там описано и что такое сообщение и что такое объект.
Собственно, о том, что вы не очень разбираетесь в ООП - уже написало довольно много человек.
В теории - да, в Redis Cluster есть шардинг. Но в реальном использовании там все не так просто и масштабирование нужно делать очень аккуратно, при этом еще и справляясь с кучей ограничений кластера. Внутренний на хазелкасте - масштабируется примерно так же, чуть сложнее для программиста, чуть проще для админа, разница не принципиальна.
Но, в любом случае, горизонтальное масштабирование не зависит от того, внутренний или внешний кэш.
Медианный latency внутреннего кэша примерно на два-четыре десятичных порядка меньше, чем доступ через сеть, хотя реальные значения зависят от множества параметров (как ни странно, нигде не увидел актуальных данных по latency доступа к современной серверной памяти и сетевых задержек внутри современного ДЦ).
На надо помнить, что для сети какой-нибудь 99.99 персентиль будет много выше медианы и может легко доходить до десятков ms, а время доступа к локальной памяти гораздо меньше подвержено флуктуациям.
Нет никакой произвольности на POS-терминале. Там есть очень жесткий протокол, все возможные обработки которого (для VISA/MC/etc) жестко описаны. Нет возможности в POSе использовать вместо банковской карты - какую-то другую (например, телефонную).
В реальном мире (и в проектировании) как раз сообщения, которые может обработать объект - всегда жестко специфицированы. И ООП - как раз про это.
Очень странная идея. Идея как раз в том, что для объекта известно, какие именно сообщения он может обрабатывать, но не известно, как именно. Если структура сообщения неизвестна получателю, то как он может его обработать?
Вообще для отправки сообщений не нужны никакие очереди, сообщения могут отправляться (и обрабатываться) и мгновенно (как в http или в том же Smalltalk).
ООП никак не противоречит системам реального времени, более того, активно в них используется.
Хм, вообще в ООП как раз тип сообщения - известен. ООП (еще со времен smalltalk) про объединение данных и методов с ними работы. Методы работы - да, можно описывать как отправку сообщений. Важно, что у конкретного объекта известно, какие сообщения он может принимать и при отправке - не важно и даже не известно, как именно они будут обрабатываться.
IoC - это поздний паттерн, ООП может быть и без IoC.
А почему "внутренний кэш" мешает горизонтальному масштабированию, а внешний - "легко горизонтально масштабируется"? Это совершенно не верно, тип кэша никак не связан с простотой масштабирования. Более того, все приведенные примеры для внешних кэшей (Тарантул, Редис) не масштабируются горизонтально. А вот вполне себе внутренний Хазелкаст - как раз масштабируется.
И подобных неточностей в статье довольно много, кажется, что автор не очень хорошо понимает, как и для чего нужно кэширование и просто пересказывает википедию. Для студента или стажера - достаточно. Для миддла - уже категорически недостаточно информации и понимания. К сожалению, в статье нигде не указано, что она для студентов.
В статье очень много как опечаток и неточностей, так и фактических ошибок и неверных советов. Для практической работы - статья скорее вредная.
Для прохождения собеседований - может помочь, если собеседующий тоже никогда не занимался системным дизайном.
Такой нет и быть, увы, не может. Системный дизайн - не какая-то дисциплина, а просто тип собеседований в некоторых компаниях.
Есть литература по архитектуре, есть много разных практик по конкретным направлениям, но все это недостаточно для даже очень базовой практики.
Тебе для проектирования или для прохождения интервью? Обычно книжки, пригодные для одного - не пригодны для другого.
Фундаментальных книг, увы, нет, так как нет фундамента. Есть множество книжек по архитектуре, но все они бесполезны без реального практического опыта (да и с ним далеко не все полезны).
Для собеседований - надо читать ту книжку, которую читал конкретный интервьюер. Обычно это Алекс Чу. Для реальной работы книжки по интервью - бесполезны (скорее даже вредны)
Понятно, никаких аргументов нет.
Хм, очень странная мыль, что у компании-владельца нет изолированных процессов )
Вот у банка эмиссия и эквайринг - чем связаны?
Вот внутри T-банка продукт "доступ к бизнес-залам" как связан с остальными продуктами? Там общих данных - clientId и все.
Я не увидел там аргументации за МСА. Поправь, но я видел следующий набор утверждений
1) Проблемы легаси в процессах и людях
2) При внедрении МСА придется перестраивать и процессы и людей
3) Поэтому в МСА лучше с частотой выкладки.
Первое и второе утверждение - верны.
Но вот пункт 3 никак и неоткуда не следует. И ниоткуда не следует, что переписать проект на модульный монолит или другой арх.стиль не решит тех же проблем с людьми и сервисами.
Хм, а где тут "один продукт"? И, заметим, тут все равно ты пишешь про примерно 100 человек, которые занимались этим софтом.
И да, я проводил довольно много разных арх.рефакторингов в очень разных окружениях. Да, это сложно. Но вполне реализуемо и внутри монолита. Но да, проблемы - не инженерные, а процессные в первую очередь. И решаются на этом уровне. А МСА - не при чем.
И, кстати, не думаю, что у меня меньше опыта )
Так переписывание на другой монолит решит ровно те же проблемы (или не решит, так как менеджеры те же самые и разработчики те же самые и архитекторы те же самые - откуда изменение-то будет?)
В любом случае для решения проблемы "релиз занимает 3 года" нужно перестраивать всю компанию (начиная от бизнеса, кстати). И какой там будет арх.стиль внутри - пофиг.
Хм, почему-то у меня были монолиты, в которых автотесты покрывали все бизнес-функции и отрабатывали за единицы часов.
Тестировать монолит - проще, нежели распределенную систему. И если почему-то не справились даже с тестами для монолита - то тем более не справятся с тестом распределенной системы.