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 架构演进策略

近年来商业世界的发展趋势，数字化转型的出现使得企业越来越多业务演变成数字化业务，数字化对于业务渠道、竞争格局、用户体验等诸多方面都带来更加严苛的要求，这就要求技术具备更快的迭代速度，业务推出速度也更加的快。因此架构演进不是一蹴而就，而是不同时期为了更好的支撑业务发展进行适配发展的行为，为了技术而进行不合适的架构过度设计是不负责任的行为，业务与架构共同朝着既定目标共同成长才是最佳策略。

一 前言