前言
计算机软件技术架构进化有两大主要驱动因素，一个是底层硬件升级，另一个是顶层业务发展诉求。
正如伴随着 x86 硬件体系的成熟，很多应用不再使用昂贵、臃肿的大中型机，转而选择价格更为低廉的以x86 为主的硬件体系，也由此诞生了包括 CORBA、EJB、RPC 在内的各类分布式架构；后由于互联网业务飞速发展，人们发现传统 IOE 架构已经不能满足海量业务规模的并发要求，于是又诞生了Spring Cloud 这样的微服务架构体系。
云计算从工业化应用到如今，已走过十五个年头，然而大量应用使用云的方式仍停滞在传统 IDC 时代，虚拟机代替了原来的物理机：使用文件保存应用数据，大量自带的三方技术组件，没有经过架构改造（如微服务改造）的应用上云，传统的应用打包与发布方式等等。对于如何使用这些技术，没有绝对的对与错， 只是在云的时代不能充分利用云的强大能力，不能从云技术中获得更高的可用性与可扩展能力，也不能利用云提升发布和运维的效率，是一件非常遗憾的事情。
回顾近年来政府行业的信息化发展趋势，数字化转型的出现使得越来越多的业务演变成数字化业务，数字化对于业务渠道、竞争格局、用户体验等诸多方面都带来更加严苛的要求，这就要求技术具备更快的迭代速度，业务推出速度从按周提升到按小时，每月上线业务量从“几十/月”提升到“几百/天”。大量数字化业务重构了政企的业务流水线，政企要求这些业务不能有不可接受的业务中断，否则会对客户体验以及营收可能造成巨大影响。
对于政府部门而言，原来内部IT建设以“烟筒”模式比较多，每个部门甚至每个应用都相对独立，如何管理与分配资源成了难题。大家都基于最底层IDC设施独自向上构建，都需要单独分配硬件资源，这就造成资源被大量占用且难以被共享。但是上云之后，由于云厂商提供了统一的IaaS 能力和云服务，大幅提升了政府单位 IaaS 层的复用程度，信息中心等部门自然而然想到IaaS 以上层的系统也需要被统一，使资源、产品可被不断复用，从而能够进一步降低政府信息化运营成本。过去开发一个后端应用最为直接的方式就是通过单一后端应用提供并集成所有的服务，即单体模式。随着业务发展与需求不断增加，单体应用功能愈发复杂，参与开发的工程师规模可能由最初几个人发展到十几人，应用迭代效率由于集中式研发、测试、发布、沟通模式而显著下滑。为了解决由单体应用模型衍生的过度集中式项 目迭代流程，微服务模式应运而生。
相对于传统 IT 基础设施，云具有更加灵活的调度策略，接近无限的资源、丰富的服务供用户选择、使用，这些都极大方便了软件的建设。而云原生开源生态的建设，基本统一了软件部署和运维的基本模式。更重要的是，云原生技术的快速演进，技术复杂性不断下沉到云，赋能开发者个体能力，不断提升了应用开发效率。
首先是容器技术和 Kubernetes 服务编排技术的结合，解决了应用部署自动化、标准化、配置化的问题。云原生一体化平台打破了云上平台的壁垒，使建设跨平台的应用成为可能，成为事实上的云上应用开发平台的标准，极大简化了多云部署。
一个完整的开发流程涉及到很多步骤，而环节越多，一次循环花费的时间越长，效率就越低。微服务通过把巨石应用拆解为若干单功能的服务，减少了服务间的耦合性，让开发和部署更加便捷，可以有效降低开发周期，提高部署灵活性。无论哪一种场景，实际上后台的运维平台的工作都是不可以缺少的，只是通过技术让扩容、容错等技术对于开发人员透明，让效率更高。
所有这些问题都指向一个共同点，那就是云的时代需要新的技术架构，来帮助企业应用能够更好地利用云计算优势，充分释放云计算的技术红利，让业务更敏捷、成本更低的同时又可伸缩性更灵活，而这些正好就是云原生架构专注解决的技术点。
1产品概述
1.1产品定位
云原生一体化平台是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
软件一旦开发完成，需要在公司内外部的各类环境中部署和交付，以将软件价值交给最终客户。软件交付的困难在于公司环境到客户环境之间的差异，以及软件交付和运维人员的技能差异，填补这些差异的是一大堆的用户手册、安装手册、运维手册和培训文档。容器就像集装箱一样，以一种标准的方式对软 件打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而可以基于容器做标准化的软件交付。
对自动化交付而言，还需要一种能够描述不同环境的工具，让软件能够“理解”目标环境、交付内容、配置清单，并通过代码去识别目标环境的差异，根据交付内容以“面向终态”的方式完成软件的安装、配置、运行和变更。
基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例，应用微服务化以后，往往被部署到成千上万个节点上，如果系统不具备高度的自动化能力，任何一次新业务的上线，都会带来极大的工作量挑战，严重时还会导致业务变更超过上线窗口而不可用。
1.2产品价值
敏捷
容器技术提升了政府行业IT 架构敏捷性的同时，让业务迭代更加迅捷，为创新探索提供了坚实的技术保障。比如疫情期间，教育、视频、公共健康等行业的在线化需求突现爆发性高速增长，很多用户通过容器技术适时把握了突如其来的业务快速增长机遇。据统计，使用容器技术可以获得 3~10 倍交付效率提升，这意味着可以更快速的迭代产品，更低成本进行业务试错。
弹性
在云计算时代，政府单位经常需要面对突发事件等各种预期内外的爆发性流量增长。通过容器技术，用户可以充分发挥云计算弹性优势，降低运维成本。一般而言，借助容器技术，用户可以通过部署密度提升和弹性降低50%的计算成本。
可移植性
容器已经成为应用分发和交付的标准技术，将应用与底层运行环境进行解耦；Kubernetes 成为资源调度和编排的标准，屏蔽了底层架构差异性，帮助应用平滑运行在不同基础设施上。云原生一体化平台云原生计算基金会推出了Kubernetes 一致性认证，进一步保障了不同 K8s 实现的兼容性，这也让用户愿意采用容器技术来构建云时代 应用基础设施。
2总体架构
2.1功能架构

