AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 03.04.2021, 19:37   #1  
Lemming is offline
Lemming
Участник
Аватар для Lemming
 
1,031 / 298 (12) ++++++
Регистрация: 20.04.2004
Адрес: Москва, Чайнатаун в Люблино
Записей в блоге: 10
? Микросервисы в ERP
Многие сегодня говорят про так называемые микросервисы и что мол надо эту концепцию использовать в ERP. Честно говоря, я с трудом представляю как это можно было бы реализовать и предлагаю поразмышлять на эту тему.

Основным вопросом остается взаимодействие модулей. Когда мы в единой БД и едином приложении, из которого доступны все бизнес-сущности, мы можем строить и управлять картиной в целом, однако если все это разделить на несколько независимых "небольших" приложений, то сразу возникает вопрос их взаимодействия и обмена данными (пример из мира 1С, когда в компании используется три конфигурации: Бухгалтерия, Кадры, Торговля и данные между ними надо как-то склеивать и держать в актуальном для всех баз виде).

Так вот, для меня остается открытым вопрос о том, как например данные из сервиса Склад будут взаимодействовать с сервисом Главная книга? Если это две разные базы данных, то как мы будем обмениваться данными между ними, REST, SOAP, что-то ещё?

Кроме того, если падает общее приложение то все как бы понятно, поднимать надо все. Если же сервис Главная книга упал, а сервис Продажи ждет от него номер бухгалтерской операции, то чем это будет принципиально отличаться от падения общей БД/приложения?

В общем, идея с микросервисами выглядит с одной стороны заманчиво, потому что помогает избежать большой связанности, но с другой стороны не окажется ли использование микросервисной архитектуры таким же проблемным, каким, в некоторых случаях, оказываются ERP приложения с монолитной архитектурой?

Мысли, идеи, мнения? Вам слово!
Старый 03.04.2021, 20:08   #2  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,627 / 628 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
По определению микросервисы - это слабосвязанные модули, причем могут быть реализованы на разных языках и платформах.
Если рассматривать ERP, конкретно DAX, то это отсутствие единого АОС под все модули и единой базы данных.
У каждого модуля должен быть свой API, через который происходит общение с этим модулем.
Идеально, если вам не нравится, как реализован, допустим склад, то вы его заменяете на модуль склад другого поставщика. Допиливаете API по своим существующим модулями и вуаля у вас ERP с другим модулем склад.
Уже не имеет смысл рассматривать интеграции с 1С или еще чем- то, так как у вас каждый модуль отделен. И вам без разницы с каким модулем у вас работает, допустим, модуль производство. API есть, оно работает, данными обменивается.
У вас в качестве модуля главной книги очень может быть 1С.
Модули обмениваются через шину данных.
Если у вас, допустим упал модуль расчеты с персоналом, то остальные модули продолжают работать.
Минусом этого, однозначно, будет сложность администрирования и управления всеми частями.
__________________
Axapta book for developer

Последний раз редактировалось MikeR; 03.04.2021 в 20:10.
За это сообщение автора поблагодарили: Lemming (5), Sancho (1).
Старый 03.04.2021, 21:37   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,321 / 4136 (196) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от MikeR Посмотреть сообщение
У каждого модуля должен быть свой API, через который происходит общение с этим модулем.
Согласен с MikeR.
И сейчас взаимодействие между "модулями" происходит через публичный интерфейс классов. Никто ж в здравом уме не пишет финансовые проводки вручную, а обращаются к классам LedgerVoucher*

другое дело, что классы в аксапте слишком много знают друг о друге.

Цитата:
Сообщение от Lemming Посмотреть сообщение
Кроме того, если падает общее приложение то все как бы понятно, поднимать надо все. Если же сервис Главная книга упал, а сервис Продажи ждет от него номер бухгалтерской операции, то чем это будет принципиально отличаться от падения общей БД/приложения?
да, люди столкнулись с этой проблемой.
в результате пришли к стандартизированным менеджерам очередей для сообщений.

