# 服务设置

服务设置主要管理服务的整个运作，包括配置服务部署的规格，流水线，镜像仓库，以及服务的删除。

# 基础信息

基础信息主要分为「公网访问」和「服务版本配置」两个部分。

# 一、公网访问

配置服务是否可以通过公网域名访问，包括默认域名和自定义域名，如果关闭公网访问，则只能通过小程序或公众号H5形式调用，杜绝被公网DDoS攻击。

# 二、服务版本配置

在发布部署新版本时，会使用该配置完成版本构建，版本在构建后会锁定配置，后续更改此配置时不会更改历史的版本。

当服务有版本接入线上时，更改此配置将会重新发布一个新的版本，代码遵循最后一次版本的代码，只是对配置进行了更改。

以下是配置的详细说明：

# 1. 容器规格

可根据服务的资源消耗进行选择，一般等同于传统服务器的规格除以2-3，比如使用 1核2G 的服务器，迁移过来后，可以选择规格为 0.5核1G，甚至还可以更少。

内存和CPU的搭配规则如下：

容器规格的设置要与自身业务相关

• 如果规格设置过于低，一个容器实例支撑不了太大的流量，当流量增大时，就会因为弹性扩容产生更多实例副本，以维持流量服务。扩缩更加频繁，也更加灵活。
• 如果规格设置过于高，一个容器实力支撑很多流量，则流量要增加到一定程度才会触发扩容，扩缩不灵活，会造成大量浪费。
• 如果规格设置过低导致一个容器实例连1个请求都支撑不了（本身系统基础逻辑就很重），可能会导致部署成功但频繁出现500错误。java服务相对较重，建议使用1核2G及以上规格。
• 适当增加容器规格，可以提高请求速度。

算一算，如果你的项目，低规格能承载10个请求，成本1元；高规格能承载100个请求，成本10元，若现在有101个请求时

低规格需要11个实例才能满足，因为 10请求 * 11 = 110请求 > 101请求，成本为 1元 * 11 = 11元 高规格需要2个实例才能满足，因为 100请求 * 2 = 200请求 > 101请求，成本为 10元 * 2 = 20元

以上低规格会更划算一些，但频繁扩缩容，会导致服务不能及时到位造成一些影响（需要看第3条，配置扩缩容条件保障），合理根据自己的项目消耗和流量，进行合理的规格配比是需要经过衡量和计算的。

# 2. 实例副本数

容器实例个数的最大最小范围阈值

• 如服务需要保证高可用（持续常驻无冷启动，能随时快速响应请求），建议实例副本数最小值设为>=1；
• 如服务需要低成本，无流量时无成本，可将实例副本数最小值设为=0；当该服务30min内无流量则后台会将实例副本数缩容为0（避免流量偶然波动带来的误判）。此时再次冷启动时，可能有服务延迟，具体延迟时间由服务启动速度决定，可以适当采用懒加载等技术手段优化；
• 即便容器实例副本数最小值设置为0，服务部署发布时都会先产生1个容器实例，部署成功后等待半小时再缩容至0，因此版本部署的过程中，还未收到正式服务请求前，就会产生一定的资源消耗；

# 3. 扩缩容条件

目前支持CPU使用率、内存使用率两种，当达到阈值时，后台会自动扩（创建）缩（删除）实例，然后检测是否再次达到条件，如果满足条件则继续扩缩容，如此反复直至实例数量达到副本个数的最小值/最大值，或不再满足扩缩容条件时停止自动扩缩容。

• 自动扩容到副本个数最大值后若仍不足以承载业务流量，即便再次达到扩缩容条件，也不会继续创建新的实例，可能导致业务受影响，请评估好业务指标，合理设定副本数最大值；
• 如需提升实例数最大值限额（大于50），请提交工单处理；

# 4. 定时扩缩容

为提高资源使用体验，进一步缩小服务缩容到0后冷启的影响，支持服务定时扩缩容，业务可根据业务流量曲线自定义设置定时扩缩容时间点。支持每日/每周/每月/不重复等四种定时类型。

例：每日08:00-10:00扩容到2个副本数，随后缩容到最小副本数。即每天的上午8点触发扩容，实例副本数扩容到2个，持续到10点，10点后缩容实例到设置的最小副本数。

• 支持添加3个自定义时间段，不支持设置的3个自定义时间段有重叠；
• 定时扩容实例副本数不能设置小于最小实例副本数且不可设置为0；
• 历史定时扩缩容情况，可在操作记录中查看；

水平扩缩容和定时扩缩容兼容逻辑

• a.水平扩缩容和定时扩缩容可以同时开启，未达到定时扩缩的触发时间点时，以水平扩缩容设置的实例副本数配置生效；

