2022技术盘点之平台云原生架构演进之道-六虎

苍山负雪，烛名天南，2022注定是不普通的一年，岁末全国铺开，在宣布改文章时，正式自己第二天，一切的惊骇源于无知，发烧39度一粒布洛芬就处理了，处理惊骇最好的方法便是直面惊骇，凡是过往，皆为终章，愿咱们能拨雪寻春，烧灯续昼，和光同尘，与时舒卷，2023冲！

一前语

1.1 布景

自2020年至今，众多传统职业都受到疫情的冲击，据IDC相关陈述，疫情期间，终端消费者需求的多样性、易变性对企业传统IT架构以及经营运营形式建议了应战，使得企业追求云效能、云价值最大化成为不可忽视的趋势，而云搬迁、云办理正是企业完结云价值最大化的重要第一步。

2022年作为公司SmartOps产品担任人，在技能方面进行了微服务架构向云原生架构的演进升级，打造更稳定、安全、有用的渠道，支撑事务更好的开展。

1.2 渠道简介

SmartOps多云办理渠道处理异构的基础设施资源复杂难办理问题。渠道可纳管不同环境、不同云厂商资源一致办理,并结合渠道的一致监控告警、一致服务办理、一致运营办理、一致运维办理、自动化运维等才能能极大简化云用户、云运维、云运营各角色的工作复杂度,提高办理功率和资源交给功率,最终协助企业下降云上本钱,提高人员功率,加快企业的数字化转型。

二高可用架构

云的时代需求新的技能架构，来协助企业运用可以更好地运用云核算优势，充沛开释云核算的技能红利，让事务更灵敏、本钱更低的一起又可弹性性更灵敏，而这些正好便是云原生架构专注处理的技能点。

SmartOps随着渠道支撑客户的增长，在安全、功用、稳定性等方面都提出了更高的要求，为习惯事务开展诉求，架构也需进行迭代升级，原始的Spring Cloud全家桶的微服务架构，经过不断开展，也在演进为基础设施下沉的云原生架构，让运用生于云，善于云，充沛运用云上才能，降本增效，减少技能债务，专注事务创新。

下图为SmartOps架构全景：

接入层：经过WAF/SLB，合作NAT网关办理出方向流量，布置有堡垒机进行运维等其他辅佐事务进行支撑；
运用层：选用腾讯TKE进职事务容器布置，合作K8s原生服务注册发现/装备中心/分布式调度中心/日志/监控/告警/链路追寻/DevOps等构筑完整运用体系；
数据层：存储运用有云硬盘/方针存储/CFS，数据库有MongoDB分片集群/MySQL/Redis/ElasticSearch/RabbitMQ进行各类事务数据核算和存储

三流量管控

3.1 南北流量

事务流量：事务流量进口最外层经过WAF进行安全防护，之后进入到腾讯云公网负载均衡，负载均衡后办理到TKE集群的NodePort完结流量接入；出口经过NAT网关完结流量分发。其他服务：其他支撑服务，如堡垒机，日志、监控等其他运用web经过堡垒机合作弹性公网IP/NAT网关完结流量接入与分发；

3.2 东西流量

在容器集群内，服务经过Kubernetes API-Server获取后端一组Service Pod真实IP，事务POD经过Calico网络进行POD与POD直接流量通讯。

四安全管控

4.1 SmartOps安全全景

全场景的安全架构规划：从网络边界、内部网络、各类基础设施、数据、事务运用到后期监控响应，运维管控，在各层面均进行安全管控规划，完结全方位立体式防护；
云安全产品防护：凭仗腾讯SaaS安全产品包含安全体检（缝隙扫描、挂马检测、网站后门检测、端口安全检测等）、安全防护（DDoS 防护、入侵检测、拜访操控来保证数据安全与用户隐私）以及安全监控与审计，构成事前、事中、过后的全进程防护；
业界干流安全东西渠道赋能：如：KubeLinter/Kubescape/Nessus/Sonarqube/AppScan等，严格把控渠道从规划、开发、测试、布置、上线、运维等各流程安全，将SecDevOps遵从在渠道生命周期中，保证渠道他安全性；
安全认证可信：SmartOps一起经过三级登保，继续性MSS服务对渠道进行安全认证及日常安全运维；

4.2 SmartOps分层安全架构

