предположение

• Смотрите видео, читайте книгу или смотрите ее и систематически изучайте
• Систематическое обобщение и размышление
• методология обучения
• рекомендуемое программное обеспечение для заметок на полях

Структура проекта

• организация каталогов

• название

• Слоистый

• инициализация ресурсов

• внедрение зависимости

• Инверсия контроля

  Мао Цзянь просмотрел более 20 ссылок и 4 видео на YouTube.

Standard Go Project Layout

GitHub.com/go wave-beach…

Необходимость проекта

• Один из меня, MAIN.go
  • Начните с чего-нибудь очень простого (одного файла main.go более чем достаточно)
  • Этот макет проекта не нужен, если вы пытаетесь изучить Go или создаете PoC или игрушечный проект для себя.
• Когда в проекте участвует все больше и больше людей, его необходимо структурировать и проектировать, чтобы облегчить совместную работу.
• Вам потребуется больше структуры, в том числе необходимость в наборе инструментов для облегчения создания шаблонов проектов, а также максимально унифицированный макет каталога проекта.

/cmd

• Сохраните основной файл этого проекта
• Не подходит для лежачего слишком большого количества кода, пишет некоторые операции инициализации
• Имя каталога каждого приложения должно совпадать с именем исполняемого файла, который вы хотите
  • (Например, /cmd/myapp).
  • Не помещайте слишком много кода в этот каталог.
• Если вы считаете, что код можно импортировать и использовать в других проектах, он должен находиться в каталоге /pkg.
• Если код нельзя использовать повторно или вы не хотите, чтобы его использовали другие, поместите код в каталог /internal.

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

/internal

• В этом проекте можно использовать только импортированные
• например, внутренний/демонстрационный
• Частное приложение и код библиотеки. Здесь вы не хотите, чтобы другие люди импортировали код в свое приложение или библиотеку.
• Этот шаблон компоновки применяется самим компилятором Go.
  • Дополнительные сведения см. в примечаниях к выпуску Go 1.4.

Уведомление

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

• Фактический код приложения может быть помещен в каталог /internal/app (например, /internal/app/myapp),
• Код, совместно используемый приложениями, можно поместить в каталог /internal/pkg (например, /internal/pkg/myprivlib).

Поскольку мы привыкли к связанным службам, таким как службы учетных записей, есть rpc, job, admin и т. д., после интеграции связанных служб нам необходимо различать приложения. Для одной службы вы можете избавиться от /internal/myapp.

Вы также можете создать pkg под каждым приложением, только для небольшого повторного использования приложения.

/pkg

• Повторно используемый код, такой как utils, общий

• Код библиотеки, который может использоваться внешними приложениями (например, /pkg/mypubliclib). Другие проекты импортируют эти библиотеки, так что дважды подумайте, прежде чем размещать что-либо здесь :-),

  • Каталог INTERNAL — это лучший способ гарантировать, что частные пакеты не могут быть импортированы, потому что он применяется Go.

• Каталог /pkg по-прежнему является хорошим способом явно указать, что код в этом каталоге является хорошим способом безопасного использования другими.

• В каталоге /pkg вы можете обратиться к организации стандартной библиотеки go и классифицировать ее по функциям.

  • string net http

• /internla/pkg обычно используется в рамках проекта для общего общего кода в нескольких приложениях, но его область действия распространяется только на один проект проекта.

