Эволюция корпоративных Web приложений. Молотков Андрей D2D Just.NET
•Download as PPTX, PDF•
0 likes•522 views
Для многих enterprise-разработка ассоциируется с бесконечным унаследованным кодом, устаревшими технологиями и неповоротливыми монолитами. Использование подходов построения сервис-ориентированной архитектуры может существенно улучшить ситуацию. Мы пишем небольшие приложения с чёткой зоной ответственности и покрытием модульными тестами, используем современные протоколы OData и OAuth, а legacy-приложения развиваем подключением повторно используемых модулей. В своем докладе я расскажу о том, чего удалось добиться за последние пару лет, какие роли мы выделили и с какими сложностями столкнулись.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Эволюция корпоративных Web приложений. Молотков Андрей D2D Just.NET
Similar to Эволюция корпоративных Web приложений. Молотков Андрей D2D Just.NET (20)
More from Dev2Dev
More from Dev2Dev (20)
Эволюция корпоративных Web приложений. Молотков Андрей D2D Just.NET
- 2. Обо мне Spectrum ZX 8+ лет профессионально Архитектор в веб-отделе большой компании C# и ООП Люблю post-rock 2
- 3. О докладе ●Кода не будет ●Не зависит от платформы ●Термины на русском ●Собственный опыт 3
- 4. Опрос ●Кто работает в ИТ-отделах средних или крупных предприятий? ●Кому нравится текущее состояние систем? ●У кого есть понимание, в каком направлении вы движетесь? 4
- 5. Мегатонна! 5
- 6. Предприятие (enterprise) 6 ● Много унаследованного (legacy) кода ● ИТ-персонал разделен на отделы согласно используемым технология (SAP, Web, Oracle) ● Решаются задачи обработки информации
- 7. Эволюция 7 ● Все выкинуть и переписать! ● Работает - не трогай ● Возьми кусок кода вон из того проекта
- 8. Что у нас есть сначала? 8 Система 1 Система 3Система 2? ?
- 9. Проблемы 9 ● Код ● Данные ● Взаимодействие Дорого поддерживать
- 10. Возможности / Каркас (framework) 10 Ядро Каркас
- 12. Каркас / Узкий или сложный? 12 ?
- 13. Каркас / Выводы 13 + Код используется повторно + Легко начать - Велосипед - Слишком много отвественности - Дорого поддерживать
- 14. Модули 14
- 15. Модули / Повторное использование 15
- 16. Модули / Один процесс 16
- 19. Модули / Выводы 19 + Код используется повторно + Тестируемость + Производительность - Дублирование данных - Ограниченное масштабирование
- 20. Сервисы 20
- 22. Сервисы / Удаленные вызовы 22
- 24. Сервисы / Выводы 24 + Код и данные используются повторно + Тестируемость + Хорошая масштабируемость - Снижена скорость обращения - Нужно следить за потребителями
- 25. Микросервисы 25
- 26. Микросервисы / Выкинуть и переписать! 26
- 29. Микросервисы / Разбиение монолита 29
- 30. Микросервисы / Команда 30 "We've seen plenty of cases of less skillful teams building messy monolithic architectures, but it takes time to see what happens when this kind of mess occurs with microservices. A poor team will always create a poor system - it's very hard to tell if microservices reduce the mess in this case or make it worse."
- 31. Микросервисы / Выводы 31 + Решения используются повторно + Использование лучших платформ + Тестируемость + Отличная масштабируемость - Сильная команда - Инструменты автоматизации - Зоопарк технологий
- 32. Много фигурок и стрелочек, скучно? 32 Закладывается фундамент для дальнейшего развития Уменьшается стоимость поддержки Приложение ведет себя более предсказуемо
- 36. Что выбрали мы? 36 Нет универсального решения Единый стек технологий (кадры) Легкий переход от модуля к сервису или обратно Простые сервисы Создание модулей-клиентов Подключение к сервисам устаревших приложений
- 38. Пользователи 38
- 39. Пользователи / Регистрация 39 password ad hr
- 41. Пользователи / Вход в домен (AD) 41 A D
- 42. Пользователи / Единый вход (SSO) 42 S S O
- 43. Пользователи / Идентификация 43 password ad hr ? ?
- 44. Пользователи / Управление учетными записями (IM) 44 IM
- 45. Пользователи / Управление правами (UM) 45 IM S S O UM
- 46. Пользователи / Больше не проблема 46 IM S S O UM
- 47. Данные / Справочники (D) 47 Английский Английский язык Англ. англиискии ... D Английский язык
- 48. Справочники / Стурктура компании (CS) 48 Головная организация ● Директор ● Секретарь ● Советник Дочерняя организация Отдел кадров Отдел продаж ● Руководитель ● Менеджер CS CS
- 49. Данные / Файлы (F) 49 F
- 50. Данные / Фотографии (P) 50 P
- 51. Инстурменты / Логи (L), мониторинг (M) 51 L M
- 52. 52 L M IM S S O UM P F D CS
- 53. Заключение 53 Почти все сервисы уже реализованы и работают Используется REST + OData (простая инфраструктура) Предусмотрены версии Автоматическая документация Сервисы используются другими отделами
Editor's Notes
- Небольшое поселение из Fallout 3, образованное вокруг несдетонировавшей ядерной бомбы. Если ваш персонаж был злым и достаточно умным, то он мог её активировать.
- Вспомните, наверное у каждого при виде чужого проекта (а может быть и своего?) возникало желание все удалить и написать с нуля, руководители проектов совершенно справедливо не выделяют время, а предлагают скопировать работающий код из другого приложения. К эволюции это все не имеет никакого отношения.
- Несколько приложений - они обозначены большими прямоугольниками В них присутсвует сходная функциональность, обозначена пунктиром Возможно, эти приложения умеют обмениваться данными, с помощью древней enterprise-магии, вроде выгрузок excel-файлов в сетевую папку.
- Можно вынести функциональность, не являющуюся уникальной для приложения в каркас: Отправка уведомлений Работа со справочными данными Ведение логов Обработка ошибок и т. п.
- Может ускорить создание очень похожих и простых приложений, например визиток. Позволит повторно использовать имеющийся код
- Специфика приложений со временем изменяется и тогда каркас, подходивший для них, не сможет обеспечить всех потребностей. Сейчас уже предлагается широкий выбор базовых решений, поэтому изобретать свое может оказать слишком трудоемкой и дорогостоящей затеей. Такой подход мог годиться лет 10-15 назад, когда выбор был невелик.
- Позволяет начать использовать код повторно, основной проблемой является нарушение SRP.
- Основная проблема каркаса в том, что на нем лежит слишком много ответственности. Если выполняемые им функции вынести в независимые модули, то ситуация существенно улушчится. У каждого модуля должны быть зафиксированы входные и выходные контракты, что обеспечит слабую связанность и простоту модульного тестирования. Примечание: аналогичным образом можно поступить и с ядром, если оно сложное.
- При таком подходе можно создавать хорошие монолиты: Команде легко работать над одним таким проектом Код используется повторно Его легко разворачивать, т.к. он состоит из небольшого числа компонентов
- Вызовы функционала осуществляются внутри одного процесса, что положительно сказывается на производительности
- У таких приложений ограничены возможности масштабирования Возможно использовать за NLB, но дублируется вся функциональность, даже если проблема только в одном модуле. Увеличивается сложность администрирования и тестирования. У нас были случаи, когда на нодах оказывались различные версии.
- Хорошо, код используется повторно. А что с данными? При таком подходе могут дублировать справочные данные и осложнено централизованное управление приложениями.
- Недостатки этого подхода становятся более значимыми с увеличением количества приложений.
- Чтобы решить предыдущую проблему, можно взять модули и выделить их в самостоятельные сервисы. Они по-прежнему обладают четкой зоной ответственности, но позволяют использовать повторно не только функциональность, но и данные.
- Они значительно лучше масштабируются. При это развертывание по-отдельности достаточно простое.
- Взаимодействие осуществляется удаленно, что увеличивает время вызова (REST/MQ). Необходимо предусматривать возможность массовых операций, скрывающих данный недостаток. Мало того, что требуется больше времени, так нет и никаких гарантий, что ответ возвращен.
- Со временем возрастает количество связей между системами. Важно поддерживать актуальную информацию обо всех потребителях сервисов, это упрощает решение возникающих проблем или миграции на новые сервера.
- Недостатки этого подхода становятся более значимыми с увеличением количества приложений.
- Сейчас модны микросервисы. Я с ними не работал. Давайте посмотрим и на них, возможно, для ваших предприятий они окажутся лучшим решением. Можно разбить функциональность модулей и сервисов на микросервисы, каждый из которых будет выполнять только определенную функцию, при этом с использованием наиболее подходящей для этого технологии. Новые же приложения будут собираться из готовых блоков.
- Микросервисы очень простые, логика его работы должна укладываться в голове. Если они не справляются с задачей, то их можно переписать. При этом тесты позволят проверить, что ничего не сломалось. К тому же они отлично масштабируются.
- За простоту реализации микросервисов приходится расплачиваться большим количеством связей. И хорошо, если количество просто большое, а не огромное. Кроме того, зачастую вызовы будут асинхронными.
- Также микросервисы полагаются на инструменты, выполняющие сбор различных метрик, диагностику и автоматическое развертывание. Вместо навыков разработки ПО требуются навыки администрирования.
- Начать с микросервисов сложно. При неправильном разбиении рефакторинг будет обходиться дороже, т.к. может повлечь изменение контрактов, слияние или разбиение функциональности. Рекомендуется начинать с монолитов и по мере их роста отладки функциональности модулей выносить их в микросервисы.
- Martin Fowler, James Lewis http://martinfowler.com/articles/microservices.html Мартин Фаулер и Джеймс Льюс в своей статье о микросервисах писали о том, что слабые команды всегда создают плохие решения, но сейчас совсем не понятно, в какую сторону изменится результат при использовании микросервисов.
- Недостатки этого подхода становятся более значимыми с увеличением количества приложений.
- Возможно, вы любите ковыряться в legacy-проектах, пытаясь найти нить здравого смысла? А может быть все таки без архитектуры?
- Строился в течение 38 лет с участием 147 рабочих по заказу Сары (вдовы Вилльяма) Винчертер Более 160 комнат. Не было сделано ни одного чертежа.
- Двери ведут на улицу или в глухие стены.
- Мансардные окна смотрят на верхние этажи. Возможно, кто-то узнает в таком поместье доставшиеся в наследство системы.
- Вернемся в наш отдел. Понятно, что занимаясь только поддержкой имеющихся приложений, ситуацию улучшить не получится. Более того, доработки будут становиться все более сложными и затратными. Мы начали постепенно реализовывать простые сервисы вместе с разрабатываемыми приложениями. Параллельно появлялись модули-клиенты.
- У нас используются как монолиты, так и сервисы. При этом доступ к сервисам обеспечивается модулями-клиентами. Далее я подробнее расскажу о выделенной в модули и сервисы функциональности
- Да, я знаю. Вы любите своих пользователей. Без них ваши системы будут бесполезны, давайте посмотрим, что можно улучшить.
- Допустим, у нас есть несколько систем (как они устроены сейчас не важно). В каждой из них регистрация пользователей происходила независимо. В первой пользователь придумал логин и пароль и пользовался ими. Во второй - регистрация осуществлялась по доменному логину. В третьей - использовалась информация из внешних кадровых систем.
- Начнем с того, что пользователь не понимает, как он входит в системы. Если он пользуется ими нерегулярно, то перед ним возникает проблема вспомнить учетные данные конкретной системы. Нередко системы ссылаются друг на друга, что приводит к необходимости выполнять следующую процедуру входа.
- В некоторых организациях проблему может решить повсеместное использование доменных учетных записей во всех внутренних приложениях. Но нужно учитывать, что логины со временем меняются, системы должны быть к этому готовы.
- В нашей организации многие сотрудники пользуются своими учетными записями настолько редко, что они успевают заблокироваться. Использование системы единого входа может решить и эту проблему. В каждую систему необходимо добавить модуль, реализующий протокол входа. При первом входе пользователь будет переадресовываться в сервис единого входа, где от него может потребоваться ввод учетных данных. Последующие же входы в приложения могут осуществляться автоматически.
- Вернемся к слайду с пользователям. При использовании различных методов входа появляется так же и другая проблема. Как узнать, что учетные записи принадлежат одному сотруднику? При этом проблема усложняется возможными дубликатами: 1. В первой системе пользователь забыл пароль и вместо того, чтобы его восстановить, зарегистрировался повтороно. 2. Во второй у пользователя могла поменяться фамилия, а значит и логин. 3. В третьей сотрудника перевели на другое предприятие и завели в системе повторно.
- Чтобы не сводить пользователей из различных систем постоянно, нужно сделать это один раз и исключить их бесконтрольное создание в дальнейшем. В этом нам поможет сервис управления учетными записями. Также этот сервис может обеспечить формирование событий жизненного цикла сотрудника: принят на работу, поменял имя, сменил место работы, уволен.
- Теперь, когда у нас есть IM + SSO, появляется возможность реализовать еще один сервис - управления правами. В одном месте служба поддержки может выдавать доступ к системам или отнимать его. Администраторы безопасности имеют возможность видеть полную картину по пользователю или системе в случае аудита.
- Как тогда будут выглядеть приложения? Пользователь входит через SSO, мы по нему запрашиваем данные из IM и его полномочия из UM. Выполнив эти шаги, система может позволить пользователю начать работу.
- Работу нескольких систем с собственными справочниками можно сравнить с работой одной системы без справочников вообще. Это приводит к дубликатам, ошибкам, сложностям в логике приложения и сбора сводной информации. Конечно, выносить каждый справочник в отдельный сервис не стоит, но все их можно объединить в один.
- Отдельно можно выделить структуру компании. В крупных компаниях она имеет иерархиечский вид (у нас вложенность достигает 10 уровней). Местоположение должности сотрудника в этой структуре важно не только для его идентификации, но и позволяет назначить ему полномочия на дочерние узлы. В отдельный модуль вынесена обработка иерархических данных, она требуется во многих приложениях.
- Если ваши системы позволяют пользователям прикладывать файлы, то большую часть БД будут занимать именно бинарные данные. Они усложняют поддержку приложения: перед каждым обновлением создаются полные бэкапы, например для одной из наших систем этот процесс занимает больше часа (~300 Gb). Здесь нам важно не столько повторное использование данных, сколько упрощение облуживания самих систем за счет вынесения работы с файлами в отдельный сервис.
- Фотографии тоже занимают много места. Кроме того, разные они не нужны. Для одного сотрудника вполне может быть достаточно одной фотографии в различных разрешениях. Сервис фотографий должен реализовывать возможность изменения разрешения и обеспечивать их хранение. Загрузка новых фотографий осуществляется в одном месте с обработкой в нужные разрешения и сжатием.
- Хорошо, когда приложения пишут логи. Это очень помогает при разборе проблем и анализе ошибок. Еще лучше, когда все логи структурированы, собраны в одном месте. Такие логи можно автоматически просматривать, выявлять проблемные системы еще до появления жалоб от пользователей. Советую посмотреть доклад Анатолия Кулакова
- Общая картина. Сервисы-интрументы своего рода аутисты, им никто не интересен. Зато ими пользуются все. Если они не работают, то остальные продолжат работу. Поставщики данных могут использоваться как приложениями, так и сервисами управления пользователями. Без них часть функций станет недоступной. Сервисы управления пользователям находятся интересны только приложениям. Их наличие критично для приложений, где вход является обязательным. Так же приложения могут общаться между собой.
- Первые версии сервисов появляются быстро