接入层：收护边界网络安全，对事务流量及运维支撑流量进行安全防护；
运用层：渠道运用选用安全结构，并严格恪守SDLC，将SecDevOps践行在运用全生命周期中；
运维层：进行MSS继续性运维，对运用无论从外部勘探到分布式链路最终，均进行安全可观测行施行；
云渠道层：重复运用云渠道供给安全产品及才能，践行云渠道安全最佳实践，保护云上资源及运维安全；
K8s层：运用K8s内置安全机制，合作业界干流安全东西渠道进行安全检测，及时快速反响反响；
容器层：凭仗腾讯云镜像安全才能，一起合作业界镜像安全扫描东西，保证镜像分层可信；
数据层：经过事务逻辑数据加密及各云基础设施高可用布置，一起进职事务数据备份康复和安全审计；
体系层：经过对云服务器进行体系安全加固，缝隙补丁办理，云主机安全和云防火墙，保证体系安全。

三 DevOps

SmartOps渠道从DevOps到SecDevOps的演进之路。

3.1 DevOps V1.0

起先DevOps运用Gitlab CI进行管控。

CI/CD：各事务代码库房保护.gitlab.yml，运用Gitlab CI进行CI和CD进程
镜像办理：构建出来的镜像运用镜像库房Harbor进行办理
容器编列：在CD进程中，运用kubectl set image进行容器编列布置，自建Kubernetes集群进职事务容器编列办理

高可用：当某个节点呈现毛病时，Kubernetes 会自动创立一个新的 GitLab-Runner 容器，并挂载相同的 Runner 装备，使服务到达高可用。
弹性弹性：触发式使命，合理运用资源，每次运转脚本使命时，Gitlab-Runner 会自动创立一个或多个新的暂时 Runner来运转Job。
资源最大化运用：动态创立Pod运转Job，资源自动开释，并且 Kubernetes 会根据每个节点资源的运用情况，动态分配暂时 Runner 到空闲的节点上创立，下降呈现因某节点资源运用率高，还排队等候在该节点的情况。
扩展性好：当 Kubernetes 集群的资源严重不足而导致暂时 Runner 排队等候时，可以很简单的增加一个 Kubernetes Node 到集群中，然后完结横向扩展。

运用Gitlab CI 共享模块库，可最大程度完结CI代码复用性。

3.2 DevOps V1.1

在之前CI/CD中缺乏安全全场景检测，代码、镜像、环境中存在安全危险，对此进行安全左移，在进行安全全场景建设中，进行五阶段施行：

第一阶段：威胁建模(场景剖析)整理并绘制软件生命周期或许引发安全问题的场景；整理渠道架构存在安全危险的的部件，以及灵敏数据的流向，协助全员树立安全模型，快速定位安全问题，及提高团队安全意识；
第二阶段：安全扫描(DevOps集成安全)，扫描阶段评价代码以保证其安全且没有安全缝隙。此处包含手动和自动代码检查。在此进程中，运用了 lint 和 scan 等 AppSec 东西。因为处于软件开发生命周期的早期，此阶段答应工程师处理大多数安全缝隙和缺点。
第三阶段：安全危险告诉及可视化，针对东西检测出来的安全危险问题进行周期性告诉及可视化，让全员知道安全问题，数字可视化安全问题，进行安全指标监控。
第四阶段：补救修复，补救阶段处理在从前阶段已辨认和组织的安全缝隙。一些 DevSecOps 技能（例如 sonaqueb）可以针对发现的缝隙、缺点和缺点提出修复主张。这使得在呈现安全问题时更简单处理它们。
第五阶段：监控，盯梢监控发现的缝隙，尽力减轻或消除他们，并对运用程序进行安全评价，盯梢和办理危险，在软件生命周期中作出决策对安全进行继续性安全施行。

3.3 SecDevOps V1.2

开发阶段：从安全意识培训，安全编码，安全剖析到代码静态扫描，提交代码Code Review，安全左移到研制进程中；
CI/CD：Gitlab+Drone CI+Argo CD进行继续集成继续布置，其中代码单元测试，运用代码及装备检测东西进行代码扫描，合规检测；
制品办理：运用镜像安全东西对制品镜像进行分层安全剖析及缝隙安全扫描，保证镜像layer安全可控；
容器办理：运用kube-bench/kubeEye/kube-eventer等对容器集群/事务容器进行合规检测，反常事情告警，集群装备；
事务办理：进行继续性MSS运维，运用Nessus/Acunetix/AppScan等事务体系进行安全缝隙扫描，及继续性安全运维；

