Автор: Ван Кан
Baishan Co-founder and Vice President of Products. Mr. Wang Kang is mainly responsible for product improvement and upgrading, product development process control and progress coordination, product design improvement and periodic optimization, product life cycle management and so on. He led the team to realize many innovations of Baishan's first product CDN-X, reduce the threshold of using CDN, greatly expand CDN customer resources, enhance the brand value of Baishan, and promote the expansion and development of the overall CDN market. Mr. Wang Kang has worked in NetSuite Technology as a senior product and pre-sale director of the company, responsible for the operation of the technical team. He has 10 years experience in CDN industry, focusing on improving the high quality and reliability of product output. Mr. Wang Kang has three patents for invention.
Сейчас многие компании занимаются свободным сцеплением, потому что с развитием бизнеса и увеличением спроса проблема системы плотного сцепления будет становиться все более серьезной. Возьмем в качестве примера индустрию облачных дистрибутивов, ее атрибуты постепенно меняются. В прошлом очень немногие люди производили контент, большинство людей потребляли контент. В облачном распространении преобладал нисходящий трафик. С появлением национального прямого вещания облачное распространение стало облачным взаимодействием. Развитие Интернета вещей сделало обмен данными между вещами основным способом, таким как умный дом, который ежедневно генерирует тысячи данных, но только одну из них. Несколько из них будут потребляться; Вспышка виртуальной реальности, данные, генерируемые пользователями, постепенно изменятся с изображений и видео на контент виртуальной реальности; исходя из этого, мы можем ожидать, что восходящий трафик будет постепенно увеличиваться и постепенно превышать нисходящий трафик, что становится огромной проблемой для инфраструктуры. Быстрое изменение пользовательского спроса и среды сетевой инфраструктуры заставляет нас все быстрее и быстрее реализовывать этот спрос. Однако тесно связанная система создает много трудностей для исследований и разработок и делает реализацию функций все более и более энергозатратной и трудоемкой. Итак, в начале создания Baishan мы решили построить весь корпус продукта с помощью архитектуры “Lego loose-coupled”. Отдел, как и строительные блоки, в целом гибкий.
I. Традиционные трудности (1) Накопление спроса, длительный период конвергенции Многие стартапы принимают жесткую модель роста в начале своего основания. Принцип заключается в том, что чем скорее, тем лучше. Тесно связанная архитектура может очень хорошо соответствовать этим требованиям. Они могут быстро создать базу данных CMDB и платформу управления ресурсами, а также настроить автоматизацию, портал, мониторинг и другие функции. Однако с увеличением функций и развитием спроса система постепенно превратилась в рыхлый песок. Когда возникают новые требования, им приходится выполнять для них множество сложных действий по кодированию, и цикл конвергенции становится все длиннее и длиннее. (2) Пустая трата ресурсов “старой китайской медицины” В тесно связанной системе, казалось бы, несвязанное незначительное изменение, скорее всего, вызовет серьезную ошибку; для предотвращения ошибок дизайн системы может быть только все более и более сложным. Например, чтобы предотвратить зависание клиента, R&D обычно добавляет к нему демона; когда демон нестабилен, общим решением для новых исследований и разработок является добавление другого демона, что приводит к тому, что система становится все более и более раздутой. В это время компаниям часто нужны опытные, понимающие общую ситуацию системы “ветераны китайской медицины” для того, чтобы преобразовать платформу. Как основной актив, “старая китайская медицина” занята борьбой с пожарами и техническими прорывами, поэтому трудно потратить время на реконструкцию системы.
2. Слабая связь архитектуры Lego Как решить противоречие между быстрой реализацией спроса и все более медленной реализацией спроса? В конечном счете, архитектура продукта Baishan фокусируется на разделении, облегчении быстрой итерации платформы, снижении зависимости между системами, подключении несвязанных проектов, обеспечении эффективной поддержки оперативного взаимодействия и обеспечении качества обслуживания. (1) Слабо Связанная Архитектура Уровня 1 Если взять в качестве примера систему облачного распространения CDN-X Baishan, то ее фундаментальным ядром является работа. Для того чтобы НИОКР и деятельность компании осуществлялись гибко за счет разделения, необходим первый уровень абстракции. Система поддержки операций разделена на пять компонентов, включая управление клиентами, информацию о выставлении счетов, управление ресурсами, мониторинг операций и управление конфигурациями. Изображены пять компонентов, определены границы, определены входные и выходные данные, а пользовательские сценарии описаны в соответствии со сценариями работы. Несколько компонентов взаимодействуют друг с другом с помощью инструкций шины сообщений и данных через стандартный интерфейс сброса. В то же время пять компонентов вводятся в фактическую разработку и создаются в соответствии с различными типами.
(Слабо Связанная Архитектура Уровня 1)
(2) Слабо Связанная Архитектура Уровня 2 После отсоединения первого слоя мы обнаруживаем, что второй слой может продолжать абстрагироваться. На примере системы управления конфигурацией можно выделить четыре части.
Конфигурация генерации: в основном отвечает за создание конфигурации и настройку хранилища git;
Контроль распространения: управление процессом публикации на уровне серого;
Выполнение распространения: Распространение полученных инструкций и передача их вышеперечисленным компонентам с помощью таких инструментов, как salt, ansible, http get;
Выполнение теста: Вызовите хранилище письменных тестовых наборов, чтобы проверить конечный результат этого процесса распространения конфигурации.
(Слабо Связанная Архитектура Уровня 2)
Каждый компонент в системе поддержки эксплуатации может быть постоянно абстрагирован, и абстрактная концепция проходит через всю платформу проектирования. Дизайн основных компонентов дополнительно абстрагируется в заводском режиме или в одноэлементном режиме, чтобы сформировать подключаемую архитектуру для различных служб и сценариев, которая может обеспечить всю службу поддержки операций, написав минимальный код посадки.
(3) Принципы построения
Компонент как услуга Все, кто занимается исследованиями и разработками, являются архитекторами. После получения требований к НИОКР необходимо не изучать ввод, вывод и границы, а понимать бизнес. Выведите документ с требованиями в соответствии с ситуацией, согласуйте его с бизнес-стороной и разработайте архитектуру в соответствии с требованиями. Каждый компонент больше не является функцией, а услугой, со своим собственным объектом обслуживания; Персонал НИОКР с точки зрения качества исходного кода, ответственности за ввод и вывод, разработанный для того, чтобы отвечать за качество обслуживания.
Компонентизация событий В процессе первоначального проектирования мы обнаружили, что многие операции не являются действиями на платформе, а состоят из событий. Если эти события будут автоматизированы, потребуется много усилий. Возьмите в качестве примера автоматизацию узла на полке, включая автоматическое сканирование портов, мониторинг, установку, настройку и управление загрузками, и даже добавьте автоматизацию в текущую системную платформу для предоставления услуг пользователям. Когда компоненты автоматически упаковываются как события, ненужные человеческие затраты будут потрачены впустую. Если события разбиты на компоненты, менеджеры по эксплуатации и техническому обслуживанию могут легко перетаскивать, ссылаться и стандартизировать компоненты на платформе и достигать общей автоматизации путем перетаскивания и настройки.
Система управления агрегацией данных Данные часто являются критерием оценки в процессе эксплуатации. Компоненты формируются отношениями между данными и данными. Поскольку API-интерфейсы между источниками данных различны, стыковка API-интерфейсов займет слишком много времени. Мы организуем данные о качестве компьютерного зала, отслеживаем нагрузку, коэффициент замедления, скорость передачи и так далее, а также создаем систему управления агрегацией данных через единый вызов интерфейса.
Общий доступ к экземпляру-Узел Автоматически подключается (Процесс завершения эксплуатации и обслуживания)
В ходе этого процесса операторы выполнили множество компонентов, таких как управление конфигурацией, внутреннее тестирование, внешнее тестирование, зона покрытия и так далее, а затем представили различные источники данных для отслеживания. После завершения шаблона события только операторам необходимо выбрать узлы, которые необходимо разместить, а также их схемы покрытия и области, а остальная часть процесса завершается автоматизацией системы. Этот шаблон также может быть изменен по мере необходимости, например: компоненты скорости потери пакетов могут быть добавлены в любое время, не влияя на бизнес. Многие компании также используют одну и ту же систему управления событиями, разница в том, что они управляют действиями; и мы обнаруживаем, что часто действия необходимо отслеживать вручную после завершения. В связи с этим мы превращаем события в полный жизненный цикл и вводим источники данных для отслеживания кодов состояния службы исключений. В процессе завершения этого события операции, необходимые операторам, были упрощены: от написания сценариев и анализа человеческой плоти до перетаскивания компонентов шаблона, установки пороговых значений на основе опыта и даже использования других шаблонов событий для завершения события.
3. Детали слабой связи (1) Упрощают ее С течением времени, а функции продолжают увеличиваться, система неизбежно будет казаться сложной, и многие из этих сложностей вызваны нашими собственными операциями, такими как пример “демона”, упомянутый выше, когда использование сложных решений для решения проблем часто приводит к раздутию системы. Эта проблема будет упрощена, если система гарантированно будет отказоустойчивой и система может быть автоматически отремонтирована, если компоненты не функционируют должным образом. Например, надежный механизм управления сообщениями требует подтверждения того, что сообщения действительно могут приниматься и выполняться каждым устройством. Мы улучшили это за счет вирусной передачи сообщений. Каждое устройство может отправлять сообщения на 5-6 периферийных устройств. Даже если произойдет один сбой, другие устройства снова отправят сообщения на это устройство. Эта отказоустойчивая способность гарантирует, что система может просто и автоматически выполнять функции сильных исследований и разработок, сильного отслеживания и так далее. (2) Создание приложений на основе платформы Например, при создании приложений на больших платформах обработки данных разработчикам не нужно учитывать проектирование баз данных и оптимизацию узких мест при разработке компонентов, а нужно только подключить платформы агрегирования данных, что значительно повышает эффективность исследований и разработок. (3) Непрерывная итерация Facebook, например, в настоящее время обрабатывает 1,2 миллиарда изображений в секунду; его первая версия позволяет пользователям загружать изображения и сохранять их только в базе данных, которая длится всего три месяца; с увеличением числа активных пользователей давление на серверную часть продолжает расти, поэтому он меняет хранилище на двоичное хранилище. Следующая итерация предназначена не для конкретной цели, а для решения бизнес-проблем. Поэтому в начале нам нужно только рассмотреть требования и бизнес, разработать достаточно простое решение, а затем выполнить итерацию, чтобы соответствовать новым требованиям.
IV. Изменения (1) Быстрое внедрение новых функций Мы используем механизм управления сообщениями P2P и алгоритм конвергенции для улучшения удаления файлов с 5 минут до 0,7 секунды. Мы не изменили систему в больших масштабах, но заменили механизм сообщений. Используя текущий базовый механизм связи и базовые данные, мы все еще можем использовать оптимизацию и пользовательский интерфейс, которые мы делали в прошлом. Эти новые функции имеют небольшой вес и практически не влияют на другие компоненты. (2) Высокая эффективность разработки Например, в процессе игрового взаимодействия взаимодействие с цифровыми пакетами, как правило, трудно достижимо в отрасли. В настоящее время мы пытаемся внедрить программное обеспечение TCP-прокси с открытым исходным кодом и планируем новые типы прикладных служб. Поместив программное обеспечение в указанное место в соответствии с указанным режимом упаковки, мы можем реализовать автоматический выпуск программного обеспечения. В то же время мы вызываем другие интерфейсы компонентов для мониторинга новых служб и пишем логику генерации конфигурации для реализации распределения бизнеса. Настройка автоматизации. Нужно только написать очень легкий код посадки, весь компонент можно использовать после посадки. (3) Улучшение автоматизации эксплуатации и технического обслуживания В месте проблемы, если ручное отслеживание обычно представляет собой последовательный расчет “да или нет выбора”, и в системе управления событиями выполняются параллельные вычисления, то есть вызывается система мониторинга для определения того, является ли узел нормальным; вызываются данные сторонних производителей для своевременного тестирования, чтобы определить, является ли текущая служба узла нормальной; вызываются данные клиентского приложения. Проверьте качество обслуживания; используйте журнал системного анализа ELK, точную и быструю проблему позиционирования, время анализа от 10 минут до 3 минут.