Больше отличных статей.
«Микросервисы — это не все, а лишь подмножество определенного домена».
С таким количеством компонентов мониторинга всегда найдется подходящий для вас
«С Нетти, что мы разрабатываем? 》
«Вероятно, это наиболее подходящая спецификация Redis».
«Портрет программиста, десять лет взлетов и падений»
Самая полезная серия:
«Наиболее часто используемый набор навыков «vim» в производственной среде Linux.
«Наиболее часто используемый набор навыков «Sed» в производственной среде Linux.
«Наиболее часто используемый набор навыков «AWK» в производственной среде Linux.
Мы изучаем SpringCloud, казалось бы, узнали SC Niubi Hong Hong, чувствую себя невероятным взглядом. Но микросервисы по приложениям корпоративного класса, только небольшая часть. Micro Services на вопрос еще больше проблем, чем он решает, вы столкнетесь с различными узкими местами.
Микросервисы решают проблему вычислительных узлов, но основной причиной являются узлы хранения. Когда масштаб бизнеса становится все больше и больше, хранение, кодирование и управление станут проблемами.
Далее поговорим о каких-то универсальных истинах, и не надо ставить ярлыки типа «хх лучших практик компании».
Ниже приведена диаграмма, связанная с микросервисами, вызванными расширением данных, которая проста, но не проста. Пока у малых и средних компаний есть эти элементы, они могут играть очень хорошо, у более крупных компаний из-за их крупного масштаба каждый компонент будет сталкиваться с узкими местами, и так называемая специальная оптимизация не может быть отделена от его сути.
Тогда мы начинаем.
Обратите внимание, что эта диаграмма представляет собой только основной путь данных, подмножество, другие, включая CDN, коммуникационный уровень и т. д., здесь не перечислены.
Эта диаграмма не содержит конкретной архитектуры конкретного поля, а представляет собой общий обзор. Начнем с узкого места емкости базы данных и посмотрим на долю микросервисов в ней.
база данных
Для хранения пользовательских данных существует база данных. За прошедшие годы NoSQL не развеял опасений разработчиков, поэтому такие системы, как MySQL, по-прежнему являются предпочтительным хранилищем для большинства компаний.
Предполагая, что ваш бизнес хорошо растет, это намного интереснее. В начале проекта, чем больше в sql вы играете, тем больше ям закопаете для будущих поколений. Поскольку функции sql слишком богаты, если вы не будете осторожны, вы будете хвастаться своими навыками. Вы обнаружите, что чем больше лес, тем выше требования спецификации для SQL. Некоторые официально объявленные функции строго запрещены внутри компании.
Рынок очень хорошо развивается, и наконец приходит возмездие. То, что раньше было уловкой, теперь стало обузой. Медленный запрос, полнотекстовое сканирование, убойные трюки. Если я хочу добавить кеш, я обнаруживаю, что не могу начать; я хочу создать подбазу данных и подтаблицу, но обнаруживаю, что отношения между таблицами сложны.
Маленькие и широкие столы
Итак, первый шаг – засыпать яму. Для совместного запроса бизнеса с более чем 3 таблицами высокая вероятность необоснованна. Перед добавлением кеша, подбазы данных и подтаблицы вам все равно придется перепроектировать таблицу данных.
Забудьте о парадигмах баз данных, у нас будет два типа таблиц: маленькие и широкие.
Небольшой стол предоставляет основные данные, возможно, простой кВ. Некоторые совместные запросы - это прямой цикл может быть разделен в программе. 10 MSEC в циклическом программе 1000 запросов, запросы, чем один намного сильнее, занимает 6 секунд. Это характерно для распределенной системы, небольшого периодического потребления пакетного запроса, больше жизнеспособности, чем там.
Широкие таблицы предоставляют аналитические данные, обычно используемые для важной функции, но с избыточностью. В таких таблицах обычно много полей, а избыточные данные получаются путем объединения во время записи, что обычно используется в сценарии большего чтения и меньшего количества записи.
После завершения этого шага можно приступать к следующей работе.
Подбиблиотека и подтаблица
существует«Подбиблиотека и подтаблица»? Отбор и процесс должны быть осторожными, иначе все выйдет из-под контроля»., подробно объясняется выбор подбазы данных и подтаблицы, а также приведено краткое введение в процесс.
Подбаза данных и подтаблица, скорее всего, вводят какое-то промежуточное программное обеспечение, потому что недостаточно разделить базу данных. HA, FailOver и другие функции необходимы одновременно.
Подбиблиотека разделена на вертикальный подраздел и горизонтальный подраздел. Вертикальный аспект — это разделение бизнеса, то есть некоторые таблицы выделяются в другие базы данных в соответствии с бизнес-логикой; горизонтальный аспект — это емкость, то есть данные имеют способ расширения в режиме подбазы данных и подтаблицы.
Данные должны иметь измеримую размерность сегментации, иначе они будут слишком разбросаны или слишком перекошены, что повлияет на последующую обработку.
синхронизация данных
Если есть общий ресурс, будет и комбинация, например, для некоторых сервисов отчетов требуются полные данные.
Надо сказать, что это очень глупая идея, чтобы разные компании делились данными, разделяя базу данных. В настоящее время необходимы некоторые инструменты синхронизации данных.
Можно сказать, что компонент синхронизации данных является обязательным компонентом для компании. Существуют инструменты синхронизации с высокой задержкой, основанные на времени последнего обновления, и инструменты синхронизации с малой задержкой, основанные на binlog. Для стабильности в некоторых компаниях предусмотрена так называемая мультирумная синхронизация.
Синхронизация данных больше всего боится исключений, потому что большинство синхронизаций имеют последовательные требования. Когда все работает хорошо, все счастливы, когда возникает исключение, нужны другие средства для обеспечения синхронизации данных и задержки во время исключения.
Это все грязная работа, автоматизация иногда может иметь неприятные последствия, и мониторинг стоит на первом месте.
многоуровневое хранилище данных
Можно предвидеть, что даже если вы разделите базу данных и таблицу, вы все равно сможете быстро добраться до узкого места. После подбазы данных и подтаблицы некоторые из ваших статистических функций могут быть недоступны.В некоторых традиционных системах управления это недостаток.
Необходим иерархический уровень хранения данных. Какое-то ваше дело, может ветка mysql, а другое условие стало ES.
Разные БД делают разные вещи. РСУБД используется только для хранения данных и запросов, что представляет собой плоский и быстрый канал данных; специальная автономная высокопроизводительная БД используется для агрегации и научных вычислений; распределенное хранилище, подобное RT, используется для хранения некоторых данных среднего масштаба. и Обеспечить некоторые функции поиска со средней задержкой, массивную систему хранения, хранить все исторические записи системы и предоставлять функции автономного анализа.
Кто гарантирует многоуровневую структуру хранения данных? Помимо части работы по распространению данных через MQ, нам все еще приходится полагаться на наш компонент синхронизации данных.
тайник
Но нагрузка на БД настолько велика, что приходится думать о кэшировании. Кэш нельзя использовать без разбора.Есть два принципа: первый - кеш не может вторгаться в бизнес, то есть не может нести бизнес-логику; другой - хитрейт кеша должен быть высоким, иначе он будет контрпродуктивен . Кэш является дополнением к высокоскоростным и высокоскоростным интерфейсам и является необходимым и недостаточным условием стабильности системы.
В дополнение к кластерам внешнего кеша, таким как Redis, кеш внутри JVM также является важным местом. Кэш существует из-за медлительности устройства ввода-вывода и обычно размещается в памяти, которая исчезает после отключения питания.
Кэширование включает синхронизацию данных между исходной базой данных и базой данных кэша. Обычно при обновлении исходной библиотеки соответствующие данные в кэше удаляются одновременно, чтобы в следующий раз можно было прочитать самые последние данные.
модульный
Пришло время модульности проекта, ведь кодовую базу делят сотни программистов, а риск уже высок.
Модульность обычно разбивается по направлениям деятельности. Например, разделение модуля оплаты и модуля отчетов.
После разделения модулей аналогичные модули совместно используют базу данных. Тем не менее, это больше решается за счет избыточных данных, которые могут разделить бизнес, так что при возникновении некоторых проблем другая часть может работать хорошо. Например, если по соседству произошло убийство, вы все равно можете пойти на работу на следующий день.
Найти способ взаимодействия между модулями, такими как использование httpClient, OKHTTP и так далее. Важное название единства, существует единое позже на высоком: RPC.
Очень вероятно, что небольшой модуль перерастет в большое бизнес-направление, а может остаться незамеченным.
MQ
Другим способом обмена данными или взаимодействия данных между модулями является MQ. В дополнение к отсечению пиков и другим функциям MQ больше меняет режим взаимодействия, разделение бизнеса.
Kafka используется почти каждой компанией с максимальной пропускной способностью в сотни тысяч. RabbitMQ, RocketMQ и т. д. больше используются в сценариях с очень высокими требованиями к надежности, но потребляют больше машин.
Ресурсы MQ, как правило, требуют абсолютно высокой надежности.Как инфраструктура, если возникает проблема, это приведет к очень большой аварии. При проектировании следует учитывать поток обработки данных в нештатных условиях и стратегию компенсации после восстановления MQ.
Разумно спроектировать кластер MQ меньшего размера, чтобы избежать взаимного влияния сообщений разных сервисов и разных уровней надежности. MQ должны быть изолированы друг от друга с точки зрения бизнеса и функций, чтобы достичь минимального набора услуг.
Чтобы избежать влияния простоя MQ на нормальный бизнес, MQ на неважных ссылках не может блокировать нормальную работу бизнеса.Такого рода сообщения обычно отправляются через асинхронные потоки.
Микросервисы
Мы использовали обмен сообщениями и модульность, чтобы разделить систему на несколько проектов. Управляйте этими проектами унифицированным образом, а также унифицируйте режим их взаимодействия и управление, описанное выше, что является областью применения микросервисов.
Микросервисы — это процесс нормализации многомодульного проекта. Нестандартные сервисы и микросервисные системы какое-то время будут сосуществовать. Как обеспечить замену старых и новых сервисов — вопрос управления.
функциональные компоненты
Согласно описанию SpringCloud, если сервис хочет быть обнаруженным, ему необходимо зарегистрироваться в общем реестре, а другие сервисы могут получить его экземпляр из того же места и вызвать его.
И функция, которая фактически генерирует вызов, — это функция RPC. RPC должен учитывать ряд функций, таких как тайм-аут, восстановление и автоматический выключатель. На некоторых узлах с очень интенсивным трафиком можно также рассмотреть возможность прогрева.
RPC, чтобы иметь возможность генерировать некоторые статистические данные, такие как TPS, QPS, значение TP и т. Д., Это понятно, что SpringCloud отсутствует, мы должны быть проанализированы с помощью внешней системы.
Перед тем, как поток внешнего запроса передается на интерьер, необходимо пройти через слой шлюза. Как и некоторые универсальные операции, такие как разрешения, ограничение тока, оттенки серого и т. Д., Можно обрабатывать в слое шлюза.
Служба управления
Наиболее важной особенностью микросервиса является его функция управления. Управление услугами основано на информации мониторинга. Подсчитав размер, затраты времени и распределение каждого вызова, можно получить общую топологию службы.
Обычно наиболее полезной является следующая информация: 1. QPS, распределение qps временного ряда, максимальный интервал qps 2. Среднее время отклика, среднее время отклика интерфейса, максимальная трудоемкость и минимальная трудоемкость 3. Распределение значения TP, 90%, 99% и другие запросы выполняются в течение x времени.
С помощью приведенной выше информации услуга может быть профилирована. Это база данных для расширения, сокращения и специального управления.
Еще одна проблема, связанная с микросервисами, — это цепочка вызовов, которая представляет собой фактический путь запроса. Устранение неполадок в распределенной среде может быть очень сложным.Цепочка вызовов может помочь отделу исследований и разработок быстро обнаружить проблемы и понять поток бизнес-данных.
Целью управления услугами является поиск необоснованных запросов и распространения. Например, определенный интерфейс занимает слишком длинное; определенный интерфейс имеет большое количество запросов и необходимо кэшировать; определенная функция зависит от длинной цепочки и необходимости оптимизации бизнеса. Отказ
Управление услугами требует большого количества внешних инструментов анализа, более общих бизнес-моделей и поддержки платформ больших данных.
Мы также включили мониторинг/аларминг в часть управления услугами, в«Так много компонентов мониторинга, всегда найдется подходящий для вас»В , мы подробно обсуждаем технические варианты для части мониторинга.
бревно
Функция сбора журнала - значит собрать разбросанные журналы в одно место, и его главная задача - это объем данных.
Обычно журнал делится на две части, одна часть заполнена, резервная копия которой может быть скопирована на хост-бастион журналов или hdfs посредством временной синхронизации; другая часть представляет собой отфильтрованный журнал, например некую аномальную информацию, которая сосредоточена в определенная платформа для обработки сигналов тревоги.
Многие разработчики любят выводить данные о поведении пользователей в лог-файлы, после того как эта часть логов будет собрана, некоторые рекомендации и модели будут получены с помощью потоковых вычислений или офлайн-вычислений. Лог-информация перешла в категорию обработки больших данных, и мы не будем ее слишком подробно описывать.
Непрерывная интеграция
Если у компании определенного масштаба есть система, над которой стоит поработать ее технической команде, то система релизов — одна из них.«Неужели так сложно опубликовать систему?», обсуждается возможная модель.
Издательская система — это удобный скин для кучи скриптов. Некоторые инструменты обработки, проверка выпуска и возможности CI/CD могут быть легко добавлены в вашу систему выпуска.
Многие статьи в продвижении микросервисов, говорили о виртуализации (Docker) и т. Д., На самом деле, не нужно. Виртуализация уменьшает оркестографию с временной службой и может способствовать проведению расширения и сокращения объема, но для мониторинга, коллекции журнала, топологии сети, требуют относительно высокого. Последнее предложение не является первым шагом во всей системе.
Ваша система гибкая, она также связана с культурной средой компании. Если последний процесс одобрения строки должен идти в неделю или два, чтобы сделать быструю непрерывную систему интеграции не так необходимую.
инфраструктура
Инфраструктура больше относится к системе эксплуатации и обслуживания, которая является краеугольным камнем, поддерживающим здоровое развитие всей системы. Я склонен разделять базовые операции и инфраструктуру, потому что их модель и культура являются краеугольным камнем исследовательской среды компании.
END
Эта система выглядит простой и имеет фиксированные решения. Но проблема в том, что многие компании играли столько лет от основания до банкротства, но до сих пор не играли хорошо.
Какая жалость.