上图为CI/CD WorkFlow，在CI最终一步经过Triger动身CD Action，进行装备布置库房修正，Argo CD检测到装备的修正，进行最新资源的布置。

运用根据 Kubernetes 的声明式 Gitops 继续布置东西Drone CI + Argo CD，可以运用界说，装备和环境变量办理均根据云关上管控，代码库房及装备资源声明清单也都存储在代码库房受版本办理，运用发布及生命周期办理自动化，可审计。

在SecDevOps中，没有永远的安全，在事务、开发、和安全方面，彻底安全不仅不合实践，也是不或许；相反咱们专注于处理核心安全问题，预测安全危险，尽或许下降安全隐患，流程中遵从安全理念思想，凭仗安全东西尽或许下降安全危险，并不断继续优化。

安全是为了事务保驾护航及下降后期安全技能债，而不是安全阻止研制效能的提高，因而开发团队应恪守安全措施集成到开发进程中，而不是完结开发后再去检测修复，安全与效能应该紧密结合，同进开展。

四云原生架构

4.1 API网关

在微服务架构中，API网关担任各类运用恳求路由、API组合和协议转换，经过调用不同服务聚合聚合，一起有的API网关也担任验证，鉴权，负载均衡，协议转换，数据缓存等，结构网关如Netflix Zuul、Spring Cloud Gateway，云原生网关：Ingress-Treafik/Nginx/APISIX，Kong，Istio，Linked等。

因为部分认证鉴权运用Spring Cloud Gateway完结，因而合作云上LB进行流量接入。

K8s流量接入可以参考：Kubernetes 集群中流量暴露的几种计划

运用LB + NodePort + Spring Gateway计划，运用公有云七层负载均衡，完结一个域名端口对应多个 Service，如图可以根据 path 路径，/cmp 对应 NodePort 的 32111，/gateway 对应 NodePort 的 32000 端口，不仅可以完结高可用，并且七层可以完结 SSL 卸载。

LB：从运用公有云七层负载均衡可以完结根据域名流量转发和负载均衡，SSL的卸载；
NodePort：运用TKE负载均衡的NodePort，完结从LB流量转发到K8s集群内部，完结流量接入；
Spring Gateway：运用Spring Gateway作为API网关进口，进行认证和鉴权及南北流量服务恳求转发。

4.2 服务注册发现

SmartOps服务注册发现中心演进，从原始Spring Cloud Consul方法到Spring Cloud Kubernetes方法。

4.2.1 通用服务注册发现

在微服务架构中，因为服务众多且单个服务具有多个实例，一起布置在Kubernetes集群中，实例的IP地址是或许随时改变的，需针对该情况对服务调用进行会集一致办理，因而引进服务注册发现机制。

服务注册和发现的意思是服务进程在注册中心注册自己的方位，客户端运用进程向注册中心建议查询，来获取服务的方位，服务发现的一个重要作用便是供给一个可用的服务列表。经过一致会集化办理，使得服务直接仅经过服务名称即可调用，无需知道详细实例的IP地址。

4.2.2 Spring Cloud Consul

Spring Cloud Consul服务注册发现计划，Consul作为服务注册中心，微服务注册自己到Consul Server，服务间调用从Consul获取其他运用信息；支撑客户端负载均衡：包含Ribbon和Spring Cloud LoadBalancer。

运用方法比较简单，引进依靠及装备相关信息：

引进依靠
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-consul-discovery</artifactId>
</dependency>

装备Consul信息：

Consul装备
server:
  port: 8206
spring:
  application:
    name: consul-user-service
  cloud:
    consul: #Consul服务注册发现装备
      host: localhost
      port: 8500
      discovery:
        service-name: ${spring.application.name}

在改架构中，事务遇到过以下应战： 1.Consul Cluster需求选用高可用布置，改组成需求投入额外投入进行保护。 2.事务布置在Kubernetes集群内，需以DaemonSet方法布置Consul Client至每个事务Node，当Node呈现毛病宕机，会呈现运用注册脏数据，需手动处理，形成事务恳求反常。

4.2.3 Kubernetes Service方法

4.2.3.1 Kubernetes服务注册发现

运用云原生服务注册发现需先了解Kubernetes中Service自动注册DNS进程

向 API Server 用 POST 方法提交一个新的 Service 界说；
这个恳求需求经过认证、鉴权以及其它的准入战略检查进程之后才会放行；
Service 得到一个 ClusterIP（虚拟 IP 地址），并保存到集群数据库房；
在集群范围内传达 Service 装备；
集群 DNS 服务得知该 Service 的创立，据此创立必要的 DNS A 记载。