• Я возьму pkg вместо внутреннего сообщения в блоге Трэвиса Джеффри (Трэвис Jeff.com/no/2019/11/i…Хороший обзор pkg и внутренних каталогов, а также когда имеет смысл их использовать.

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

Kit Project Layout

• Каждая компания должна создать единый проект комплекта KIT (базовая библиотека/фреймворк) и элемент приложения для различных микросервисов.
  • Соедините общий код
• Базовый комплект библиотек является самостоятельным проектом, на уровне компании рекомендуется иметь только один, разбирать по справочнику функций.
  • Клубы приносят много управленческой работы, поэтому рекомендуется консолидация.
  • Используйте административные средства, не делайте печки сами, просто покажите, что вы хорошо пишете

Справочная статья Пакетно-ориентированный дизайн(Woohoo. AR, но labs.com/blog/2017/0…)

"С этой целью проекту Kit не разрешается иметь папку поставщика. Если какой-либо из пакетов зависит от сторонних пакетов, они всегда должны создаваться с использованием последней версии этих зависимостей".

• Сторонние пакеты не разрешены из-за зависимостей
• Пакет комплекта зависит от третьей стороны и будут проблемы со сменой зависимого пакета

библиотека Кратоса

Особенности проекта Kit должны иметь:

• Унифицировать нормативные вещи, объединившись как можно скорее
• Стандартный макет библиотеки
  • Название пакета «effectice go» говорит о
• очень абстрактный
• Поддержка плагинов
• базовая библиотека go-kit

Минимизировать зависимость не должно полагаться на конкретную реализацию

Service Application Project Layout

/api

Сохраните каталог определений протокола API, файл xxapi.proto protobuf и сгенерированный файл go. Обычно мы описываем документацию по API прямо в файле proto.

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

/configs

Шаблон профиля или конфигурация по умолчанию.

• Рекомендуемый YAML

/test

Дополнительные внешние тестовые приложения и тестовые данные. Вы всегда можете структурировать каталог /test по мере необходимости. Для больших проектов имеет смысл иметь подкаталог данных. Например, вы можете использовать /test/data или /test/testdata (если вам нужно игнорировать содержимое каталога). Обратите внимание, что Go также игнорирует каталоги или файлы, начинающиеся с «.» или «_», поэтому существует больше гибкости в том, как называется каталог тестовых данных.

Важное не должно содержать: /src

• В некоторых проектах Go есть папка src, но это обычно происходит, когда разработчики имеют опыт работы с Java, где это распространенный шаблон.
• Не используйте каталог src уровня проекта вместе с каталогом src, который Go использует для своей рабочей области.
• Путь Go (пакет) первоклассный гражданин, нет необходимости в src
• Отличить GOPATH (рабочая область)

Service Application Project

Gitlab проекта может быть размещен во множестве микро- и сервисных приложений (аналогично монорепозиторию). Может быть создано в соответствии с несколькими проектами gitlab группы, каждая из которых соответствует проекту приложения.

• В методе с несколькими приложениями каждая микрослужба в каталоге приложений создает каталог в соответствии со своим собственным глобальным уникальным именем, например «account.service.vip», например: account/vip/*.
• В каталоге pkg на уровне приложения хранятся публичные библиотеки, связанные с бизнесом (небазовые библиотеки фреймворка). Если приложение не хочет экспортировать эти каталоги, их можно поместить в myapp/internal/pkg.

biz не зависит ни от какой инфраструктуры

Типы сервисов приложений в микросервисах делятся на 4 категории: интерфейс, сервис, задание и администратор.

interface:

• Внешние службы BFF принимают запросы от пользователей, такие как предоставление интерфейсов HTTP/gRPC.
• Это слой BFF, а верхний слой - асиупитание
• xxxinterface

service:

• Внутренняя микрослужба принимает запросы только от внутреннего шлюза или другой службы, например открытые интерфейсы внутренней службы gRPC.
• xxxservice

admin:

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

job:

• Предпочитаю резидентное исполнение
• Для потоковых служб обработки задач восходящий поток обычно полагается на брокера сообщений.
• Например: подписка на бинлог и т.д.

task:

• Предпочитаю исполнение по времени
• Запланированные задачи, похожие на Cronjobs, развернуты на платформу хостинга задач.
• Хостинг на платформе задач хронометража
  • gocron
  • airflow
  • библиотека CMD кобры

Каталог приложения cmd отвечает за работу программы: запуск, завершение работы, инициализацию конфигурации и т.д. Журнал мониторинга конфигурации инициализации ресурсов

Проект приложения Evolution Service-v1

В нашем старом макете в каталоге приложения есть api, cmd, configs и внутренние каталоги, а README, CHANGELOG и OWNERS обычно размещаются в каталоге.

• api: поместите определение API (protobuf) и соответствующий сгенерированный клиентский код на основе файла swagger.json, сгенерированного pb.
• configs: поместите файлы конфигурации, необходимые службе, такие как database.yaml, redis.yaml и application.yaml.
• Внутренний: это сделано для того, чтобы кто-то не мог ссылаться на внутренний каталог в рамках одного и того же бизнеса.
  • структура модели Отображение таблицы структуры MYSQL
  • дао и другие внутренние структуры. (объект доступа к данным)
    • БД доступа, табличная, одна таблица соответствует одному методу
  • бизнес-логика службы будет зависеть от dao
  • server
• сервер: поместите код маршрутизации для HTTP/gRPC и код для преобразования DTO.
• инициализация cmd

пример модели

• дао зависит от модели
• сервис зависит от дао
• сервер зависит от службы
• restful ---> server
  • Как написать привязку службы и слушателя
  

Болевые точки

Однозначное соответствие между моделью и таблицей базы данных - Поля, чувствительные к паролю, следует игнорировать.json: "-"- int64 не поддерживается при сериализации json - Данные слоя mysql перебрасываются на уровень представления - Сложные данные уровня представления должны быть связаны с кодом уровня данных.

решать

DTO(Data Transfer Object):数据传输对象，这个概念来源于 J2EE 的设计模式。
但在这里，泛指用于展示层/API 层与服务 层(业务逻辑层)之间的数据传输对象。

Зависимость приводит к

Путь зависимости проекта: модель -> дао -> сервис -> API Структура модели подключается к каждому слою до тех пор, пока API не потребуется преобразовать в объект DTO.

• модель: размещение структуры, соответствующей «уровню хранения», представляет собой однозначное сопоставление хранилища.
• dao: уровень чтения и записи данных, база данных и кэш обрабатываются на этом уровне,
  • Включает обработку промахов кэша.
  • Сначала уровень бизнес-логики изначально был преобразован в уровень DAO.
  • Бизнес-уровень фокусируется на бизнесе
• сервис: объединение различных доступов к данным для построения бизнес-логики.
• сервер: он использует службу, определенную proto, в качестве входного параметра, и предоставляет быстрый глобальный метод для запуска службы.
• api: определяет файл APIproto, сгенерированный код-заглушку, генерируемый им интерфейс, и его реализация находится в службе.

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

Модель анемии

DO (Объект домена): объект домена,

• Это материальный или нематериальный бизнес-объект, абстрагированный от реального мира. Отсутствие преобразования объекта DTO -> DO.
• ориентированный на бизнес

Приложение Evolution Service Application Project-v2

В каталоге приложения есть api, cmd, configs и внутренние каталоги, а README, CHANGELOG и OWNERS обычно размещаются в каталоге.

internal:

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

biz:

• Уровень сборки бизнес-логики, аналогичный уровню домена DDD, данные, аналогичные DDD REPO, здесь определяется интерфейс REPO с использованием принципа опоры на инверсии.
• Постоянный интерфейс определяется на уровнях бизнес-логики
• Постоянство зависимостей уровня бизнес-логики (инверсия зависимостей)

data:

• Доступ к бизнес-данным, включая инкапсуляцию кеша, БД и т. д., реализует интерфейс репо biz. Мы можем спутать данные с dao. Данные сосредоточены на значении бизнеса. Что нужно сделать, так это снова вынуть объекты домена. Мы удалили инфра-уровень DDD.

service:

• Он реализует сервисный уровень, определенный API, аналогичный прикладному уровню DDD, который обрабатывает преобразование DTO в объекты бизнес-домена (DTO -> DO) и взаимодействует с различными бизнес-взаимодействиями, но не должен обрабатывать сложную логику.
• Сосредоточьтесь на реализации уровня интерфейса grpc

PO (Постоянный объект): Постоянный объект, который формирует отношение сопоставления один к одному со структурой данных уровня сохранения (обычно реляционной базы данных).Если уровень сохранения является реляционной базой данных, то каждое поле (или несколько) соответствует одному (или нескольким) атрибутам ПО.GitHub.com/Facebook/ En...(Горм не рекомендуется)

Lifecycle

Жизненный цикл должен учитывать инициализацию объекта приложения-службы и управление жизненным циклом.Все предварительные ресурсы, от которых зависит HTTP/gRPC, инициализируются, включая данные, бизнес и службу, а затем запускается служба мониторинга.

Мы используемgithub.com/google/wire, чтобы управлять внедрением зависимостей для всех ресурсов.

Зачем вам нужна инъекция зависимостей?

Ядро состоит в том, чтобы:

• 1. Удобно для тестирования;
• 2, одна инициализация и повторное использование;

Инверсия контроля

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

Wire

blog.golang.org/wireИнициализация и закрытие ручных ресурсов очень громоздки и подвержены ошибкам. Как упоминалось выше, мы используем идею внедрения зависимостей, DI в сочетании с google wire и static go generate для генерации статического кода, который можно легко диагностировать и просматривать, вместо использования отражения во время выполнения.

Дизайн API

• Сосредоточьтесь на gRPC
• protobuf определяет сообщение
• Транспортный уровень (tpc/http/rpc) и реализация сервиса изолированы

gRPC

Что такое gRPC, можно описать одним предложением с официального сайта.

«Высокопроизводительная универсальная среда RPC с открытым исходным кодом»

• Многоязычность: не зависит от языка, поддерживает несколько языков.
• Легкий и высокопроизводительный: Сериализация поддерживает PB (Protocol Buffer) и JSON, PB — это независимая от языка высокопроизводительная платформа сериализации.
• Подключаемый
• IDL: определите службу на основе файла и создайте структуру данных, интерфейс сервера и клиентскую заглушку для указанного языка с помощью инструмента proto3.
• концепт дизайна
• Мобильный: на основе стандартного дизайна HTTP2 он поддерживает двунаправленную потоковую передачу, сжатие заголовков сообщений, мультиплексирование одного TCP, отправку сервера и другие функции, которые делают gRPC более энергосберегающим и сетевым трафиком на мобильных устройствах.
• Службы, а не объекты, сообщения, а не ссылки: упрощение философии проектирования микросервисов для крупномодульного взаимодействия сообщений между системами.
• Независимость от полезной нагрузки: разные службы должны использовать разные типы сообщений и кодировки, такие как буферы протоколов, JSON, XML и Thrift.
• Потоковая передача: API потоковой передачи.
• Блокировка и неблокировка: поддерживает асинхронную и синхронную обработку последовательностей сообщений, взаимодействующих между клиентом и сервером.
• Обмен метаданными. Общие сквозные задачи, такие как аутентификация или отслеживание, зависят от обмена данными.
• Статус стандартизации Код статуса: Клиент обычно отвечает на ошибку, возвращаемую вызовом API ограниченным образом.

Взгляните на документацию gprc и используйте ее.

Не сосредотачивайтесь преждевременно на проблемах производительности, сначала стандартизируйте.

protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative helloworld/helloworld.proto

API Project

GitHub.com/API Google/… GitHub.com/envoy-proxy/… github.com/istio/api

Автоматически обновлять каталог API проекта, а затем автоматически обновлять его до выделенного внешнего каталога, соответствующего другому проекту.

• Скрыть исходный код для API могут только видеть
• Обращаясь к идее Гоголя
• Иметь хорошую структуру каталогов
• Простое управление версиями API
  • проверка кода, контроль версий

Как избежать случайного удаления чужих файлов

Чтобы единообразно извлекать и стандартизировать API, мы создали единый внутренний репозиторий bpis для интеграции всех внутренних и внешних API.

• Репозиторий API для совместной работы между отделами.
• Управление версиями на основе git control.
• Проверка нормализации, APIlint.
• APIdesignreview, изменение diff.
• Управление правами, каталог ВЛАДЕЛЬЦЕВ.

  • В каждом каталоге будет определен файл OWNERS, чтобы отметить автора.

API Project Layout

Определите proto в проекте с API в качестве корневого каталога имени пакета: Управляйте proto в едином репозитории, где репозиторий является корневым каталогом имени пакета:

API Compatibility

Модификации, совместимые с предыдущими версиями (неразрывные)

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

Без изменения поведения других полей ответа ответные сообщения без ресурсов (например, ListBooksResponse) могут быть расширены без нарушения совместимости клиента. Любые поля, ранее заполненные в ответе, должны продолжать заполняться с той же семантикой, даже если введена избыточность.

Обратно несовместимые (ломающие) модификации

• Удалить или переименовать службу, поле, метод или значение перечисления
  • По сути, если клиентский код может на что-то ссылаться, то его удаление или переименование является несовместимым изменением, и необходимо изменить основной номер версии.
• Изменить тип поля Даже если новый тип совместим с транспортным форматом, это может привести к изменению кода, сгенерированного клиентской библиотекой, поэтому его необходимо увеличить.
  • основной номер версии. Для скомпилированных статических языков легко ввести ошибки компиляции. • Изменить видимое поведение существующих запросов.
  • Клиенты часто полагаются на поведение и семантику API, даже если такое поведение явно не поддерживается или не задокументировано. Поэтому в большинстве случаев поведение или семантика изменения данных API будут считаться потребителями разрушительными. Если поведение не скрыто криптографически, вы должны предположить, что пользователи обнаружили его и будут полагаться на него.
• Добавить поля для чтения/записи в сообщения ресурсов

API Naming Conventions

Имя пакета — это идентификатор приложения (APP_ID), который используется для создания пути запроса gRPC или для ссылки на прото-сообщение. Имена пакетов, объявленные в файле, должны соответствовать названиям продуктов и услуг. Имя пакета API с версией должно заканчиваться этой версией.

• my.package.v1, каталог API, определяет сервисные интерфейсы для использования в бизнесе.

// RequestURL: /<package_name>..<service_name>/{method} package <package_name>.;

См. спецификацию дизайна googleAPI.

Входной параметр разработан как объект для облегчения будущего расширения.

API Primitive Fields

GRPC использует формат Protobuf V3 по умолчанию, поскольку требуемые и необязательные ключевые слова удалены, и все являются дополнительными полями по умолчанию. Если нет назначенного поля, по умолчанию используется значение по умолчанию поля в основном типом, например 0 или «».

В Protobuf v3 рекомендуется использовать:Раздел GitHub.com/protocol…Поле типа Warpper, которое упаковывает сообщение, при использовании становится указателем. Как файл описания строгой схемы, Protobuf также может быть легко расширен.Может ли он также использоваться для определения файла конфигурации?

API Errors

Согласно спецификации Google, grpc также использует стандартные коды состояния.

Используйте небольшой набор стандартных ошибок с большим количеством ресурсов

Например, сервер не определяет различные типы ошибок «не удалось найти», а использует стандартный код ошибки google.rpc.code.not_found и сообщает клиенту, какой конкретный ресурс не найден. Пространство состояния уменьшено для уменьшения сложности документа, обеспечивает лучшее привычное отображение в клиентской библиотеке и снижает логическую сложность клиента, а также не ограничивает необходимость включения владельцев (/Google/RPC/Error_Details).

распространение ошибок

Если ваша служба API зависит от других служб, вы не должны слепо передавать ошибки из этих служб своим клиентам. В случае ошибок перевода рекомендуем сделать следующее: Скрыть детали реализации и конфиденциальную информацию. Настройте сторону, ответственную за ошибку. Например, сервер, который получает ошибку INVALID_ARGUMENT от другой службы, должен передать INTERNAL своим собственным вызывающим сторонам.

глобальный код ошибки

Глобальный код ошибки представляет собой свободный и легко нарушаемый контракт.Основываясь на том, что мы обсуждали выше, когда каждая служба распространяет ошибку, выполняйте перевод, чтобы гарантировать, что каждая служба + перечисление ошибок должны быть уникальными, а в прототипе можно вычеркнуть из документа.

API Design

Частично обновленная схема FieldMask: • Клиенты могут выполнять поля, которые необходимо обновить: пути: "автор" пути: "submessage.submessage.field" пусто FieldMask по умолчанию применяется ко "всем полям"

Управление конфигурацией

• готовое решение
• Как создавать файлы конфигурации и управлять ими
• инициализация

переменные окружения (конфиг)

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

статическая конфигурация

Ресурсы должны инициализировать информацию о конфигурации, такую ​​как сервер http/gRPC, redis, mysql и т. д. Риск онлайн-изменений конфигурации для таких ресурсов очень высок.Я обычно не поощряю изменения на лету, которые могут привести к неожиданным бизнес-аварии. , нет никакой разницы между изменением статической конфигурации и публикацией приложения bianry, и оно должно пройти итеративный процесс выпуска.

Динамическая конфигурация

Приложение может понадобиться некоторые онлайн-переключатели для контроля некоторых простых стратегий бизнеса, которые будут регулярно и использованы часто. Мы используем этот тип конфигурации, такой как основные типы (INT, BOOL), которые будут использоваться для динамической смены потока бизнеса., В то же время рассмотрите возможность объединения с аналогичной официальной стандартной библиотекойpkg.go.dev/expvarдля использования в комбинации.

Глобальная конфигурация

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

Configuration Best Pratice

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

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

управление пакетами

• gomod

GitHub.com/go magister/at и… goproxy.cn blog.golang.org/modules2019 blog.gowaves.org/using-go-mo… blog.golang.org/migrating-he… blog.golang.org/module-увлекательно как… blog.golang.org/publishing-… blog.golang.org/V2-go-Module… blog.golang.org/module-comp…

контрольная работа

• Небольшие тесты обеспечивают превосходное качество кода, хорошую обработку исключений и элегантные отчеты об ошибках, а средние и крупные тесты обеспечивают общее качество продукта и проверку данных.
• У разных типов проектов разные потребности в тестировании, но есть общее практическое правило, правило 70/20/10: 70 % — это небольшие тесты, 20 % — средние тесты и 10 % — большие тесты.
• Если проект ориентирован на пользователя, имеет высокий уровень интеграции или сложный пользовательский интерфейс, у него должно быть больше средне- и крупномасштабных тестов; если это базовая платформа или проект, ориентированный на данные, например, индексация или веб-сканирование, то лучше иметь большое количество небольших тестов, количество средних и больших тестов будет намного меньше.

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

Основные требования к модульному тестированию:

• быстрый
• Согласованная среда
• Любой заказ
• параллельно

Реализуйте кроссплатформенное и кросс-языковое решение для управления зависимостями контейнеров на основе docker-compose, чтобы решить проблему зависимости контейнеров (mysql, redis, mc) в запущенном сценарии модульного тестирования:

• Установите Docker локально.
• Нет навязчивой инициализации среды.
• Быстро сбросить среду.
• Работает в любое время и в любом месте (не полагаясь на внешние сервисы).
• Семантические API объявляют ресурсы.
• Реальные внешние зависимости, а не внутрипроцессное моделирование.

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

Перед запуском модульного теста импортируйте упакованную библиотеку тестирования, чтобы упростить запуск и уничтожение контейнера. Для модульного тестирования сервисов используйте библиотеки, такие как gomock, для имитации дао, поэтому при разработке пакетов следует ориентироваться на абстрактное программирование. Локальное выполнение зависит от Docker, а при выполнении Unittest в среде CI необходимо учитывать сеть Docker на физическом компьютере или снова запускать Docker в Docker.

Пройдите весь модульный тест, используя официальную версию: Subtests + Gomock. /апи Он больше подходит для интеграционного тестирования, непосредственного тестирования API, использования фреймворков для тестирования API (например, yapi) и поддержки большого количества бизнес-тестов. /данные Docker compose реалистично имитирует базовую инфраструктуру, поэтому уровень абстракции инфраструктуры может быть удален. /биз Положитесь на репозиторий, клиент rpc и используйте gomock для имитации реализации интерфейса для тестирования бизнес-единиц. /услуга Опираясь на реализацию biz, создайте класс реализации biz и передайте его для модульного тестирования. Разработайте функцию на основе ветки git, выполните локальное модульное тестирование, затем отправьте запрос на слияние gitlab для модульного тестирования CI, создайте на основе ветки функций, завершите функциональное тестирование, затем выполните слияние мастера, выполните интеграционное тестирование и выполните регрессионное тестирование после подключения к сети.

• тестирование API
• ДАО тест
• тест уровня сервера
• Структура проекта хорошо сделана, а тестирование эффективно и удобно.
• модульный тест
  • Техническая настройка не изменена
  • технический долг

References

Центр конфигурации

Состав приложения

Управление конфигурацией

вид конфигурации

• Динамическая конфигурация, например определение количества рабочих потоков в зависимости от количества процессоров.

механизм конфигурации

Управление (интерфейс UI, API) и разделение инфраструктуры

Сторона управления может полагаться на исходный yml или на интерфейс, а портал можно модифицировать.

Проверка синтаксиса Заранее проверьте, является ли он законным и допустимым Сокращение затрат на эксплуатацию и обслуживание

Как заполнить эти конфигурации?

• посмотреть документацию?
• Объявление метаданных конфигурации

идеи - window分辨率修改 10秒后自动恢复成上个版本 - 危险的操作 多次确认 避免出现事故

Настроить классификацию

Сценарий конфигурации — бизнес-приложение

Сценарий конфигурации — собственная инфраструктура