Собственно, зовут меня Юрий, и я работаю (и считаю себя) архитектором решений. В основном, это IT-решения, но и внутреннее устройство аппаратуры, и зданий — это тоже в каком-то смысле архитектура. Они мне тоже интересны и будут появляться тут. Как было точно подмечено, "architecture is an art how to waste space". Эта фраза содержит гораздо больше смысла, чем может показаться сначала.

В настоящий момент я отвечаю за проектирование решений для самой крупной в Европе системы поддержки работы специалистов поликлинического звена [ЕМИАС]. Только никому не говорите :)

В качестве первого материала — иллюстрация, чем архитектор решений отличается от архитектора приложений, например. Моя зона ответственности и интересов сейчас — Solution Architecture

Сегодня мы будем читать, смотреть, крутить слайды про Tomcat.
Не про тот, который джава-мерзость, а про Tomcat CPU — центральный процессор БЦВМ истребителя F-14. Был разработан около 1970 год, и на тот момент представлял интересный и передовой девайс.

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

http://1500py470.livejournal.com/253902.html

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

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

Задач у архитектора несколько:

1. Знать, как надо делать, и особенно — как вписать в текущий системный ландшафт новое решение.
Эти знания он доносит в виде проектов, планов, технологических документов, прототипов и прочих понятных артефактов.

2. Знать, как не надо делать
От этого он оберегает установкой и легитимизацией политик и стратегий, и донесением их до тим-лидов и других представителей команд, отниманием у команд многообразия инструментов и установкой их на рельсы разработки — негибкие, но зато предсказуемые и просчитываемые.

3. Планировать движение продукта и портфеля продуктов на шаг вперёд. Помогать отвечать менеджеру на вопрос "где, сука, план?"
Это делается прототипами и подготовкой пресейлов.

4. Отвечать за нефункциональные требования к продукту
Тут помогают эксперименты и испытания, багаж знаний.

На каждом из этих шагов можно допустить ошибку. Ошибка обойдётся тем дороже, чем на более раннем этапе она допущена. Наличие архитектора — попытка исправить ошибку ещё до того, как на неё будут выделены бюджеты и работа закипит.

Возвращаемся к исходному вопросу.


Вам, скорее всего, НЕ НУЖЕН архитектор, если:

1. У вас одна или парочка небольших команд разработки. Ошибки, допущенные ими, обойдутся всё равно дешевле, чем попытки соблюдать гору дополнительных требований, поступивших от архитектора, и ещё бороться с конфликтами несоблюдения этих требований.

2. У вас "стартап", "эджайл" и "горящие глаза". Стратегическое управление заключается обычно в минимизации рисков усечением количества доступных вариантов результата. Но только не в стартапе. Там стратегическое управление — это увеличение неопределённости и максимизация числа вариантов результата, чтобы даже самый неожиданный вариант выстрелил. Эти два варианта между собой несовместимы, и архитектор будет душить (((креатив))) и тормозить результаты работ.

3. У вас нет легаси-системы с длинным жизненным циклом. Напрмер, вы либо делаете прототипы, либо у вас нет существующего системного ландшафта, куда необходимо вписаться и учесть риски — так зачем тратить деньги и силы на ненужную работу?

Stay tuned.

Голубая мечта многих архитекторов — просчитывать проекты, класть их в стол и получать за это деньги. Не перформеры, т.е. Поосторожнее с ними.

Почему я против микросервисов

Тема, которая сейчас обсуждается очень часто, это микросервисная архитектура (МСА).
Конкретно я придерживаюсь мнения, что МСА это скорее зло для большинства проектов, выходящих из стадии прототипа в долгое плавание в продакшне. Несмотря на то, что мне знакомы некоторые успешные системы, построенные на этом принципе.

Почему я не поддерживаю безмерное распространение? Вот причины, все они — скепсис системного инженера.

1. Мало кто способен дать определение микросервиса. В текущей индустрии микросервис - это "всё то, что мы захотели назвать микросервисом".

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

3. Любое решение состоит из трёх компонент:
- целевая система (то, что мы разрабатываем)
- система в операционном окружении (это бизнес-процессы и т.п. в полях)
- поддерживающая система (разработчики, тестировщики, эксплуатанты и т.п)
Согласно эмпирическому правилу, любая целевая система своей топологией стремится отразить топологию поддерживающей системы. Скажем, если у вас есть два плохо коммуницирующих отдела, работающие над какой-то IT-системой, то и внутреннее устройство результата будет повторять эту ситуацию — две независимые части со слабой коммуникацией между собой.
Так вот, МСА по своей сути отбрасывает, входит в противоречие в этим правилом. Плыть против течения — это лишняя трата сил. Чтобы бороться с энтропией, уходят драгоценные ресурсы, которых обычно и так не хватает