总体来说，Kubernetes的服务注册与发现总结首要经过Etcd+CordDNS来完结，其中又包含了endpoints/kube-proxy等组件的协同。

4.2.3.2 Spring Boot+K8s Service服务注册发现计划

计划简介：运用K8s 原生service/endpoints/coredns/etcd组成完结服务注册发现进程，服务注册运用和服务发现均运用service，在K8s环境下，凭仗K8s service才能完结负载均衡，更高级流量、安全等功用需求凭仗服务办理结构完结。

服务注册：spring Boot 运用装备有serivce的服务，发动后k8s集群针对调用该service，后端会回来详细的pod列表。

服务发现：在同一名称空间，直接运用service信息建议调用；

计划特色：
- 优势：负载均衡算法在服务端完结（service 的原生负载均衡算法），后期可运用服务办理结构例如istio/linkerd进行服务办理。
- 不足：服务直接经过k8s服务发现，经过service一层，在书主机恳求经过iptables/lvs是转发一层，功用稍弱。

4.2.4 Spring Cloud Kubernetes方法

4.2.4.1 通用计划

Spring Cloud Kubernetes 服务注册发现：

服务注册经过Spring Cloud运用的Service进行注册，服务发现经过项目引进Spring-cloud-kubernetes-discovery的jar包完结，更上层调用java完结的Kubernetes-client与API-server进行Rest调用完结获取service后端相关的endpoints信息，经过spring cloud openFeign完结服务间的通讯，spring cloud ribbon完结负载均衡.选用如上几个模块，可以在k8s的环境下，完结重试，超时，限流，负载均衡等常用功用。

4.2.4.2 Spring Cloud Kubernetes 服务注册发现-东西流量

Spring Cloud Kubernetes 服务注册发现-东西流量：

计划简介：运用Kubernetes原生service/endpoints/coredns/etcd组成完结服务注册进程，服务发现经过Spring Cloud Kubernetes调用Kubernetes API-server获取后端服务Pod的IP/Port，运用openFeign完结服务间调用，运用ribbon完结客户端负载均衡。

服务注册：spring Cloud运用装备有serivce的服务，发动后k8s集群针对调用该service，后端会回来详细的pod列表；服务发现：服务发现经过Spring Cloud Kubernetes调用Kubernetes API-server获取后端服务Pod的IP/Port；

计划特色：
- 优势：服务直接经过k8s服务发现，获取service后的实例POD IP和端口，流量直接对POD建议，不经过service转发，功用高；
- 不足：负载均衡在调用端(客户端)完结，例如ribbon，后期服务办理结构如Istio/Linkerd或许需改造；

4.2.4.3 Spring Cloud Kubernetes 服务注册发现-南北流量

Spring Cloud Kubernetes 服务注册发现-南北流量：

计划简介：运用Kubernetes原生service/endpoints/coredns/etcd组成完结服务注册进程，Springboot Gateway 运用Spring Cloud Kubernetes 与api Servier的http交互，获取后端服务 Services / Endpoints，完结服务恳求转发。

服务注册：spring Cloud运用装备有serivce的服务，发动后k8s集群针对调用该service，后端会回来详细的pod列表；服务发现：服务发现经过Spring Cloud Kubernetes调用Kubernetes API-server获取后端服务Pod的IP/Port，Gateway进行恳求转发；

计划特色：
- 优势：Gateway服务经过k8s服务发现，获取service后的实例POD IP和端口，Gateway流量转发，直接对POD建议，不经过service转发，功用高；
- 不足：负载均衡在调用端(客户端)完结，例如ribbon，后期服务办理结构如Istio/Linkerd或许需改造；

4.3 装备中心

传统的静态装备方法要想修正某个装备只能修正之后从头发布运用，要完结动态性，可以选择运用数据库，经过守时轮询拜访数据库来感知装备的改变。轮询频率低感知装备改变的延时就长，轮询频率高，感知装备改变的延时就短，但比较损耗功用，需求在实时性和功用之间做折中。装备中心专门针对这个事务场景，兼顾实时性和一致性来办理动态装备。

SmartOps原始装备中心为Spring Cloud Config计划，需求考虑一下问题：

需求独立在K8s中部Config服务；
需求考虑Config服务的高可用性；
因为Config服务需求链接私网git repo，安全问题和网络互通问题。

