1.2.12 Admin Processes（管理进程）

将管理任务作为一次性流程运行。

云原生应用运行中可能会需要执行一些管理任务，比如生成报表或者执行一次性的数据查询等，这些任务通常并不属于业务流程的一部分，更多的是为了管理和运维的需要。这些任务在执行中会使用到云原生应用所依赖的支撑服务，对于这些任务，应该创建独立的应用，并在同样的云平台上运行。对于定期执行的任务，可以充分利用云平台的支持，比如，Kubernetes提供了对定时任务（CronJob）的支持。

以上是对云原生应用设计的十二原则的详述，十二原则的总结如下。

1.单一代码：每个微服务都有单个代码库，存储在其自身的存储库中。它通过版本控制进行跟踪，可以部署到多个环境（QA、暂存、生产）。

2.依赖管理：每个微服务都隔离并打包其自身的依赖项，以在不影响整个系统的情况下进行更改。

3.配置：配置信息通过代码之外的配置管理工具移出微服务之外，并实现外部化。在应用了正确配置的情况下，相同部署可以在环境间传播。

4.支撑服务：辅助资源（数据存储、缓存、消息中间件等）应通过可寻址的URL进行公开。这样做可使资源与应用程序分离，使其可以动态替换。

5.构建、发布、运行：每个版本都必须在构建、发布和运行阶段执行严格的分离。各自都应使用唯一ID进行标记，并支持回滚功能。新式的持续集成和持续部署CI/CD系统有助于实现此原则。

6.进程：每个微服务应在其自身的进程中执行，与正在运行的服务隔离。将所需状态外部化到支持服务，如分布式缓存或数据存储。

7.端口绑定：每个微服务都应是独立的，其接口和功能在自己的端口上公开。这样做可与微服务隔离。

8.并发：当需要增加服务能力的时候，通过扩展多个相同进程（副本）横向扩展服务，而不是在功能强大的计算机上纵向扩展单个大型实例。将应用程序开发为并发应用程序，从而顺滑地在云环境中横向扩展。

9.易回收：服务实例应是易回收的。支持快速启动以增加可伸缩性机会，以及支持正常关闭以使系统保持正确状态。Docker容器以及业务流程协调程序本质上满足此要求。

10.环境对等：使整个应用程序生命周期中的各个环境尽可能相似，避免使用成本高昂的方式。在这里，通过促进使用相同的执行环境，容器技术可以提供重要帮助。

11.日志流：将微服务生成的日志视为事件流。使用事件聚合器处理它们。将日志数据传播到数据挖掘/日志管理工具（如Azure Monitor或Splunk）并最终长期存档。

12.管理进程：以一次性进程形式运行管理性/管理任务，例如数据清理或计算分析。使用独立工具从生产环境调用这些任务，但独立于应用程序。