2.2技术架构

3产品特性
大规模容器管理
大规模应用：提供多集群、多节点场景下容器统一管理，支撑分布式云业务稳定运行
企业级增强：持续提升集群高可用、故障自愈、易用性和安全能力
任意位置部署协同
屏蔽异构基础设施差异，实现资源的标准化，解决不同环境部署的一致性问题
提供多云混合管理，实现跨云跨集群的统一资源协同、算力协同、服务协同、数据协同
架构优化，组件裁剪、能效提升，基础资源消耗降低3倍，满足现场级业务算力需求
PaaS服务敏捷交付
提供声明式服务封装工具及幂等的自动化部署能力，便捷实现第三方服务的原子化封装与接入
灵活支撑各类业务服务应用的运行需求，快速构建面向行业、场景化的平台级产品
应用生命周期管理
涵盖DevOps全流程的软件开发能力，简化应用云上创建、发布、部署过程，缩短应用迭代周期
提供微服务引擎实现微服务统一治理，支持异构微服务框架互通、协议转换及API统一管理
覆盖基础设施、平台、应用的立体运维，观测数据全链路可跟踪、垂直关联、跨维度打通
全栈高可用
提供涵盖服务访问、应用层、服务层、基础设施层的全栈高可用能力
提供多集群管理能力，支持跨云、跨区域集群高可用，满足各种场景下的容灾需求
4功能说明
4.1容器管理平台
容器是用来解决资源隔离、提高系统利用率的一种技术，容器比较轻量 (容器空间在MB 级别)，部署密度高，性能损耗小。基于容器镜像分层技术可以实现通用依赖库和系统特定库依赖打包，可以做到一处编译 ，到处运行。容器运行效率基本接近于物理机，容器操作 (启动，停止 启动，停止，重启等)响应在毫秒到级，容器的灵活性极大促进混合云场景中的负载迁移效率。
Kubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提供了分布式应用管理的核心能力：
资源调度：根据应用请求的资源量 CPU、Memory，或者GPU 等设备资源，在集群中选择合适的节点来运行应用；
应用部署与管理：支持应用的自动发布与应用的回滚，以及与应用相关的配置的管理；也可以自动化存储卷的编排，让存储卷与容器应用的生命周期相关联；
自动修复：Kubernetes 可以会监测这个集群中所有的宿主机，当宿主机或者 OS 出现故障，节点健康检查会自动进行应用迁移；K8s 也支持应用的自愈，极大简化了运维管理的复杂性；
服务发现与负载均衡：通过 Service 资源出现各种应用服务，结合 DNS 和多种负载均衡机制，支持容器化 应用之间的相互通信；
弹性伸缩：K8s 可以监测业务上所承担的负载，如果这个业务本身的 CPU 利用率过高，或者响应时间过长， 它可以对这个业务进行自动扩容。
容器服务平台的资源一共有三个层级，包括集群 (Cluster)、 企业空间 (Workspace)、 项目 (Project) 和 DevOps Project (DevOps 工程)，层级关系如下图所示，在每个层级中，每个组织中都有多个不同的内置角色。