4. МСА гребёт и против эмпирического первого правила распределённых систем, которое формулируется так: если можете не распределять, не распределяйте.

5. Я придерживаюсь мнения, что деление должно проходить по границам бизнес-доменов, а не по техническим границам. Каждый сервис должен иметь некоторое значение для пользователя. Микросервис "генератор уникальных гуидов" для конечного пользователя не значит ничего, т.е. — не имеет прав на существование.

6. Достаточно хорошего разделения на слои и компоненты можно достичь и в монолите, если понять, что выбор Монолит VS МСА - это только выбор средства упаковки и деплоймента решения. Хорошо структурированный монолит — неплохой выбор для типичных задач.

7. Организовать мониторинг, отладку, разные виды тестирования и обеспечить выдерживание SLA в микросервисной архитектуре чудовищно дорого — сложность системы растёт как факториал числа взаимодействующих компонент. Инструменты, которые поддерживают инфраструктуру МСА, пока что далеки от идеала.

Краткий вывод: не ведитесь, пацаны! МСА это средство last resort, когда уже ничего другого не остаётся.

Про GC из личного опыта.

Пока многоуважаемые инженеры JVM со всего мира пилят супер GC в какой-нибудь будущей версии, где всё будет збс, нам, простым пацанам-практиками, надо как-то уметь обращаться с тем, что есть.

Типовой вычислительный юнит у нас выглядит так: 8-ядерный CPU с 16 Гб RAM на борту, на котором стоит, чтобы не соврать "Java HotSpot(TM) 64-Bit Server VM (25.111-b14) for linux-amd64 JRE (1.8.0_111-b14)". Под java выделяется 13 Гб из 16 доступных.

Ситуация при первых пусках системы была ужасной, и её расследование выглядело настоящим детективом. К расследованию был привлечёт эксперт Red Hat по джава Алексей Шипилёв (в частном порядке). Он и указал, что наш GC был чересчур оптимистичен, а когда хватался за работу, было уже поздно что-то делать. С этими мыслями мы и отправились выживать.

Выжить нам помогла минимальная теория и парочка установок.

1. Недостаток памяти, также, как и событие Stop The World, когда машина полностью остановилась на полную сборку мусора — это считается у нас аварией, критическим отказ системы. Такого нужно избегать — пусть сборка происходит параллельно процессу работы программы.

2. Чтобы не кончалась память, в конечном итоге на бесконечности средняя скорость освобождения памяти (скорость работы сборщика) должна быть больше, чем скорость работы мутатора (всех потоков, которые аллоцируют память)

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

4. Кроме того, скорость выделения памяти (траффик памяти) не должна превышать физических пределов JVM и оборудования.

На современном железе скорость выделения памяти в 1000+Мб/сек можно считать достижимой в пиках, скорость в 500Гб/сек не напрягает почти никого. На наших ящиках мы остановились на параметре 100-200 в норме и 500+ в пике, считаем это нормой. Лимит достаточно легко увеличивается простым добавлением количества юнитов за балансировщиком (не забудьте про общее состояние, если оно у вас есть). Таким образом, пункт 4 нас не тревожит. Что же мы делаем для пп 1-3? Здесь и начинается тюнинг.

Прежде всего, мы отказались от того, чтобы использовать SOAP в продуктиве для интерконнектов между компонентами-бэкендами одного продукта.
Точнее, так: контракт обмена описывается всё равно при помощи wsdl, из него генерируется обычным образом java-интерфейс, а далее этот интерфейс реализуется более удобным транспортом, чем SOAP (у нас — Spring Invoker).
Это, что удивительно, дало сильную экономию (вдвое) траффика памяти при отправке/получении сообщений, что само по себе заслуживает отдельного эксперимента — похоже, парсеры xml во всех каркасах веб-сервисов откровенно плохие.

Идём далее.

Сборка JRE (1.8.0_111-b14) достаточно хороша, чтобы задействовать различные тонкие настройки и избежать аварии п.1.

Мы используем сборщик G1 GC, который параллелит сборку старого поколения, и работает с отдельными регионами, практически не блокируя мутатор.
Для того, чтобы выполнить пп.2. и 3, применяется следующее:

1. Ужатый до минимума размер стека потоков.
Для систем массового обслуживания, построенных не на асинхронном I/O, большое количество потоков может оказывать сильное давление на сборщик. Мы древние мамонты, у нас много потоков. Так проще, понятнее, в итоге дешевле. А железо — ну, развернём ещё несколько юнитов.

