msa что это такое простыми словами
MSA на Xiaomi: что это за программа и как отключить
Если вы, так же как и мы, любите ковыряться в вашем смартфоне Xiaomi, то вы наверняка натыкались на приложение с лаконичным названием MSA. Что же это такое, зачем оно и можно ли его отключить? Давайте разбираться.
ЧТО ТАКОЕ MSA XIAOMI?
Можно утверждать почти со стопроцентной вероятностью, что прошивка MIUI от Xiaomi за все годы своего существования набрала гораздо больше положительных отзывов, чем негативных – не зря же бренд до сих пор остается настолько популярным. Однако почти бескомпромиссная любовь фанатов не означает, что MIUI – идеальная прошивка. Есть и в ней недостатки, и, пожалуй, самый главный из них – назойливая реклама. Наиболее «рукастые» умельцы уже давно разобрались, что за «выдачу» рекламы в родных приложения Xiaomi отвечает то самое MSA.
Официально Xiaomi утверждает, что приложение MSA имеет только одну функцию – поддержка приложений «Живые обои», «Погода» и «Календарь». Однако по Сети уже давно ходит информация о расшифровке трех букв в названии MSA: MIUI System Ads, то есть «реклама в MIUI на системном уровне». Верить этому или нет – решать только вам, но стоит отметить, что эту расшифровку используют такие крупные западные издания, как Android Authority.
Наверняка вы уже знаете, что Xiaomi добавили возможность удалить рекламу почти во всех родных для MIUI приложениях – для этого существуют отдельные пункты в меню данных программ. Но многие не догадываются, что несмотря на отключенную рекламу, траффик, выделяемый на нее, все равно постоянно «долетает» до вашего устройства. В этом и есть самый большой грех MSA.
ГЛАВНАЯ ПРОБЛЕМА MSA
Если вы никогда не пользуетесь мобильным интернетом, то вас MSA, в принципе, не должно беспокоить, но все остальные, так или иначе, будут подмечать увеличенное количество скачанных мегабайт в течение дня. Кроме этого, постоянная работа MSA в фоне может заметно высасывать соки из вашей батарейки. Возникает вопрос – можно ли тогда избавиться от негативных последствий работы MSA?
Многие просто боятся лезть в системные приложения – кто знает, как производитель настроил смартфон? В самом опасении нет ничего плохого, ведь действительно после удаления нужных для прошивки файлов могут появиться ошибки в работе устройства. Однако многие владельцы телефонов Xiaomi на своем личном опыте уже показали, что отключение или удаление MSA не влияет на адекватную работу смартфона.
Проблема состоит в том, что просто так удалить MSA не получится – для этого нужно получение рут-прав. Если вы знаете, как это сделать, то наша помощь и не нужна – с «рутированным» устройством можно делать все, что угодно, вплоть до перепрошивки.
ОТКЛЮЧАЕМ MSA В MIUI 12 БЕЗ ЛИШНИХ ХЛОПОТ
Можно ли отключить работу MSA без рута? Да, и самым простым способом является блокировка его доступа к Интернет-траффику. Заходим в приложение «Безопасность», находим там пункт «Передача данных», а в нем ищем подпункт «Сетевые подключения». Перейдя в это меню, нажимаем на «три точки» сверху, из которых «вываливается» раздел «Фоновые подключения». Заходим в него и находим то самое MSA. Переводим его в положение «Отключено». После этого перезагружаем смартфона и радуемся.
Многие умельцы также советуют выходить из Mi-аккаунта на смартфоне – по их словам, так MSA отключается автоматически. Однако многие привыкли к возможности загружать свои данные в облако, чтобы впоследствии удобно переходить с телефона на телефон, так что это точно не самый комфортный вариант.
Теперь мы разобрались с вами, что же такое MSA и что можно сделать, чтобы вас не раздражала назойливая реклама и быстро разряжающаяся батарейка. Не забывайте о том, что это смартфон должен работать так, как вы хотите, а не наоборот.
Просто о микросервисах
Вступление
Чуть ли не каждый второй, кто впервые сталкивается с MSA (Micro Service Architecture), на первых порах восклицает: «Да я эти микросервисы еще …надцать лет назад». Отчасти они правы. И я тоже был из этой самой половины, и не понимал — почему такой шум?
В самом деле! Ведь MSA — это тоже про разработку софта. Какие здесь могут быть революции? Все методики знакомы. В некоторых местах можно даже удивиться: «А разве бывает по-другому»? Фанаты Agile и DevOps тоже скажут, что это всё наше, родное.
Но всё же прошу вас набраться терпения и продолжить читать дальше.
Что такое микросервисная архитектура (MSA)
MSA — принципиальная организация распределенной системы на основе микросервисов и их взаимодействия друг с другом и со средой по сети, а также принципов, направляющих проектирование архитектуры, её создание и эволюцию.
Что такое микросервис (MS)
Понять суть микросервиса проще всего на сравнении, или даже противопоставлении его крупному приложению — монолиту. В отличии от MSA, я не буду давать определение микросервису, а перечислю его наиболее важные характеристики.
А дальше мы рассмотрим каждую из них подробнее.
Я выделил восемь свойств микросервиса:
Небольшой
Что такое «небольшой»? Такая малоинформативная формулировка! На самом деле, по-другому не скажешь. Каждый должен самостоятельно определиться с размером. Лучше всего на практике. В качестве индикативных оценок можно ориентироваться на рекомендации экспертов. Размер микровервиса должен быть таким, чтобы выполнялось одно из условий:
Независимый
Микросервисная архитектура — воплощение паттернов High Cohesion и Low Coupling. Всё, что противоречит этому, отвергается беспощадно. В противном случае команду ждут большие проблемы. Так что микросервис обязан быть независимым компонентом.
Здесь попрошу вас не начинать холивар о том, что же такое «компонент». Давайте в рамках этой статьи сойдемся на том, что
Компонент — это единица ПО, код которой может быть независимо заменен или обновлен.
Конечно любая мало-мальски серьезная программа пишется с разбиением на компоненты, которые, безусловно, основываются на тех же принципах. Но в монолите общая кодовая база открывает возможности для нарушения низкой связанности. И при слабой дисциплине рано или поздно код превращается в спагетти.
Под такую формулировку компонента подходят и сторонние библиотеки. Здесь сложнее с нарушением границ произвольными связями, но не на много.
В то же время методология разбиения на отдельные микросервисы вынуждает придерживаться жесткого их разделения, ведь они должны отвечать более жестким критериям независимости.
Так, каждый микросервис работает в своем процессе и поэтому должен явно обозначить свой API. Учитывая, что другие компоненты могут использовать только этот API, и к тому же он удаленный, минимизация связей становится жизненно важной.
Такое разделение дает явный выигрыш с точки зрения независимого развития разных компонентов. И с учетом этого различные языки вводят конструкции, позволяющие явное создание независимых компонентов (например, модули в Java 9), и это перестает быть прерогативой микросервисного подхода.
Не хочу, чтобы создалось впечатление, будто в микросервисной архитектуре запрещено использование библиотек. Их использование не приветствуется, поскольку так или иначе приводит к зависимостям между микросервисами, но всё же допускается. Как правило, это допущение распространяется на инфраструктурные функции вроде логирования, вызова удаленного API, обработки ошибок и тому подобного.
Независимость микросервисов позволяет организовать независимый жизненный цикл разработки, создавать отдельные сборки, тестировать и развертывать.
Поскольку размер микросервисов невелик, то очевидно, что в крупных системах их будет немало. Управлять ими вручную будет сложно. Поэтому команда обязана иметь приемлемый уровень автоматизации согласно Continuous integration и Continuous Delivery.
Где же микросервис (бизнес-потребность)
Итак, вы решили спроектировать новый микросервис.
Определение его границ — самый важный шаг. От этого будет зависеть вся дальнейшая жизнь микросервиса, и это серьёзно повлияет на жизнь команды, отвечающей за него.
Основной принцип определения зоны ответственности микросервиса — сформировать её вокруг некоторой бизнес-потребности. И чем она компактнее, чем формализованней её взаимоотношения с другими областями, тем проще создать новый микросервис. В общем, довольно стандартный посыл. На нем основывается создание любых других компонентов. Вопрос только в том, чтобы в дальнейшем выдержать эту зону ответственности, что мы и обсуждали в предыдущем параграфе.
Когда границы микросервиса заданы и он выделен в отдельную кодовую базу, защитить эти границы от постороннего влияния не составляет труда. Далее внутри микросервиса создают свой микромир, опираясь на паттерн «ограниченного контекста». В микросервисе для любого объекта, для любого действия может быть своя интерпретация, отличная от других контекстов.
Но что делать, если границы оказались неправильными? В этом случае изменение функциональности в новом микросервисе ведет к изменению функциональности в других микросервисах. В результате «поплывут» интерфейсы всех зависимых микросервисов, а за ними интеграционные тесты. И всё превращается в снежный ком. А если эти микросервисы ещё и принадлежат разным командам, то начинаются межкомандные встречи, согласования и тому подобное. Так что правильные границы микросервиса — это основа здоровой микросервисной архитектуры.
Чтобы минимизировать ошибки при определении границ, нужно вначале их продумать. Поэтому оправданным является подход Monolith First, когда вначале систему развивают в традиционной парадигме, а когда появляются устоявшиеся области, их выделяют в микросервисы. Но всё течет и меняется. И границы тоже могут меняться. Главное, чтобы выигрыш от разбиения превышал сложности пересмотра этих границ. Такой подход к постепенному формированию набора микросервисов похож на итерационное развитие, используемое в Agile, ещё его называют «эволюционным проектированием» (Evolutionary Design).
Есть ещё одно интересное следствие создания микросервисов, соответствующее закону Конвея (Conwey Law).
Если организация использует монолитное приложение, то оно нарушает соответствие структуре и коммуникациям внутри организации. А команды разработчиков строятся вокруг архитектурных слоев монолита: UI, серверная логика, база данных.
Микросервисная архитектура приводит IT и бизнес в гармонию, с точки зрения Конвея. Поскольку микросервисы формируются вокруг бизнес-потребностей конкретных бизнес-подразделений, то архитектура предприятия начинает повторять оргструктуру и каналы социальной и бизнес-коммуникации. А команды становятся кроссфункциональными и формируются вокруг этих бизнес-потребностей / бизнес-подразделений.
Поскольку разные микросервисы получаются независимыми не только логически, но и технологически, а создавать их могут разные команды, ничто не мешает для каждого случая подбирать подходящие языки программирования, фреймворки и даже операционные системы.
Интеграция. Smart endpoints and dumb pipes
Интеграция микросервисов обходится без ESB, как центрального промежуточного звена. Наверное, комьюнити уже натерпелось от неудачных вариантов реализации этого подхода. То, что были и удачные — не принимается в расчет. Впрочем, ESB ещё и противоречит таким критериям как децентрализация и независимость. Таким образом, сложность интеграции распределяется с центрального звена в виде ESB непосредственно на интегрируемые компоненты: «умные конечные точки».
Здесь есть дилемма. Конечно бинарные протоколы гораздо эффективнее. Но, во-первых, появляются технологические ограничения. Во-вторых, на бинарных протоколах сложнее реализовывать шаблон Tolerant Reader, сохраняя эффективность. В-третьих, опять появляется зависимость провайдера и потребителей, поскольку они оперируют одними и теми же объектами и методами, то есть связаны по кодовой базе.
Другая отличительная черта взаимодействия микросервисов — синхронные вызовы не приветствуются. Рекомендуется использовать один синхронный вызов на один запрос пользователя, или вообще отказаться от синхронных вызовов.
И еще пара замечаний.
Design for failure для распределенной системы
Одно из наиболее критичных мест в микросервисной архитектуре — необходимость разрабатывать код для распределенной системы, составные элементы которой взаимодействуют через сеть.
А сеть ненадежна по своей природе. Сеть может просто отказать, может работать плохо, может вдруг перестать пропускать какой-то тип сообщений, потому что изменились настройки файрвола. Десятки причин и видов недоступности.
Поэтому микросервисы могут вдруг перестать отвечать, могут начать отвечать медленнее, чем обычно. И каждый удаленный вызов должен это учитывать. Должен правильно обрабатывать разные варианты отказа, уметь ждать, уметь возвращаться к нормальной работе при восстановлении контрагента.
Дополнительный уровень сложности привносит событийная архитектура. А отладку такой системы — не одного микросервиса, а системы, где много потоков разнонаправленных неупорядоченных событий — даже трудно представить. И даже если каждый из микросервисов будет безупречен с точки зрения бизнес-логики, этого мало. По аналогии со спортом, «звёзды» не гарантируют звездную команду, ведь в команде важнее не «звезды», а слаженность всех её игроков.
И поскольку сложность таких систем очень высока, то проблему решают так.
Децентрализация данных
Каждому микросервису по своей базе данных!
Лозунг популиста на выборах.
На самом деле и в монолите можно побороться за изолированность компонентов, например, на уровне серверного кода. Если время от времени изоляция даёт течь, современные инструменты предлагают продвинутые инструменты рефакторинга. Пользуйтесь. Хотя, как правило, на это находится время, только когда дела уже совсем плохи.
Теперь опустимся ниже, на уровень базы данных. Почему-то здесь на изолированность обращают внимание гораздо реже. В результате через пару тройку лет активного развития в базе данных монолита образуется если не хаос, то энтропия продвинутого уровня. Чтобы её побороть, мало уже одной строчки в бэклоге. Необходимы месяцы кропотливого и долгого труда.
В микросервисной архитектуре это решается гильотиной. Общей базы данных просто нет.
Помимо изолированности есть и побочные плюсы. Например, легче реализовать Polyglot Persistence, когда база подбирается под конкретные цели. Ничто не мешает делать это и без микросервисов, и так часто делают. Но всё же в одном случае это закон, в другом — исключение.
У этой медали есть оборотная сторона. Много баз, много контекстов, как их все согласовать? Старая техника распределенных транзакций сложна и обладает низкой скоростью. Возможно это иногда можно пережить. А вот необходимость синхронного взаимодействия нескольких микросервисов не может устраивать, и это не побороть.
Проблема решается нетрадиционно для монолита: отказом от постоянной согласованности данных. Добро пожаловать в мир Eventual consistency. На первых порах это вызывает волну «справедливого» гнева. Но если разобраться, то нужна ли повсеместно немедленная согласованность данных по окончании транзакции? При детальном рассмотрении значительную часть случаев можно отбросить. Где возможно, заменяют одну распределённую транзакцию серией локальных с компенсационными механизмами. Где-то мирятся с временной несогласованностью. А возможные ошибки либо обрабатывают за счет более сложной архитектуры, либо благодаря данным мониторинга. Если ничего не получается, то в особо экстремальных случаях всё же используют распределенные транзакции. Но это, с моей точки зрения, нарушение принципов MSA.
Монолит против микросервисов
Микросервисный подход несет довольно много проблем. Их найти не трудно и каждый может поупражняться.
Например, организационные вопросы. Как удержать в согласованном по версиям состоянии сотню микросервисов, которые еще и постоянно и непредсказуемо редеплоятся. А доступ к средам у каждого инженера каждой команды? Какая команда напишет интеграционные тесты? И если кто-то согласится, то попробуй еще их напиши для такой запутанной конфигурации. А если возникает ошибка, то чья она? Только той команды, у которой сломалось? Как не узнать вечером в пятницу, что версия API N-го сервиса, которой вы пользуетесь, вдруг стала deprecated?
Да, это действительно проблемы. Но команды, которые практикуют Agile и DevOps, уже знают решение. Поэтому начинать путь к микросервисной архитектуре стоит с внедрения этих практик.
Кроме организационных есть и чисто архитектурные. Как перейти от монолита, где всё синхронно, согласованно и едино, к распределенной событийной архитектуры, основанной на множестве мелких элементов, в которой надо учитывать возможную неконсистентность данных? Одного этого достаточно, чтобы задуматься: а стоит ли игра свеч? На этом фоне, например, падение скорости обработки одного запроса кажется мелочью. Хотя бы работает!
Тогда зачем? Если у вас нет проблем с вашим «монолитом», то не надо их искать.
Но если проблемы есть, то посмотрите на плюсы MSA, и возможно она спасет вас.
Разбиение на независимые компоненты даёт безусловные и неоспоримые преимущества: легкое понимание контекста, гибкость развития, управления и масштабирования. Независимость и небольшой размер дают и неожиданные плюсы с точки зрения инфраструктуры. Вам теперь не нужна монструозная машина за 100500 долларов. Микросервисы можно устанавливать на обычные дешевые машинки. И окажется, что даже все вместе они будут стоить на порядок меньше, но работать эффективнее той самой супермашины, на которую у вас в организации, наверняка, молятся и сдувают с неё пылинки.
Здесь уместен другой лозунг от популиста. Хотя, как и предыдущий, он вполне серьезен.
Каждому микросервису по своему серверу!
Продолжим агитировать за микросервисы. Посмотрим на лидеров IT-индустрии: Amazon, Netflix, Google и другие показывают впечатляющие результаты. Их гибкость и скорость вывода новых продуктов поражают. Поэтому игра точно стоит свеч! Здесь уместно вспомнить, что в упомянутых организациях команд «уровня бог» не одна и не две. Им сложности микросервисной архитектуры вполне по зубам. И если предложить создать монолит, то они и его сделают так, что он будет сверкать путеводной звездой.
А, например, Amazon вполне себе работал на монолите, уже будучи гигантом и имея миллиардные обороты. Сайт газеты Guardian до сих пор, а возможно и навсегда, базируется на микросервисах вокруг монолита. Это говорит о том, что значительная часть задач успешно, а зачастую и легче, решается без привлечения микросервисов.
И всё же это не значит, что микросервисы не для вас. Не боги горшки обжигают. Но бросаться с головой в омут тоже не стоит. Для микросервисной архитектуры команда должна быть достаточно зрелой. Один из главных критериев: использует ли она Agile и DevOps? Команда должна быть грамотной. Это сложно формализовать, но всё же попробуйте трезво оценить возможности. Например, насколько команда продвинута в Reactive и Event-Driven Architecture? К тому же команда должна иметь подготовленную инфраструктуру для поддержки микросервисной системы.
Впрочем, достаточно. Просто попробуйте. Надеюсь, получится и понравится.
MSA и не только: как мы создаем высоконагруженные сервисы для банка
Проектирование высоконагруженных сервисов уже не является таинственным мастерством, которым владеют лишь просвещенные сэнсеи. Сегодня для этого существуют вполне устоявшиеся практики, которые комбинируются и видоизменяются в зависимости от особенностей компании и ее бизнеса. Мы хотим рассказать о наших лучших методиках и инструментах создания высоконагруженных сервисов.
Сразу оговоримся, что речь пойдет о заказной разработке. Как завещал нам здравый смысл, проектирование мы начинаем с постановки бизнес-задач. И в том числе определяем, будет ли система высоконагруженной. Понятно, что со временем она будет меняться (например, изменится профиль нагрузки), поэтому при описании бизнес-логики мы закладываем вероятные пути развития там, где это возможно. Скажем, если это какой-то сервис по обслуживанию клиентов, то можно спрогнозировать изменение размера аудитории. Иногда бывает сразу понятно, как система будет меняться со временем, а некоторые контрольные точки трудно поддаются прогнозу.
На начальном этапе мы можем посчитать объемы данных, которые нам нужны для хранения, посчитать начальную нагрузку на наш абстрактный сервис и скорость ее роста. Также можно классифицировать данные по виду работы с ними: хранение, запись или чтение, и в зависимости от этого оптимизировать процессы.
У нас есть KPI по работе системы, на основании которых определяется допустимая степень ее деградации. Для большинства систем критичным является время отклика. В некоторых случаях оно может достигать нескольких секунд, а в других счёт идёт на миллисекунды. Также на этом этапе определяется степень доступности системы. Как правило, мы разрабатываем высокодоступные системы или системы непрерывного режима работы: с уровнем доступности от 99,9% до 99,999%.
Определившись с бизнес-логикой, допустимыми объемами данных и поведением системы, начинаем строить диаграммы движения данных. Это необходимо для того, чтобы понять, какой шаблон проектирования лучше всего выбрать. И после построения диаграмм приступаем к самому проектированию.
Микросервисы — buzzword нашего времени
В последнее время при создании высоконагруженных систем мы предпочитаем сервис-ориентированную архитектуру. В частности, столь модную в последние годы микросервисную: берем функциональность системы и разбиваем её на небольшие кусочки — сервисы, каждый из которых выполняет какую-то маленькую задачу. Сервисов может быть очень много, сотни или тысячи. Такая архитектура облегчает поддержку системы, а вносимые в отдельные сервисы изменения гораздо меньше влияют на систему в целом.
Также ещё одна важная плюшка микросервисной архитектуры — хорошая масштабируемость.
Но кроме весомых достоинств у микросервисной архитектуры есть и существенный недостаток: не всегда возможно разделить бизнес-логику на достаточно маленькие функциональные кусочки.
Задача эта сложная, и, как правило, решается на этапе проектирования. Обратной стороной медали является межсервисное взаимодействие. Необходимо следить за тем, чтобы накладные расходы на обмен сообщениями были не слишком большими. Достигается это в основном за счёт выбора эффективных методов сериализации/десериализации данных (об этом чуть ниже), перемещения взаимодействующих сервисов «поближе» друг к другу или объединения их в один микросервис. Зато если удается успешно разделить логику на мелкие задачи, то к вашим услугам будут все преимущества микросервисной архитектуры.
Микросервисная архитектура позволяет разместить сервисы на большом количестве узлов и заложить необходимое резервирование на случай выхода каких-то узлов из строя (тьфу-тьфу-тьфу). Схема резервирования во многом зависит от исходных задач. Где-то нельзя допускать пауз и требуется моментальное восстановление сервиса — в этом случае используется схема Active/Active, когда балансировщик мгновенно отключает вышедший из строя узел. В других случаях допустим небольшой простой на время восстановления сервиса, и тогда используется схема Active/Standby, когда резервный узел становится доступен не сразу, а через небольшой промежуток времени, пока сервис автоматически переносится на резервный узел.
Очевидными примерами необходимости использования вариантов схем Active/Active могут служить сервисы удаленного банковского обслуживания – интернет- и мобильный банкинг.
Если говорить точнее, то новые системы в банке проектируются как набор микросервисов на платформе Spring Boot. Основные причины выбора Spring Framework были ее широкое распространенность на рынке ИТ-услуг, а также относительная простота ее использования при разработке сервисов и микросервисов.
Для взаимодействия с пользователем, как правило, используется веб-интерфейс, разработанный с использованием React или Angular, взаимодействующий с серверными компонентами через Rest API.
Отдельная тема — взаимодействие компонентов MSA между собой, а также их интеграция с существующей ИТ-экосистемой. Наряду с традиционными подходами, такими как очереди MQ, мы активно внедряем новые паттерны взаимодействия на основе слабой связанности и платформы Apache Kafka.
Языки и фреймворки
Сейчас достаточно много технологий, позволяющих строить высоконагруженные системы с небольшим временем отклика. Но их состав постоянно меняется: постоянно приходит что-то из мира Open Source, разрабатываются новые внутренние проекты, часть из которых тоже переходят в стан открытого исходного кода. Однако мы предпочитаем проверенные решения известных вендоров. Наша задача — наращивать компетенции в использовании подобного рода систем.
Трудно представить себе высоконагруженную систему, не использующую кэширование данных. Хотя здесь на рынке большой выбор инструментов, обычно мы придерживаемся проверенной «классики» — Memcached и Redis. Но в последнее время стали поглядывать в сторону Apache Ignite, на некоторых проектах он хорошо зарекомендовал себя в роли распределённого кэша.
Что касается выбора языков программирования, то многое зависит от задачи. Как правило, выбор падает на Java — тут и большое количество фреймворков, позволяющих быстро и качественно реализовывать необходимую функциональность, и большое количество настроек самой JVM, позволяющих добиться необходимых показателей производительности.
При проектировании MSA мы тоже придерживаемся стека технологий Java. Помимо унификации это позволяет нам легко интегрироваться с уже работающими в банке приложениями через традиционные механизмы интеграции — очереди MQ, веб-сервисы, многочисленные API на основе Java. Также это позволяет использовать имеющийся на данной платформе развитый инструментарий разработки и управления микросервисами.
Немаловажно и то, что на российском рынке уже довольно много специалистов по разработке MSA-приложений с использованием технологического стека на основе JVM.
Хранение данных
Что касается хранения данных, то в первую очередь при проектировании возникает вопрос: какую модель данных должна использовать СУБД — реляционную или какую-то другую? От выбора зависят дальнейшие методики повышения эффективности обработки запросов к базе данных, ведь высоконагруженные сервисы априори должны обладать маленьким временем отклика. Если мы говорим о реляционных СУБД, то их использование в высоконагруженных проектах требует решать задачи повышения эффективности запросов. Начинается всё с анализа плана запросов.
Как правило, по его результатам мы меняем сами запросы, добавляем индексы. Можно применять партиционирование к таблицам, сокращая объемы данных при выборках с помощью ограничения их рамками одной или нескольких партиций. Также часто приходится использовать денормализацию данных, внося некую избыточность — так можно повысить эффективность запросов.
А с нереляционными СУБД приходится использовать практически индивидуальные подходы в зависимости от конкретного продукта, от бизнес-сценариев. Из общих подходов можно выделить разве что отложенную обработку трудоёмких вычислений.
Безусловно, всё зависит от конкретной задачи, но если есть возможность, то мы используем Oracle, потому что написание эффективных запросов и настройка занимает у наших инженеров меньше времени. Также в последнее время мы часто смотрим в сторону Apache Ignite.
Масштабирование
Как говорилось выше, мы не всегда можем предсказать, какую нагрузку будет испытывать создаваемая система через полгода или год. И если не заложить возможность масштабирования, то система очень быстро перестанет справляться с растущей нагрузкой. В зависимости от конкретного проекта применяется вертикальное или горизонтальное масштабирование. Вертикальное — увеличение производительности отдельных компонентов за счёт добавления ресурсов в рамках одного компонента/узла; горизонтальное — увеличение количества компонентов/узлов, чтобы распределить по ним нагрузку.
Масштабировать сервис или компонент гораздо проще, если он использует stateless-парадигму, то есть не хранит в себе контекст между запросами. В таком случае мы можем запросто развернуть в системе несколько копий этого компонента или сервиса, сбалансировав нагрузку между ними. В случае stateful-парадигмы нужно позаботиться о том, чтобы балансировка учитывала наличие состояний у компонентов/сервисов.
Физический мир
Тесты, тесты, и ещё раз тесты
Запуск высоконагруженной системы немыслим без нагрузочного тестирования. Под нагрузочным тестированием понимается проверка достижения определённых KPI на входе. Из нашего опыта, большая длительность обработки запросов чаще всего связана с неэффективностью алгоритма. Также росту производительности способствует кэширование данных при большом количестве однотипных запросов.
Тесты позволяют выявить узкие места, которые мы могли упустить из виду при проектировании. Веб-сервис, реализованный в рамках одного из проектов, при нагрузочном тестировании работал с низкой производительностью, несмотря на свою простоту. Профилирование показало, что большую часть времени занимала сериализация-десериализация данных, то есть в основном мы перегоняли структуры данных в битовое представление и обратно. Решение нашлось достаточно быстро — характер данных был таков, что они изменялись крайне редко. Мы смогли реализовать предсериализацию данных (заранее подготовив сериализованное представление), и сильно сократили время отклика.
Оптимизация сериализации для внешнего API (предсериализация)
Наряду с нагрузочным тестированием, в рамках которого мы проверяем систему на соответствие предъявляемым требованиям, мы также проводим нагрузочные испытания. Цель таких тестов — узнать предельную возможную нагрузку, которую способна выдерживать система.
Мониторинг
Метрики выполняют роль датчиков, ими густо усыпана любая серьезная система, в особенности высоконагруженная. Без метрик любая программа превращается в черный ящик со входами и выходами, непонятно как работающая внутри. При проектировании в архитектуру закладываются измерители, генерирующие информацию для системы мониторинга.
В некоторых проектах для визуализации активности системы и ее мониторинга использовался ELK (Elastick Search Kibana). У этого фреймворка гибкий интерфейс, позволяющий просто и быстро настроить необходимую форму отчетности.
Мониторинг Kibana