2023 平台云原生演进痛点与探索，围绕 SmartOps 平台展开，IDC FutureScape 2022 中国云计算市场预测中，应用现代化位列 Top1，到 2025 年，数字经济将催生出超过 5 亿个新应用/服务，90%的应用程序将是云原生应用程序，大多数遗留应用将实现一定程度的现代化改造。SmartOps 是一款 SaaS 模式的云管理平台，通过统一视角实现多云资源纳管，权限分配、通过监控、费用分析帮你更合理的管控费用支出，加上强大的审计、工单、运维自动化等功能帮助你更高效的管理云资源。
利用云原生技术为企业应用现代化改造提供工具平台建设、落地实施 &咨询服务，覆盖基础设施现代化、架构现代化、开发运维现代化、数据现代化、安全现代化五个维度，推动企业应用现代化改造，加速企业数字化转型。
应用现代化是指将系统、流程、工具、方法等更新为最新或者最佳实践的做法，就好比对“老房子”进行全新装修升级，在云计算盛行的背景下，实现应用现代化最佳实践就是通过云原生技术对现有应用进行升级改造。
2.1 应用现代化的价值
应用现代化的价值可以从创新、效能、弹性、安全这四个维度来体现。
-
加速创新：让企业更专注于业务本身，减少试错时间和成本，从而让企业获得更快速的创新能力。
-
提升效能：通过自动化工具、敏捷方法论、高效研发流程，过程中不断的发现问题、解决问题， 持续提升团队效能。
-
弹性可控：从基础设施弹性、技术框架弹性、应用弹性保障应用的极致弹性能力。
-
安全可靠：基于云安全能力从基础设施、开发运维等实现安全前移、安全内置， 结合高可用设计、性能监控、灾备、 灾难恢复等自动化实现应用高安全、 高可用、高可靠。
2.2 痛点与破局
SmartOps 随着平台支撑客户的增长，在安全、性能、稳定性、产品迭代速度等方面都提出了更高的要求，应用现代化则为 SmartOps 提供了解决方案，SmartOps 在应用现代化过程中遇到的部分痛点如下：
2.2.1 服务拆分难
微服务架构演进过程中经常会遇到两个常见的问题：1. 微服务框架，2. 微服务拆分。技术框架的选择基本理清楚当前技术、人员、组织结构现状，各类技术框架的优缺点、业务发展方向等一系列问题后就可以做出决定。然而微服务如何拆分这在业内也是老大难问题，虽然业内也有拆分方法论（如：康威定律、领域驱动设计 DDD），但是实际落地过程中还是非常有挑战的。
以 SmartOps CMP 服务为例，CMP 服务原先包含了资源管理、费用管理、服务过程管理、用户权限管理、合同和客户管理等相关功能，拆分前存在的一些问题：
拆分之后每个服务只负责 1 个模块的核心业务，服务中的代码量减少很多，基本上通过查看项目中的类文件就能对服务有基本了解，同时阅读和修改代码所涉及的影响也容易把控，并且编译和部署速度也得到很快提升，基本上都是在 10～20 秒左右（提升 10 倍以上），同时由于不同服务提供不同功能，对于特定功能的发布也更容易控制，发布影响的业务范围也更小。
2.2.2 环境一致性差
SmartOps 有 Dev/Test/Prod 环境，在最开始多个服务以 Jar 包部署在主机上，通过简单的 Jar 启动，或者 Supervisor 监控维护单进程，但是在不同环境，系统表现出不同异常，混乱不一致的环境导致不同部门及开发和测试直接耗费非常大的精力排查测试，很大程度拖慢了产品迭代速度，通过应用容器化，将微服务及其所需的所有配置、依赖关系和环境变量打包成容器镜像，确保 Dev/Test/Prod 均采用容器部署，使得经过 Test 的镜像可以保障线上环境的一致性，从而极大的提升了产品迭代速度。
2.2.3 非业务组件维护成本高
SmartOps 在进行微服务拆分前期架构使用 Spring Cloud Consul 服务注册发现方式，使用 Spring Cloud Config 配置中心方式，服务注册发现需要独立在不同环境维护多个 Consul，在生产环节维护 Consul Cluster 成本比较高，需要独立自建集群，且集群的安全、性能、监控等都带来了极大挑战，这些运维工作对业务的帮助不是很大，而且是整体系统服务注册发现的核心，如果该单点出现异常，整体系统将不可避免发生故障，由于已经使用到了 Kubernetes 进行容器编排，因此将一些非功能性需求进行基础设施下沉，利用 Kubernetes 原生的服务注册发现与配置中心，该方案避免厂商锁定，而且下沉基础设施后，无需额外投入维护其他组件，释放更多效能赋能业务系统开发。
云原生技术的三大支柱：微服务、容器、DevOps，微服务解决了单体架构的局限性，容器解决了虚拟机部署的局限性，然而微服务带来了好处的同时也让部署运维工作更复杂，DevOps 通过工具链连通了微服务与容器，在整个应用现代化的过程中，微服务、容器、DevOps 三者密不可分。
工欲善其事、必先利其器，应用现代化的过程往往依赖一系列高度集成的 DevOps 工具链， DevOps 工具链贯穿了应用的全生命周期，覆盖从需求、设计、开发、测试、部署、运维各个环节。根据不同阶段对应的工具链可以分为：项目管理工具、源代码管理工具、测试管理工具、持续集成工具、持续部署工具等类型。
在应用现代化过程中， DevOps 工具链最直接的一个体现就是自动化，通过不同阶段的工具集成，可以让开发、测试、部署的动作完全自动化，如：开发人员提交代码，触发持续集成、代码扫描、自动化测试、生成制品、部署等操作，过程无需人工干预，大大减少了日常开发过程中的重复劳动，解决了微服务数量增多带来的复杂度问题。
在当前大背景下，各大企业都在强调效能，研发效能指的是更高效、更高质量、更可靠、可持续的交付业务价值，如何提升效能成为了重中之重，从工具链出发很多时候是一个很好的切入点，合适的工具带来的效能提升是能在短期内快速体现。《软件研发效能提升实践》一书中提出了“研发效能提升的双流模型”， 其中不管是价值流还是工程流，其底层少不了工具平台的支撑，“一体化”的工具平台为研发效能的提升打下了坚实的基础，同时也能加快研发效能提升的进程。
3.1 DevOps 1.0 阶段工具链
使用 Gitlab 进行代码托管，CI/CD 直接使用 Gitlab CI 来做，在部署阶段利用 kubectl 镜像进行容器编排操作。
- GitLab：主要利用 Gitlab 进行 CI/CD 管控和容器部署；
- CICD：各业务代码仓库保护 .gitlab.yml，利用 Gitlab CI 进行 CI 和 CD 过程；
- 镜像管理：构建出来的镜像使用镜像仓库 Harbor 进行管理；
- 容器编排：在 CD 过程中，利用 kubectl set image 进行容器编排部署，自建 Kubernetes 集群进行业务容器编排管理；
3.2 DevOps 2.0 阶段工具链: DevSecOps
在原始 CI/CD 流程中缺乏安全方面全场景检测，在代码、镜像、环境配置等场景均存在各类安全风险，因此必须实行安全左移。
在这一阶段，重点针对 CI/CD 中的安全进行了增强，可以分为五个阶段：
-
第一阶段：威胁建模(场景分析)梳理并绘制软件生命周期可能引发安全问题的场景；梳理平台架构存在安全风险的部件以及敏感数据的流向，帮助全员建立安全模型并提升团队安全意识。
-
第二阶段：通过安全扫描( DevOps 集成安全)评估代码安全风险，确保不存在安全漏洞,此处包括手动和自动代码审查,在此步骤中，使用了 Lint 和 Scan 等 AppSec 工具。由于处于软件开发生命周期的早期，此阶段允许工程师解决大多数安全漏洞和缺陷。
-
第三阶段：针对工具检测出来的安全风险问题以可视化的方式呈现并进行周期性通知，让全员知道安全问题。
-
第四阶段：进入补救修复阶段，通过代码静态扫描工具（SAST）可以针对发现的漏洞、缺陷提出修复建议，这样的操作是为了在出现安全问题时更容易处理它们。
-
第五阶段：进入监控阶段，跟踪监控发现的漏洞，努力减轻或消除他们，并对应用程序进行安全评估。通过跟踪和管理风险，在软件生命周期中作出决策对安全风险进行持续性安全实施。
3.3 DevOps 3.0 阶段工具链: SecDevOps + GitOps
- 开发阶段：从安全意识培训、安全编码、代码静态扫描到最后进行提交代码 Code Review，将安全左移到研发全流程中（安全性已成为软件生命周期不可分割的一部分，所以进一步向左转移安全性，SecDevOps 而非 DevSecOps）；
- CI/CD：通过 Gitlab+Drone CI+Argo CD 进行持续集成持续部署，其中代码单元测试可以利用代码及配置检测工具进行代码扫描，实现合规检测；
- 制品管理：利用镜像安全工具对制品镜像进行分层安全分析及漏洞安全扫描，确保镜像 layer 安全可控；
- 容器管理：利用 kube-bench/kubeEye/kube-eventer 等对容器集群、业务容器进行合规检测与异常事件告警；
- 业务管理：进行持续性 MSS 运维，利用 Nessus/Acunetix/AppScan 等业务系统进行安全漏洞扫描以及持续性安全运维。
这一阶段中着重提升了 CI 效率和 CD 的安全性，利用基于 Kubernetes 的声明式 Gitops 持续部署工具 Drone CI + Argo CD，可以更便捷地进行应用定义、环境配置和变量管理。代码及配置资源声明清单也都存储在代码仓库受版本管理，使得应用发布及生命周期管理实现自动化且具备可审计性。
在云计算的后半场，各种共有云平台都提供了丰富的产品资源，涵盖了从基础设施层到开箱即用的 PaaS/SaaS，以及各种工具和人工智能（AI）功能。作为云运维支撑平台的 SmartOps，在不断深入了解具体云资源和运维业务场景的基础上，23 年将成为补充云技能的关键一年。为了更好地服务用户并洞察企业常见的服务需求，提升自身技能，你已经获得了国内阿里/腾讯/华为等厂商的认证。在今年，你的主要目标是获得 Azure 305/400、AWS SAP C02/DOP C02、TF-003 等云厂商的认证，以便更好地比较不同厂商的特性，并为 SmartOps 平台的迭代发展提供技术支持和场景洞察。
技术架构中随着业务的发展，还面临着不少的瓶颈与缺陷，需要根据业务需求和技术需求不断平台，希望 23 年更跟近一步，充分赋能业务，共同朝着既定目标共同奋进。
infoq原文链接：2023 平台云原生探索与实践