2. Ключ -XX:InitiatingHeapOccupancyPercent=16.
Указывает jvm, что стартовать цикл пометки мусора к удалению надо, как только будет занято 16% объёма памяти. Это заставляет сборщик очень рано обходить память, не тормозя мутатор, и быстро заканчивать работу, т.к. мусора ещё не набралось много. Типичный цикл пометки: 10-30 секунд, чаще сильно быстрее.

3. Ключ -XX:+UseStringDeduplication
Для тех, кто использует SOAP и большой объём текста (JSON тоже относится), позволяет jvm в фоновом режиме компактифицировать идентичные строки. Их находится реально много — сотни мегабайт в минуту.

4. Ключи -XX:+G1EagerReclaimHumongousObjects -XX:+G1EagerReclaimHumongousObjectsWithStaleRefs
Сборщик G1GC размещает объекты, которые считает "гигантскими", по отдельным регионам. Тут мы говорим ему, что цикл уборки мусора должен как можно ранее убирать и эти объекты. Опыт показывает, что ценой 1-2 ms в каждую уборку мы очищаем около гигабайта здоровенных объектов в минуту (в основном, это сериализованные объекты), которые в противном случае давили бы на сборщик впустую.

5. Ключи -XX:G1HeapWastePercent=2 -XX:G1MaxNewSizePercent=25
По умолчанию, G1 GC подстраивается сам под запрошенное время паузы. Этими ключами мы ограничиваем его возможности адаптации, взамен получаем более стабильное поведение (разброс пауз меньше).

6. Ключ -XX:G1MixedGCLiveThresholdPercent=15
Говорит сборщику, что можно вовлекать в компактификацию регионы, в которых есть уже хотя бы 15% мусора.

Путём этих опытных манипуляций на инсталляции из 6 юнитов мы добились установившейся скорости аллокации в 2.5Гб/сек, и мгновенной скорости уборки в 60-70Гб/с, средней в 10-12 Гб/сек, со средней загрузкой по памяти в 6-9 ГБ из 13 доступных. При этом на сборку машина тратила 70-120 ms каждые 10-20 секунд, что было практически незаметно. Остальные паузы мутатора не превышали миллисекунд и долей миллисекунд, и юнит всегда оставался отзывчивым, а отклик — стабильным.

Таким образом, цель была достигнута, а у системы остался запас в 2-3 раза по памяти, и память перестала быть узким местом.

В твитторе просят рассказать за мониторинг. Ок, скоро будет про него.

Это проблема, да

За мониторинг тележка.

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

Для некоторых это будет диспетчерский центр с эргономичной мебелью и экранами во всю стену. Для других — СМС на пейджер, что система испытывает проблемы. Третьему достаточно периодических картинок в чат, и всё такое.

Поэтому, ваш мониторинг, наверное, совсем не такой, как у нас. А как у нас?

Для нас это инструмент, решающий следующие задачи:
1. Обнаружение нештатного поведения системы
2. Помощь в расследовании инцидентов, когда они случились; при этом нужны данные на глубину неделя-две-месяц.
К сожалению, стабильного повторяемого опыта предотвращения (2), глядя на (1), у нас нет

Что из этого важнее? Оба важнее. Что такое нештатное поведение системы? Да хрен его знает, на самом деле. НО — мы можем зафиксироваться о поведении, когда пользователи вроде как довольны, и когда — недовольны, и интерполировать показатели, пытаясь понять, что так, а что не так.

По этой причине мы обмазались немалым количеством инструментов для:
- сбора логов
- коллекционирования логов
- анализа логов
- трассировки запросов, как синтетических, так и натурально пользовательских онлайн
- некоторые оперативные инструменты типа OEM (Oracle Enterprise Manager — знает всё-всё про состояние и процессы внутри БД).

Для трассировки и заглядывания внутрь мы используем инструменты CA Infrascope и Riverbed.
Прелесть этих инструментов — в том, что они сами подстраиваются под твоё приложение. Достаточно указать агенту, что за приложение стартовано (точнее, попросить приложение подгрузить в себя агент), и дело в шляпе. Агент проанализирует устройство приложения, разберёт его на компоненты, покажет сервисы, которые это приложение выставляет, и начнёт вести статистику по ним. Для каждого входящего запроса покажет статус, время исполнения, результат, и на какие составляющие распадается, включая обращения к внешним сервисам. Плюсы — очень удобно. Минусы — недёшево.

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

