1. 前言

在当今数字化浪潮中，云原生转型是企业提升竞争力、实现创新发展的必由之路。然而，云原生转型并非一蹴而就，其中应用上云是决定转型成败的关键环节。应用上云涵盖了将企业现有的平台工程体系与云端对接;也涵盖了业务系统迁移到云底座上，以充分利用云的弹性、可扩展性和高效性等优势。但在实际推进过程中，面临着技术架构适配、数据安全保障、业务流程重塑等诸多难题。本主题聚焦于云原生转型中平台工程上云工程的应用，结合实际工作中的挑战，探索最佳实践与解决方案，助力企业顺利跨越 “最后一公里”，实现云原生转型的目标。

2. “最后一公里”

笔者早年曾任职于国内一家颇具规模的大型通讯企业，在新通讯技术普及与推广过程中，通讯运营商的核心设备和主干网络的替换往往不是最具挑战的，而从通信运营商的通信基站、交换中心等网络节点到用户终端设备之间的最后一段通信连接问题才是方案的重点，这段距离虽然相对较短，但在实际操作中却面临着诸多困难和挑战，影响着通信服务的质量和普及程度。这个就是所谓的“最后一公里”问题。

“最后一公里”问题不仅仅是在通讯，也在其他领域普遍存在。最后一公里”通常用来指代在各种系统或流程中，将产品、服务、信息等从相对集中的节点或环节传递到最终用户或目的地的最后一段关键距离或环节中所面临的一系列困难和挑战。最后一公里问题的症结在于用户需求的多样化、成本效益和用户的配合度低。

3. 云原生转型的“最后一公里”问题

3.1. 云转型“三步走”

企业的云原生转型堪称数字化转型进程中的一项庞大且复杂的体系工程。它并非单一维度的变革，而是涵盖了云基础平台建设、云平台适配以及应用上云等多个关键环节。

1)云基础平台建设作为转型的基石，这一阶段是整个云原生转型的整体技术选型，既可以建设私有云，即企业依据自身业务需求与安全标准，构建专属的云环境，确保数据的安全性与隐私性，为核心业务提供坚实的保障;也可以租赁公有云，借助公有云的规模效应与成本优势，满足企业一般性业务需求，实现资源的高效利用与快速部署。这一阶段有相对成熟的解决方案和案例。

2)云适配则是让云平台与企业现有管理流程、架构深度融合的关键步骤。它要求企业对自身的管理流程进行梳理与优化，确保云平台能够无缝对接，发挥最大效能。第一阶段如果说可以直接应用业界成熟的解决方案，这个阶段就是个性化定制，既要保留最佳实践，又要符合行业组织对于流程、安全和合规的要求。

3)应用上云，作为整个云原生转型的最终目标，无疑是最为关键的一步。应用成功上云不只是把应用简单的部署在云上，而是能够充分利用云计算的弹性、可扩展性等优势，实现业务的敏捷创新与高效运营，为企业在数字化浪潮中赢得竞争优势。

3.2. 云转型的“最后一公里”

企业云原生转型也存在“最后一公里”问题。云基础平台建设是个基础能力，但是在整个云原生转型的过程中，是相对容易解决的。外购云平台或直接使用公有云的优势在于可以快速构建云基础能力，引入最佳实践。但是完成云基础设施的建设只是完成了云原生转型的百分之二十，剩下的百分之八十的工作，是云适配和应用迁移上云。

云适配和应用上云是相互关联相互促进的，这一环节需要企业将各类应用系统迁移至云环境，不仅要解决技术层面的兼容性、稳定性等难题，还要克服组织架构、人员习惯等方面的挑战，堪称上云工程的 “最后一公里”。实际在企业中，云采用框架的落地存在诸多的问题：

1)用户需求的多样化。从行业类型角度看，不同行业的企业有着独特的业务特性和运营模式，对于云原生的诉求也大相径庭。对于银行业核心系统，数据的一致性和核心系统的稳定性是第一需求;对于互联网金融，系统的高并发和弹性伸缩也是需要一并考虑的;对于某些敏感数据的行业，合规审查和数据安全在上云中也是重要考量点。另外每个企业现有的研发运维工具体系也存在差异，需要和云原生应用实践相结合。

2)用户的配合度。开发团队长期习惯传统开发模式，对云原生技术的理解存在偏差，存在认为其学习成本高的普遍现象，因此对云原生应用转型积极性不足。同时云应用和传统应用的技术架构存在一定的差异，部分开发团队希望能够在不改变现有架构和开发习惯的基础上实现上云，导致不好的上云体验。