以下列出了一些其他装备中心的功用点对比。

演进方向：事务在Kubernetes上，所以应尽或许运用K8s原生装备办理才能，将装备中心不可控性托付给K8s，运用K8s原生configmap和secret资源，无需考虑单独布置装备中心，不用引进新服务，configmap/secret发生改变，服务能及时监控到这一改变然后按照装备的装备更新战略进行动态更新或许服务重启，如下选用Spring Cloud Kubernetes装备中心示意图：

Spring Cloud Kubernetes 装备中心计划简介：spring-cloud-starter-kubernetes-config是spring-cloud-starter-kubernetes下的一个库，作用是将kubernetes的configmap与SpringCloud Config结合起来。 spring-boot-actuator/ spring-boot-actuator-autoconfigure 两个包的引进，使得运用可以进行热更新，当configmap/secret发生改变的时候，可以不重启Pod或进程进行热改变装备。

计划特色：

优势：运用K8s内置资源，无需考虑引进装备中心服务，不用考虑装备中心服务高可用。云原生架构，装备中心下沉至基础设施层，无需事务代码耦合，减少本钱。
不足：dev/test 环境也需求上K8s，保证环境一致性。需求将装备资源configmap/secret引进到GitOps流程中。

运用云原生装备办理，安全性问题Secret存储相对灵敏的信息，需结合其他东西或处理计划处理，例如后期可以合作Vault 或许Sealed Secrets处理K8s装备安全性问题，针对热更新，可运用reloader或其他计划处理。

4.4 分布式使命调度

在渠道中存在很对守时使命，存在多服务使命完结方法纷歧致，排错本钱高，难以一致管控，针对此窘境，进行会集化分布式使命调度渠道改造，xxl-job中心式的调度渠道轻量级，开箱即用，操作简易，上手快，与SpringBoot有非常好的集成，且监控界面就集成在调度中心，界面简练，选取xxl-job做调度渠道，调度中心：担任办理调度信息，按照调度装备宣布调度恳求，自身不承当事务代码。支撑可视化界面，可以在调度中心对使命进行新增，更新，删去，会实时生效。支撑监控调度成果，检查履行日志，检查调度使命计算报表，使命失利告警等等。履行器：担任接纳调度恳求，履行调度使命的事务逻辑。履行器发动后需求注册到调度中心。接纳调度中心的宣布的履行恳求，终止恳求，日志恳求等等。

同一个服务多个实例的使命存在互斥时，需求一致的调度。
使命调度需求支撑高可用、监控、毛病告警。
需求一致办理和追寻各个服务节点使命调度的成果，需求记载保存使命特点信息等。

运用其高可用布置在Kubernetes集群中，完结分布式使命调度会集管控，一致标准下降开发本钱，提高研制效能，极大程度处理后台使命管难管控的痛点问题。

五可观测性

5.1 Logging

之前SmartOps选用Graylog 日志监控计划，在代码内部引进日志收集jar包，将日志数据收集只graylog server端，现在graylog server布置在K8s集群内，Graylog server运用MongoDB和ES，现在ES和MongoDB占用K8s集群资源，存在必定问题，改造方针：

日志服务下沉到基础设施层与事务低耦合，事务仅重视事务；
日志服务无侵入事务代码；
开发服务适配多言语；
不占用过多K8s资源；
易保护，扩展性强。

事务日志遵从必定标准，如将日志输出到stdout/stderr，在Node上以Ds方法布置日志收集Pod，针对打印到操控台日志进行检查剖析。

序号	计划思路	长处	不足	代表计划
1	在独立运用内布置事务日志收集Agent	无需新增k8s yaml	适用于一致言语开发项目，讲日志组成保护在事务中，强耦合，不便于保护	graylog
2	sidecar形式，独立日志组成与事务运转在同一个Pod中	低耦合，扩张性强，易保护，与言语无关	需求独立装备k8s yaml文件，功用问题需求考虑	filebeat
3	事务日志遵从必定标准，如将日志输出到stdout/stderr，在node上以ds方法布置日志收集Pod	日志彻底与事务解耦，扩张性保护性强，与开发言语无关	需事务遵从一致标准，一致手机规则	fluentd

根据事务特征，现阶段针对事务体系日志运用ELK进行存储剖析，针对运用内部事务操作日志运用graylog进行日志剖析。

5.2 Tracing

