安畅 SmartOps 混合云平台架构的演进之道
前言
2021 年，“十四五规划纲要草案”提出“加快数字发展，建设数字中国”，云计算不仅是“新基建”中的新型基础设施，更是数字化场景的重要基座，为上层智能应用加速落地提供了重要保障。因此，积极采用云上数字化战略已成为越来越多企业转型的核心。云上数字化转型往往涉及到多个方面，如架构现代化、应用现代化、云原生安全等诸多领域。今天就让我们通过安畅 SmartOps 混合云管理平台自身的架构现代化实践，来了解企业如何规划并构建云上现代化架构。
关于 SmartOps：安畅 SmartOps 是一款 SaaS 模式的云管理平台，通过统一视角实现多云资源纳管，权限分配、通过监控、费用分析帮你更合理的管控费用支出，加上强大的审计、工单、运维自动化等功能帮助你更高效的管理云资源。
一、SmartOps 如何从微服务架构演进到云原生架构
云时代企业需要更完善的技术架构帮助自身应用获得更好的敏捷性、用户体验与更低的成本，而这些正好就是云原生架构专注解决的技术点。SmartOps 随着平台支撑客户的增长，在安全、性能、稳定性等方面都提出了更高的要求。为适应业务发展诉求，架构也需进行迭代升级。原始基于 Spring Cloud 全家桶的微服务架构，也在逐渐演进为基础设施下沉的云原生架构，充分让应用生于云、长于云，削减技术债务并且专注业务创新。
下图为 SmartOps 架构全景：
接入层：通过 WAF/SLB，配合 NAT 网关治理出方向流量，部署堡垒机进行运维等，或使用其他辅助业务进行支撑；
应用层：采用腾讯 TKE 进行业务容器部署，配合 K8s 原生服务注册发现/配置中心/分布式调度中心/日志/监控/告警/链路追踪/DevOps 等构筑完整应用体系；
数据层：存储使用有云硬盘/对象存储/CFS，数据库有 MongoDB 分片集群/MySQL/Redis/ElasticSearch/RabbitMQ 进行各类业务数据计算和存储。
二、SmartOps 流量管控全景
2.1 南北流量
业务流量：业务流量入口最外层经过 WAF 进行安全防护，之后进入到公有云公网负载均衡，然后到 TKE 集群的 NodePort 实现流量接入；出口通过 NAT 网关实现流量分发。其他服务：其他支撑服务，如堡垒机，日志、监控等其他应用 web 通过堡垒机配合弹性公网 IP/NAT 网关实现流量接入与分发。
2.2 东西流量
在容器集群内，服务通过 Kubernetes API-Server 获取后端一组 Service Pod 真实 IP，业务 POD 通过 Calico 网络进行 POD 与 POD 直接流量通讯。
三、SmartOps 安全管控全景
3.1 SmartOps 安全全景
全场景的安全架构规划：从网络边界、内部网络、各类基础设施、数据、业务应用到后期监控响应，在各层面均进行安全管控设计，实现全方位立体式防护；
云安全产品防护：借助 SaaS 安全产品实现安全体检（漏洞扫描、挂马检测、网站后门检测、端口安全检测等）与安全防御（DDoS 防护、入侵检测、访问控制来保证数据安全与用户隐私）以及安全监控与审计，形成事前、事中、事后的全过程防护；
业界主流安全工具平台赋能，如：KubeLinter/Kubescape/Nessus/Sonarqube/AppScan 等，严格把控平台从设计、开发、测试、部署、上线、运维等各流程安全，将 SecDevOps 贯彻在平台生命周期中，确保平台的安全性；
安全认证可信：SmartOps 已获得三级等保认证，并且通过 MSS 服务（Managed Security Service，安全托管服务）持续对 SmartOps 进行日常安全运维。
3.2 SmartOps 分层安全架构
接入层：守护边界网络安全，对业务流量及运维支持流量进行安全防护；
应用层：平台采用安全框架，并严格遵守 SDLC，将 SecDevOps 安全最佳实践应用在全生命周期；
运维层：进行 MSS 持续性运维，对应用无论从外部探测到分布式链路，均进行安全可观测性实施；
云平台层：利用云平台提供安全产品及能力，践行云平台安全最佳实践，保护云上资源及运维安全；
K8s 层：利用 K8s 内置安全机制，配合业界主流安全工具平台进行安全检测，及时快速反馈；
容器层：凭借公有云镜像安全能力，同时配合业界镜像安全扫描工具，确保镜像分层可信；
数据层：通过业务逻辑数据加密及各云基础设施高可用部署，同时进行业务数据备份恢复和安全审计；
系统层：通过对云服务器进行系统安全加固、漏洞补丁管理，确保系统安全。
四、从 DevOps 到 SecDevOps 的演进
4.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 代码复用性。
4.2 DevOps V1.1
在原始 CI/CD 流程中缺乏安全方面全场景检测，在代码、镜像、环境配置等场景均存在各类安全风险，因此必须实行安全左移。主要从以下五个阶段实现在安全全场景建设：
第一阶段：威胁建模(场景分析)梳理并绘制软件生命周期可能引发安全问题的场景；梳理平台架构存在安全风险的部件以及敏感数据的流向，帮助全员建立安全模型并提升团队安全意识；
第二阶段：通过安全扫描(DevOps 集成安全)评估代码安全风险，确保不存在安全漏洞。此处包括手动和自动代码审查。在此步骤中，使用了 lint 和 scan 等 AppSec 工具。由于处于软件开发生命周期的早期，此阶段允许工程师解决大多数安全漏洞和缺陷；
第三阶段：针对工具检测出来的安全风险问题以可视化的方式呈现并进行周期性通知，让全员知道安全问题；
第四阶段：进入补救修复阶段，通过 sonarqueb 代码管理工具可以针对发现的漏洞、缺陷提出修复建议，这样的操作是为了在出现安全问题时更容易处理它们；
第五阶段：进入监控阶段，跟踪监控发现的漏洞，努力减轻或消除他们，并对应用程序进行安全评估。通过跟踪和管理风险，在软件生命周期中作出决策对安全风险进行持续性安全实施。
4.3 SecDevOps V1.2
开发阶段：从安全意识培训、安全编码、代码静态扫描到最后进行提交代码 Code Review，将安全左移到研发全流程中（安全性已成为软件生命周期不可分割的一部分，所以进一步向左转移安全性，SecDevOps 而非 DevSecOps）；
CI/CD：通过 Gitlab+Drone CI+Argo CD 进行持续集成持续部署，其中代码单元测试可以利用代码及配置检测工具进行代码扫描，实现合规检测；
制品管理：利用镜像安全工具对制品镜像进行分层安全分析及漏洞安全扫描，确保镜像 layer 安全可控；
容器管理：利用 kube-bench/kubeEye/kube-eventer 等对容器集群、业务容器进行合规检测与异常事件告警；
业务管理：进行持续性 MSS 运维，利用 Nessus/Acunetix/AppScan 等业务系统进行安全漏洞扫描以及持续性安全运维。
上图为 CI/CD WorkFlow，在 CI 最后一步通过 Trigger 触发 CD Action，进行配置部署仓库修改、Argo CD 检测到配置的修改以及最新资源的部署。
利用基于 Kubernetes 的声明式 Gitops 持续部署工具 Drone CI + Argo CD，可以更便捷地进行应用定义、环境配置和变量管理。代码及配置资源声明清单也都存储在代码仓库受版本管理，使得应用发布及生命周期管理实现自动化且具备可审计性。
在 SecDevOps 中没有永远的安全。我们只需专注于解决核心安全问题，预测安全风险，尽可能降低安全隐患，并且在流程中贯彻安全意识，借助安全工具尽可能降低安全风险并持续优化。安全是为了业务保驾护航及降低后期安全技术债务，而不是阻碍研发效能的提升，因此开发团队应遵守安全措施集成到开发过程中，不是完成开发后再去检测修复。安全与效能应该紧密结合，同进发展。
五、基于云原生架构的 SmartOps
5.1 API 网关
在微服务架构中，API 网关负责各类应用请求路由、API 组合和协议转换，同时一些 API 网关也负责验证、鉴权、负载均衡、协议转换、数据缓存等，其中框架网关有 Netflix Zuul、Spring Cloud Gateway，云原生网关有 Ingress-Treafik/Nginx/APISIX、Kong、Istio、Linkerd 等。在 SmartOps 微服务架构中采用 Spring Cloud Gateway 作为 API 网关方案，部分认证鉴权使用 Spring Cloud Gateway 完成，因此需配合云上 LB 进行流量接入。
通过使用 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 网关入口，进行认证和鉴权及南北流量服务请求的转发。
5.2 服务注册发现的演进
我们针对 SmartOps 服务注册发现中心进行演进升级，由原始 Spring Cloud Consul 方式演进为 Spring Cloud Kubernetes 方式，并直接利用 Kubernetes 内部服务注册发现底层能力。
5.2.1 通用服务注册发现
在微服务架构中，由于服务众多且单个服务具有多个实例同时部署在 Kubernetes 集群中，实例的 IP 地址是可能随时变化的，需针对该情况对服务调用进行集中统一管理，因此我们引入服务注册发现机制。
服务注册和发现的意思是指服务进程在注册中心注册自己的位置，客户端应用进程向注册中心发起查询来获取服务的位置，服务发现的一个重要作用就是提供一个可用的服务列表。通过统一集中化管理使得服务直接仅通过服务名称即可调用，无需知道具体实例的 IP 地址。
5.2.2 Spring Cloud Consul
在 Spring Cloud Consul 服务注册发现方案中，各微服务注册到 Consul Server 上，服务间调用从 Consul 获取其他应用信息实现服务发现，在客户端发起对目标端请求中，客户端使用包括 Ribbon 和 Spring Cloud LoadBalancer 等实现负载均衡：
使用方式比较简单，引入依赖及配置相关信息：
配置 Consul 信息：
在该架构中，业务遇到过以下挑战：
1.Consul Cluster 需要采用高可用部署，该组建需要投入额外成本进行维护。
2.业务部署在 Kubernetes 集群内，需以 DaemonSet 方式部署 Consul Client 至每个业务 Node，当 Node 出现故障宕机会出现应用注册脏数据，这些需手动处理，易造成业务请求异常。
5.2.3 Kubernetes Service 方式
5.2.3.1 Kubernetes 服务注册发现
利用云原生实现服务注册发现，需先理解 Kubernetes 中 Service 自动注册 DNS 过程：
向 API Server 用 POST 方式提交一个新的 Service 定义；
这个请求需要经过认证、鉴权以及其它的准入策略检查之后才会放行；
Service 得到一个 ClusterIP（虚拟 IP 地址）并保存到集群数据仓库；
在集群范围内传播 Service 配置；
集群 DNS 服务得知该 Service 的创建，据此创建必要的 DNS A 记录。
总体来说，Kubernetes 的服务注册与发现主要通过 Etcd+CoreDNS 来实现，其中又包含了 endpoints/kube-proxy 等组件的协同。
5.2.3.2 Spring Boot+K8s Service 服务注册发现方案
方案简介：使用 K8s 原生 Service/Endpoints/Coredns/Etcd 等内置资源对象和相关服务组建实现服务注册发现过程，服务注册和服务发现均通过内置 Service 对象完成，借助 K8s Service 的负载均衡能力可减少额外部署和维护服务注册发现中心成本，针对高级流量治理功能需要借助其他服务治理框架实现。
服务注册：Spring Boot 应用配置提供 service 服务，启动后 k8s 集群针对调用该 service，后端会返回具体的 pod 列表。
服务发现：在同一名称空间，直接使用 service 信息发起调用。
方案特点：
优势：负载均衡算法在服务端实现（service 的原生负载均衡算法），后期可使用服务治理框架，例如 istio/linkerd 进行服务治理。
不足：服务直接通过 k8s 服务发现，经过 service 一层在宿主机请求通过 iptables/ipvs 转发一层，性能稍弱。
5.2.4 Spring Cloud Kubernetes 方式
5.2.4.1 通用方案
Spring Cloud Kubernetes 服务注册发现：
服务注册通过 Spring Cloud 应用的 service 资源对象进行注册，服务发现通过项目引入 Spring-cloud-kubernetes-discovery 的 jar 包，利用 Kubernetes-client 与 API-server 进行 Rest 调用获取 Service 后端关联的 Endpoints 信息，通过 spring cloud openFeign 完成服务间的通信，Spring Cloud ribbon 实现负载均衡。采用如上几个模块，可以在 k8s 的环境下实现重试、超时、限流、负载均衡等常用功能。
5.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 应用配置有 service 的服务，启动后 k8s 集群针对调用该 service，后端会返回具体的 pod 列表。
服务发现：通过 Spring Cloud Kubernetes 调用 Kubernetes API-server 获取后端服务 Pod 的 IP/Port。
方案特点：
优势：服务直接通过 k8s 服务发现，获取 service 后的实例 POD IP 和端口，流量直接对 POD 发起，不经过 service 转发，性能高；
不足：负载均衡在调用端(客户端)实现，例如 ribbon，后期服务治理框架如 Istio/Linkerd 可能需改造。
5.2.4.3 Spring Cloud Kubernetes 服务注册发现-南北流量
Spring Cloud Kubernetes 服务注册发现-南北流量：
方案简介：使用 Kubernetes 原生 service/endpoints/coredns/etcd 组建实现服务注册过程，Springboot Gateway 使用 Spring Cloud Kubernetes 与 api Server 的 http 交互，获取后端 服务 Services / Endpoints，完成服务请求转发。
服务注册：Spring Cloud 应用配置有 service 的服务，启动后 k8s 集群针对调用该 service，后端会返回具体的 pod 列表。
服务发现：服务发现通过 Spring Cloud Kubernetes 调用 Kubernetes API-server 获取后端服务 Pod 的 IP/Port，Gateway 进行请求转发。
方案特点：
优势：Gateway 服务通过 k8s 服务发现，获取 service 后的实例 POD IP 和 PORT，从而发起针对 POD 调用，该请求不经过 Service 转发，性能较高；
不足：负载均衡在调用端(客户端)实现，例如 ribbon，后期服务治理框架如 Istio/Linkerd 可能需改造。
5.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 或其他方案解决。
5.4 分布式任务调度
在平台中存在大量定时任务，而且很多服务任务实现方式不一致，一旦遇到问题排错成本高、很难统一管控。针对此困境，我们需进行集中化分布式任务调度平台改造，选用轻量级 xxl-job 中心式的调度平台，不仅开箱即用，而且操作简易、上手快，与 SpringBoot 有非常好的集成且监控界面就集成在调度中心、界面也非常简洁。选取 xxl-job 做调度平台，承担的调度中心职责有：1）负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。2）支持可视化界面，可以在调度中心对任务进行新增、更新、删除，会实时生效。3）支持监控调度结果，查看执行日志，查看调度任务统计报表，任务失败告警等等。4）执行器：负责接收调度请求，执行调度任务的业务逻辑。执行器启动后需要注册到调度中心，接收调度中心发出的执行请求、终止请求、日志请求等等。
同一个服务多个实例的任务存在互斥时，需要统一的调度；
任务调度需要支持高可用、监控、故障告警；
需要统一管理和追踪各个服务节点任务调度的结果，需要记录保存任务属性信息等。
利用其高可用部署在 Kubernetes 集群中，实现分布式任务调度集中管控，可大幅降低开发成本并且提升研发效能，极大程度解决后台任务难管控的问题。
六、SmartOps 架构可观测性建设
6.1 Logging
之前 SmartOps 采用 Graylog 日志监控方案，在代码内部引入日志采集 jar 包，将日志数据收集在 graylog server 端。目前 graylog server 部署在 K8s 集群内，而 Graylog server 使用 MongoDB 和 ES，由于 ES 和 MongoDB 占用 K8s 集群资源，这存在一定问题，本次改造目标为：
日志服务下沉到基础设施层与业务低耦合，业务人员仅需关注自身业务；
日志服务无侵入业务代码；
开发服务适配多语言；
不占用过多 K8s 资源；
打造易维护、扩展性更强的日志监控方案。
业务日志遵循一定规范，如将日志输出到 stdout/stderr，在 Node 上以 Ds 方式部署日志采集 Pod，针对打印到控制台日志进行查看分析。
6.2 Tracing
分布式链路使用了链路追踪的 API 规范，支持多种编程语言，与平台、厂商无关，使得开发人员能够方便地添加或更换链路跟踪系统的实现，虽然 OpenTracing 不是一个标准规范，但现在大多数链路跟踪系统都在尽量兼容 OpenTracing。目前业界主流 API 标准的就有 SkyWalking、Jaeger、Zipkin、Open Telemetry、 Pinpoint、CAT 等。
SmartOps 由于内部服务特殊性，目前选用业界主流 Skywalking 作为 APM 系统服务链路追踪进行日常服务定位及排错。在追踪系统，平台更关注请求的质量和服务可行性，利用其优化系统排查问题。
6.3 Metrics
在 Metrics 方面，主要利用云平台告警结合 Prometheus+Grafana 的方式实现，并配合外部站点探测实现全场景平台 Metrics 指标分析及告警，配合高可用架构及云原生故障自愈能力能最大程度保障系统 SLA。
日志系统、度量系统、追踪系统这三个纬度所关注的重点不同，日志系统用于记录应用或系统事件，日志也是排查问题和取证的主要依据；度量系统更多关注事件聚合，当达到设置告警，关于进行系统状态的反馈及后续的自适应策略；APM 系统帮助我们更深入全面了解环境、可视化整个应用程序和基础架构堆栈，应用场景丰富并且提供全链路追踪。
七、未来方向
7.1 云原生最佳实践原则落实
服务化原则：使用微服务架构，服务内功能高度内聚，模块间通过公共功能提取增加软件复用程度，从架构层面抽象化业务模块关系，标准化服务流量传输，帮助业务模块基于服务流量的策略控制与治理；
弹性原则：系统的部署规模可以随着业务量的变化自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源，而且可以动态扩容，降低企业 IT 成本；
可观测原则：在云分布式系统中，主动通过日志、链路跟踪和度量等手段，让每次业务请求获悉背后服务的调用耗时、返回值，下钻到每次第三方软件调用、SQL 请求、节点拓扑、网络响应，使运维、开发和业务人员实时掌握系统情况；
所有过程自动化原则：通过 IaC（Infrastructure as Code）、GitOps、OAM（Open Application Model）、Kubernetes operator 和大量自动化交付工具在 CI/CD 流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化；
零信任原则：零信任对访问控制进行了范式上的颠覆，引导安全体系架构从“网络中心化”走向“身份中心化”，其本质诉求是以身份为中心进行访问控制；
架构持续演进原则：云原生架构本身应该是一个具备持续演进能力的架构，而不是一个封闭式架构，在演进过程中需注意对新建应用架构控制策略及对遗留系统迁移改造成本考虑及风险评估。
7.2 行业赋能
目前，安畅 SmartOps 混合云管平台已沉淀众多行业客户，在稳定、安全、实用方面赋能不同领域用户进行现代化云上管控：
在互联网行业，SmartOps 可以颠覆传统的基础设施及运维模式，带来了可编排、极速全局管控、自服务运维的能力；
在教育行业，借助 SmartOps 的资源纳管能力和资源抽象能力，助力高校填补公有云技术迭代与高校技术管理人员技能间的鸿沟，打破院级/科系数据孤岛，面向高校用户提供统一的服务目录；
在政务行业，SmartOps 支持国产化部署，满足基础设施自主可控，以平台的实时统一监管、宏观调度、审计等能力，帮助客户降低成本和运维压力，实现不同部门统一规范，推动跨部门业务协同；
在工业领域，基于 SmartOps 预算管理、资源交付、资源运营能力，大幅提升资源的交付效率及资源使用率，从而降低项目成本。
7.3 架构演进策略
近年来商业世界的发展趋势，数字化转型的出现使得企业越来越多业务演变成数字化业务，数字化对于业务渠道、竞争格局、用户体验等诸多方面都带来更加严苛的要求，这就要求技术具备更快的迭代速度。架构的演进不是一蹴而就，而是不同时期为了更好的支撑业务发展进行适配发展的行为，为了技术而进行不合适的过度架构设计是不负责任的行为，将业务与架构共同朝着既定目标共同成长才是最佳策略。如果您企业的数字化转型之旅需要一位专业的伙伴，那拥有海量云上最佳实践的安畅或许是您最好的选择！
还未添加个人签名 2022-12-29 加入
还未添加个人简介
评论