Всё это даёт представление о том, каково пользователям работать с нашей системой. Онлайн-статистика постится картинками и табличками в разные чаты (телеграмм, к примеру). Это даёт возможность видеть массовые сбои ещё до того, как на них отреагирует служба поддержки. И не только прямые сбои, но и косвенные. К примеру, если отказал UI, то мы увидим уменьшение числа запросов к бизнес-операциям сервисной платформы.

Теперь про расследование инцидентов — то, что не онлайн.

Логи собираются с каждого узла. Обычно это плейн-текст. Джава, .нет, 1C, логи серверов приложений, access log на шлюзах, логи шины, har-логи с клиентских машин — всё это собирается. Собранные логи транспортируются в места хранения и складируются там. Для этого используются Flume, Greylog, Kafka и прочие. Инструментарий — разнородный. Для хранения и анализа используются тоже разные продукты. Из тех, что помню - Kibana. Важно, чтобы инструмент позволял заглянуть в прошлое, все используемые нами позволяют.

Ну и инструменты, о которых я не упомянул — OEM, разнообразные консоли управления инструментов (типа weblogic-а), консоли шины — нужны для сбора специфичных данных по запросу, в случае расследования ошибок. Это тоже часть мониторинга.

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

Важно: конфигурации и инструменты мониторинга непрерывно меняются, и это нормально для нас.

Когда-то давно, когда я был совсем юн, я участвовал в проекте системы для одного телеком-оператора США.

Бэкенд этой системы был реализован на JavaEE, а фронтальные продукты - на php.

Это может показаться смешным, но это была бомба.

Фронты позволяли передеплоивать страницы по щелчку пальцев.
Если бэкенд не был готов, то на php за 15 минут писалась заглушка, которая могла даже в БД заглянуть.
Разработчиков php достаточного уровня найти было не так сложно.

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

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

В последнее время у нас в компании широко используется SOA, основанная на WSDL/SOAP сервисах. Что самое важное в сервисе, кроме того, что он есть? Его Величество Контракт. Чтобы помочь подрядчикам спроектировать контракт, мы выпустили рекомендации. Буду рад, если они пригодятся и вам.

Рекомендации

Всячески рекомендую к прочтению статью Левенчука про технологии http://ailev.livejournal.com/1275676.html
Этот этап размять мозг необходим, чтобы успешно разобраться в другое его статье, много более содержательной - про модульность. Её я дам завтра.

Что такое технология, можно прочесть в его старой статье http://ailev.livejournal.com/930608.html
Из неё видно, как дисциплина вкладывается в метод, а метод - в технологию, как матрёшки друг в друга

Обещанная статья про модульность. Запаситесь, по меньшей мере, получасом свободного времени, и почитайте не торопясь, пробуя помапить на свои ситуации — тут есть над чем подумать http://ailev.livejournal.com/1294242.html

Всё в том же твиттерочке меня попросили рассказать про самые важные инструменты, которыми я пользуюсь.

Среди самых важных инструментов 3:
1. Переговорка.
2. Инструмент для записей и набросков.
3. Набор ментальных шаблонов для частых случаев анализа и синтеза - да, домашние заготовки, рельсы анализа и синтеза.

Почему (1) это очень важно, важнее всего остального? Потому что отныне для каждой системы или её части, существующей или будущей вам понадобится определить стейкхолдеров, и учесть их интересы. С ростом системы естественные и искуственные барьеры всё больше мешают это делать. Не пообщавшись с самими интересантами, нельзя оказать влияние на систему. Инженерия требований - это теперь тоже про вас: не упускайте шансов пообщаться с носителями требований: спонсоры, пользователи, администраторы, аналитики, да много кто. Не забывайте - систем 3:
- сама целевая
- поддерживающая
- операционное окружение
И во всех трёх есть заинтересованные лица.
Успешная система значит удовлетворяющая всех их.

Что касается записей (2), то тут всё просто: с возрастом память ослабевает. А если и нет - вам всё равно нужен экзокортекс, при помощи чего:
- сможете зафиксировать написанное;
- сможете обсудить это с другими людьми, поводив пальцами по нарисованному. Так модели оживают.

Набор рельсов для мышления нужен, чтобы превратить мозг в инструмент, а не полагаться в такой критичной задаче на интуицию, "авось" и креатив. Разум инженера, решающий задачу, должен быть подобен машинке, в которую засовываются условия задачи, а на выходе появляется понятный, предсказуемый, качественный ответ. Это не должен быть чёрный ящик в стиле "ой, я не знаю, как это я придумал решение".

Про тулинг и методы 2 и 3 расскажу следующим сообщением.