4.1.1多租户管理
4.1.1.1用户管理
容器服务平台中的 admin 角色可以为其他用户创建账号并分配平台角色，平台内置了集群层级的以下三个常用的角色，同时支持自定义新的角色。可以通过设置不同角色给用户。
4.1.1.2角色管理
容器服务平台中的 admin 角色可以创建多个不同角色，可设置角色集群查看权限，应用查看权限，平台设置权限；每个权限都对应两个子权限：查看和管理。设置的角色可给用户分配。
4.1.2集群
容器服务平台由多台服务器组成集群，可快速新增集群，并且可查看集群数量，状态（cpu，内存），IP等信息。
4.1.2.1集群组件
容器平台采用可插拔组件模式，可快速开启容器管理组件，包括但不限于应用商店，DevOps，日志系统，事件系统，告警系统，审计日志，服务网格。
4.1.2.2容器资源
在集群管理中可查看到整个集群所有资源，包括命名空间，项目，工作负载，服务，配置，储存。如果启动了相关可插拔组件，也可以查看
4.1.2.3节点管理
节点是接入到集群的计算资源，是集群的工作节点。节点信息中包括运行状态，CPU用量，内存用量。
4.1.2.4存储管理
存储管理用于管理容器的持久化卷，主要支持云盘、对象存储、S3对象存储、RBD存储、CEPHFS存储、NFS存储、本地存储七种类型。
4.1.3企业空间
企业空间是一组资源的集合，这些资源包括CPU、内存、存储、网络等。你可以创建命名空间，设置各种资源的配额，然后分配给用户使用。用户的应用会被部署到命名空间中，并受其配额的限制，使其所能够使用的CPU、内存、存储、网络等资源可控。
企业空间 (workspace) 是 容器服务平台 实现多租户模式的基础，是用户管理项目、DevOps 工程和企业成员的基本单位。
4.1.3.1项目管理
项目是管理服务、工作负载、配置文件的集合，给应用区分不同项目，方便管理。
4.1.3.2服务管理
服务用于将集群应用暴露，通映射外网端口，可在集群外访问服务，及访问对应实例。
4.1.3.3工作负载
工作负载即Kubernetes对一组Pod的抽象模型，用于描述业务的运行载体，并支持工作负载伸缩，包括无状态负载（Deployment）、有状态负载（Statefulset）、容器组（POD）。提供基于Kubernetes原生的Deployment，StatefulSet等负载创建、配置、删除等生命周期管理。应用实例可部署一个或多个无状态负载或有状态负载，一个无状态负载或有状态负载对应一个或多个容器组。
3.1.1.5.14.1.3.3.1无状态负载
无状态负载，即kubernetes中的Deployments。应用实例可部署一个或多个无状态负载，一个无状态负载对应一个或多个容器组。适用于容器组完全独立、功能相同的场景，如nginx等。
4.1.3.3.2有状态负载
有状态负载，即kubernetes中的Statefulsets。应用实例可部署一个或多个有状态负载，一个有状态负载对应一个或多个容器组。适用于容器组不完全独立，容器组之间存在互访的场景，如mysql等。
4.1.3.3.3普通任务
普通任务，即kubernetes中的Job。Job负责批量处理短暂的一次性任务，仅执行一次，并保证处理的一个或者多个Pod成功结束。
4.1.3.3.4容器组
容器组，即kubernetes中的POD，容器组是kubernetes中可以创建和部署的最小单位，一个容器组代表着集群中运行的一个进程。
4.1.3.4服务弹性伸缩
Pod 弹性伸缩 (HPA) 是高级版新增的功能，应用的资源使用率通常都有高峰和低谷的时候，如何动态地根据资源使用率来削峰填谷，提高集群的平台和集群资源利用率，让 Pod 副本数自动调整呢？这就有赖于 Horizontal Pod Autoscaling 了，顾名思义，能够使 Pod 水平自动伸缩，也是最能体现 容器服务平台 之于传统运维价值的地方，用户无需对 Pod 手动地水平扩缩容 (Scale out/in)。HPA 仅适用于创建部署 (Deployment) 时或创建部署后设置，支持根据集群的监控指标如 CPU 使用率和内存使用量来设置弹性伸缩，当业务需求增加时，容器服务平台 能够无缝地自动水平增加 Pod 数量，提高系统的稳定性。
4.1.3.5灰度发布
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。通过配置一个 灰度转发策略，将一部分用户的请求转发到老版本的容器上，同时让另一部分用 户开始使用新版本的容器，如果使用的结果理想，则将灰度转发策略调整或取消，直至所有用户的请求迁移到新版本的容器中。
容器服务平台 基于 Istio 提供了蓝绿部署、金丝雀发布、流量镜像等三种灰度策略，无需修改应用的服务代码，即可实现灰度、流量治理、Tracing、流量监控、调用链等服务治理功能。
4.1.3.6服务域名
域名映射是为微服务提供外部访问能力的基础域名。 集群绑定弹性IP后，会默认生成一个xip域名（格式为：{IP}.xip.io）。也可是自行申请的域名，并确保域名能解析到当前集群的弹性IP。
4.1.3.7配置管理
配置管理提供配置项和密钥两种配置方式实现对容器中应用的配置管理，实现镜像配置与镜像本身解耦，使容器应用做到不依赖于环境配置。
4.1.3.7.1配置项
配置项是一种用于存储容器所需配置信息的资源类型。可通过添加“环境变量”引用配置项，使其成为容器中的环境变量，或者通过“挂载卷”的方式将配置项数据映射为容器中的文件，在容器中加载使用。
4.1.3.7.2密钥
密钥是一种用于存储应用所需要认证信息、密钥的敏感信息等的资源类型。可通过添加“环境变量”引用配置项，使其成为容器中的环境变量，或者通过“挂载卷”的方式将配置项数据映射为容器中的文件，在容器中加载使用。
4.1.4镜像仓库
镜像仓库提供镜像存储管理功能，存储和管理docker基础镜像及源代码编译构建、程序包构建生成的镜像，简化镜像仓库的创建、维护和部署容器应用的规范流程，并提供内部和外部网络访问能力，提供安全可靠的镜像资源托管空间，方便用户在任何平台上使用安全可靠的镜像快速部署容器应用，同时支持对接代码托管服务和CI/CD流水线服务，能够实现容器镜像的自动化构建与更新。镜像资源包括私有镜像和官方镜像，支持镜像上传、下载、删除功能，还支持企业级扩展功能，包括提供镜像仓库管理端页面；提供基于项目多仓库镜像同步复制和跨区域镜像仓库同步管理；提供基于项目的用户角色权限控制，同时添加了镜像扫描功能帮助排除镜像漏洞。
4.1.4.1我的镜像
可管理个人用户私有 Docker 镜像仓库，提供镜像上传、下载和设置tag标签等功能。还可根据用户设置相应的配额权限，用户可在镜像配额限制内管理和维护镜像资源；同时提供镜像详细信息查询功能。详细信息中可以查看：镜像名称、已用存储、版本数量、下载次数、创建时间和更新时间，还可以查看镜像版本中对应的版本详细信息，包括：标识、大小、镜像版本和更新时间以及镜像元数据信息。
4.1.5模板仓库
4.1.5.1模板市场
模板市场用来管理基于Kubernetes Helm标准的应用模板。高效实现了模板的快速部署，简化了Kubernetes部署应用的版本控制、打包、发布、删除、更新等操作。
模板市场提供自定义模板和官方模板，平台提供模板开发指南，用户可根据开发指南，自行开发模板，并打包上传到模板市场进行管理，支持模板版本管理、更新、删除等功能。平台提供10个官方模板供用户使用，包含：MySQL、Redis、瀚高数据库、TongWeb、神通数据库、金蝶中间件，PostgreSQL-HA、RabbitMQ-HA、Kafka、Zookeeper等。
4.1.5.2模板实例
提供模板实例的全生命周期管理，同一个模板可在多个隔离的命名空间创建不同用途的实例，满足用户不同应用场景的需求。
提供集群内访问、节点访问、以及域名访问等多种访问方式
支持模板创建时，动态配置存储，选择CPU内存等不同规格
支持模板实例修订版本管理
支持根据更新配置，更新实例，重启容器组，重建资源
支持模板实例回滚到某一修订版本
4.2微服务管理平台
4.2.1工作台
提供总览微服务管理平台运行情况工作台，包括机构数量、用户数量、服务数量、应用数量、资源使用情况、系统预警列表、最近七天每天的系统访问量、最近七天服务访问趋势。
4.2.2服务注册发现
4.2.2.1服务列表
查看已发布的服务，按照空间进行展示，包括服务名、分组、集群数目、实例数、健康数等，可查看服务详情，对服务进行上线、下线操作。
4.2.2.2订阅者列表
查询当服务有哪些订阅者。
4.2.3配置管理
4.2.3.1配置列表
配置文件通过Nacos来进行集中管理，不仅可以在线实时修改相关文件配置，将配置动态应用到相关应用。 同时可以查看配置文件的历史版本，并对版本进行回滚。
4.2.3.2历史版本
查看配置文件的历史版本。配置文件通常会根据环境的改变而做出修改，对配置文件进行历史版本管理，方便文件历史的追溯，以及文件变动的比较。
4.2.3.3监听查询
监听查询提供配置订阅者即监听者查询能力，同时提供客户端当前配置的MD5校验值，以便帮助用户更好的检查配置变更是否推送到 Client 端。
4.2.4服务治理
4.2.4.1API列表
API列表是网关路由相关服务对应的访问接口。API列表提供两种方式对API进行维护管理，一种是直接通过新增的方式。另一种是对接口进行同步，同步的接口，通常是服务在启动扫描时暂存到Redis中的接口数据；同步时，会将该数据持久化到数据库。
4.2.4.2API分组
API分组是灵活配置API的方式，以用于流控与降级。 在API分组中，包含3种匹配规则：精确、前缀、正则，支持多种匹配规则混合过滤。
4.2.4.3访问控制
访问控制主要是对IP与域名进行黑白名单控制。
4.2.4.4访问日志
对调用API的访问记录。包括请求地址、请求方式、IP、区域、终端、浏览器、服务名、响应状态，请求头、请求参数等消息。
4.2.5服务熔断降级
4.2.5.1流量控制
流量控制主要是对网关路由的访问流量进行控制。
流量控制是一个计算机网络的网络交通管理技术，从而延缓部分或所有数据包，使之符合人们所需的网络交通规则，速率限制的其中一种主要形式。
网络流量控制是用来优化或保证性能，改善延迟，或增加某些类型的数据包延迟满足某些条件下的可用带宽。如果某一个环节趋于饱和点，网络延迟可能大幅上升。因此，网络流量控制可以利用以防止这种情况发生，并保持延迟性检查。
网络流量控制提供了一种手段来控制在指定时间内（带宽限制），被发送到网络中的数据量，或者是最大速率的数据流量发送。这种控制可以实现的途径有很多，但是通常情况下，网络流量控制总是利用拖延发包来实现的，一般应用在网络边缘，以控制进入网络的流量，但也可直接应用于数据源（例如，计算机或网卡），或是网络中的一个元素。
4.2.5.2流量监控限流算法
限流算法主要为：漏桶、令牌桶、计数器
漏桶
一个固定容量的漏桶，按照常量固定速率流出水滴。
令牌桶
令牌桶算法是一个存放固定容量令牌的桶，按照固定速率往桶里添加令牌。
计数器
有时候我们还使用计数器来进行限流，主要用来限制总并发数，比如数据库连接池、线程池、秒杀的并发数；只要全局总请求数或者一定时间段的总请求数设定的阈值则进行限流，是简单粗暴的总数量限流，而不是平均速率限流。
4.2.5.3应用运行监控
监控客户端请求、支撑平台运行环境、微服务组件运行环境、业务应用系统运行环境：对外用户请求；对内各个系统之间的回调请求；上报数据格式标准化；监测数据质量情况；处理过程的实时和延时结果；监测不同各节点的CPU、内存、网卡等设备使用情况；心跳监控,时刻了解每一个机器的运行状态；业务层监控，涉及JVM，Nginx，数据库服务器的连接数等。
根据以上监测结果，当资源成为瓶颈时，需要对请求访问做限流启动流控保护机制。流量控制包括针对访问速率的静态流控、针对资源占用的动态流控和自定义流控机制等。
4.2.5.4限流方式
限制总并发数（比如数据库连接池、线程池）
限制瞬时并发数（如nginx的limit_conn模块，用来限制瞬时并发连接数）
限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）
限制远程接口调用速率
限制MQ的消费速率。
可以根据网络连接数、网络流量、CPU或内存负载等来限流
4.2.5.5限流框架

