пролог

Эх, очень извиняюсь, в этот раз я не делюсь багами, поэтому не могу показать всем мою неловкую внешность, и в этот раз не слишком много технического контента, будет несколько скучновато. Однако, возможно, план переноса и разделения проекта на этот раз, по вашему мнению, не идеален, поэтому у вас все еще есть возможность критиковать и развлекать.

задний план

Без лишних слов, давайте поговорим о предыстории миграции и разделения этого проекта.

классическая модель

Давайте сначала взглянем на системную архитектуру большинства современных микросервисных фреймворков.Здесь Dubbo используется в качестве основы для RPC-сервисов и используется традиционная бизнес-модель электронной коммерции (зрители, знакомые со мной, должны знать, что я всегда защищали бизнес-код компании, поэтому здесь используется известная бизнес-модель в качестве примера).Кратко объясните:

Это простая бизнес-модель электронной коммерции, которая делится на пользовательские услуги, товарные услуги, транзакционные услуги, складские услуги, послепродажные логистические услуги и финансовые услуги в рамках бизнес-подразделения микросервисов. (Если есть конкретные подразделения и другие службы, тут больше не скажу)
Архитектура микрослужб использует Dubbo в качестве среды управления службами, и каждая служба взаимодействует с RPC через Dubbo.
Классы сущностей, классы инструментов, интерфейсы Dubbo и т.д., задействованные в каждом сервисе, размещены в публичном интерфейсном сервисе (не знаю, как это сказать, но на самом деле это публичный jar-пакет, а не сервис, но давайте назовем это то, что на данный момент. ), на которые ссылаются соответствующие веб-проекты бизнес-службы, на которые фактически ссылаются в файле maven pom.

Выше может быть самая простая модель.Конечно, с точки зрения бизнеса и архитектуры у каждой компании есть свои решения и расширения, которые уже не рассматриваются, но ядро все равно крутится вокруг этой самой примитивной модели.

текущий статус

Так в чем проблема сейчас? Давайте еще раз посмотрим на такую модель. Соответствующие веб-проекты бизнес-сервисов будут полагаться на этот публичный сервис, что само по себе не является проблемой, в конце концов, есть некоторые интерфейсы Dubbo и т. д., и конкретные классы реализации все еще находятся в соответствующих сервисных проектах. Но тут возникает проблема, я не знаю, с каких пор эта модель изменилась, то есть все классы реализации написаны в этом сервисе публичного интерфейса.
Поскольку это многомодульный проект maven, соответствующие веб-проекты ссылаются на ту часть модуля, которая им нужна. Таким образом, все веб-проекты — это просто файлы конфигурации в разных профилях среды. Это противоречит первоначальному замыслу вышеупомянутой модели. как показано на рисунке:

оказать влияние

Так в чем проблема:

Проблемы со структурой проекта. Код каждого находится в этой общедоступной интерфейсной службе, что делает структуру очень запутанной. Для веб-проектов можно даже ссылаться на модули, которые им не принадлежат. Например, на класс финансовой реализации ссылаются в товарных службах. протокол используется Напротив, веб-проект вводит некоторые избыточные банки и даже вызывает проблему приоритета зависимости maven, что приводит к риску несчастных случаев. (Приоритет зависимостей maven относится к случаю, когда ссылаются на разные модули, но включают разные версии одного и того же jar-файла. Maven сначала принимает принцип кратчайшего пути зависимости, который будет подробно обсуждаться в следующей статье.)
проблемы с управлением кодом. Так как код разных модулей находится в этом общем сервисе, то при слиянии кода будет много конфликтов. Например, когда студенты товарных сервисов отправляют коды для Merge, будет много конфликтов, в основном это не собственные бизнес-модули, или транзакции, или складирование, или другие бизнес-модули. В идеальной модели, то есть на моей первой картинке, конфликт, порожденный слиянием, также должен быть конфликтом кода соответствующих бизнес-модулей, что неизбежно. (Объединенный код, наконец, превращается в режим копирования кода, или используется выбор вишни, предоставляемый Git, но на самом деле это расширенная версия кода копирования, и обычное слияние использовать нельзя)
Проблемы управления развертыванием. Поскольку все сливают код в этот общедоступный сервис, процесс компиляции и упаковки во время развертывания CI (будь то на gitlab или Jenkins) очень медленный. Первоначально бремя компиляции и упаковки могло ложиться на соответствующие бизнес-веб-сервисы, но теперь все они сконцентрированы в одном сервисе. С непрерывным увеличением бизнес-кода в будущем это время будет становиться все длиннее и длиннее, и даже если в коде будет ошибка, все развертывание и выпуск потерпят неудачу.

