1. Причина: буйный рост
За последние десять лет Интернет в Китае развивался все быстрее и быстрее. Интернет-технологии подрывали все больше и больше традиционных отраслей. С развитием Интернет-технологий наши основные жизненные потребности претерпели коренные изменения. На этой волне как грибы после весеннего дождя вырастает все больше и больше новых компаний, их бизнес растет очень быстро, а масштабы компаний становятся все больше и больше. Это связано с быстрым ростом экономики Китая и бурным развитием Интернета.
Недостаток 1: Самораспространение
В процессе бурного развития компании часто возникает такая цепочка. Добавьте новый бизнес -> наймите старший технический персонал -> создайте техническую команду вокруг этого коллеги -> бизнес в основном отвечает за эту команду. Затем формируется замкнутый цикл. Когда возникает необходимость взаимодействовать с другими предприятиями, зачастую это вопрос самоопределения между техническими лидерами. (У меня был проект с одним и тем же бизнес-интерфейсом, который одновременно предоставлял RPC, HTTP, MQ и другие методы, чтобы предоставлять базовые услуги для разных проектов).
Недостаток 2: контрольные барьеры
С быстрым развитием масштаба бизнеса эта команда быстро сформировала отдел.Лица, принимающие решения в команде, обычно учитывают свои собственные интересы и надеются свести к минимуму зависимость от внешних отделов, будь то выбор технологии, установление спецификации, выбор компонентов и Операционная среда может контролировать себя. (Расскажите тут анекдот, как стать руководителем среднего звена в компании? Это очень просто, достаточно набрать достаточное количество подчиненных.)
Недостаток 3: Эффект скалы
Как только будет сформирована такая техническая атмосфера, влияние одного сотрудника на один проект станет очень огромным. Продукт часто становится неустойчивым из-за ухода одного или двух основных сотрудников, и, в конце концов, приходится заново разрабатывать новый продукт.
Недостаток четвертый: пустая трата ресурсов
Когда каждая команда пытается построить свой собственный законченный процесс НИОКР. В процессе технических исследований, разработки продуктов, управления эксплуатацией и техническим обслуживанием будет много растраты ресурсов.
Недостаток пятый: трудно оценить
Как измерить, кто лучше, шеф-повар из провинции Сычуань или шеф-повар из провинции Шаньдун? Когда каждая команда использует свой технологический стек, разные технологические компоненты, разные методы обслуживания и спецификации. Больше невозможно судить о работе команды по эффективности ее работы. Показатели KPI также очень сложно установить.
Во-вторых, как взломать?
На ранней стадии развития компании, чтобы быстро расширить свой бизнес, большинство вопросов, таких как затраты, эксплуатация и техническое обслуживание, а также технические осадки, не рассматривались. Все показатели ориентированы на быстрое развитие бизнеса, максимальный захват доли рынка и получение достаточного количества пользователей.
После того, как компания разовьется до определенной стадии, рынок постепенно станет стабильным, и постепенно будут выявляться различные проблемы быстрого расширения на ранней стадии. С технической точки зрения, если удастся сформировать единую структуру разработки на уровне компании, это принесет большую пользу в реальном производственном процессе.
В-третьих, преимущества единой структуры разработки
3.1 Избегайте повторяющихся технических исследований — экономьте трудозатраты
Пусть команда проекта посвящает больше энергии бизнесу. Я полагаю, что это консенсус большинства технологических компаний: разрешено ли проектной команде направлять свою энергию на бизнес? Необходимо построить платформу базовой архитектуры разработки под командой проекта, чтобы выделить общие технические проблемы и передать их такой команде для их решения. Избегайте решения различных технических проблем, с которыми сталкивается каждый проект в одиночку, и эффективно высвобождайте энергию.
3.2 Стандартизированные технические спецификации – повышение качества продуктовых проектов
Нужно иметь тысячу человек, а не тысячу человек. После принятия единой среды разработки (платформы) может быть сформирован стандартизированный режим вывода технологий с точки зрения стеков технологий, компонентов технологий, схем реализации технологий и даже спецификаций кода.Наибольший эффект от стандартизации заключается не только в быстром совершенствовании эффективность разработки, но и существенное улучшение качества продукции, что очевидно.
3.3 Осуществлять техническую осадку - улучшать общие технические возможности компании и не допускать, чтобы один человек мог решать проект.
Технический прогресс происходит от непрерывного технологического накопления и осаждения. Каждый инженер выполняет свою работу, стоя на плечах других. Ориентированные на проекты технические группы обычно считают реализацию потребностей бизнеса наиболее важной целью, а технологии — всего лишь инструментом для завершения бизнеса. Исходя из этого, команда по развитию бизнеса не может рассматривать накопление технологий как важную задачу. Когда основной сотрудник строит какие-то базовые инструменты платформы, с его уходом часто сбрасывается накопление предыдущих технологий, а в более серьезных случаях непрерывная работа всего проекта становится проблемой.
Когда на уровне компании существует единая среда разработки (платформа), команда проекта проводит собственные проектные исследования и разработки на основе этой платформы, и больше не нужно сосредотачиваться на реализации базовой технологии, а нужно сосредоточиться только на бизнес. Когда основные коллеги уходят, коллеги по исследованиям и разработкам платформы могут предоставить соответствующее обучение новым коллегам, которые входят в проект, что не приведет к плохим последствиям. Более того, чтобы лучше удовлетворять технические потребности проектной группы, коллеги, которые сосредоточены на платформе, постоянно улучшают платформу, чтобы достичь цели накопления и осаждения технологий.
3.4 измеримые инвестиции в НИОКР — эффективное управление и оценка команды НИОКР.
Когда устанавливаются стандартизированные технические спецификации, основанные на одной и той же среде разработки (платформе), кодовая реализация бизнес-функций может быть оценена и рассмотрена относительно эффективно, и можно избежать различных проблем, вызванных различиями в технической реализации. Это огромная помощь для формулирования и оценки KPI.
В-четвертых, позиционирование и цели единой среды разработки (платформы)
Единая структура разработки (платформа) позиционируется на техническом уровне, и ее основная цель заключается в унификации технической основы и средств разработки, используемых при исследованиях и разработках смежных продуктов и реализации проектов внутри компании, эффективном совершенствовании единой технической поддержки, формировании непрерывные средства накопления технологий и улучшения технического персонала. Это может повысить коэффициент использования и снизить зависимость от персонала и, наконец, улучшить крупномасштабные и конвейерные производственные мощности программного обеспечения.
5. Идея построения единой среды разработки (платформы)
5.1 На основе стека технологий Spring Cloud
Spring Cloud стал самой популярной средой разработки микросервисов в 2017 году. Он не использует среду Spring Cloud для реализации микросервисной архитектуры и обладает преимуществами микросервисной архитектуры. Правильное понимание состоит в том, чтобы использовать инфраструктуру Spring Cloud для разработки системы микросервисной архитектуры, чтобы система обладала преимуществами микросервисной архитектуры. На следующем рисунке показаны причины выбора Spring Cloud в качестве стека технологий.
5.3 Усовершенствования некоторых компонентов SpringCloud
Базовая конструкция, предоставляемая Spring Cloud, может не полностью соответствовать потребностям бизнеса, а для некоторых компонентов требуются дополнительные исследования и разработки. Например, разработанный нами API-шлюз на базе Zuul, центр регистрации и обнаружения сервисов EurekaPlus и т.д.
На следующем рисунке показан снимок экрана центра обнаружения регистрации служб EurekaPlus, который может вручную управлять состоянием узла центра регистрации служб для поддержки сине-зеленого развертывания.
5.3 Исследования и разработка новых основных компонентов продукции
В дополнение к базовым компонентам Spring Cloud нам часто требуется разрабатывать новые продукты с базовыми компонентами для удовлетворения потребностей проектной группы. В частности, текущая микросервисная архитектура очень популярна, и часто необходимо разрабатывать новые продукты-компоненты на основе дизайнерских идей микросервисной архитектуры, таких как разработанная нами структура распределенного планирования задач. Он принимает режим автоматического сканирования и онлайн-оркестровки, что полностью соответствует стеку технологий Spring Cloud.
На следующем рисунке показан принцип структуры распределенного планирования задач. Исполнитель регистрирует интерфейс задачи в распределенном центре обработки данных при его запуске, центр оркестрации получает информацию об исполнителе из распределенного центра обработки данных для оркестровки, а затем сохраняет информацию об оркестровке в хранилище данных, а центр планирования получает информацию из хранение данных исполнителю для удаленного планирования.
6. Как работает команда единой среды разработки (платформы)
Как продвигать построение единого фреймворка (платформы) разработки в компании — дело непростое. Из моего личного опыта, с точки зрения разделения труда и эксплуатации, я в основном ориентируюсь на разделение работы единой среды разработки (платформы) на три части.
Разработка примеров, техподдержка и техническое задание. Напишите полный пример разработки. Для многих коллег, которые плохо знакомы с унифицированной средой разработки, очень важно иметь копию для завершения разработки бизнеса. правильный и эффективный код. Также необходимо обеспечить техническое обучение и техническую поддержку многих коллег, что является работой, которую должна выполнить команда единой среды разработки (платформы).
Сервисная эксплуатация и техническое обслуживание. Единая среда разработки (платформа) предоставляет множество сервисов внутри компании, таких как центр регистрации и обнаружения сервисов, центр конфигурации, центр мониторинга, центр ссылок, центр мониторинга работоспособности и т.д. Все это требует единой команды разработки (платформы) для эксплуатации и обслуживания.
Исследования и разработка новых компонентов и новых продуктов. Шлюз API, структура распределенного планирования задач, сервисный реестр Plus и т. д., упомянутые в предыдущей главе. И то, и другое входит в сферу деятельности команды единой среды разработки (платформы).
Семь, слишком поздно
Хотя создание единой среды разработки (платформы) на уровне компании принесет большие преимущества в реальном производственном процессе. Однако он может быть применим не ко всем ситуациям, а учитывая специфику некоторых продуктов проекта, его нельзя обобщать.
Автор: Лян Синь
Источник: Технологический институт CreditEase.