Автор | Тан Чжилун (Кунлун), старший инженер-разработчик Alibaba

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

предисловие

Разработчики часто сталкиваются со следующими сценариями:

• Новые новобранцы должны изучать существующую систему, как часть посадки, как узнать?
• Вас остановили для участия в итеративной разработке или обслуживании системы (исправлении ошибок) незнакомой системы. Как быстро приступить к работе?
• При увольнении или переводе коллеги систему нужно передать вам, как это сделать? Внутренний зев: Это горшок?

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

бизнес-обучение

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

Общая проблема:

• Какова отраслевая ситуация, в которой работает система?
• Кто является целевым пользователем системы? Например, используется ли он для принятия решений наверху компании? Для операций или обслуживания клиентов? Или для интернет-пользователей?
• Сколько людей в среднем им пользуются? Сколько людей используют его в часы пик?
• Какую ценность для бизнеса имеет система? Какие показатели могут измерить ценность системы для бизнеса?
• Какие функциональные модули есть в системе?
• Какие концепции предметной области есть в системе? разобраться в предметной модели системы;
• Каковы ключевые бизнес-процессы системы? Каковы основные бизнес-процессы?
• Каковы нефункциональные требования к системе? Такие как производительность, качество, масштабируемость, безопасность и т.д.;
• Будущее системы планирования развития, как?

техническое обучение

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

Пять взглядов:

• логическая архитектура
• Архитектура разработки
• запустить архитектуру
• физическая архитектура
• схема данных

логическая архитектура

Логическая архитектура фокусируется на функциональных требованиях, и система должна предоставлять пользователям какие услуги, и основное внимание уделяется разделению поведения или обязанностей. Обычно используемые графические выражения, статические карты включают диаграммы пакетов, диаграммы классов, карты объектов; динамические карты включают диаграммы порядка, диаграммы сотрудничества, диаграммы состояний и активные диаграммы. Основной задачей проектирования логической архитектуры является разделение модулей, определение интерфейса, уточнение модели предметной области.

Общая проблема:

• Какие подсистемы или модули существуют? Какая связь между системами?
• Что такое внешние восходящие и нисходящие интерфейсы? Кто является контактным лицом?
• Как реализация ключевых бизнес-процессов? Высказывайте его с диаграммой классов, диаграммой последовательности и тому подобным.

Архитектура разработки

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

Общая проблема:

• Где код?
• Как разделены пакеты? Как наслаивать? Например, mvc, controller-service-dao;
• Какие рамки используются, такие как SSH, Dubbo;
• Какие наборы используются? Такие как Apache Commons, Guava;
• Какое промежуточное ПО используется? Такие как metaq, tair, schedulerX, Diamond;
• На какие платформы вы полагаетесь? Например, платформа разрешений, механизм обработки и т. д.

запустить архитектуру

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

Общая проблема:

• Сколько запросов в секунду может поддерживать система? Каков пиковый qps?
• Как взаимодействовать с вышестоящей системой? ПКП? HTTP? Синхронизация или асинхронность?

физическая архитектура

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

Общая проблема:

• Как система публикуется и развертывается? Какие существуют среды развертывания?
• Сколько машин в системе?
• Как развертывается система? Обратите внимание на уровень доступа и методы развертывания, такие как кластерное развертывание, распределенное развертывание и т. д.
• Есть ли контейнеризация?
• Есть ли многокомнатное развертывание?

схема данных

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

Общая проблема:

• Где хранятся данные? Какая база данных используется, например, oracle, mysql;
• Разобрать диаграммы E-R;
• Какой объем данных? Будут ли участники библиотечной подтаблицы?
• Какие библиотеки nosql используются?
• Каковы задачи синхронизации данных?
• Как используются структуры больших данных?

Эксплуатация и техническое обслуживание системы

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

Общая проблема:

• Когда легко ошибиться? Например, электронная коммерция Double 11 оказывает сильное давление на систему, и в это время могут возникнуть проблемы;
• Отслеживаются ли ключевые функции? Вам необходимо увидеть, какие элементы сигнализации настроены в системе и какие аспекты отслеживаются;
• Как решить проблему? Где журналы? Есть ли полная трассировка ссылок? Есть ли какие-то аварийные операции, такие как конфигурация коммутатора, понижение версии, конфигурация ограничения тока;
• Какие ямы в системе? Найдите одноклассников по развитию, чтобы просмотреть исторические выпуски, чтобы не наступить на яму. Через случай, обобщенный коллегами, или с ответственным продуктом, работой, технологией и пониманием. В системе всегда будут какие-то ямы, и эти ямы нужно заполнить. После многих итераций исторического кода это всегда будет приводить к высокой сложности (множество ответвлений, вложенности, циклов), лазейкам в дизайне, угрозам производительности и т. д., и его сложно поддерживать, что требует от нас рефакторинга. Помните поговорку: чем больше дыра, тем больше способности;
• Каковы общие проблемы эксплуатации и обратной связи с клиентами?

упражняться

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

Суммировать

Существующие системы обычно проходят процесс построения от 0 до N. Знакомство с системой на самом деле является обратным процессом вывода, а также процессом изучения архитектуры и чтения исходного кода. В процессе обучения лучше всего доводить до размышлений, например, почему так устроено? Зачем использовать это промежуточное ПО? Есть ли лучший способ закодировать его? Какие области можно оптимизировать и т. д., чтобы добиться глубоко знакомого процесса.

Приложение: сводная схема

Скоро откроется саммит Cloud Native Practice

"Облачная нативная платформа Alibaba关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。 "