Это одни из самых раздражающих болевых точек, которые я наблюдал до сих пор. Я даю обратную связь по этому поводу с прошлого года, и эту государственную услугу нужно разделить. Но одна из них связана с некоторыми причинами на уровне отдела, а другая связана с тем, что развитие бизнеса затруднено, и ни у кого нет времени вести или продвигать последующие действия.
До этого Double Eleven, поскольку его нельзя было выпустить во время большого рекламного периода, не было необходимости в итерации. Поэтому я снова поднял этот вопрос, и на этот раз у меня наконец-то появилось время его продвинуть. (Я все-таки считаю, что раз уж обнаружено много болевых точек, то все же стоит подумать об их излечении заранее, иначе рано или поздно это будет дамоклов меч, либо надо не допустить этого в первую очередь)

Перед внедрением

Так что подумайте об этом сейчас, как начать это дело. (Вы думаете это дело вроде как не имеет технического содержания, а вдруг я не знаю как это сделать? Я думал это большие ребята сделали это, но у больших парней другие оптимизации, так что кто бы что не предлагал это,Кто это решает.Конечно,как программист он все же в основном решает проблемы)

Цель анализа

Наша цель — перенести определенные классы реализации бизнеса (в основном, реализацию уровня сервиса и интерфейса уровня контроллера) в соответствующие веб-проекты. Итак, первое, что приходит на ум, — можно ли удалить эти коды непосредственно из общедоступной службы, а затем добавить их в соответствующие веб-проекты или объединить их с помощью операций git. Тогда я думаю, если рассматривать только из практики, конечно, возможны оба ответа. Но если бы все было так просто, мне не нужно было бы писать эту статью сегодня. Давайте подумаем о проблемах, если мы сделаем это:

Первый — удалить код и переместить код, что я считаю худшим. Потому что хоть ваш код и был перенесён, но он также потерял запись коммита на git, а во-вторых, сохранить каждую ветку в проекте невозможно.
Во втором вроде эффект лучше, но из-за другой структуры проекта после работы Git будет много конфликтов. В Интернете есть много подобных операций, но поскольку демонстрационные бизнес-сценарии, представленные в Интернете, относительно просты и слишком просты, как этотКак git объединяет два проекта?, а фактическая операция сложнее и труднее реализовать, чем эта демонстрация, а точка риска слишком велика и неконтролируема.

филиал проекта

Многие люди могут задаться вопросом, поскольку я переношу проект, зачем сохранять ветку. Прежде всего, давайте проясним, что если это ветка разработки, которая была несколько месяцев назад, или ветка слияния только для генерации кода слияния, эта ветка не имеет особого смысла для всего проекта. Важные ветки при миграции фактически делятся на две категории:

Разрабатываемая на данном этапе ветка разработки, например feature/abc;
Оценки с важными вехами, такими как среда в градациях серого: серый/abc, или специальная ветвь: vip/abc, или предварительная ветвь: релиз/abc, и такая резервная ветвь: remaster/abc и т. д.

По этой причине такие ветки должны быть безоговорочно перенесены, а ремонтопригодность проекта кода должна быть сохранена.

Конечно, в нашей компании есть еще одна особенность, которая вносит в этот вопрос большие трудности. Поскольку наша компания является предприятием категории «Б» и бизнес, которым она занимается, также ориентирован на предприятия, разные типы компаний будут работать в разных средах, которые мы называем «средой оттенков серого» (хотя я лично думаю, что здесь это называется «градациями серого»). немного не соответствует фактическому значению оттенков серого. Я думаю, что оттенки серого могут быть более склонны к среде пользователей с низким трафиком, и они используются для перехода в оттенки серого на этапе тестирования новой функции. Это может быть в B и в C. разные). Поэтому в нашей компании будет много «оттенков серого», что окажет большое сопротивление миграции этого проекта.
Причина, по которой я так много рассказываю здесь, заключается в том, что это действительно вызвало большую проблему:

