|
26.02.2023, 14:53 | #1 |
Участник
|
Причем тут c#?
Микросервис можно писать на чем угодно. |
|
26.02.2023, 16:44 | #2 |
Участник
|
|
|
26.02.2023, 18:32 | #3 |
Участник
|
Сейчас их не пишу. Знакомые к примеру пишут на go
|
|
26.02.2023, 19:09 | #4 |
Участник
|
|
|
26.02.2023, 19:50 | #5 |
Участник
|
Зачем?
Им реклама не нужна. |
|
26.02.2023, 22:14 | #6 |
Участник
|
А вот что мои друзья делают, им тоже реклама не нужна. Как говорится, кто на что учился.
p.s. Можете банить за оффтопик |
|
27.02.2023, 10:45 | #7 |
Участник
|
Пока ещё меня не забанили, вот тоже мои друзья - https://www.youtube.com/watch?v=8SkMhe7NPbU Итак, вопрос: как будем размножать на микросервисы модели?
|
|
27.02.2023, 11:27 | #8 |
Участник
|
Ну чисто в рамках интеллектуальной разминки.
Модели в 365 вообще муть какая то не понятная. Скорей для разработчиков, а не для функционала. Хотят может я такой "не проникся". Если бы я писал систему с нуля, то делал бы так как жизнь делит. По опыту лучшая система - это отражения процессов в реальной жизни. Делить на модули (в реале отделы предприятия). Бухгалтерия, склад, производства и т.д. Каждый можно покупать/подключать/отключать по усмотрению. Как в реальной организации при необходимости создаются доп. отделы. Модули в "ширину" делятся на задачи - Инвентаризация, Перемещение, приемка, отгрузка и т.д. В "высоту" наращивается сложность. Ячейки - сверху докупаем ставим. Ну и обмен документами между сервисами как в реальной жизни - Склад делает свои документы, формирует ЗАЯВКУ на разноску по ГК (json xml) в сервис "бухгалтерия". Там заявка проходит обработку и отправляется в ГК (автоматом и вручную). Склад видит что проводка прошла и какой датой (может бухгалтерия там чуть подвинет, сама сторнирует, перенесет на другую дату, либо вообще не проводить - склад это не должно волновать и касаться). В общем все как в жизни. Физически, ес-но каждый модуль/задача/сервис может ставится на отдельный компьютер при желании. Сейчас MS какую то опять мешанину сделал из функционала. Все в кучу - управление командировками, талоны на обед в столовую, проводки ГК. Покупай что тебе нужно плюс еще 100500 функционала, который не нужен. Идеальный ориентир - должна быть возможность купить то что тебе нужно, и только это. И каждый модуль должен работать сам по себе. С возможностью докупки/расширения. Главная проблема Аксапты очевидна - тяжкое наследие монолита. Как бы была надежда, что они как то плавно переделают на сервисы. Но что то я пока не замечаю. Скорей винегрет какой-то выходит. Не судите строго. Мнение дилетанта. Чисто мечты об идеальной системе. ЗЫ Кстати именно это бесит в Windows. Ставишь чистую систему - она тормозит даже на простых задачах. И там крутятся сотни каких то сервисов, жрут ресурсы, нервы. А пользы от них нет лично мне никакой. Сделали бы лучше возможность подключать/отключать сервисы. На телефонах хорошо это реализовано. Ты четко понимаешь что у тебя стоит. Последний раз редактировалось LETTO; 27.02.2023 в 11:38. |
|
|
За это сообщение автора поблагодарили: sukhanchik (5), twilight (1). |
27.02.2023, 15:11 | #9 |
Аманд
|
С точки зрения названия приложения - да, но что на самом деле у него внутри - нет, чёрный ящик
|
|
27.02.2023, 16:24 | #10 |
Участник
|
Поздравляю! Вы изобрели oracle fusion erp, релиз которой состоялся где-то в 2009. Если вбить в поиск oracle fusion - выпадет список модулей. Все основано на сервере приложений oracle fusion middleware, просто написан ряд сущеностей (Items, Accounts, Contacts, Opprtunities и т.д.), а сверху ставится "модуль рассирения" - CRM, Логистика, Управление Закупками / Продажами и т.д. Кстати, недавно все это было перенесено в облако Oracle и доступно только из него.
|
|
27.02.2023, 18:52 | #11 |
Administrator
|
Цитата:
1. Маркетинг. Чем больше модулей - тем больше видна масштабность системы. Поэтому часть пунктов меню выпилили в отдельные модули (например, Консолидация или Налог) 2. Каждое новое приобретение (сам MS глобально функционал не пишет, а приобретает у партнеров) - это новый модуль. Так технически проще его встроить в систему. Поэтому Управление активами и Аренда актива - это разные модули, а фукнкционал госсектора (Public sector) - хоть и не выделен в меню явно, но технически выделен в отдельный модуль. Тоже самое касается разделения модуля Управление персоналом и Зарплата (которую обещали вырезать) 3. Рабочие места (Workspaces) - это те формы, в которых в основном люди должны работать. Плюс есть поиск по меню. Следовательно - какая разница в какой модуль запихнёт разработчик свой пункт меню? 4. Какие-то блоки, которые можно попытаться отдельно продать (вспомним историю с HRM) - удобно вынести в отдельный модуль как с маркетинговой т.з., так и с технической. 5. Технически удобно, если все доработки партнёров / клиентов будут в их собственных единых модулях 6. Инсталляция модулей сторонних разработчиков должна проходить быстро и легко. Чем больше будет сторонних разработчиков - тем лучше будет держаться "на плаву" система в целом. Другое дело, что конечным пользователям / консультантам деление неудобно. Но... когда MS думал о них )
__________________
Возможно сделать все. Вопрос времени |
|
27.02.2023, 11:46 | #12 |
Участник
|
Ну и технически реализация обмена - стоят модули на одном компьютере - обмен через память. Стоят в одной организации - через Сервер БД. Стоят в разных организациях - через веб.
|
|
27.02.2023, 11:57 | #13 |
Участник
|
Если б мне вдруг ударила в голову романтика и я захотел бы сделать свою ЕРП, то я бы один не стал писать. Это должен быть открытый проект, с какой то монетизацией для вольных разработчиков. Аля гугл плей. Одному такое не по силам. Сделал хороший функционал - тебе с каждой покупки падает копеечка.
Я помню когда игрался в бизнес и майкрософт только собиралась переходить на сервисы - они мне звонили. Мол не хотите поучаствовать в написании сервисов для 365. Потом это заглохло как то. А жаль. Для парочки отраслей/модулей/задач я бы мог хороший аддон написать. |
|
27.02.2023, 11:57 | #14 |
Moderator
|
Я просто напомню, что первый микросервис (MRP) микрософт запустил кажется в 2018ом году. То что у них сейчас сделано закрывает далеко не всю старую функциональность модуля MRP, поэтому клиенты не особо торопятся на него переходить. Кроме того - возможности расширения там весьма ограничены, даже по сравнению с D365FO с отключенным overlayering'ом. Кроме того, не было никаких анонсов о том, как планируется поддерживать новый микросервис для тех, кто купил версию On Premises. Ну и наконец - когда этот микросервис запустили, анонсировалось что он работает в сотни раз быстрее чем старый MRP; После того как туда приделали производственное планирование (по ресурсам) сотни раз сократились до десятков. Не уверен что после покрытия 100% старой функциональности, десятки раз не преврятятся в 200-300%
Кроме того - не понятно, как поддерживать переход на новые версии микросервиса. Для основной версии D365FO сейчас можно заранее установить новую версию и ее эдак месяца 2-3 потестить в Sandbox. Насчет микросервисов были какие-то анонсы, но я не уверен что там реально дают время потестироваться в sandbox... Так что есть шансы, что микросервисы будут работать также как интеграция Ax и CRM (ой простите - D365FO и D365CE). Ее, помнится, первый раз анонсировали в момент выхода Dynamics Ax 4.0, ее уже раз 5 переносили на новую технологическую платформу, а она как была тормозным и нестабильным глюкалом - так и осталась. (Хотя с момента анонса прошло уже 16 лет примерно). P.S. Ну и последний - вполне классический вопрос: Невозможно обеспечить 100% работоспособность любой системы. Соответственно - возникает вопрос, как будет обрабатываться ситуация когда у нас сама Аксапта работает, а микросервисный модуль рассчета налогов, например, на минуту-другую подвис. Будем разносить инвойсы без налогов и потом налоги доначислять ? Или будем вообще разноску инвойсов в аксапте отключать ? А что если у нас таких микросервисов штук 10 и каждый из них в сумме пару минут в день висит? Последний раз редактировалось fed; 27.02.2023 в 12:01. |
|
|
За это сообщение автора поблагодарили: LETTO (1), twilight (1). |
27.02.2023, 16:29 | #15 |
Участник
|
Цитата:
Сообщение от fed
P.S. Ну и последний - вполне классический вопрос: Невозможно обеспечить 100% работоспособность любой системы. Соответственно - возникает вопрос, как будет обрабатываться ситуация когда у нас сама Аксапта работает, а микросервисный модуль рассчета налогов, например, на минуту-другую подвис. Будем разносить инвойсы без налогов и потом налоги доначислять ? Или будем вообще разноску инвойсов в аксапте отключать ? А что если у нас таких микросервисов штук 10 и каждый из них в сумме пару минут в день висит?
|
|
28.02.2023, 09:37 | #16 |
Участник
|
Цитата:
К тоже же сервис можно поднимать на любой системе. Хоть Unix с реал таймом. И писать сервисы можно на любом подходящем языке. Плюс проблема с узким местом - единой БД - уходит. Расширять сервисы - в json предусмотреть вложенную ветку с данными под расширение (стандартное обновление чтоб его не трогало никогда). Для сервисов pre- post- операции. Доп. проверка - в pre-. Доп. разноски в post-. ЗЫ Размечтался я что то... Последний раз редактировалось LETTO; 28.02.2023 в 09:56. |
|
28.02.2023, 10:06 | #17 |
Moderator
|
Люди из веба владеют собственным кодом и могут делать все что им угодно. В ERP кодом частично владеет внедривший партнер и сам клиент, для которых эти сервисы являются черным ящиком, содержимое которого им не известно. Соответственно ЛЮБЫЕ изменения интерфейсов этих черных ящиков - максимально болезненны для всех участников.
В общем - <известный мем с Gustavo Fring из Breaking bad> |
|
28.02.2023, 10:17 | #18 |
Участник
|
Цитата:
Та же пресловутая разноска заказа на продажу. Там контракт и не менялся практически с версии 2.5. Клиент, Договор, Налоги. Строки - номенклатура, кол-во-цена. Все остальные приблуды для стран/клиентов должны идти как расширения к сервису с неизменным базовым контрактом. Последний раз редактировалось LETTO; 28.02.2023 в 10:21. |
|
28.02.2023, 10:29 | #19 |
Moderator
|
Цитата:
Сообщение от LETTO
Да и не должно быть известно. В сервисах есть открытый контракт. Все что внутри - не должен туда лезть никто, кроме владельца. Для клиента должны быть точка расширения. Как в 365 сейчас (но плохо что это расширения в том же монолите). Пусть пишет расширения клиент и сам за них отвечает.
Та же пресловутая разноска заказа на продажу. Там контракт и не менялся практически с версии 2.5. Клиент, Договор, Налоги. Строки - номенклатура, кол-во-цена. Все остальные приблуды для стран/клиентов должны идти как расширения к сервису с неизменным базовым контрактом. Теперь представим себе расширение облачного MRP. Допустим мне, по требованиям бизнеса, нужно приделать расширение, которое при сопоставлении чистых потребностей проверяет - подходит ли этот плановый приход к этому плановому расходу по каким-то дополнительным требованиям (специфичным для клиента). Это значит, после поиска каждого кандидата на сопоставление, микросервис должен вызвать другой микросервис (уже не микрософтом, а мной написаный). И это потребует 2 секунды. Типичное число чистых потребностей для при планировании (для средней руки производственного предприятия) - это где-то 100-200K. Множим 2*150000 = 300000 секунд, то есть - порядка 85 часов на одну сессию планирования. В старом X++овском коде времен DAX2012 обработка этой дополнительной проверки занимала порядка 50-100ms (пара запросов в БД + еще какая-то логика) и планирование для всех этих 200000 чистых потребностей отрабатывало в параллельном режиме часа за 2-3. |
|
28.02.2023, 10:28 | #20 |
Участник
|
Отчеты те же. В Аксапте сложный отчет вешают всю систему. В парадигме сервисов - это просто параллельный асинхронный запрос к сервисам, которые для отчета можно поднять дополнительно в любом количестве. И обращаться они должны не к базе сервиса, а к своей копии базы с режимом только для чтения. Как собственно BI сейчас делает в Аксапте.
|
|
|
|