3)安全问题。云是一种公用的基础设施，资源的管理方式和数据传输存储和传统存在很大的差距。在数据保护、合规性和法律风险、身份和访问管理问题和业务连续性风险等方面都存在很多挑战。

4)成本效益。上云的成本包括应用上云改造、配套工具和流程的改造等的显性成本，也包括新技术的学习的隐性成本，同时云资源的过渡使用也是上云的一项显著的成本。上云的价值需要应用云原生化改造配合才能够体现，上云的过程就是要尽量的提升云原生的成熟度，充分发挥上云的价值，提升应用上云的获得感，抵消上云的成本。

3.3. 云采用框架

这个领域已经受到越来越多的重视，大多数的大型公有云厂商提供了针对公有云应用上云的解决方案，也有很多专业的公司为私有云提供应用上云的解决方案。包括：

AWS Cloud Adoption Framework (AWS CAF) 利用 AWS 经验和最佳实践，通过创新性地使用 AWS 来帮助您实现数字化转型并加快业务成效。它侧重于支撑成功云转型的具体组织能力。

谷歌云迁移中心(Cloud Migration Center)：谷歌云的这项服务为企业迁移到谷歌云平台提供了一系列工具和指南。它能帮助企业评估现有应用和基础设施，识别可迁移到云端的部分，并提供迁移路径规划。

阿里云云原生架构实践指南：阿里云结合自身云服务特点和云原生技术，为企业提供架构设计和实践指导。该指南强调云原生技术在构建弹性、高效应用方面的优势，帮助企业将传统架构逐步向云原生架构演进。

云采用框架是应用上云最佳实践的总结，对于应用上云有很好的参考和指导作用。云采用框架和指南从以下的几个方面解决最后一公里问题。

1)资源组织：是组织架构和云的特性相匹配，最大程度的减少内耗。

2)技术采用：通过技术改造使业务系统适应现代化传统基础设施，提高可靠性、增强安全性和提高性能来降低业务风险 。

3)流程改进：优化现有的开发流程来配合云迁移，从而获得敏捷性、灵活性和数据安全性。

4. 云原生转型的优秀实践

4.1. 研发赋能-平台工程

平台工程是一种专注于设计、构建、维护和改进软件开发和交付所使用的工具链及工作流的专业学科。应用上云的平台工程对云的特性进行了对接和封装，实现工具体系的对接和流程的连接，为业务开发人员提供一套自助式内部开发者平台。Gartner 预计到 2026 年，80% 的大型软件工程组织将建立平台工程团队，作为应用交付的可重复使用服务、组件和工具的内部提供者。通过平台工程支持上云的优势在于：

降低上云门槛，提升上云体验

规范上云流程，落地上云规范

提升交付效率，加速价值交付

在组织内部进行平台工程的建设时，为了能够充分发挥平台工程的功能，遵循以下的建议：

1)将平台作为产品进行运营，指定一个产品经理来分析用户的痛点

2)由专职的平台团队负责策划和构建。

3)平台必须自服务方式提供

平台工程是以面向应用维度的平台，服务的对象是应用开发人员，通过web和IDE插件的方式，将应用创建，编码，测试，部署到运维的整个流程整合到一起。以下是一个平台工程的应用架构实践。

在这个实践案例中，云原生应用管理平台对接了DevOps平台，运维管理平台，PaaS和云平台。开发人员只需要在熟悉的工具中(IDE或浏览器)中，就可以实现工程创建，流水线创建，云服务申请，多环境应用发布，灰度发布，变更申请和生产环境的运维监控。

4.2. 交付提效 - GitOps

GitOps 这个概念最早是由 Kubernetes 管理公司 Weaveworks 公司在 2017 年提出的。GitOps可以说是IaC+自动化部署方案的Plus版本，它的核心是使用 Git 仓库来管理基础设施和应用的配置文件，并且以 Git 仓库作为基础设施和应用的单一事实来源，你从其他地方修改配置(比如手动改线上配置)一概不予通过。

基础设施即代码(Infrastructure as Code, IaC)是一种代码来定义、部署和管理基础设施的方法。基础设施即代码将传统的基础设施操作转化为代码操作，使基础设施的创建、配置和管理等工作可以像软件开发一样，通过编写代码来实现。IaC通常采用声明式编程，声明式编程指明目标状态，不关注实现过程，可以实现应用开发和部署过程的解耦。

Git是是一个开源的分布式版本控制系统，最初是由 Linus Torvalds 在 2005 年为辅助 Linux 内核开发而创建，目前已经发展成为最主流的代码管理系统。