• b. 达到定时扩缩的触发时间时，以定时扩缩设置的实例副本数配置生效；

• c.扩容条件不受定时/水平影响，达到扩缩容条件时即触发缩容，缩容条件受定时扩缩容影响；（本质上定时扩缩是重新定义了一个临时的最小副本数）

• d.服务版本更新不影响；

• e.同时开启水平扩缩容和定时扩缩容，实例副本数的取值规则如下

# 5. 日志采集路径

可设置目录或文件，支持设置多个路径。采集到的日志可以在「服务管理-日志」中查看。支持标准输出（stdout）以及 * 通配路径（例：/logs/*），使用 ,（半角逗号）分割，留空将采集标准输出。标准输出日志指的是在服务代码中将日志直接打印到控制台的标准输出(stdout)和标准错误(stderr)。

*注意：*日志采集路径和Dockerfile中volume配置的路径不能相同，否则路径将被二次映射将无法采集到日志。

# 6. 环境变量

服务所需的环境变量，直接传入容器中，以 key value 的形式，可配置多个。

如果你有非常多个变量，可以使用JSON方式导入，如下：

---

# 流水线

流水线是微信云托管提供的可视化实现和集成自动持续交付的能力。

流水线的作用就是，为服务锁定一个线上的代码仓库并配置相关信息，在部署新版本时，可以直接触发，进行快速的版本部署流程。

流水线可以通过两种方式设定，「首次代码仓库形式创建版本配置」和「主动配置」

# 一、首次代码仓库形式创建版本配置

在部署发布，版本方式选择以下任意一种

• 绑定Github仓库
• 绑定Gitlab仓库
• 绑定Gitee仓库

就会将此信息写到流水线配置中，当流水线信息首次配置后，接下来部署发布时，版本方式就会变成「执行流水线」，如果想更改信息，则需要在流水线更改。

# 二、 主动配置

即在流水线配置页面直接进行相关配置

配置的变更不会影响已经发布的版本，而是会影响之后部署发布时，要执行流水线时的版本。

# 三、 配置说明

# 1.代码源

目前支持GitHub 、 GitLab 、 码云Gitee 三种类型仓库，授权成功后，后台将从对应的仓库中拉取代码并根据流水线触发规则将代码构建为镜像、将镜像推送到服务下绑定的镜像仓库存储、后基于该镜像部署到容器上。

• 首次使用时，需先将对应仓库授权给微信云托管，授权成功后，当前环境任意服务新建流水线使用该仓库下的代码源都不再需要再次授权。
• 授权成功并通过代码仓库成功部署过一次后，会能在代码仓库侧看到微信云托管创建了一个webhook用来实现流水线自动推送触发。如果删除这个webhook，会导致流水线失效。
• 微信云托管流水线仅拉取代码不做任何其他操作，请放心使用；
• 业务自己搭建的私人仓库因涉及需要填写账密，暂不支持，可将对应服务的代码先同步迁移至GitHub 、 GitLab 、 码云Gitee 中的私密仓库中，或者采用CLI工具配合私人仓库使用。参考文档 CLI工具。

# 2.代码仓库和分支

选择授权的代码源中的项目仓库，以及指定该仓库的分支。

# 3.目标目录

当你的项目中有多个类别的代码文件夹，需要指定服务部署所需的代码文件目录。

# 4. 端口

当前项目仓库中代码在运行时暴露的端口号，目前仅支持配置一个端口，如果你的服务同时开多个并对外提供服务，可以分拆成多个服务。

# 5. DockerFile文件

项目指定的目标目录中有、无 DockerFile 文件

如果项目目录中有，则可以进一步指定 DockerFile 文件所在路径和名称，会以目标目录做根寻找。

如果没有 DockerFile 文件，则可以根据项目框架语言选择官方设置的部署模版来部署。

# 6. 推送触发

勾选时，将在代码仓库分支中有 push 或者 merge 行为时，自动构建部署版本，并发布到现网。

• 如果在代码仓库侧手动删除了微信云托管创建的webhook，推送触发会失效；
• 如果一次推送会在同一时间触发多次部署，优先检查是否代码仓库侧有多个同样的webhook，删除重复的即可恢复正常。

注意：此推送触发只能全量发布现网，按测试、生产环境分开使用此功能效果最佳

---

# 镜像仓库

镜像仓库的操作细节请前往此文档

---

# 删除服务

点击删除按钮，在弹出窗口确认即可删除。

删除时会永久删除此服务下的所有部署记录、流水线和镜像信息，需要填写「服务名称」二次确认。