分布式链路为一套链路追寻的 API 标准，支撑多种编程言语,与渠道无关、与厂商无关，使得开发人员可以便利的增加（或替换）链路盯梢体系的完结，尽管OpenTracing不是一个标准标准，但现在大多数链路盯梢体系都在尽量兼容OpenTracing。现在业界干流这API标准的就有 SkyWalking,Jaeger,Zipkin,Open Telemetry，Pinpoint、CAT等。

SmartOps因为内部服务特殊性，现在选用业界干流Skywalking作为APM体系进行服务链路追寻日常服务定位及排错。在追寻体系，渠道更重视恳求的质量和服务可行性，运用其优化体系，排查问题。

5.3 Metrics

在Metrics方面，首要运用云渠道告警结合Prometheus+Grafana完结，合作外部站点勘探完结全场景渠道Metrics指标剖析及告警，合作高可用架构及云原生毛病自愈才能，能最大程度保障体系SLA。

日志体系，衡量体系，追寻体系这三个纬度所重视重点是纷歧。一般来说日志体系是对咱们运用或许体系事情做一个记载，这些记载是咱们问题排查，取证的一些根据；衡量体系是对某些咱们重视事情的聚合，当到达必定指标咱们会设置告警，会设置自习惯机制，会有容灾等；APM体系为跟高阶体系内部服务优化及便利问题排查定位，组合运用能提高全体渠道的可观测性。

六未来方向

6.1 云原生最佳实践准则执行

服务化准则：微服务架构，服务内功用高度内聚，模块间经过公共功用提取增加软件复用程度，从架构层面笼统化事务模块关系，标准化服务流量传输，协助事务模块根据服务流量的战略操控与办理；
弹性准则：体系的布置规模可以随着事务量的改变自动弹性，无须根据事先的容量规划准备固定的硬件和软件资源，动态扩所容，下降企业IT本钱；
可观测准则：在云分布式体系中，自动经过日志、链路盯梢和衡量等手段，让每次事务恳求获悉背面的服务调用耗时、回来值，下钻到每次第三方软件调用、SQL恳求、节点拓扑、网络响应，使运维、开发和事务人员实时掌握体系情况；
一切进程自动化准则：经过 IaC（Infrastructure as Code）、GitOps、OAM（Open Application Model）、Kubernetes operator 和大量自动化交给东西在 CI/CD 流水线中的实践，一方面标准化企业内部的软件交给进程，另一方面在标准化的基础上；
零信任准则：零信任对拜访操控进行了范式上的颠覆，引导安全体系架构从“网络中心化”走向“身份中心化”，其本质诉求是以身份为中心进行拜访操控；
架构继续演进准则：因而云原生架构自身也应该和必须是一个具有继续演进才能的架构，而不是一个封闭式架构，在演进进程中需注意对新建运用架构操控战略及对遗留体系搬迁改造本钱考虑及危险评价。

6.2 职业赋能

SmartOps沉淀有不同职业的客户，稳定、安全、有用的功用赋能不同范畴用户进行现代化云上管控：

在互联网职业，以云办理渠道支撑。颠覆了传统的基础设施及运维的形式，带来了可编列、极速大局管控、自服务运维的才能；
在教育职业，凭仗云办理渠道的资源纳管才能和资源笼统才能，助力高校添补公有云技能迭代与高校技能办理人员技能间的距离，打破院级/科系数据孤岛，面向高校用户供给一致的服务目录；
在政务职业，云办理渠道支撑国产化布置，满足基础设施自主可控，以渠道的实时一致监管、宏观调度、审计等才能，协助客户下降本钱和运维压力，完结不同部分一致标准，推动跨部分事务协同
在工业范畴，根据云办理渠道预算办理、资源交给、资源运营才能,大幅提高资源的交给功率及资源运用率,然后下降项目本钱。

6.3 架构演进战略

近年来商业国际的开展趋势，数字化转型的呈现使得企业越来越多事务演变成数字化事务，数字化关于事务渠道、竞赛格式、用户体验等诸多方面都带来愈加严苛的要求，这就要求技能具有更快的迭代速度，事务推出速度也愈加的快。因而架构演进不是一蹴而就，而是纷歧起期为了更好的支撑事务开展进行适配开展的行为，为了技能而进行不合适的架构过度规划是不担任任的行为，事务与架构一起朝着既定方针一起生长才是最佳战略。

「回顾2022，展望2023，我正在参加2022年终总结征文大赛活动」

2022技术盘点之平台云原生架构演进之道

一 前语