4.2.5.6流控规则
通过对请求的QPS、线程数进行阈值设置，对API进行流量控制。 当前API的流控基于路由ID和API分组两种类型。
4.2.5.7降级规则
设定降级规则，降级策略可以依据RT、异常比例、异常数进行设置；时间窗口是指在满足降级条件时，在下一个时间窗口将会执行降级。当再下一个时间窗口到来时，会根据请求情况，决定是否取消降级。
4.2.6开放服务网关管理
客户端向微服务网关请求。如果客户端通过微服务网关权限校验、限流控制，微服务网关则会将网关请求路由转发至数据缓存，如果缓存未命中，则进入接口监控，经过接口监控后转发至代理服务，代理服务响应后再次返回原调用链。如果缓存命中，则返回数据到客户端。
4.2.6.1网关路由
业务应用系统不能直接访问微服务组件接口，必须通过支撑平台网关进行路由代理进行访问，微服务组件将屏蔽一切非支撑平台网关发起的访问。业务应用系统访问支撑平台网关，由支撑平台网关统一接收请求后，通过模块定位具体处理的微服务组件，并将其转发至目标微服务组件进行处理，微服务组件处理结果通过支撑平台网关将数据封装后返回业务应用系统。
网关为微服务提供统一的入口/出口管理，通过网关路由配置，为HTTP/TCP提供流程配置负载均衡器。能够跨多个应用对微服务进行路由规则配置，暴露统一的域名访问方式。
通过网关路由配置，可以将多个微服务绑定到一个域名上，支持精确、前缀及正则三种路由匹配规则。
4.2.7服务链路追踪
4.2.7.1仪表盘
服务视角
服务视角有以上的监控数据可以自定义监视数据图表的展示
实例视角
实例仪表盘分析了JVM相关的图表和请求响应相关的图表，可以直观的看到请求或者服务占用等情况。
端点视角
端点仪表盘展示了每个端点的请求响应情况以及延时情况。在端点可以看到影响性能的端点名称等。

