Понимаю, что слоупок, прозевал революцию и т.д. Предлагаю обсудить парадигму микросервисов (как её описал Мартин Фаулер) в практическом применении. У кого есть опыт покупки IaaS, настройки этого в кластер EMR, какой планировщик задач использовался (самописный или Apache Spark или что-то ещё)?
Здравствуйте, Тёмчик, Вы писали:
Тё>Понимаю, что слоупок, прозевал революцию и т.д. Предлагаю обсудить парадигму микросервисов (как её описал Мартин Фаулер) в практическом применении. У кого есть опыт покупки IaaS, настройки этого в кластер EMR, какой планировщик задач использовался (самописный или Apache Spark или что-то ещё)?
Прошу прощения, но такое чувство, что тему создавали при помощи какого то bullshit bingo или автореферата... Как все названные слова и термины связаны в вашем понимании?
Здравствуйте, Тёмчик, Вы писали:
Тё>Понимаю, что слоупок, прозевал революцию и т.д. Предлагаю обсудить парадигму микросервисов (как её описал Мартин Фаулер) в практическом применении.
Ну если фаулера...
Фаулер... До него было linux way app development, COM/CORBA, dbus и т.п. не особо понимаю что нового предложил Фаулер кроме переосмысления известных концепций в рамках несколько иной задачи.
По мне так микросервисы на основе Erlang+rabbitmq довольно красиво сомтрится.
Здравствуйте, Kernan, Вы писали:
K>Фаулер... До него было linux way app development, COM/CORBA, dbus и т.п. не особо понимаю что нового предложил Фаулер кроме переосмысления известных концепций в рамках несколько иной задачи. K>По мне так микросервисы на основе Erlang+rabbitmq довольно красиво сомтрится.
Не важно, какая message bus и какой язык. Надо чтоб в облаках, куча микросервисов, лямбда, эластик, кафка или аналоги, спарк или аналоги и т.д. Надо ещё вчера. Купил в киндле "Building Microservices: Designing Fine-Grained Systems" Сэма Ньюмана, читать до просветления.
Здравствуйте, Тёмчик, Вы писали:
Тё>Понимаю, что слоупок, прозевал революцию и т.д. Предлагаю обсудить парадигму микросервисов (как её описал Мартин Фаулер) в практическом применении.
У Мартина Фаулера есть хорошие книги, вроде "Архитектура корпоративных программных приложений" в которой нет ни слова про микросервисы. Понятное дело в "UML Основы Краткое руководство по унифицированному языку моделирования" и других книгах вряд ли что тоже будет. Но у нас же есть гугл, а он говорит, что речь идёт об этой статье.
Моё мнение, что по сравнению с книгой "Архитектура корпоративных программных приложений" у них там представлен краткий обзор, который вряд ли поймёт тот, кто не в теме, а я вижу это так. В нашем мире есть объекты (сущности) и действия над ними. Объект может воздействовать как на себя, так и на другой объект, во всяком случае именно так это себе представляют люди. С одной стороны мы имеем существительные (сущность), с другой глаголы (действия).
Соответственно для связи используется два подхода, это передача данных и функций. В одном случае мы передаём данные самого объекта, это поля и прочие ресурсы, в другом функции, для экземпляров класса это будут методы и так далее. Теперь о том, какие технологии вошли в первую и во вторую группу:
И так далее. Взять тот же HTTP, сразу видно, что он входит в первую группу, но есть важное отличие, мы обсуждаем не вообще всё, что есть и привязывается к принципу CRUD, хотя для общего понимания я и впихнул сюда его, а так же SQL, а то, что хоть как-то связано с архитектурой приложений.
Раз уж мы заговорили о Мартине Фаулере, который писал так же и об UML, обязательно стоит упомянуть OMG.
BPMN — графическая нотация для моделирования бизнес процессов.
MDA — концепция модельно ориентированного подхода к разработке программного обеспечения
Meta-Object Facility
UML — язык графического описания для объектного моделирования
XMI — стандарт для обмена метаданными с помощью языка XML.
CWM
CORBA
IDL — язык описания интерфейсов
IIOP
DDS
Object Management Architecture (OMA)
Возможно кому-то было бы интересно взглянуть на тот же DDS. О DCOM и CORBA можно почитать на этом сайте в разделе статей. Я далёк от Java и тем не менее есть такая штука как сервлеты.
Подведём предварительные итоги, различать технологии довольно просто. Первые используют 4-е функции по CRUD, вторые передают действия, которые нужно осуществить. Причём и то и другое можно использовать для достижение одного и того же результата, то есть вызовом функции передать данные или вызвать функции использую ресурсы по CRUD.
Но в наше время баланс всё больше смещается в сторону CRUD, а всё потому, что этот способ жрёт меньше трафика и лучше масштабируется. Плюс к этому ещё прикручивают децентрализацию. Таким образом никакой особой революции и не было, мы сейчас обсуждаем уже давно "поросшие мхом" технологии.
Что касается сетевого взаимодействия, то здесь достаточно прочитать статьи про кластеры. У них так же есть огромное множество проблем. Из книги Мартина Фаулера "Архитектура корпоративных программных приложений" я усвоил, что не нужно воспринимать всё сугубо с точки зрения взаимодействия компонентов по сети.
Причём в другой книге про протокол TCP говорилось, что сеть сети рознь, локалхост это одна скорость и надёжность, локалка другая, а интернет и вовсе требует совершенно иного подхода. Это, кстати, ещё раз напоминает про кластеры, облачка и всякие лошарики, а в реальности на эффективность приложения будет влиять местоположение серверов по которым оно раскидано.
Лично я считаю, что нельзя сбрасывать со счетов симметричную мультипроцессорность. Давайте даже не будем далеко ходить, а возьмём DDR3. Вот стандарт у Intel позапрошлого поколения.
Стандартное название DDR3‑1600
Частота памяти, МГц 12800
Время цикла, нс 5,00
Частота шины, МГц 800
Эффективная (удвоенная) скорость, млн. передач/с 1600
Название модуля PC3‑12800
Пиковая скорость передачи данных при 64-битной шине данных в одноканальном режиме, МБ/с 12800
Посмотрите на объёмы и скорость передачи, чудовищная производительность. А теперь давайте вспомним TCP по которому нам предлагают гнать обмен данными и функциями. Нет, можно конечно порассуждать, что в обычной программе всё не так, там стеки вызовов, ещё вспомнить какой-нибудь ассемблер. Но если уж речь идёт о Мартине Фаулере, а у него там всё насыщено различными концепциями, очень уж он любит делить приложения на уровни и слои, где уровни это и есть взаимодействия между сервером и клиентом, а слои разделение внутри самого приложения.
Но если мы уж опустились до таких абстракций, а они там совсем не хилые, то кто сказал, что сервер и клиент обязательно должны находиться в сети. А клоню я к тому, что если оно на уровне SMP, например, подключение плагинов, пусть уж работает однотипно как и на уровне кластеров просто используя расслоение, и без разницы там по Фаулеру, по Брауну или по хрену с горы.
Будем надеяться, что я выражался достаточно непонятно и туманно, чтобы мой труд оценили по достоинству.
Тё>>Понимаю, что слоупок, прозевал революцию и т.д. Предлагаю обсудить парадигму микросервисов (как её описал Мартин Фаулер) в практическом применении.
V>У Мартина Фаулера есть хорошие книги, вроде "Архитектура корпоративных программных приложений" в которой нет ни слова про микросервисы. Понятное дело в "UML Основы Краткое руководство по унифицированному языку моделирования" и других книгах вряд ли что тоже будет. Но у нас же есть гугл, а он говорит, что речь идёт об этой статье.
V>Моё мнение, что по сравнению с книгой "Архитектура корпоративных программных приложений" у них там представлен краткий обзор, который вряд ли поймёт тот, кто не в теме, а я вижу это так. В нашем мире есть объекты (сущности) и действия над ними. Объект может воздействовать как на себя, так и на другой объект, во всяком случае именно так это себе представляют люди. С одной стороны мы имеем существительные (сущность), с другой глаголы (действия).
V>Соответственно для связи используется два подхода, это передача данных и функций. В одном случае мы передаём данные самого объекта, это поля и прочие ресурсы, в другом функции, для экземпляров класса это будут методы и так далее. Теперь о том, какие технологии вошли в первую и во вторую группу:
V>1) данные: CRUD, SQL, REST V>2) функции: RPC, CORBA, DCOM, SOAP
V>И так далее. Взять тот же HTTP, сразу видно, что он входит в первую группу, но есть важное отличие, мы обсуждаем не вообще всё, что есть и привязывается к принципу CRUD, хотя для общего понимания я и впихнул сюда его, а так же SQL, а то, что хоть как-то связано с архитектурой приложений.
V>Раз уж мы заговорили о Мартине Фаулере, который писал так же и об UML, обязательно стоит упомянуть OMG. V>
V> BPMN — графическая нотация для моделирования бизнес процессов.
V> MDA — концепция модельно ориентированного подхода к разработке программного обеспечения
V> Meta-Object Facility
V> UML — язык графического описания для объектного моделирования
V> XMI — стандарт для обмена метаданными с помощью языка XML.
V> CWM
V> CORBA
V> IDL — язык описания интерфейсов
V> IIOP
V> DDS
V> Object Management Architecture (OMA)
V>
V>Возможно кому-то было бы интересно взглянуть на тот же DDS. О DCOM и CORBA можно почитать на этом сайте в разделе статей. Я далёк от Java и тем не менее есть такая штука как сервлеты.
V>Подведём предварительные итоги, различать технологии довольно просто. Первые используют 4-е функции по CRUD, вторые передают действия, которые нужно осуществить. Причём и то и другое можно использовать для достижение одного и того же результата, то есть вызовом функции передать данные или вызвать функции использую ресурсы по CRUD.
V>Но в наше время баланс всё больше смещается в сторону CRUD, а всё потому, что этот способ жрёт меньше трафика и лучше масштабируется. Плюс к этому ещё прикручивают децентрализацию. Таким образом никакой особой революции и не было, мы сейчас обсуждаем уже давно "поросшие мхом" технологии.
V>Что касается сетевого взаимодействия, то здесь достаточно прочитать статьи про кластеры. У них так же есть огромное множество проблем. Из книги Мартина Фаулера "Архитектура корпоративных программных приложений" я усвоил, что не нужно воспринимать всё сугубо с точки зрения взаимодействия компонентов по сети.
V>Причём в другой книге про протокол TCP говорилось, что сеть сети рознь, локалхост это одна скорость и надёжность, локалка другая, а интернет и вовсе требует совершенно иного подхода. Это, кстати, ещё раз напоминает про кластеры, облачка и всякие лошарики, а в реальности на эффективность приложения будет влиять местоположение серверов по которым оно раскидано.
V>Смотрим сюда: Классификация многопроцессорных вычислительных систем V>Image: 01_04.gif
V>А теперь сюда: Схематический вид SMP-архитектуры V>Image: 3-1.gif
V>Лично я считаю, что нельзя сбрасывать со счетов симметричную мультипроцессорность. Давайте даже не будем далеко ходить, а возьмём DDR3. Вот стандарт у Intel позапрошлого поколения. V>
V>Стандартное название DDR3‑1600
V>Частота памяти, МГц 12800
V>Время цикла, нс 5,00
V>Частота шины, МГц 800
V>Эффективная (удвоенная) скорость, млн. передач/с 1600
V>Название модуля PC3‑12800
V>Пиковая скорость передачи данных при 64-битной шине данных в одноканальном режиме, МБ/с 12800
V>Посмотрите на объёмы и скорость передачи, чудовищная производительность. А теперь давайте вспомним TCP по которому нам предлагают гнать обмен данными и функциями. Нет, можно конечно порассуждать, что в обычной программе всё не так, там стеки вызовов, ещё вспомнить какой-нибудь ассемблер. Но если уж речь идёт о Мартине Фаулере, а у него там всё насыщено различными концепциями, очень уж он любит делить приложения на уровни и слои, где уровни это и есть взаимодействия между сервером и клиентом, а слои разделение внутри самого приложения.
V>Но если мы уж опустились до таких абстракций, а они там совсем не хилые, то кто сказал, что сервер и клиент обязательно должны находиться в сети. А клоню я к тому, что если оно на уровне SMP, например, подключение плагинов, пусть уж работает однотипно как и на уровне кластеров просто используя расслоение, и без разницы там по Фаулеру, по Брауну или по хрену с горы.
V>Будем надеяться, что я выражался достаточно непонятно и туманно, чтобы мой труд оценили по достоинству.
Можно, конечно, йорничать, но пока я сидел в келье писал "высоко производительные распределённые приложения" (C) автора не буду раскрывать, успел сдохнуть jqyery, родиться и сдохнуть хадуп, амазон с гуглом борются за первенство в облачных вычислениях (вроде у ibm тоже что-то такое есть), а сейчас разворачивается драма между спарком и флинком. Умнейшие phd-ки калифорнийских и сиэттловских компаний проповедуют их фреймворки в том же ютубе доклады.
Здравствуйте, Тёмчик, Вы писали:
Тё>Понимаю, что слоупок, прозевал революцию и т.д. Предлагаю обсудить парадигму микросервисов (как её описал Мартин Фаулер) в практическом применении. У кого есть опыт покупки IaaS, настройки этого в кластер EMR, какой планировщик задач использовался (самописный или Apache Spark или что-то ещё)?
Что-то с Flink накидал, не закончил правда но может завтра добью пруф-оф-концепт конвертера данных из параллельной пачки файлов. Потом можно и в облака на Elastic Map Reduce закинуть. В принципе к микросервисам оно ортогонально
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Тёмчик, Вы писали:
Тё>>Понимаю, что слоупок, прозевал революцию и т.д. Предлагаю обсудить парадигму микросервисов (как её описал Мартин Фаулер) в практическом применении. K>Ну если фаулера... K>Фаулер... До него было linux way app development, COM/CORBA, dbus и т.п. не особо понимаю что нового предложил Фаулер кроме переосмысления известных концепций в рамках несколько иной задачи. K>По мне так микросервисы на основе Erlang+rabbitmq довольно красиво сомтрится.
И всё же основное отличие микросервисов от всего остального вы упустили...