сейчас это RabbitMQ, Kafka и подобные (эти живут и здравствуют)
Раньше в виндах был MicrosoftMQ и BizTalk (эти умерли)

Цитата:
Сообщение от Lemming Посмотреть сообщение
В общем, идея с микросервисами выглядит с одной стороны заманчиво, потому что помогает избежать большой связанности, но с другой стороны не окажется ли использование микросервисной архитектуры таким же проблемным, каким, в некоторых случаях, оказываются ERP приложения с монолитной архитектурой?
Ну... на самом деле не очень.
История повторяется:
1. раньше были "мощные" мэйнфреймы и тупые терминалы.
2. решили что это не гибко и монстроидально, начали в персональные компьютеры
3. персональные компьютеры изначально были персональными и плохо работали в сети.
4. затем появились сетевой инструментарий для персональных компьютеров
5. теперь снова уходит "в облака", где работают мощные "мэйнфреймы", а персональные компьютеры являются тупыми терминалами по большей части

идея с микросервисами - примерно то же самое.
она привлекательна только для небольших и независимых команд разработчиков.

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

если говорить в терминах аксапты,
то кажется, что главная книга, склад, производство и... та-дам... сводное планирование, например, очень хорошо выносится в микросервисы.

Майкрософт так и сделал со сводным планированием. Можно почитать отзывы, посмотреть на результат, так сказать

но когда с уровня космического архитектора спускаешься на уровень реализации, тут же выясняется, что в ERP есть много действительно общих вещей. Валюты и валютные курсы например. Особенно с учётом разных стран, кросс-курсов, управляемых курсов типа УЕ.
А также нормативные справочники типа налоговых инспеций, ИНН/КПП. В Аксапте DirInfo, не к ночи будь помянут... Даже тривиальные финансовые периоды, которые в Аксапте в модуле главной книги. И даже в существующей аксапте они не очень используются....

Стоит примерить как придется реализовать ЭТО в парадигме микросервисов. И сколько этих микросервисов придется сделать.

С другой стороны, микрсервисы - это именно такие справочники, а не сводное планирование
__________________
Полезное на axForum, GitHub, Facebook, mazzy.priot, mazzy.music, coub.
За это сообщение автора поблагодарили: Lemming (5).
Старый 03.04.2021, 22:13   #4  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
668 / 691 (25) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Есть же ещё сервис для on hand https://docs.microsoft.com/en-us/dyn...ory-visibility реализованный на Dataverse и судя по слайдам это первый из многих. Далее обещают сервис для цен.
Старый 05.04.2021, 10:31   #5  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,467 / 1125 (46) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от Lemming Посмотреть сообщение
Основным вопросом остается взаимодействие модулей. Когда мы в единой БД и едином приложении, из которого доступны все бизнес-сущности, мы можем строить и управлять картиной в целом, однако если все это разделить на несколько независимых "небольших" приложений, то сразу возникает вопрос их взаимодействия и обмена данными (пример из мира 1С, когда в компании используется три конфигурации: Бухгалтерия, Кадры, Торговля и данные между ними надо как-то склеивать и держать в актуальном для всех баз виде).

Так вот, для меня остается открытым вопрос о том, как например данные из сервиса Склад будут взаимодействовать с сервисом Главная книга? Если это две разные базы данных, то как мы будем обмениваться данными между ними, REST, SOAP, что-то ещё?

Кроме того, если падает общее приложение то все как бы понятно, поднимать надо все. Если же сервис Главная книга упал, а сервис Продажи ждет от него номер бухгалтерской операции, то чем это будет принципиально отличаться от падения общей БД/приложения?
А почему именно микросервисы? Потому что модно? Вообще-то, они в основном нужны для быстрого развертывания, например когда на сайт заходит не 5, а 50 000 человек - в обычной архитектуре сайт бы упал, но при использовании докеров просто поднимается куча готовых виртуалок с преднастроенными сервисами, которые отрабатывают запрос. Валидна ли подобная технология для ERP - вопрос открытый.