4.2.7.2拓扑图
拓补图可以看到整个微服务的相互作用关系，可以看到整个调用链的大致结构，以及服务的类型。方便开发者理解整个系统的架构。
拓补图可以大致的看出某个服务的运行情况，也可以点击服务相关内容查看详细信息。在每个调用链上也展示了请求数和延时情况等信息，方便查看者对服务情况大体的了解。

4.2.7.3链路追踪
链路追踪可以收集整个服务的调用链，以及调用情况，执行情况，和参数等，蓝色为调用成功的链路，点击列表可展示链路具体的调用信息，查看耗时，参数，执行情况等，方便对链路进行分析。

4.2.7.4性能分析
性能分析，在根据服务名称、端点名称，以及相应的规则建立了任务列表后，在调用了此任务列表的端点后。会自动记录，剖析当前端口，生成剖析结果。
4.2.7.5服务日志监控
4.2.7.5.1日志检索
日志检索可以根据具体服务名以及其他检索条件，查询出应用发送到es中的日志记录。
4.2.7.5.2日志规则
应用注册到nacos，并且开启端点后可以在此在线修改应用的日志规则。
4.3软件开发服务
DevOps（软件开发服务）就是为了提高软件研发效率，快速应对变化，持续交付价值的的一系列理念和实践，其基本思想就是持续部署（CD)，让软件的构建、测试、发布能够更加快捷可靠，以尽量缩短系统变更从提交到最后安全部署到生产系统的时间。
要实现持续部署（CD)，就必须对业务进行端到端分析，把所有相关部门的操作统一考虑进行优化，利用所可用的技术和方法，用一种理念来整合资源。DevOps 理念从提出到现在，已经深刻影响了软件开发过程。DevOps 提倡打 破开发、测试和运维之间的壁垒，利用技术手段实现各个软件开发环节的自动化甚至智能化，被证实对提高软件生产 质量、安全，缩短软件发布周期等都有非常明显的促进作用，也推动了IT技术的发展。
软件开发服务是对软件交付方法的实现工具，开发和运营团队基于该平台以速度、质量和控制协作构建、测试、部署和监控应用程序，平台支持敏捷开发，实现快速支付，可缩短版本发布间隔时间，提高可靠性。
软件开发服务建设可以打通需求、开发、测试、发布、部署上线、运维等各环节，促进需求、开发、测试、运维团队更紧密地合作，敏捷开发，持续交付、自动运维，提高支持系统的生产、交付效率。
软件开发服务通过持续服务交付价值链打破孤岛，整合开发和运维的能力成为一个协作的团队。进行端到端持续服务交付流程的变革。对新的应用和服务，加快且缩短实现价值的时间。不影响安全性、兼容性和性能。
软件开发服务在保证高质量的前提下缩短系统变更从提交到部署至生产环境的时间，通过进入生产环境前执行自动化测试用例，对新部署的代码密切监控。容器化的交付机制具备高度的可靠性和可重复性。目标导向，不拘泥于实践的形式或者是否使用工具，目标是减少从提交代码到部署到生产环境之间的时间，而不局限于用户测试和部署实践。
4.3.1项目管理
软件开发服务包含项目集管理，项目集管理。可对单项目进行分支、标签等管理，并可把多个项目集合管理，已达到项目集合的作用。
4.3.2配置管理
支持署流程和容器化的DevOps工具，这些内容均部署在被管理的容器服务平台上，包括代码管理、流水线驱动、镜像/产成品仓库等容器。部署过程中，源代码和Dockerfile会被推送至代码库和流水线构建。流水线工作节点负责构建和打包应用程序以及负责构建容器镜像。流水线定义代码化，配置权限交给开发人员，使得开发流程具有最大的灵活度。使用镜像产成品仓库存储所创建的镜像或二进制文件。打包好的镜像会先进入测试环境测试，测试通过后发布到生产环境运行。
4.3.3持续集成
开发人员提交代码后，软件开发服务自动进行构建、（单元）测试，通过自动化测试保障所有的提交在合并主线之后，出现问题及时预警，从源头减少解决问题的成本与时间。
4.3.4持续部署
软件开发服务通过流水线的方式，将申请环境、部署环节（包括代码扫描、接口测试、自动化测试、镜像推送、环境部署等）及资源回收串联起来，及自动化的方式完成高效的持续部署。
4.3.5自动化测试
软件开发服务自动化测试是将自动化工具和技术应用于软件测试，旨在减少测试工作，更快，更经济地验证软件质量。有助于以更少的工作量构建质量更好的软件。
提供UI自动化测试、接口自动化测试、Mock测试及测试数据自动构造功能，极大地提高了发现问题的广度及深度，并以自动化代替人工测试，最大程度节约人工成本。
4.3.6组件商店服务
为用户提供基础的中间件服务。包括但不限于数据库服务、消息队列服务、缓存 服务、Jenkins 服务等，用户可以根据自己的需求通过向导或者配置文件的方式创建自己需要的服务。用户可以通过平台管理界面快速的构建具备高可用能力 的数据库服务。并且可以通过监控界面实时管理平台的运行状况。