Архитектура микросервисов для .NET
205 views
Skip to first unread message
Alex A.
Jul 30, 2017, 9:08:59 AM7/30/17
to dotnetconf
Доброго времени суток.
Вот и до нашей маленькой команды докатилось эхо микросервисов. На данный момент наш проект имеет вид монолитной архитектуры. У нас конечно же есть разделение на проекты, но все чаще, последнее время, небольшие изменения в коде приводят к необходимости поднятия новой версии на продакшн. Вот я и задумался, что было б не плохо использовать микросервисы, вместо монолитной архитектуры. Но тут возникло множество вопросов. Теории полно в интернете, а вот практические советы я встречал крайне редко. Основной вопрос, который меня волнует: как на один IP усадить все микросервисы, хранящиеся в разных DLL-ках и как наладить взаимоотношения между ними, так, что бы я мог продолжать пользоваться MVC.NET + Web API слоем, уже написанном и работающем на сегодняшний день? Буду рад любым работающим примерам, использующим MVC.NET + Web API, или же доходчивым объяснениям как это сделать.
С уважением, Саша.
Вот и до нашей маленькой команды докатилось эхо микросервисов. На данный момент наш проект имеет вид монолитной архитектуры. У нас конечно же есть разделение на проекты, но все чаще, последнее время, небольшие изменения в коде приводят к необходимости поднятия новой версии на продакшн. Вот я и задумался, что было б не плохо использовать микросервисы, вместо монолитной архитектуры. Но тут возникло множество вопросов. Теории полно в интернете, а вот практические советы я встречал крайне редко. Основной вопрос, который меня волнует: как на один IP усадить все микросервисы, хранящиеся в разных DLL-ках и как наладить взаимоотношения между ними, так, что бы я мог продолжать пользоваться MVC.NET + Web API слоем, уже написанном и работающем на сегодняшний день? Буду рад любым работающим примерам, использующим MVC.NET + Web API, или же доходчивым объяснениям как это сделать.
С уважением, Саша.
Alexander Byndyu
Jul 31, 2017, 1:57:53 AM7/31/17
to dotne...@googlegroups.com
Привет!
Если я правильно понял, то ты возьмешь веб-приложение с API и разделишь его на несколько веб-приложений. При этом фронт для клиентов API не должен измениться. При этом веб-сервер должен знать какой метод API где хостится. Всё верно?
Best regards,
Alexander Byndyu
CEO at Byndyusoft
--
---
Вы получили это сообщение, поскольку подписаны на группу dotnetconf.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+unsubscribe@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.
Denis Kodua
Jul 31, 2017, 3:51:22 AM7/31/17
to dotnetconf
Может не в тему, но как то читая книжку по WCF видел там пример уменьшения нагрузки за счет вынесения слоя DAL в отдельный сервис, типа экономия на восстановлении данных (из бд в объекты и тд... как понял). Обновлять его соотвественно можно отдельно....
31 июля 2017 г., 9:57 пользователь Alexander Byndyu <c...@byndyusoft.com> написал:
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Alex A.
Jul 31, 2017, 8:18:12 AM7/31/17
to dotnetconf
Привет.
Постараюсь объяснить свою задумку. В идеале, я бы не хотел разносить одно веб-приложение по разным. Я хотел бы написать сервисы (или микро-приложения) каждый из которых отвечает за свою область применения. К примеру, я хочу оформлять заказы продукции нашей фирмы. У меня есть три корня агрегации: продукт, пользователь и заказ. Я заинтересован сделать для каждого из них свой микро-сервис в которых будут включены сами корни агрегации, а так же их объекты-значения и сопровождающие классы. Однако между сервисами должно быть взаимодействие, так как пользователь может сделать / изменить / отменить заказ. Заказ в свою очередь содержит продукты и должен иметь доступ к свойствам продуктов. Все это я к тому, что сервисы должны уметь взаимодействовать между собой, но если надо будет сделать изменения в процессе оформления и сопровождения заказов, то мне надо будет поменять / проверить или отладить только один сервис, а не все приложение. Скорей всего не правильно разносить сервисы по разным серверам, так как пострадает скорость работы всей системы. Однако, разнести их по разным приложениям и заставить работать как одно целое с точки зрения пользователя сервисов - это то, что я бы хотел сделать. Так что, Александр, думаю ты понял правильно. Вопрос лишь в том, как это сделать?
Постараюсь объяснить свою задумку. В идеале, я бы не хотел разносить одно веб-приложение по разным. Я хотел бы написать сервисы (или микро-приложения) каждый из которых отвечает за свою область применения. К примеру, я хочу оформлять заказы продукции нашей фирмы. У меня есть три корня агрегации: продукт, пользователь и заказ. Я заинтересован сделать для каждого из них свой микро-сервис в которых будут включены сами корни агрегации, а так же их объекты-значения и сопровождающие классы. Однако между сервисами должно быть взаимодействие, так как пользователь может сделать / изменить / отменить заказ. Заказ в свою очередь содержит продукты и должен иметь доступ к свойствам продуктов. Все это я к тому, что сервисы должны уметь взаимодействовать между собой, но если надо будет сделать изменения в процессе оформления и сопровождения заказов, то мне надо будет поменять / проверить или отладить только один сервис, а не все приложение. Скорей всего не правильно разносить сервисы по разным серверам, так как пострадает скорость работы всей системы. Однако, разнести их по разным приложениям и заставить работать как одно целое с точки зрения пользователя сервисов - это то, что я бы хотел сделать. Так что, Александр, думаю ты понял правильно. Вопрос лишь в том, как это сделать?
Alex A.
Jul 31, 2017, 8:23:16 AM7/31/17
to dotnetconf
Денис, вынесение слоя DAL в отдельный сервис - это может рассматриваться как часть решения. Буду рад получить ссылку на книжку или подробное (на сколько это возможно) пояснение, как это сделать.
Anton Permyakov
Jul 31, 2017, 9:18:08 AM7/31/17
to dotne...@googlegroups.com
А вот для пытливых умов, читающих по-английски, более-менее свежая книжка от Майкрософт про микросервисы.
И заодно уж про Asp.Net с Core и Azure.
Все это пару месяцев назад было в рассылке MSDN, на которую несложно подписаться.
31 июля 2017 г., 17:23 пользователь Alex A. <aagr...@gmail.com> написал:
Денис, вынесение слоя DAL в отдельный сервис - это может рассматриваться как часть решения. Буду рад получить ссылку на книжку или подробное (на сколько это возможно) пояснение, как это сделать.
--
---
Вы получили это сообщение, поскольку подписаны на группу dotnetconf.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+unsubscribe@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.
Андрей Чистяков
Jul 31, 2017, 2:55:42 PM7/31/17
to dotnetconf
воскресенье, 30 июля 2017 г., 16:08:59 UTC+3 пользователь Alex A. написал:
Основной вопрос, который меня волнует: как на один IP усадить все микросервисы, хранящиеся в разных DLL-ках и как наладить взаимоотношения между ними, так, что бы я мог продолжать пользоваться MVC.NET + Web API слоем, уже написанном и работающем на сегодняшний день?
Задачу рассаживания нескольких сервисов на одном IP я решал с помощью nginx'а (вероятно, можно использовать и любой другой прокси).
Было так:
- монолит, в котором две относительно независимых предметных области (называются ChronometryApi и JiraApi)
- торчат наружу REST'ом; фронт-энд к ним ходит по url'ам типа http://myserver/api/chronometry/apiMethod1 и http://myserver/api/jira/apiMethod2
Распилил монолит на два отдельных сервиса ChronometryApi и JiraApi
- теперь запускаются на той же машине, на разных портах. Ходить к ним снаружи можно по прямым url'ам типа http://myserver:2000/api/chronometry/apiMethod1 и http://myserver:3000/api/jira/apiMethod2
- но это не круто с той точки зрения, что теперь придётся перенастраивать фронт на новую систему адресации
- поэтому я добавил впереди nginx, который редиректит старые url'ы на новые: все запросы начинающиеся с "http://myserver/api/chronometry/" отправляет в первый микросервис (на 2000й порт), а запросы, начинающиеся с "http://myserver:3000/api/jira/" - во второй (на порт 3000)
- таким образом, для фронтенда ничего не поменялось, он по-прежнему ходит по старым адресам, при этом запросы распределяются по двум микросервисам. Микросервисы сейчас находятся на одной машине, но ничего не мешает их разнести на разные, просто исправив пару строчек в конфиге nginx'а
Не знаю, подойдёт ли вам такой подход. Если покажется интресным, пишите, можно будет обсудить детали.
Alexander Byndyu
Aug 1, 2017, 1:00:08 AM8/1/17
to dotne...@googlegroups.com
Уже рассказали много хороших решений и дали ссылки.
Добавлю, что в презентации https://www.slideshare.net/AlexanderByndyu/ss-73574376 есть конкретные инструменты, которые стоит использовать.
Есть список шаблонов, которые стоит применять http://microservices.io/patterns/index.html
Best regards,
Alexander Byndyu
CEO at Byndyusoft
--
---
Вы получили это сообщение, поскольку подписаны на группу "dotnetconf".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+unsubscribe@googlegroups.com.
Message has been deleted
Alex A.
Aug 1, 2017, 3:08:06 AM8/1/17
to dotnetconf
Антон, спасибо за интересные книги. Обязательно прочитаю в ближайшее время. К сожалению, последнее время не успеваю следить за всеми рассылками.
Андрей, буду рад задать несколько вопросов по теме и пообщаться. Скажи куда писать.
Александр, спасибо за ссылки, особенно порадовал список шаблонов.
Если у кого-нибудь ещё есть желание поделиться информацией или готовыми решениями, буду рад ознакомиться.
Андрей, буду рад задать несколько вопросов по теме и пообщаться. Скажи куда писать.
Александр, спасибо за ссылки, особенно порадовал список шаблонов.
Если у кого-нибудь ещё есть желание поделиться информацией или готовыми решениями, буду рад ознакомиться.
Андрей Чистяков
Aug 1, 2017, 3:41:03 AM8/1/17
to dotnetconf
Сверчков Евгений
Aug 15, 2017, 4:57:36 AM8/15/17
to Alexander Byndyu, dotne...@googlegroups.com
Здравствуйте, Alexander.
Вы писали 1 августа 2017 г., 10:59:25:
Вы писали 1 августа 2017 г., 10:59:25:
|
|
|
-- --- Вы получили это сообщение, поскольку подписаны на группу "dotnetconf". |
| Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+...@googlegroups.com. |
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
На мой взгляд архитектура микросервисов нужна в том случаи, если вы хотите запускать сервисы на разных серверах или даже на разных отказоустойчивых кластерах. Если все Ваши сайты будут крутиться на одном сервере, лучше не думать об этом. так как смысл микросервисов разделить точки отказа на разное железо, и если что-то упадет, то не весь сайт а только часть.
--
С уважением,
Сверчков mailto:u02...@gmail.com
Alexander Byndyu
Aug 15, 2017, 8:52:32 AM8/15/17
to dotne...@googlegroups.com
Евгений,
Вы описали только часть, связанную с отказоустойчивостью. Есть еще важная часть, связанная со скоростью поставки новых фич и организация работы над разными частями системы разными командами. Здесь микросервисы тоже полезны и эти две части для бизнеса чаще важнее, чем отказоустойчивость.
Best regards,
Alexander Byndyu
CEO at Byndyusoft
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+unsubscribe@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
--
---
Вы получили это сообщение, поскольку подписаны на группу "dotnetconf".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+unsubscribe@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
На мой взгляд архитектура микросервисов нужна в том случаи, если вы хотите запускать сервисы на разных серверах или даже на разных отказоустойчивых кластерах. Если все Ваши сайты будут крутиться на одном сервере, лучше не думать об этом. так как смысл микросервисов разделить точки отказа на разное железо, и если что-то упадет, то не весь сайт а только часть.
--
С уважением,
Сверчков mailto:u02...@gmail.com
--
---
Вы получили это сообщение, поскольку подписаны на группу "dotnetconf".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес dotnetconf+unsubscribe@googlegroups.com.
Евгений Сверчков
Aug 15, 2017, 11:36:35 AM8/15/17
to dotne...@googlegroups.com
Согласен, спасибо.
15 августа 2017 г., 18:51 пользователь Alexander Byndyu <c...@byndyusoft.com> написал:
Reply all
Reply to author
Forward
0 new messages