С другой стороны, можно посмотреть как работает Oracle Fusion. В ERP есть "сердце" - основные справочники (номенклатура, план счетов, валюта) и транзакционные таблицы (главная книга, перемещение номенклатуры). Данные справочники едины для всех модулей, которые являются расширением базового функционала. Т.е. все модули видят, какой товар есть в наличии на каком складе, а где именно он лежит - знает только модуль WMS. Если WMS упал - ну, чините, ничего страшного, система работает. CRM - видит список компаний и контактов, а как именно с ними ведется работа - знает только сам CRM, который, в свою очередь, может выдавать информацию о заказе или предполагаемых заказах, основанную на оценке стадии сделки и её предполагаемой сумме. И подобные модули являются расширением стандартного функционала системы, без которого она может работать, но которые дополняют и расширяют стандартную функциональность.

Таким образом, Fusion выступает как сервер приложений, который обеспечивает контроль доступа, работу с БД и шину данных.

Если и писать "микросервисы", то логичнее их писать не к БД напрямую, а к подобному серверу приложений.

Но у меня не вяжется "микроcервис" и, например, "WMS". Микросервис ближе к мобильному рабочему месту оператора, чем к модулю ERP.

С Уважением,
Георгий.
За это сообщение автора поблагодарили: mazzy (2), Lemming (5).
Старый 05.04.2021, 12:38   #6  
trud is offline
trud
Участник
Лучший по профессии 2017
 
981 / 1370 (47) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
Майкрософт так и сделал со сводным планированием. Можно почитать отзывы, посмотреть на результат, так сказать
Ну кстати по поводу сделал - если посмотреть список тех настроек стандартных сводного планирования что не поддерживается этим сервисом, он просто огромен, т.е. сделали какую-то упрощенную модель. Можно посмотреть по словам - not supported и pending
https://docs.microsoft.com/en-us/dyn...n-fit-analysis

Думаю реализовать такой же сервис внутри D365 было бы на порядок проще, плюс работал бы он так же быстро, т.е. основная сложность таких операций, это как раз множественные настройки, каждая из которых резко усложняет систему, вынуждает делать доп. запросы и прочее

Микросервисы это все же про людей, а не про техническую составляющую, вот просто отличное видео, которое раскрывает проблему
https://www.youtube.com/watch?v=gfh-VCTwMw8
За это сообщение автора поблагодарили: mazzy (2), cuba (1), Lemming (5).
Старый 12.04.2021, 17:50   #7  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,139 / 2157 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Я когда думал на эту тему для себя разделил примерно как расписали уже выше: внутри "модуля" можно сделать модную микросервисную архитектуру (и пример масштабирования сводника - это запуск много отдельных параллельных микросервисов расчета), а вот сама ERP - это уже система из таких модулей-"сервисов".

В общем случае модули ERP могут быть на разных платформах, ПО и т.п. По сути классика жанра Аксапта + 1С для БУ + WMS + BI и есть модульная ERP.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: Lemming (5).
Старый 13.04.2021, 09:13   #8  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,467 / 1125 (46) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
По сути классика жанра Аксапта + 1С для БУ + WMS + BI и есть модульная ERP.
Нет, Иван. Это не так. Ты не поднимешь 100 экземпляров 1С для расчета или 1000 экземпляров DAX для параллельного запуска сводного планирования, а это и есть смысл микросервисов.

С Уважением,
Георгий
Старый 13.04.2021, 10:28   #9  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,139 / 2157 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Нет, Иван. Это не так. Ты не поднимешь 100 экземпляров 1С для расчета или 1000 экземпляров DAX для параллельного запуска сводного планирования, а это и есть смысл микросервисов.

С Уважением,
Георгий
Так я не говорю, что текущие системы / модули написаны в парадигме микросервисов. Они могли бы / будут. Сейчас в ентерпрайзе среди ERP, WMS, TMS и т.п. я не знаю примеров. Тот же новый сводник совсем не туда?

