В марте 2015 года он покинул Netease BoBo и пришел в Бэйчао с чувствами и ожиданиями предпринимателя. В мгновение ока прошло почти три года. За последние три года фоновая системная архитектура Beichao претерпела сложный и полноценный процесс эволюции.
Этот процесс эволюции можно условно разделить на несколько этапов: этап замены технологической платформы, сервис-ориентированный зародышевый этап, сервис-ориентированный этап формирования и сервис-ориентированный этап развития.
Во-первых, этап замены технологической платформы
В первые дни бизнеса BeiLiao архитектура фоновой системы была основана на технологической платформе PHP и поддерживалась двумя разработчиками PHP. Технологическая платформа PHP является первым выбором для большинства компаний на ранней стадии своего бизнеса. На ранней стадии бизнеса компании сложность бизнеса невелика, а количество пользователей невелико.Основной задачей является завершение разработки с наименьшими возможными затратами (затраты на рабочую силу, затраты времени, стоимость технологий и стоимость сервера).
С 2013 по начало 2015 года, после более чем трех лет бурного развития, оборудование (система и персонал) на базе технологической платформы PHP стало не в состоянии удовлетворить потребности развития бизнеса компании. Впоследствии постепенно начался этап замены технологической платформы PHP на технологическую платформу JAVA.
Начало всего сложное, и есть много трудностей на ранней стадии работ по замене технологической платформы.
Во-первых, бизнес компании стремительно развивается, а перестройка системы и итерация бизнес-требований идут параллельно. Что говорили предшественники: Это равносильно замене колес на скоростном спортивном автомобиле, сложность и риск можно себе представить.
Во-вторых, сможет ли это сделать новая техническая команда JAVA? Результата нет, и он не признан руководителями и коллегами.
Опять же, может ли исходная техническая команда PHP хорошо работать вместе? Рефакторинг систем равносилен ниспровержению того, за что они изначально были ответственны.
Наконец, технической команде JAVA не хватает понимания индустрии дошкольного образования, которая полностью отличается от бизнеса развлекательных прямых трансляций Netease BoBo, и это совершенно новая сфера бизнеса.
Столкнувшись с этими трудностями, руководители сформулировали стратегию замены технологической платформы: новая бизнес-система разрабатывается с использованием технологии JAVA, старый бизнес продолжает итерироваться на технологии PHP, и в то же время технология JAVA постепенно используется для реконструкции и переключения.
Оглядываясь назад на опыт этого этапа сейчас, память еще свежа.
Разработка новой бизнес-системы не является большой проблемой, а работа по реконструкции — головной болью. Как и беспокойство, у технической команды PHP есть эмоции, и в процессе общения возникает много конфликтов, больших и малых. В процессе рефакторинга я не знаю, сколько раз у онлайн-бизнеса возникали большие и маленькие проблемы, и я не знаю, сколько раз из-за вопроса ответственности. Работать сверхурочно, всю ночь, а по выходным быть готовым решать проблемы дома — это норма. Однажды ночью я отпросился пораньше из-за физического дискомфорта и обнаружил, что «небо еще яркое», что на самом деле очень непривычно.
К счастью, этот сложный этап сохранился. К началу 2016 года замена и реконструкция исходной системы технологической платформы PHP в основном завершены (90%). Это неотделимо от доверия и терпимости лидеров, усилий технической команды JAVA, сотрудничества и самопожертвования технической команды PHP. В конце концов, можно решить столько трудностей.Суть в том, что у всех одна цель: взять за основу развитие компании.
Во-вторых, зарождающийся этап службы
Ключевым моментом этапа замены технологической платформы является обеспечение плавного перехода при реконструкции и переключении системы при обеспечении нормальных бизнес-итераций Масштабируемость и ремонтопригодность новой системной архитектуры не были полностью учтены.
В марте 2016 года, после того как компания завершила раунд финансирования B, техническая структура столкнулась с риском не справиться с быстрым расширением линейки продуктов и технической команды. Несколько линеек продуктов и группа разработчиков, работающих только над несколькими приложениями одновременно, неизбежно приведут к увеличению количества бизнес-приложений и их все большему и большему раздуванию. Как сотрудничать в разработке, как управлять версиями и как управлять рисками? Если это не работает, это испорчено.
Размышляя над этими вопросами, мы вступили в зарождающуюся стадию служения. Исходная архитектура показана на следующем рисунке:
Получается, что одна прикладная система интегрирует множество сервисов, а несколько прикладных систем имеют дублирующие сервисы, и каждая прикладная система вызывает сторонние сервисы (такие как SMS, push, IM и т. д.). Обновленная и скорректированная архитектура показана на следующем рисунке:
Этот этап работы — в основном извлечение государственных услуг и повторное использование бизнес-модулей. Например, SMS, отправка и загрузка изображений извлекаются в общедоступное веб-приложение для предоставления унифицированного интерфейса REST API; в то же время вводится облегченная структура RPC Hessian для реализации повторного использования бизнес-модулей между системами.
Есть две очевидные проблемы с такой архитектурой: одна заключается в том, что метод вызова интерфейса REST API неэффективен, а другая заключается в том, что им трудно управлять после увеличения отношения вызова бизнес-модуля по Гессе. В то же время с расширением продуктовых линеек и членов команды он не может эффективно решать поставленные выше проблемы и риски.
3. Стадия формирования службы
В мае 2016 года была представлена платформа распределенных услуг Dubbo от Alibaba. Начало комплексной декомпозиции и реконструкции системного бизнеса BeiLiao.К концу 2016 года распределенная сервисно-ориентированная архитектура BeiLiao в основном была сформирована. Архитектура показана на следующем рисунке:
На этом этапе также были внедрены распределенный центр конфигурации Disconf (Baidu) и распределенная система планирования задач Elastic-Job (Dangdang). На этом этапе проблемы, вызванные расширением линейки продуктов и членов команды, могут быть лучше решены. Гибкость добавления и комбинирования компонентов бизнес-услуг может решить проблему увеличения линейки продуктов, а увеличение числа членов команды — это именно то, что требуется для поддержания большого количества компонентов бизнес-услуг. При этом способ вызова интерфейса на основе протокола DUBBO более эффективен, чем HTTP.
Путь API намного выше.
К настоящему времени сервис-ориентированная архитектура в основном сформировалась, но есть и две очевидные проблемы: во-первых, нечеткая граница между сервисными компонентами, и между сервисными компонентами существует взаимная вызывающая связь; во-вторых, отсутствует механизмы мониторинга аномальных ссылок.
В-четвертых, этап развития службы
В начале 2017 года была переосмыслена проблема разделения и дизайна сервисных компонентов. Во избежание путаницы, вызванной взаимными вызовами, сервисные компоненты разделены на две категории: основные сервисные компоненты и бизнес-сервисные компоненты. При этом формулируется принцип вызова между компонентами: только компоненты верхнего уровня могут вызывать компоненты нижнего уровня для обеспечения одностороннего вызова. Архитектура показана на следующем рисунке:
В середине 2017 года CAT Дяньпина (Центральный
Применение
Отслеживание) проект аномального мониторинга и завершен доступ ко всем прикладным системам в октябре. Доступ к CAT реализует мониторинг и уведомление о тревоге стека исключений, что позволяет точно обнаруживать и устранять многие ошибки до получения обратной связи от пользователя, что значительно улучшает пользовательский опыт и чувство достижения разработчика.
V. Заключение
В конце 2017 года вся сервисно-ориентированная архитектура окончательно оформилась. Я хотел бы поблагодарить каждого брата в отделе исследований и разработок за их усердную работу! Находитесь ли вы в Бэйчао или покинули Бэйчао, код проекта на складе SVN/GIT был отмечен вашим глубоким отпечатком (а также оставил много дыр, которые вы вырыли, ха-ха). В будущем нас ждет еще много проблем и трудностей.Братья из отдела исследований и разработок BeiLiao не должны останавливаться, давайте вместе преодолевать трудности.
Спасибо за вашу усердную работу в Beichao!
Ли Хуан и Гао Си (братья PHP), Чжэн Сяобинь (2-й сотрудник отдела исследований и разработок), Линь Тяньруй (4-й сотрудник отдела исследований и разработок), Ли Сингуан (5-й сотрудник отдела исследований и разработок), Ли Хайвэнь, Ма Лин, Лань Годун, Цзян Дасянь, Ченг Цзяньюй, Ли Чжифэн, Кэ Фусян, Цю Цзюнь, Линь Сунмянь