Git的版本控制和分支管理能力结合IaC，为云应用提供了快速的多环境部署、灰度发布和快速回滚的能力。通过自动化部署的方式，降低了云应用部署的复杂性，减少因为手工操作的错误。同时能快速创建、修改和调整基础设施配置，快速响应业务需求变化，在不同环境中快速部署和迁移基础设施。

使用GitOps实现云应用的部署发布，重点在于自动化能力的建设。部署引擎用于解析部署IaC文件，将制品仓库中的应用根据声明式的部署文件的描述，推送到运行环境汇总。

4.3. 安全提升 - 基于服务网格的零信任架构

上云系统的安全一直是上云评估中备受关注的问题，传统的主机应用的业务数据都在独占的物理设备中，内部传输和存储受到的安全威胁低，只需要守住边界，就可以保证安全。但是云是一个多用户的环境(即便是私有云，也会运行不同的业务系统)，内部传输和存储都存在风险，对于安全等级高的系统该如何上云，是目前上云进程遇到的一个问题。

云应用目前遇到的问题和零信任模型解决的问题存在很大的相似。零信任的最早雏形源于2004年成立的耶利哥论坛(Jericho Forum )，其成立的使命正是为了定义无边界趋势下的网络安全问题并寻求解决方案。在《零信任网络》一书中，埃文.吉尔曼(Evan Gilman)和道格.巴斯(Doug Barth)将零信任的定义建立在如下五个基本假定之上：

网络无时无刻不处于危险的环境中。

网络中自始至终存在外部或内部威胁。

网络的位置不足以决定网络的可信程度。

所有的设备、用户和网络流量都应当经过认证和授权。

安全策略必须是动态的，并基于尽可能多的数据源计算而来。

这几个假定刚好与我们应用云上的问题相一致，因此产生了零信任架构。零信任架构(Zero Trust Architecture)是一种网络安全模型，旨在通过消除默认信任、实施严格的访问控制和持续验证，来增强组织的网络安全。零信任与传统的安全模型存在很大不同，传统的安全模型通过“一次验证+静态授权”的方式评估实体风险，而零信任基于“持续验证+动态授权”的模式构筑企业的安全基石。零信任架构的设计要点：

持续验证：用户和设备的身份验证不仅仅在登录时进行，而是在整个会话过程中持续进行。这意味着即使用户已经登录，系统也会定期重新验证其身份和权限。

最小权限原则：用户和设备仅被授予访问他们当前任务所需的最小权限。这减少了潜在攻击者在成功入侵后能够造成的损害。

设备和网络无关性：不使用源地址作为唯一的安全校验标准，对于请求都需要经过相同的验证和授权过程。

数据保护：所有数据传输都必须加密，确保即使在网络被入侵的情况下，数据也不会被窃取或篡改。

服务网格(Service Mesh)是一种用于管理微服务架构中服务间通信的基础设施层。它通过在服务之间添加一个透明的通信层，提供了服务发现、负载均衡、监控、安全、流量管理等多种功能，帮助开发者更轻松地构建和管理复杂的分布式系统。服务网格可以降低安全的威胁，包括：

服务模拟：行为不端的人会获得您的应用程序对专用网络的访问权，冒充是授权服务，并开始请求敏感数据。

未经授权的访问：合法服务会请求未经授权的敏感数据。

数据包嗅探：不良行为者可以访问您的应用程序专用网络，并从通过网络的合法请求中捕获敏感数据。

数据泄露：不良行为者将敏感数据从受保护的网络发送到他们选择的目的地。

零信任架构是一种安全模型，和服务网格的结合，可以避免对应用的过渡侵入，实现安全、性能和复杂性的平衡。

系统采用微服务架构，服务网格作为零信任模型的控制面，通过以Sidecar的方式 提供网络代理，对系统间的访问流量进加密。对于访问的权限控制则通过认证服务进行控制，对每个网络的访问的token进行有效性校验，确保访问的安全。全局安全策略可以对服务网格的安全策略进行配置和监控，实现实时阻断。

5. 总结

云原生转型是一个持续的迭代的过程。在上云的过程根据反馈，不断的优化工具平台和流程，吸取经验，提升应用架构设计能力，才能在真正实现云原生。除了文中提到的平台工程和零信任架构外，还有其他一些实践可以参考，比如已经被广泛接受的DevOps实践，还有近年开始流行的AIOPs等，这些技术都是为了解决应用声明周期的问题而生。根据自身的实际问题，有计划的灵活的引入这些技术，可以使应用上云过程事半功倍。最终实现云原生助力业务转型的目标。