Я вижу примеры роста различных BPM систем, low code и вот это всё. Новые пишутся в такой парадигме, в т.ч. некоторые "клиенты" пишут под себя такое и потом выходят на рынок с "платформой". Но пока рано говорить о значительной доли рынка таких систем.
__________________
Ivanhoe as is..
Старый 13.04.2021, 11:35   #10  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,467 / 1125 (46) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Но пока рано говорить о значительной доли рынка таких систем.
Это да... Во-первых, рынок ERP довольно неповоротливый. И просто так все на новой архитектуре переписывать не будет, хотя попытки мы видим. И они, кажется, не всякого радуют .

К тому же, ERP лицензируются по пользователям, сервисы - скорее по потреблению ресурсов (ЦПУ / трафик / место на диске). В итоге приходится много чего пересматривать с точки зрения лицензирования, чтобы новое сводное не отъедало тысячу конкурентных пользователей, но при этом подчинялось базовым настройкам безопасности.

С Уважением,
Георгий
За это сообщение автора поблагодарили: Lemming (5).
Старый 13.04.2021, 14:07   #11  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,610 / 5021 (173) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от George Nordic Посмотреть сообщение
И они, кажется, не всякого радуют .
С выходом микросервисной версии MRP, выражение "сводник", так любимое выходцами из Коруса, наконец-то начало звучать неожиданно уместно.
Старый 02.06.2021, 12:28   #12  
mau is offline
mau
Участник
 
34 / 19 (1) ++
Регистрация: 12.03.2003
Адрес: Москва
Когда говорят о микросервисах, то в качестве их преимуществах говорят о слабосвязанности.
А насколько она - слабосвязанность - нужна?
В концептуальном анализе есть прием - антропоморфная редукция. Это когда сложные системы понятий проектируются на человека и/или его деятельность - при этом все должно вставать на свои места и сложные понятия становятся простыми до очевидности.
Попробуем спуститься еще ниже - не до человека, а до повара (повароморфная редукция, мда..).
Представим повара и его, ну например, микроволновку (сервис). Повар засовывает в него курицу (информационный продукт) и, согласно контракту, микроволновка должна его разморозить. При этом:
- если открыть дверцу микроволновки во время работы она должна выключиться. Это жесткая функциональная связь, реализуемая на "железячном" уровне.
- после отработки микроволновки повар (процессный движок) должен вынуть курицу (информационный продукт) из микроволновки и засунуть её в кастрюлю, согласно рецепту (шаблон бизнес-процесса). Здесь связи определяются процессом и также достаточно жесткая, хотя может в процессе приготовления меняться.
- после отработки микроволновка блямкает - посылает сигнал о завершении работы в космос. Кому он нужен? Да мало ли кому - на кухне и в зале трётся много народа. Может кому и сгодится. И только вот эти, самые малозначимые с точки процесса, связи и являются "слабосвязанными". И только они в достаточной мере годны для реализации микросервисами.
Получается, что основная выгода от микросервисов - реализация самых малозначимых компонентов системы.
Старый 02.06.2021, 13:09   #13  
axm2017 is offline
axm2017
Участник
 
489 / 184 (7) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от mau Посмотреть сообщение
Представим повара и его, ну например, микроволновку (сервис). Повар засовывает в него курицу (информационный продукт) и, согласно контракту, микроволновка должна его разморозить...
Получается, что основная выгода от микросервисов - реализация самых малозначимых компонентов системы.
Попробуем от обратного:
Cоздадим монолит: привяжем повара к микроволновке цепочкой, и мордочку закрепим скотчем на уровне дверцы: он сразу будет видеть курочку, а это конкурентное преимущество над микросервисом.
Тут же вырисовываются и проблемы: поваренок должен быть мелким иначе проигрываем по габаритам и не на каждую кухню влезет такая система + есть опасность потребления ресурсов со стороны поваренка.

