В последнее время я участвовал во многих проектах по реконструкции, включая реконструкцию таких сервисов, как Gateway gateway и AMAPS, с целью улучшения использования серверных ресурсов, а также разделение общих бизнес-сервисов с целью повышения рациональности архитектуры и эффективности НИОКР. , Я воспользовался этой возможностью, чтобы разобраться с соответствующим содержанием, это обмен, а также самообобщение и обучение. Приготовьтесь рассказать о тех местах, которые склонны к недопониманию, или о ключевых моментах, которые легко упустить из виду в работе по рефакторингу, это не будет повторять одни и те же различные схемы материалов в Интернете, а также будет иметь справочное значение для работы по рефакторингу.
Что такое «Дао Гармония»? Если исходить из простого личного понимания, Дао — это мысль, а искусство — это метод. Можно сказать, что есть путь, но нет искусства, а искусство еще можно искать; если есть искусство, но нет пути, то оно кончается искусством. Из основных идей и принципов реконструкции, а также применения общих схем реконструкции мы поговорим о «Дао и Технике» системной реконструкции.
1. Способ реконструкции системы
Сейчас подходящее время для рефакторинга? Какую подготовку мне нужно сделать перед рефакторингом? Как обеспечить плавное завершение работ по рефакторингу и достижение ожидаемых целей? Из этих вопросов, которые волнуют всех, поговорим об основных идеях и принципах, которым следует работа по реконструкции.
от практических задач
"Реконструкция, которая не может решить практических задач, есть хулиганство. Отталкиваясь от практических задач, не делайте рефакторинг ради реконструкции. Это кажется простым, но на самом деле есть реконструкции, инициированные ради реконструкции. Возможно, они хотят их применить. Привлекательные новые технологии могут быть инициированными рефакторингами, чтобы не отставать от модных тенденций или даже иметь свои собственные активные потребности YY. Как инженеры, мы должны помнить, что стабильность системы превыше всего, и любой рефакторинг сопряжен с риском, а рефакторинг без пользы для бизнеса равносилен допущению бизнеса к ненужным рискам, что крайне безответственно.
Итак, инициируя проект рефакторинга, вам сначала нужно выяснить, какую реальную проблему необходимо решить, чтобы повысить производительность? Или усилить безопасность? Или для быстрой непрерывной интеграции и выпуска? Хочешь понять, а потом действуй.
Ставьте четкие цели
Ясность целей во многом определяет то, чем все закончится, и то же самое касается проектов рефакторинга. Принцип постановки целей SMART часто упоминается в курсах организационного управления и управления целями. Точно так же проекты рефакторинга должны иметь конкретные, измеримые, выполнимые, достижимые и ограниченные по времени цели. Реализация и временные ограничения легко понять. Акцент делается на конкретные и измеримые.Могут ли вышеупомянутые проблемы, которые необходимо решить, быть целями проекта реконструкции? Ответ нет,проблема кроется в конкретной измеримости.Возьмем в качестве примера проект реконструкции для решения проблемы производительности.Цель должна заключаться в том,насколько надо уменьшить служебный отклик RT?Или на сколько должен загружаться одноядерный QPS быть улучшенным? Может еще на сколько ресурсы сервера урезаны? Это конкретная и измеримая цель.
Как некоторые цели, не поддающиеся количественной оценке, могут быть измеримы? В качестве примера возьмем проект реконструкции с целью повышения доступности услуг. Цель действительно трудно поддается количественной оценке. Для таких проблем в качестве эталона измерения могут использоваться конкретные события, такие как осознание отказа пользователей в оборудовании. помещения, или автоматическое ухудшение состояния и устранение основных сбоев и т. д. (Высокая доступность системы часто оценивается с помощью нескольких 9 показателей, но это показатель сбора данных постфактум, и он не подходит для управления проектами с коротким и средним циклом). цели).
Внутри Али часто называют отправной точкой работы, и эта конкретная и измеримая цель является отправной точкой нашей работы по рефакторингу.
Дизайн должен быть
"Недостаточный дизайн" и "чрезмерный дизайн" являются ошибками проектирования. Недостаточный дизайн возникает из-за отсутствия необходимого абстрактного мышления и перспективного мышления, что приводит к дефектам дизайна системы; в то время как чрезмерный дизайн часто не дает ясности о системные проблемы и отклонение от реальных потребностей.Чрезмерная погоня за масштабируемостью приводит к внедрению избыточного дизайна.Результатом чрезмерного проектирования являются не просто бесполезные функции расширения, но чаще он приносит некоторые новые проблемы, такие как увеличение стоимости обслуживания системы и итерация, рост онлайн-проблем, проверка сложности и т. д.
В дополнение к недостаточному и чрезмерному проектированию необходимо также учитывать аспект затрат и выгод.Некоторые проекты могут быть внедрены для решения некоторых проблем, но их решения слишком сложны, а стоимость реализации слишком высока. решать, принимать его или нет.
К несовершенному дизайну почти нет ярлыков, и требуется постоянное обучение и накопление опыта. Чрезмерный дизайн требует, чтобы мы больше думали о необходимости и вопросах рентабельности связанных проектов при составлении планов дизайна.
идти быстро
Заранее составить план итерации — важный пункт, который легко упустить из виду в работе по рефакторингу.В начале проектирования схемы рефакторинга необходимо продумать, как реализовать ее поэтапно, и даже некоторые компромиссы в схеме проектирования иногда требуются для достижения цели фазирования. Если сравнивать рефакторинг со строительством, то стратегия разделения слоев небольшими шагами эквивалентна возведению строительных лесов на строительной площадке, что является эффективным средством контроля рисков в допустимых пределах.
Чтобы дать реальный опыт реконструкции, это служба заказа с небольшим объемом заказа, но многими видами бизнеса (гостиницы, билеты, билеты на поезд и т. д.). Окончательный проект делит систему на четыре модуля в соответствии с процессом обработки заказов: модуль размещения заказов, модуль синхронизации заказов CP, модуль обработки заказов и модуль статистики. Некоторые студенты спрашивают, не велик ли объем заказа и уместно ли разделить несколько модулей? На самом деле, помимо рассмотрения самого дизайна, причина, по которой важно разделить несколько модулей в соответствии с процессом заказа, заключается в возможности запуска и проверки поэтапно, и только таким образом риск может быть действительно контролируемым. (по некоторым конкретным причинам он не разбит по вертикали по бизнесу, здесь пока Unknown table).
Таким образом, рефакторинг системы должен выполняться итеративно, насколько это возможно, и его следует рассматривать с самого начала.
Во-вторых, техника реконструкции системы
В работах по реконструкции системы будут использованы некоторые специфические средства для решения поставленных конкретных задач.В технической части мы поговорим о некоторых схемах, которые часто используются при реконструкции.Конкретного содержания и материалов схемы много, и мы Здесь остановимся на том, на какие вопросы стоит обратить внимание, говоря о применении сопутствующих решений.
Обслуживание
Сервис-ориентированность упоминалась во многих проектах рефакторинга. Абстракция, разделение, разделяй и властвуй и унификация являются важными идеями при проектировании и реконструкции системы. Сервис-ориентированность является важной практикой этой идеи. При использовании сервис-ориентированного проектирования что следует вы обращаете внимание на?вопрос?
цель обслуживания
Выполняя ориентированные на обслуживание работы по проектированию или реконструкции, мы должны в первую очередь думать о ценности, которую приносит ориентированность на услуги, что также является целью нашей работы, ориентированной на услуги.
Уровень спроса: поддержка быстрой итерации
Уровень разработки: разделение кода, независимая разработка, снижение затрат на обслуживание
Уровень эксплуатации и обслуживания: независимое развертывание, независимое расширение, контроль деградации
Вышеупомянутое является ценностью, которую приносит сервис-ориентированный.Интересно, что если это плохой сервис-ориентированный дизайн, вышеперечисленное также будет проблемой, вызванной сервис-ориентированным дизайном.Например, некоторые студенты часто жалуются, что сервис-ориентированный дизайн ориентированный дизайн более хлопотный, чем предыдущая разработка и запуск. Таким образом, четкое понимание целей, ориентированных на обслуживание, является первым шагом в работе, ориентированной на обслуживание.Если цели не достигаются или даже вызывают негативные последствия, необходимо пересмотреть целесообразность соответствующего дизайна.
Акцент на обслуживании отдельных лиц, слабая коммуникация
Участвуя в сервисно-ориентированной работе, я часто сталкиваюсь со студентами, которые рассказывают о различных RPC-фреймворках или различном промежуточном программном обеспечении для сообщений. Сервисно-ориентированная работа делает упор на дизайн отдельных сервисов, а конкретный способ коммуникации не так важен, по крайней мере на начальном этапе. Постарайтесь сосредоточиться на основных проблемах на разных этапах.
Выбор детализации
Сервисно-ориентированная работа является наиболее сложной и наиболее зависимой от опыта является выбор степени детализации обслуживания, как правильно определить границу подсистемы в сочетании с реальными характеристиками системы, с одной стороны, существуют соответствующие принципы проектирования, которые могут быть упоминается (например, единый принцип, без гражданства и т. д., есть много онлайн-материалов) и многое другое Больше накопления опыта.Если это работа по реконструкции системы, рекомендуется уточнить из модулей с важными приоритетами.Когда степень детализации может быть большой или маленькой, ее трудно контролировать, вы можете сначала рассмотреть возможность реализации более масштабного решения, чтобы даже при наличии проблем можно было дополнительно оптимизировать разделение, но если оно сразу слишком тонкое, оно приведет к чрезмерному проектированию, и вернуться назад будет труднее.
Высокая отказоустойчивость
Как было сказано выше, сервис-ориентированный делает упор на обслуживающих лиц, и как самостоятельный сервис следует рассматривать его отказоустойчивый дизайн, а также он определяет стабильность всей сервисной системы. Поэтому сервитизация — это не просто разделение сервисов, после разделения необходимо проанализировать зависимости между сервисами, выделить сильные и слабые связи и провести связанное отказоустойчивое проектирование.
дизайн кэша
Если кэширование данных является наиболее часто используемым методом в работе по реконструкции, по оценкам, не будет слишком много неоднозначности.При использовании схемы кэширования данных необходимо обратить особое внимание на следующие моменты.
Кэширование — не серебряная пуля
Когда дело доходит до оптимизации производительности, вы часто слышите «тогда давайте добавим кеш». Действительно, эффект кэширования данных на повышение производительности немедленный, и многие студенты стали практически условным рефлексом при решении проблем с производительностью системы.
Будь то новый дизайн системы или рефакторинг старой системы, не всегда делайте кэширование данных первоочередным выбором при возникновении проблем с производительностью, это ослепит вас и не позволит увидеть проблемы на других уровнях. Я помню, когда я работал в компании, занимающейся корпоративным программным обеспечением, я следовал за главным архитектором компании, чтобы разработать базовый сервисный дизайн.У него было требование, чтобы при первоначальном проектировании системы не учитывался дизайн кэша, что произвело на меня глубокое впечатление. Добавление кеша для повышения производительности на самом деле использует тактическое усердие, чтобы скрыть стратегическую лень.При решении проблем нам нужна всесторонняя оценка с разных сторон и разных измерений, чтобы можно было решать проблемы систематически.
Лавина и проникновение
Кэширование данных решает проблему производительности чтения данных, но также создает новую точку отказа в архитектуре системы.
Лавина и проникновение — это проблемы, которые следует учитывать при внедрении кэширования данных. Прежде всего, с бизнес-уровня нам необходимо рассмотреть стратегию понижения и конкретный план понижения в соответствующей ситуации.С технического уровня, высокая доступность самого кеша, являются ли кэшированные данные постоянными, нужно ли добавлять кеш механизм прогрева, следует ли выполнять дискретный расчет по истечении времени и т. д. Детали подлежат рассмотрению.
Внутренняя оптимизация системы
Рефакторинг
Оптимизация кода делится на оптимизацию структуры кода и оптимизацию содержимого кода.Последняя фокусируется на том, как определить неприятные запахи в коде.Существует множество конкретных методов руководства, которые не будут здесь упоминаться. Первый больше связан с корректировкой дизайна кода, который проверяет способность проектировать абстракцию и требует лучшего знания модели предметной области (DDD). Поэтому хороший программист должен быть экспертом в предметной области.
Асинхронное преобразование
Для приложений с интенсивным вводом-выводом асинхронное преобразование является очень эффективным методом, но его все еще довольно сложно реализовать.Это отражается в двух аспектах.Во-первых, поддержка полных технических решений,к счастью, коллеги уже посетили нас Хорошо, я решил проблему асинхронности часто используемого промежуточного программного обеспечения компании (Hsf, Tair, Metaq, Tddl, Sentinel и т. д.) и хотел бы порекомендовать вам соответствующую информацию о проекте обновления архитектуры Taobao. проект — это микросервисы и асинхронное преобразование на основе реактивного программирования.Из этого мы можем видеть, насколько большим является проект по асинхронному преобразованию системы с нуля. С другой стороны, это затраты на обучение самой команды, что требует от всех участников хорошего понимания модели асинхронного и реактивного программирования, что особенно важно.
Подбиблиотека и подтаблица
Когда объем данных быстро растет и одна база данных не может удовлетворить потребности бизнеса, для ее решения обычно используются подбаза данных и подтаблица.
Если вы разрабатываете новую систему, если только сам бизнес не опирается на массивные данные, не рекомендуется внедрять подбазу данных и подтаблицу на ранней стадии разработки, потому что это усложнит проектирование и разработку системы до определенная степень. И с самого начала пусть бизнес-разработчик обратит внимание на подтаблицу подбазы данных, если он неопытен, легко внести дополнительную путаницу и усложнить решение изначально простой проблемы.
Что касается стратегии генерации первичного ключа, вы можете выбрать различные механизмы.В настоящее время используется и обсуждается больше Snowflake, который требует системного времени, а другой является стратегия генерации Tddl, которая учитывает производительность, глобальную уникальность. и приращение одной базы данных.
После подбазы данных и подтаблицы вам необходимо рассмотреть проблему кросс-базы данных и кросс-табличного запроса.Прежде всего, этого следует избегать в бизнесе, насколько это возможно, но для бизнеса заказа необходимы данные в разных измерениях. быть разделены на пользователей и продавцов (основная база данных и подбаза данных могут использоваться отдельно. Пользователи и продавцы используются в качестве ключей подтаблицы). Если это сложный запрос с несколькими условиями в фоновом режиме работы и управления, будь то подбаза данных или подтаблица, поддержка одной базы данных также не годится.Вы можете рассмотреть возможность использования ES для немассивных данных, и ES+HBASE для массивных данных.
3. Расскажите об оценке системы
Наконец, давайте кратко поговорим об оценке системы. С точки зрения исследований и разработок ее можно рассматривать с точки зрения шести аспектов высокой производительности, высокой доступности, масштабируемости, масштабируемости, безопасности и работоспособности. рекомендуется использовать так называемый стандарт, результат оценки системы должен быть выводом, основанным на фактической ситуации в бизнесе, такой как высокая доступность, развертывание нескольких экземпляров платформы управления операциями может быть хорошим, но если это система онлайн-транзакций, мультирум - это только начальное требование.
При оценке системы, основанной на фактической ситуации в бизнесе, вышеупомянутые шесть параметров оцениваются в соответствии с тремя категориями серьезных недостатков, недостатков и удовлетворенности, и проводится предварительный анализ недостатков системы. Кроме того, следует отметить, что эти измерения не существуют независимо друг от друга, поэтому при рефакторинге и оптимизации определенного аспекта необходимо детально учитывать влияние на другие аспекты системы.
Последнее, что я хочу сказать, это то, что сделать хорошую работу по реконструкции системы непросто.Сложность не в решении конкретных задач.Это системный проект.Как мы можем всесторонне рассмотреть и выбрать относительно оптимальное решение после рассмотрения различных факторов — самая большая проблема.