В связи с растущим давлением бизнес-потребностей нашего завода и постоянным улучшением инфраструктуры преобразование микросервисной архитектуры системы было официально поставлено на повестку дня. Обсуждение началось с разработки проекта целевой архитектуры для преобразования микросервисов.Команда архитекторов провела два дня интенсивных обсуждений и прояснила многие границы бизнеса. В ходе этого процесса я узнал много нового, и я обобщу и поделюсь им здесь, основываясь на некотором предыдущем опыте.
Вот что делает преобразование микросервисов
00 Предисловие
Что касается того, почему системный дизайн построен на микросервисной архитектуре,Как построить микросервисную архитектуру, По этим вопросам есть много статей, и у меня самого есть статья на смежные темы, и студенты, которым это интересно, могут ее прочитать.
Тема этой статьи — показать, как построить идеальную целевую архитектуру на начальном этапе преобразования микросервиса. Все будущие действия по преобразованию приближаются к этой цели. Целевая архитектура будет направлять нашу реализацию преобразования микросервиса. Эффект.
Источником материала для этой статьи является процесс генерации целевой архитектуры микросервисной трансформации нашей фабрики.Запишите этот незабываемый и мозго-выжигающий процесс.После его написания,может быть работающий аккаунт. Я надеюсь, что когда я прочитаю эту статью после завершения преобразования микросервиса, я обнаружу, что все эти архитектурные проекты в начале были реализованы, и это прекрасно! ! !
Участники этого семинара представляют группу архитектуры технического отдела и основных разработчиков каждой группы развития бизнес-возможностей.В то же время эксперты по программному обеспечению Huawei также приглашены для предоставления рекомендаций на месте. С точки зрения участников, это не только архитекторы, которые могут оценить текущую ситуацию в компании, но и фронтовые разработчики с опытом разработки (покрывающие большинство бизнес-сценариев), у каждого в душе прекрасное видение, у каждого свои идеи. сталкиваются друг с другом, интегрируются и поглощают свои превосходные решения и, наконец, образуют относительно полную целевую структуру.
01 План внедрения трансформации микросервисов
Трансформация микросервисов — это долгий процесс, я видел процесс трансформации некоторых компаний, трансформация системы подобного масштаба занимает около 2 лет. Следовательно, чтобы обеспечить упорядоченное выполнение всего процесса преобразования микросервиса, должен быть реализован план, который можно реализовать. Наш план таков:
- Предоставьте план целевой архитектуры компании.
- Выбор рамы и улучшение инфраструктуры.
- Сформулируйте спецификации разработки для преобразования микросервисов.
- Типовая проектная практика, обобщение опыта.
- Пересмотренная спецификация схемы.
- Масштабная трансформация и внедрение микросервисов.
Кажется, что это относительно стабильный план, после такого процесса трансформации микросервисов все наши бизнес-системы имеют более разумную структуру, связь между собой уменьшается, границы бизнеса четкие, а зависимости близки к вершине. отношение снизу вверх древовидная структура.
02 Статус архитектуры
Мы являемся сторонней платежной компанией, и студенты должны легко представить общий объем бизнес-системы и внутреннюю структуру системы. Мы также можем видеть информацию о крупных сторонних платежных компаниях онлайн.Диаграмма архитектуры системы, Хоть мы и небольшая платежная компания, хоть воробей и маленький, но у него есть все внутренние органы и все такое. Просто потому, что на ранней стадии разработки все было ориентировано на бизнес, появилось много систем, многие из которых были построены независимо. Было неизбежно, что построение системы будет немного раздутым, и было много необоснованных вызовов между многими системами. , Рисуя диаграмму взаимосвязи вызовов, кажется, что очень грязно. И многие функции создаются повторно, что приводит к трате ресурсов.
Статус архитектуры приложения
В текущей архитектуре некоторые системы подверглись рефакторингу, но эти рефакторинги также выполняются относительно независимо, и единой спецификации нет. Дизайн рефакторинговой системы полностью зависит от видения знаний главного дизайнера и его понимания бизнеса. Существуют также различия в техническом отборе, как правило, отбор относительно привычный и охватывает относительно большие рамки. Каждая система также отличается с точки зрения архитектурного дизайна.Некоторые недавно созданные системы в основном используют режим проектирования микросервисов, некоторые используют архитектуру SOA, а некоторые системы имеют только отдельный дизайн до и после, которые представляют собой полностью монолитные структуры.Также существуют проекты.
Хотя у нас и появились определенные планы по построению системы, при быстром и варварском развитии бизнеса мы слепо гнались за скоростью и подстраивались под бизнес-дизайн. Результатом этого является то, что, будь то рефакторинговая и трансформированная система или вновь построенная система, содержащиеся в ней бизнес-границы не очевидны, и между ними разрабатываются дублирующие функции, которые относительно разбросаны. нет естественного ощущения.
Основные проблемы, возникающие в этой ситуации:
- Строительство новых продуктов идет медленно и совершенно не соответствует быстрому развитию бизнеса.
- Трудно автоматизировать операции.
- За счет масштабирования сложно повысить производительность.
Благодаря идее дизайна микросервисной архитектуры мы проводим трансформацию системы. Базовые услуги отделены от каждой бизнес-системы, чтобы сформировать единую сервисную возможность; различные системы поддержки реализуют постепенное улучшение высокопроизводительной и высокодоступной инфраструктуры, так что бизнес-система может больше сосредоточиться на реализации бизнес-логики. Используйте руководящую идеологию проектирования, ориентированного на предметную область, для определения бизнес-границ каждой системы. После такого планирования и проектирования должно быть достигнуто идеальное обновление архитектуры системы.
03 Основные спорные моменты
Архитектура микросервисов просто концептуально указывает нам направление, формулируя несколько важных принципов проектирования:Сервис как можно меньше, независимо развертываемый, автоматизированный развертывание и эксплуатация и обслуживание. Эти концепции должны быть реализованы на местах. Из-за различий в понимании и текущей ситуации в компаниях каждая компания должна иметь разные реализации. Это собственная уникальная микросервисная архитектура каждой компании. В конце концов, проектирование архитектуры должно служить бизнесу. .модуль. Поэтому наша фабрика также обсуждает, как реализовать микросервисную архитектуру, соответствующую характеристикам нашей собственной компании.
В ходе обсуждения было несколько тем для обсуждения, которые кратко изложены здесь:
- Где проходит граница между базовыми возможностями и продуктами верхнего уровня? В какой степени базовые возможности абстрагированы, интересует ли вас бизнес-логика продуктов верхнего уровня?
- Игра разделяй и объединяй.
- Позволяет ли дизайн бизнес-модуля существовать единой точке.
- Какие изменения можно внести в организационную структуру и разделение труда.
По сути, предыдущие два пункта касаются разделения границ бизнеса: первый пункт — это вертикальная граница после наслоения, а второй пункт — горизонтальная граница. Для первого пункта возьмем в качестве примера функцию перезарядки:
Стандартный процесс пополнения: 1. Списание денег с банковской карты пользователя (платежный интерфейс) 2. Учет внутреннего счета пользователя. Подробные шаги здесь не объясняются.Студенты, знакомые с платежным бизнесом, должны понимать, что существуют различные платежные методы для оплаты, а также различные внутренние счета (стандартное пополнение — кассовый счет пользователя). Если это стандартное пополнение, два шага также являются стандартными процедурами, если есть особый бизнес, пополнение осуществляется на комиссионный счет.Должно ли пополнение такого конкретного бизнеса осуществляться в центре пополнения? После длительного пребывания в сторонней платежной компании вы обнаружите, что существуют различные стандартные продукты и множество индивидуальных продуктов.
Наш вывод состоит в том, что стандартизированные функции поддерживаются базовыми службами, предоставляя стандартные возможности для уровня продукта, и имеют мощные индивидуальные бизнес-функции, которые непосредственно инкапсулируются и реализуются на уровне продукта путем прямого вызова возможностей более низкого уровня.
Что касается второго пункта, некоторые студенты могут задаться вопросом: не является ли принцип микросервисной архитектуры разделением сервисов как можно меньше для достижения высокой связанности и низкой связанности? Почему до сих пор происходит слияние? Насколько я понимаю, этот принцип применим только к полной бизнес-логике.Есть также некоторые компоненты, которые не имеют ничего общего с базовым бизнесом, которые должны быть реализованы при построении системы.Эти общедоступные службы (такие как унифицированный серийный номер, унифицированное управление сессиями и т. д.) .) должны быть абстрагированы и реализованы единообразно. , что вызывается бизнес-системой. Существуют также некоторые данные, которые схожи по методам управления и использованию, и этими данными можно управлять вместе, чтобы предоставлять услуги унифицированным образом.
При бизнес-дизайне принцип проектирования микросервисов заключается в том, чтобы избегать одноточечных модулей. Полностью распределенные и высокосвязные сервисы имеют много преимуществ, разрозненное давление и меньшее взаимное влияние, но ими нужно управлять отдельно. На самом деле эти преимущества относительны: в компании с высоким средним технологическим уровнем сплоченная система относительно хороша, а различные технологии можно хорошо контролировать. Например, должна ли система платежных поручений быть распределена между различными продуктовыми системами или ее следует объединить в центр заказов, чтобы при необходимости повышения производительности, когда необходимо выполнить некоторую асинхронную обработку, производительность можно было бы повысить за один раз. место.
Как видно из демонстрации микросервисов Мартином Фаулером, микросервисная архитектура — это не только системная архитектура, но и руководство по организации персонала. Команда должна быть как можно более полной, чтобы достичь высокой сплоченности и низкой связанности. Чтобы снизить неэффективность, вызванную перекрестным сотрудничеством ведомственных организаций, мы несем ответственность за каждый продукт, а не за завершенный после поставки проект, весь жизненный цикл продукта должен поддерживаться этой командой. В этом случае исходная организационная структура также нуждается в корректировке под реализацию микросервисной трансформации, что требует поддержки руководителей.
О системе поддержки и инфраструктуре много не говорят, этот набор низкоуровневых услуг по эксплуатации и обслуживанию является относительно стандартным, и большинство из них завершены и в настоящее время находятся в стадии доработки и оптимизации.
Подводя итог, архитектурный дизайн сам по себе является игрой обмена знаниями, будь то популярная микросервисная архитектура или другие архитектуры, такие как SOA, исключений нет. Лучший архитектурный проект должен соответствовать развитию бизнеса и планированию самой компании, а также организационной структуре.Существующие могут препятствовать процессу микросервисов, но с практической точки зрения, сколько могут сделать эти предприятия и организации для микросервисов Изменения также являются проблемой, которую необходимо учитывать. Мы не проводим кардинальных реформ, трансформация микросервиса должна быть естественным и постепенным процессом оптимизации.
Это первый раз, когда я участвовал в таком масштабном архитектурном проектировании, и я обнаружил, что есть слишком много вещей, которые нужно взвесить, и нужно ли придерживаться некоторых принципов проектирования.
04 Целевая архитектура (схема)
В итоге, основываясь на достигнутом всеми консенсусе и собственном понимании бизнеса, я составил следующую схему архитектурного проекта:
целевая архитектура
Эта статья - мое понимание трансформации микросервисов и реконструкции бизнеса. Она не представляет собой формальную структуру компании. Некоторые конструкции не бывают хорошими или плохими. Взвешивание плюсов и минусов и оценка ситуации являются ключевыми моментами.