Последний раз редактировалось axm2017; 02.06.2021 в 13:13.
Старый 02.06.2021, 13:30   #14  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,546 / 2708 (100) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от mau Посмотреть сообщение
А насколько она - слабосвязанность - нужна?
Давайте определим что такое слабосвязанность?
Когда говорят о микросервисах, то обычно разделяют следующие выгоды:
  • повар может быть реализован на другой технологии (белковой)
  • повар может продолжать жить, когда микроволновка сдохла просто его функции деградируют
  • повар может быть разработан отдельной командой от микроволновки
  • микроволновку можно устанавливать отдельно от повара (да и вообще поменять на микроволновку другого производителя). Не требуется обновлять повара отдельно от микроволновки.
  • можно дешево купить кучу микроволновок и масштабировать горизонтально не нанимая новых поваров

В качестве минуса - Eventual consistency - повар может не услышать сообщение от микроволновки и думать что еда готовится, когда еда уже готова.
__________________
blog | twitter
За это сообщение автора поблагодарили: Dynamics365Eng (1), Sancho (1).
Старый 02.06.2021, 15:46   #15  
mau is offline
mau
Участник
 
34 / 19 (1) ++
Регистрация: 12.03.2003
Адрес: Москва
Когда говорят о микросервисах возникает одно ощущение — мешанина.
Начиная от определения, например Фаулера: архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP.
Мешанина туманной концепции (небольшие сервисы) и конкретной реализации.

Теперь к нашим баранам, сиречь повару.
Независимость повара и микроволновки, производителя микроволновки, команды микроволновки и установки микроволновки определяемтя не микросервисной архитектурой (использованием отдельного процесса, отдельного источнока данных и протокола HTTP), а компонентной архитектурой. Вспомним приснопамятную RAD-архитектуру и наборы компонентов для Delphi, покупаемых на Горбушке. Без микроскрвисов.

Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов.

Единственное применение микросервисов - использование другой технологии (скорее всего, языка программирования). Я знаю не много языков, но мне не особо верится что есть такие технологии, которые можно реализовать в одном языке и невозможно реализовать в другом. Конечно, беря во внимание наиболее распространенные универсальные языки. Скорее, речь пойдет о том, что независимая команда не шарит в языке и технологии, на которой реализована основная система. Причиина опять не технологическая, а организационная.

И особенно доставляет слушать доклады с всевозможных конференция о историях успеха внедрения микросервисной архитектуры (или особенно какой-нибудь Event-Driven Microservice Architecture) в крупных гигантах. Ребята все делают правильно, а получают неуправляемый ворох сервисов и перекосы в системе хранения данных.
Но это неважно, ведь используются самые передовые технологии, правдв?
Старый 02.06.2021, 16:09   #16  
axm2017 is offline
axm2017
Участник
 
489 / 184 (7) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от mau Посмотреть сообщение
Когда говорят о микросервисах возникает одно ощущение — мешанина.
...
Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов.
Микроволновка вполне себе работает как самостоятельная вещь с вполне конкретной целью - греет. Пихай яблоки и прочее и грей на выходе получишь какую то обработанную пищу. Микросервис.

Цитата:
Сообщение от mau Посмотреть сообщение
Единственное применение микросервисов - использование другой технологии (скорее всего, языка программирования).
Откуда такое мнение?
Естественно как у любой архитектуры есть + и - и бездумно применять не стоит

ps домохозяйкам на заметку
https://habr.com/ru/post/249183/
Не фан микросервисов (мне например не нравятся слухи об invoice машинах и прочем внутри MS как отдельных сервисах так как беглый опрос показывает что MS ники видят это как black boxes со всеми вытекающими) но имеет место быть.

Последний раз редактировалось axm2017; 02.06.2021 в 17:00.
За это сообщение автора поблагодарили: mau (1).
Старый 02.06.2021, 19:37   #17  
twilight is offline
twilight
MCTS
MCBMSS
 