Во-первых, поскольку это миграция и разделение проекта, его нельзя полностью менять за одну ночь, подумайте о существовании такого количества сред, и даже если трансформация происходит в одночасье, то риски вам не страшны! Я не могу справиться с этой кастрюлей.
Во-вторых, если его модифицировать, то конкретные классы реализации в сервисе публичного интерфейса нужно удалить (удалить на git), оставив голый публичный интерфейс, поэтому при разработке студенты-разработчики точно будут из этой голой ветки master службы публичного интерфейса. В нормальных условиях происходит смена одной среды с одной среды на другую.Когда возникает экстренный баг, который нужно исправить, когда ветка хотфикса, вырезанная из этого голого сервиса, вливается в среду, которая еще не трансформировалась, соответствующий Окружение будет объединено, код на том сервисе удален, но так как окружение не трансформировалось, а удаление происходит в это время, то явно что-то пойдет не так. Если в какой-то момент не будут сделаны все модификации, чтобы избежать этого, например, в 1 выше. как показано на рисунке:

план реализации

Так действительно ли это бесполезно? Позже я тщательно обдумал это: поскольку я не могу сделать что-то за один шаг, могу ли я пойти по кривой, чтобы спасти страну. Поэтому я задался вопросом, поскольку я не могу преобразовать его напрямую, могу ли я повторно отразить службу общедоступного интерфейса для каждой бизнес-службы и перенести зависимость от исходной службы общедоступного интерфейса на это зеркало службы общедоступного интерфейса, потому что у каждой тогда вам нужно только изменить соответствующие зеркала, поэтому изменения и влияние будут намного меньше. как показано на рисунке:Это дает следующие преимущества:

Поскольку копирование зеркала является практикой, вы сохраните записи коммитов и все ветки во всем проекте Git.
Каждый бизнес-модуль может добавлять, удалять или изменять собственное изображение, не затрагивая другие бизнес-модули.
Для каждого итеративного выпуска среды в образ службы общедоступного интерфейса необходимо передать только ссылку maven.

Давайте посмотрим на следующую итерацию среды:Таким образом можно избежать описанных выше проблем, а среда без миграции и среда с миграцией могут быть хорошо совместимы.

последний вопрос

Но здесь все еще есть проблема, я не знаю, заметила ли аудитория, так что как быть с оригинальным сервисом публичного интерфейса. Здесь также возникнет проблема, удалять ли код:

Если вы удалите код, но это то же самое, что и второй только что упомянутый пункт;
Если код не удалить, классы реализации в исходной публичной интерфейсной службе и в зеркале будут продублированы, поэтому при компиляции двух последние перезапишут первые, и тоже возникнут проблемы.

Так что делать? Это все еще идея, которую дал мне супервайзер.Поскольку координаты maven исходной службы публичного интерфейса совпадают с зеркальными координатами maven, необходимо переименовать зеркальные координаты maven, а затем позволить веб-проекту ссылаться на зеркальный maven координаты, так что даже если один и тот же класс реализации существует и в сервисе публичного интерфейса, и в образе, но веб-проект фактически загружает только класс в образе, что может решить эту проблему.

в процессе реализации

Теперь, когда идеи и планы были ясно объяснены выше, следующим шагом будет реализация процесса, Этот процесс относительно прост, как и высотное здание, полка построена, и нужно передвигать только кирпичи.
Поскольку каждый бизнес продвигается каждой бизнес-группой, а бизнес-миграция и разделение тоже имеют последовательность, то в качестве примера для расширения возьмем разделение товаров и услуг:

Сообщите всем разработчикам, в основном разработчикам стандартных сервисов, о необходимости ветвления и отправки одновременно, поскольку сервис общедоступного интерфейса необходимо зеркально отразить и скопировать. Это очень важный момент, иначе после копирования зеркала в первоначальном сервисе публичного интерфейса останутся ветки, поэтому миграция функциональных кодов на эту ветку будет очень безвкусной.
В образе сохраняются только классы реализации товарных сервисов, включая контроллер, классы реализации сервисов, бизнес, дао и т. д., а остальные коды нетоварных сервисов удаляются, фиксируются и отправляются.
Измените координаты maven и измените имя. Самый быстрый способ изменить имя здесь — изменить groupId. Например, изначально он назывался com.abc.abc, затем теперь он изменен на com.abc.xyz, а ArtifactId остается неизменным, сохраняя семантику, такую как abc-item.
версия: комплект. Это необходимо для развертывания и упаковки в соответствующей среде, а официальная среда должна быть развернута.
В веб-проекте товарного сервиса будут изменены координаты maven, зависящие от класса реализации товарного.На самом деле, хорошо модифицировать groupId, чтобы веб-проект ссылался на зеркало, а не на исходный публичный интерфейсный сервис .
Опубликуйте, проверьте, не сообщает ли запуск об ошибке. Разумеется, я добавил в зеркало контроллер запросов пульса, чтобы проверить, дошел ли запрос до кода в зеркале.

Затем для ситуации с другими учащимися развития нам также необходимо учитывать:

Развитие нетоварного бизнеса: В принципе, эти изменения в развитии не могут касаться товарного бизнес-кода. Однако, поскольку раньше он был в общедоступной интерфейсной службе, это трудно гарантировать. В этом случае он будет либо отклонен, либо код будет скопирован в текущий процесс с копируемым кодом;
Развитие товарного бизнеса: Перед вырезанием зеркала у некоторых студентов уже есть ветка развития бизнеса.В этом случае вам нужно только обратно слить зеркальную основную ветку, потому что основная ветка сохраняет только бизнес товаров.Код и другие коды были удалены.После обратного слияния эти коды также будут удалены.После вырезания образа, если вам нужно разработать новые функции или выполнить исправления, вам нужно только начать с образа.Оформить новую ветку.

После реализации

После разделения миграции требуется простая проверка. Здесь я беру товарный сервис в качестве примера и пишу запрос сердцебиения на уровне контроллера на изображении:

@RequestMapping(value = "/healthCheck", method = RequestMethod.GET)
@ResponseBody
public Object healthCheck() {
    return successResponse();
}

Затем, если вы можете запросить этот интерфейс, это означает, что проект стандартной веб-службы успешно сослался на модуль в зеркале, и другие бизнес-модули также можно отслеживать с помощью этого метода.

резюме

В общем случае миграция и разделение проекта в этом проекте может оказаться более сложной задачей из-за управленческих соображений. Хотя я не знаю, столкнулись ли структуры проектов других компаний с такими узкими местами, но проекты небольших компаний, в которых работают мои друзья, я вижу, что следующая тенденция также столкнется с теми же проблемами. На самом деле не сложно понять, что на ранней стадии основной упор делается на развитие бизнеса (он должен быть на зарабатывание денег, иначе кто будет платить зарплату), но я думаю, что когда любой небольшой проект на ранней стадии превращается в биг-мак, мы должны понимать, что проект важен для проекта.Теперь тимбилдинг влияет на все аспекты, потому что успех или неудачу определяют не только детали, но и правда книги.
С другой стороны, в случае, если мы не можем сделать это в одночасье, нам нужно спасти страну в известной степени кривой и решить проблему путем введения промежуточных звеньев. Как и в описанном выше решении, эффект от миграции и разделения косвенно достигается введением зеркалирования и изменением maven-координат, и в этом мультисредовом сценарии также может быть хорошо достигнута совместимость, а в бизнесе код изолирован, что значительно повышает ремонтопригодность системы.

Наконец

Если моя статья была вам полезна, я надеюсь, что вы, ребята, $\color{red}{Нажмите, чтобы подписаться}$ $\цвет{красный}{Нравится}$ , Еще раз спасибо за вашу поддержку!
Вот также мой адрес Github:GitHub.com/showyoOL/Согласно…