开发工具微服务云原生CLI【免费下载链接】tyeTye is a tool that makes developing, testing, and deploying microservices and distributed applications easier. Project Tye includes a local orchestrator to make developing microservices easier and the ability to deploy microservices to Kubernetes with minimal configuration.项目地址https://gitcode.com/gh_mirrors/ty/tye点击查看免费下载导读微服务应用常常横跨多个 Git 仓库前端、后端、基础设施各自独立演进。Tye 通过服务配置中的include与repository两个字段允许一个tye.yaml引用其他仓库中的tye.yaml或直接引用 Git 仓库作为依赖从而在不合并仓库的前提下完成本地编排tye run与 Kubernetes 部署tye deploy。读完本文你将掌握跨仓库服务的声明方式、依赖解析与就近优先合并规则以及 Git 依赖克隆的目录约定与注意事项。本文基于 docs/reference/multirepo.md 展开并结合仓库内 ApplicationFactory.cs 源码、tye-schema.json 配置结构与 E2E 测试加以印证。一、多仓库场景为什么需要跨仓库编排在真实项目中一个完整的应用往往由多个仓库共同组成前端仓库frontend repo负责页面与交互后端仓库inventory repo负责订单/库存等业务逻辑基础设施依赖如 redis可能由任一仓库管理。Tye 对这一场景的支持方式是通过服务条目引用另一个tye.yaml或直接引用一个 Git 仓库。这样既不必把多个仓库强行合并为一个 monorepo也能在tye run/tye deploy时一次性把跨仓库的依赖全部拉起。单仓库形态下的基线配置先看一个典型的单仓库应用。假设应用由 frontend、inventory 两个服务加上 redis 组成inventory 依赖 redis 做订单缓存name: multirepo-app services: - name: frontend project: ./frontend/frontend.csproj - name: inventory project: ./inventory/inventory.csproj - name: redis container: redis bindings: - port: 6793该示例即来自原文档 docs/reference/multirepo.md。注意示例中 redis 显式指定了宿主端口6793bindings下的port这是容器服务声明绑定端口的典型写法。二、跨仓库引用include 一个 tye.yaml当 inventory 服务被拆分到独立仓库、与 frontend 仓库并排存放时可以把上面的配置拆成两份tye.yaml通过include字段互相引用。frontend 仓库的 tye.yaml# frontends tye.yaml name: multirepo-app services: - name: frontend project: ./frontend/frontend.csproj - name: inventory include: ../inventoryRepo/tye.yamlinventory 仓库的 tye.yaml# inventorys tye.yaml name: multirepo-app services: - name: inventory include: inventory/inventory.csproj - name: redis container: redis bindings: - port: 6793两份配置使用了相同的name: multirepo-app。这并非巧合而是被引用的嵌套配置必须满足的硬性约束——源码 ApplicationFactory.cs 中的GetNestedConfig会校验if (nestedConfig.Name ! rootConfig.Name) { throw new CommandException($Nested configuration must have the same \name\ in the tye.yaml. Root config: {rootConfig.Source}, nested config: {nestedConfig.Source}); }也就是说任何通过include引入的 tye.yaml其顶层name必须与根配置完全一致否则会抛出CommandException。这一点在组织多个仓库的配置文件时需要格外留意。运行/部署的行为差异配置完成后在两个仓库分别执行命令会得到不同的结果在frontend 仓库执行tye run或tye deployfrontend、inventory、redis 三者会被一起运行/部署——因为 frontend 的 tye.yaml 通过include引用了 inventory 的 tye.yaml而后者又声明了 redis在inventory 仓库执行tye run或tye deploy只有 inventory 与 redis 会被运行/部署——该仓库的配置是独立的不会反向拉起 frontend。这一行为由解析阶段决定include是一个单向引用依赖方向从引用方指向被引用方不会产生反向闭包。底层实现中ApplicationFactory.CreateAsync使用一个队列对配置图做广度优先展开每遇到include就把嵌套配置压入队列继续处理见 ApplicationFactory.cselse if (!string.IsNullOrEmpty(configService.Include)) { var expandedYaml Environment.ExpandEnvironmentVariables(configService.Include); var nestedConfig GetNestedConfig(rootConfig, Path.Combine(config.Source.DirectoryName!, expandedYaml)); queue.Enqueue((nestedConfig, new HashSetstring())); AddToRootServices(root, dependencies, configService.Name); continue; }服务发现注入的粒度控制需要特别注意的是frontend 不会获得 redis 的服务发现信息注入因为 frontend 并没有直接依赖 redis。Tye 的依赖图严格依据配置中的引用关系构建而非引入了某个 tye.yaml 就把里面的服务全算作依赖。如果 frontend 确实需要访问 redis有两种做法在 inventory 的 tye.yaml 中把 redis 服务引用到 frontend不现实方向相反仅用于展示在 frontend 自己的 tye.yaml 中直接添加对 redis 的引用例如补一个 redis 服务条目container: redis 绑定端口或在 frontend 的配置里直接声明对 redis 的include。第二种做法是推荐路径哪个服务需要依赖就在哪个服务的配置中显式声明依赖关系一目了然。三、重复服务与就近优先合并规则当多个嵌套配置中出现了同名的服务时Tye 采用first/closest wins第一个/最近的胜出的广度优先breadth-first排序规则越靠近根配置、越先被解析到的同名服务定义优先保留后出现的重复定义不会覆盖它。这一规则在源码中有明确的实现支撑。展开循环ApplicationFactory.cs维护了一个visited集合用于避免同一个配置文件被重复展开if (!visited.Add(config.Source.FullName)) { continue; }同时在逐服务处理时ApplicationFactory.cs如果根应用中已存在同名服务则只更新依赖信息、跳过服务创建if (root.Services.Any(s s.Name configService.Name)) { // Even though this service has already created a service, we still need // to update dependency information AddToRootServices(root, dependencies, configService.Name); continue; }E2E 测试 ApplicationFactoryTests.cs 中的SettingsFromFirstWins用例直接验证了这一点测试在嵌套的 results/tye.yaml 中同时声明了include: ../worker/tye.yaml、project: results.csproj和image: redis2的 redis 服务最终断言根应用中的 redis 服务镜像为redis2——即先到先得的合并语义得到保留。同一测试文件中的DoubleNestingWorksApplicationFactoryTests.cs还验证了嵌套可以多级根配置 include 两个子 tye.yaml子配置再 include 更深层的 worker/tye.yaml最终 5 个服务全部正确展开且每个服务的依赖集合Dependencies均按引用关系精确构建。四、引用 Git 仓库repository 字段除了引用已存在的 tye.yamlTye 还支持直接克隆一个 Git 仓库作为依赖。将上一节的例子改写为# frontends tye.yaml name: multirepo-app services: - name: frontend project: ./frontend/frontend.csproj - name: inventory repository: https://github.com/MyOrg/InventoryRepo克隆后的运行方式判定仓库被克隆后Tye 会按照与本地仓库相同的约定顺序来判断如何运行/部署判定基准是克隆仓库的根目录。支持的文件类型与顺序定义在 ConfigFileFinder.csprivate static readonly string[] FileFormats { tye.yaml, tye.yml, docker-compose.yaml, docker-compose.yml, *.csproj, *.fsproj, *.sln };即优先级为tye.yaml/tye.ymldocker-compose.yaml/docker-compose.yml*.csproj/*.fsproj*.sln。判定细节对于每种格式目录下恰好一个匹配文件时直接采用若有多个匹配文件如多个 csproj则判定失败并报错More than one matching file was found in directory ...全部格式都找不到时报错No project project file or solution was found in directory ...见 ConfigFileFinder.cs。也就是说被克隆的仓库若想被 Tye 正确识别根目录下应恰好存在一个 tye.yaml首选或单个项目/解决方案文件。repository 字符串即 git clone 参数repository字段的字符串原样传递给git clone命令。因此可以充分利用git clone的参数语法——例如指定分支repository: https://github.com/MyOrg/InventoryRepo --branch release/1.0Tye 执行的实际命令为git clone repository clonePath见 ApplicationFactory.cs所以诸如--branch、--depth、--single-branch等git clone支持的选项都可以追加在 URL 之后。示例中的--branch release/1.0即克隆release/1.0分支。克隆目录.tye/deps所有 Git 依赖默认克隆到当前仓库下的.tye/deps目录每个依赖一个子目录子目录名即服务名name。源码中的默认路径为ApplicationFactory.csvar path configService.CloneDirectory ?? Path.Join(.tye, deps); if (!Directory.Exists(path)) { Directory.CreateDirectory(path); } var clonePath Path.Combine(rootConfig.Source.DirectoryName!, path, configService.Name);这里有两个可观察的行为若克隆目录已存在说明之前克隆过Tye不会重新 clone直接复用现有目录——这类似于增量/缓存语义二次tye run时无需重新拉取克隆位置可通过可选的cloneDirectory字段自定义见下文配置结构。从配置结构看repository服务条目还支持cloneDirectory属性用于指定克隆目标目录相对根配置目录解析。tye-schema.json中对repository定义如下tye-schema.jsonrepository: { properties: { name: { description: The service name. Must be unique per-application., type: string }, repository: { description: The repository url which will be cloned., type: string }, cloneDirectory: { description: The directory to clone the repository into., type: string } }, required: [ name, repository ] }其中name与repository为必填项cloneDirectory可选默认即为.tye/deps。Git 前置依赖与失败处理仓库克隆依赖本机安装git。源码通过 GitDetector.cs 在首次需要时执行git --version检测 git 是否可用若未安装会抛出明确错误ApplicationFactory.cs未安装 gitCannot clone repository ... because git is not installed. Please install git if youd like to use repository in tye.yaml.clone 失败退出码非 0Failed to clone repository ... with exit code ...并附带git clone的标准错误输出以辅助排查。E2E 测试 TyeRunTests.cs 中的MultiRepo_WorksWithCloning用例即演示了通过repository字段引用远程仓库的完整配置形态。五、多仓库编排的完整流程综合以上机制使用 Tye 编排跨仓库应用的完整工作流如下拆分配置为每个仓库准备独立的tye.yaml所有被互相引用的配置必须使用相同的name建立引用在需要聚合的仓库中用include: 相对路径/tye.yaml引用其他仓库的配置文件或直接用repository: git url [git clone 参数]声明 Git 依赖本地运行在聚合仓库执行tye runTye 会按广度优先展开全部嵌套配置拉起所有被引用的服务并仅向直接依赖方注入服务发现信息部署上线执行tye deploy将同样展开后的服务清单部署到 Kubernetes按仓库独立运行在任一被引用仓库内执行tye run/tye deploy只运行该仓库自身声明的服务互不影响。整个过程由 ApplicationFactory.CreateAsync 统一驱动从根配置出发借助队列做广度优先遍历对include展开嵌套配置、对repository执行 git clone 后按文件约定寻找可解析的配置文件再通过AddToRootServicesApplicationFactory.cs逐步构建各服务间的依赖集合最终生成完整的ApplicationBuilder应用模型。六、常见问题与注意事项Q1include 的 tye.yaml 与根配置 name 不一致会怎样A直接抛错。GetNestedConfig强制要求嵌套配置与根配置同名请在所有相关仓库的 tye.yaml 中统一name。Q2多个仓库都声明了同名服务谁生效A广度优先排序下第一个/最近的生效先被解析的同名服务定义保留后出现的只补充依赖信息、不覆盖服务定义SettingsFromFirstWins测试用例即为佐证。Q3repository 克隆的仓库里放什么文件ATye 依次寻找tye.yaml/tye.yml→docker-compose.yaml/docker-compose.yml→ 单个csproj/fsproj→sln全部位于克隆仓库根目录若同格式文件不止一个或完全缺失会报错。Q4git 依赖重复运行会重复 clone 吗A不会。克隆目录默认.tye/deps/服务名已存在时直接复用不会重新 clone如需强制刷新可清理对应目录后重跑。Q5repository 可以加参数吗A可以。repository的字符串整体传给git clone支持追加--branch、--depth等参数例如repository: https://github.com/MyOrg/InventoryRepo --branch release/1.0。Q6服务发现信息怎么控制ATye 按配置中的引用关系而非 include 展开后的服务全集注入服务发现。哪个服务依赖哪个服务就在哪份配置里显式声明避免隐式全量注入。延伸阅读完整 schema 定义src/schema/tye-schema.json多仓库解析核心实现src/Microsoft.Tye.Core/ApplicationFactory.cs克隆仓库文件类型判定src/Microsoft.Tye.Core/ConfigFileFinder.cs多仓库 E2E 测试资产test/E2ETest/testassets/projects/multirepo配置解析与校验src/Microsoft.Tye.Core/Serialization/ConfigServiceParser.cs赞分享开发工具微服务云原生CLI【免费下载链接】tyeTye is a tool that makes developing, testing, and deploying microservices and distributed applications easier. Project Tye includes a local orchestrator to make developing microservices easier and the ability to deploy microservices to Kubernetes with minimal configuration.项目地址https://gitcode.com/gh_mirrors/ty/tye点击查看免费下载相关推荐Earthly 多仓库Multirepo构建实战跨仓库引用远程 Target 与制品拷贝Earthly 多仓库Multirepo构建实战跨仓库引用远程 Target 与制品拷贝 本篇指南围绕 Earthly 官方示例 examples/mulCI/CDDevOps构建工具Git子模块与子树完整指南如何高效管理多仓库依赖关系Git子模块与子树完整指南如何高效管理多仓库依赖关系 Git子模块submodule与子树subtree是Git版本控制系统中用于管理多仓库依赖关系的教程文档Tye多仓库项目管理如何高效管理跨仓库的微服务架构Tye多仓库项目管理如何高效管理跨仓库的微服务架构 在现代微服务开发中跨多个仓库管理分布式应用已成为常态。Tye作为微软推出的微服务开发工具专门解决了多仓开发工具微服务云原生CLI上一篇Easydict构建优化缩短编译时间的技巧下一篇Linux accel/rocket 驱动深度解析Rockchip RK3588 NPURKNN在 Linux 内核中的实现原理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考