750 / 155 (7) ++++++
Регистрация: 17.10.2004
Адрес: Москва
Компоненты это хорошо. Но почему обязательно микро? Это какое-то упрощение. Сначала стремимся все запихнуть в одну систему (ERP). Потом все поделить на маленькие кусочки. Надо выделять области наибольшей связности кода, их и можно выносить в сервисы.
__________________
I could tell you, but then I would have to bill you.
Старый 02.06.2021, 19:58   #18  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,546 / 2708 (100) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от mau Посмотреть сообщение
(использованием отдельного процесса, отдельного источнока данных и протокола HTTP), а компонентной архитектурой. Вспомним приснопамятную RAD-архитектуру и наборы компонентов для Delphi, покупаемых на Горбушке. Без микроскрвисов.
Ну там такая отдельность. Как только компонент хочет какой-то персистенстности, ему надо сообщать данные для хранилища, пользователь становится зависим от внутренней реализации компонента.

В случае микросервиса, хранение и администрирование лежит на команде, которая поддерживает микросервис, она может даже сменить вид хранилища по желанию.

Цитата:
Сообщение от mau Посмотреть сообщение
Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов.
Да, процессам теперь придется взаимодействовать через IPC, если хочется горизонтального масштабирования (добавлением дополнительных VM) придется учится межсетевому взаимодействию. Если не хочется тащить в worker процессы код и данные, которые в них не используются, придется запускать не копии одного приложения, а отдельные приложения для разных видов задач. Что-то это напоминает.

Цитата:
Сообщение от mau Посмотреть сообщение

Единственное применение микросервисов - использование другой технологии (скорее всего, языка программирования).
Еще хранилище, например.

Цитата:
Сообщение от mau Посмотреть сообщение
Я знаю не много языков, но мне не особо верится что есть такие технологии, которые можно реализовать в одном языке и невозможно реализовать в другом.
Все верно. Если не думать о стоимости. (вон фейсбук свой PHP написал) Языки связаны с технологиями. Сборка мусора на .NET, JS, Python и GO устроена по-разному. На objective C неудобно писать под Android и так далее, для DataScience много либ и материалов под питон.

Цитата:
Сообщение от mau Посмотреть сообщение
И особенно доставляет слушать доклады с всевозможных конференция о историях успеха внедрения микросервисной архитектуры (или особенно какой-нибудь Event-Driven Microservice Architecture) в крупных гигантах. Ребята все делают правильно, а получают неуправляемый ворох сервисов и перекосы в системе хранения данных.
Но это неважно, ведь используются самые передовые технологии, правдв?
Можно сослаться на примеры, пожалуйста? Что за доклады? Кто получил неуправляемый ворох?
__________________
blog | twitter
Старый 03.06.2021, 08:11   #19  
mau is offline
mau
Участник
 
34 / 19 (1) ++
Регистрация: 12.03.2003
Адрес: Москва
Цитата:
Сообщение от twilight Посмотреть сообщение
Компоненты это хорошо. Но почему обязательно микро? Это какое-то упрощение. Сначала стремимся все запихнуть в одну систему (ERP). Потом все поделить на маленькие кусочки. Надо выделять области наибольшей связности кода, их и можно выносить в сервисы.
Именно. в том же концептуальном анализе есть понятие "естественная целостность", которые необходимо выявлять и строить по ним контуры управления.
Старый 03.06.2021, 08:16   #20  
mau is offline
mau
Участник
 
34 / 19 (1) ++
Регистрация: 12.03.2003
Адрес: Москва
Цитата:
Сообщение от belugin Посмотреть сообщение
Можно сослаться на примеры, пожалуйста? Что за доклады? Кто получил неуправляемый ворох?
Например, тут
Понятно, что никто не выйдет и не скажет "Ребята, мы обделались". Все будут говорить о проблемах и их решении.
Но послушайте, с какими проблемами они столкнулись на пустом месте. Именно из-за того, что у них куча отдельных микросервисов с собственными источниками данных.
Теги
erp, микросервисы

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
ERP как залежи говнокода mazzy Курилка 18 02.04.2011 19:21
Русский вопрос - разборки по понятиям на рынке ERP (Предпроект) Мартынов Дмитрий Курилка 28 16.02.2011 11:56
ERP-системы — мэйнстрим или тупиковая ветвь? slava09 Курилка 30 26.09.2010 18:00
О причинах неудачных внедрений ERP Poleax Курилка 4 11.09.2010 16:29
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:19.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.