深度解读|持续拥抱云原生 加速企业应用现代化
Posted 安畅网络
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了深度解读|持续拥抱云原生 加速企业应用现代化相关的知识，希望对你有一定的参考价值。
怎么样让运转的旧系统和新应用之间做到无缝衔接？如何快速敏捷地完成应用的集成，以提高可持续的交付能力？如何在混合多云环境下，最大程度的降低架构转型的技术风险?
应用现代化是许多推进数字化转型进程中的企业所共同面临的挑战。本文将从从定义、价值、实现路径等角度深度解读现代化应用以及企业如何实现应用现代化。
帮助企业构建现代化应用
01 什么是现代化应用？
现代化应用是一种弹性的、支持多云的微服务架构，由虚拟机、容器和无服务器功能的协调发布组成。一个应用应该从不同的角度（比如构建、运行、管理、连接和保护）具有某些特质，才能称作是现代化的应用。应用现代化是指把应用改造为现代化应用的过程。
现代化应用既要能快速响应变化，又要能快速交付使用，这就要求我们的应用系统是弹性的，可以快速扩容，同时也能对故障进行容错，为了快速交付，系统架构必须要能够解耦，这就要求我们采用微服务架构、采用 DevOps CI/CD流水线等，同时企业客户为了避免厂商绑定、实现高可用等原因也需要能够支持多云部署，这就要求我们采用虚拟机、容器、无服务器等方式解耦应用和基础设施。实现企业应用现代化可以从根本上应对业务、技术的飞速发展做带来的挑战，为用户提供切实的价值。
02 应用现代化服务的价值
根据 VMware 的市场洞察报告显示，目前有72%的企业重视为现有应用构建转型之路，即通过对云原生的应用体系架构进行现代化改造和重构，以便在多云环境下开发混合云应用。
企业进行应用现代化改造将获得哪些收益呢？
降本增效
传统巨石应用迁移上云，通过云计算基础设施大大节省了前期的采购成本和后期的运维成本、按需付费，同时通过采用 DevOps 理念，引入CI/CD流水线工具极大的提高了研发效能。
敏捷交付
现代化应用结合敏捷软件开发方法，通过容器技术、微服务和DevOps工具链能快速建立自动化流水线，加速企业应用快速交付，同时可以实现在快速交付的过程中保障交付质量，持续学习和改进。
弹性
通过微服务架构对传统单体架构进行解耦，让各个服务保持灵活性，针对当前业务场景下的潮汐流量、流量洪峰等场景可以快速针对性的进行服务扩容。
容错
分布式微服务架构由于其本身特性，故障是不可避免的，所以微服务架构在设计角度就考虑了如何容错，尽可能实现在保障整体可用的前提下限制故障范围，实现故障自愈。
服务自治
采用容器编排框架，可以管理成千上万的应用容器，当某个应用出现故障时，编排系统能够及时发现并自动摘除问题应用，同时智能调度到有效资源上，保证了应用系统的稳定运行。
基础设施解耦
屏蔽底层异构资源，基于容器的PaaS平台兼容屏蔽底层基础设施、负载均衡、网络、存储等异构资源，为云及业务应用系统提供统一的PaaS能力。
应用更轻、更快、更强
相对于虚拟机方式，容器部署方式更轻量级，能够快速启动、CPU 资源利用率更高。
信创生态
国产化云原生技术和生态体系，持续建设包含容器化技术、编排技术、监控告警技术、网络技术、日志技术等，支持国产信创的云原生平台。
03 应用现代化过程中的挑战
不同企业实现应用现代化的路线各不一样，例如：有先进行容器化改造的，有先做微服务架构改造的，也有直接在上云迁移的过程中同步实现微服务改造的，另加之企业内部环境各不一样，所以企业在实现应用现代化进程中遇到的挑战也不尽相同。
归根结底，应用现代化改造过程中离不开软件架构、开发模式、部署方式三个纬度的改造，结合应用现代化的概念从技术特征表现来讲就会涉及到微服务、容器、DevOps，接下来我们从这三个角度来看实现应用现代化的过程中所遇到的一些的挑战：
挑战一：微服务
微服务架构：如何搭建整体的微服务技术架构，如何做技术选型？
微服务拆分：服务拆多大合适，服务边界怎么识别？
架构迁移：迁移的过程中如何在保持现有业务支撑的情况下平滑过渡？
挑战二：容器
容器虽好但也不是银弹，容器化迁移过程中也会遇到很多问题，例如：资源规划，迁移策略，不完整隔离带来的调优复杂性、镜像化的系统环境，语言版本的差异问题、容器安全等问题。
挑战三：DevOps
DevOps 融合了敏捷开发、持续交付、技术运营等，企业落地 DevOps 过程中涉及从人、工具、文化的变革，各个环节牵一发而动全身，比如：如何在企业内部推动敏捷软件开发？如何建立DevOps 工具链？工具链选开源还是商用平台？如何建立DevOps 文化？
实际在应用现代化的过程中除了上述列出的这些挑战，同时也因为应用现代化的过程不同会有各种各样的问题，基于应用现代化所面临的这些挑战，我们在帮助企业实现应用现代化的过程中也做了很多探索与实践。
安畅持续拥抱云原生
携手信通院发布多个云原生标准
01 国内首个云原生成熟度模型落地
安畅与信通院携手其他行业企业制定的国内首个云原生成熟度模型标准体系正式发布，针对行业性的成熟度给出了规范指南。同时，安畅网络CTO张玮获得信通院授牌的"云原生成熟度专家顾问"称号
▲云原生成熟度专家顾问授牌（右四为安畅CTO张玮）
云原生成熟度模型是基于云原生构建的业务应用的能力成熟度评估模型，覆盖IT架构的全栈技术能力建设，是一套体系化的方法论、实践和标准的集合。从功能上看，云原生架构成熟度模型从基础设施域、应用研发域、服务治理域以及组织管理域等四个方面评估云原生业务应用在弹性、高可用、自愈性、可观测性以及自动化等方面的云原生能力成熟度。
云原生能力成熟度模型主要包括三大板块，分别是：云原生技术架构成熟度评估标准、云原生业务应用综合成熟度评估标准、云原生平台安全能力要求。
云原生应用的落地，会随着业务逐渐复杂，服务数量越来越多，引入的问题也越来越复杂。如何在业务发展的同时保障服务的 SLA 和最大化利用机器资源，是摆在微服务应用面前一个很大的挑战。我们需要一个统一的服务治理机制对所有服务进行统一管控，保障服务正常运行。
云原生成熟度模型的服务治理范围覆盖了服务的整个生命周期，从服务建模开始，到开发、测试、审批、发布、运行时管理，以及最后的下线。云原生成熟度模型涵盖以下服务治理能力：
架构级别的基础服务治理能力，如：鉴权、限流、路由、容错等。
客户端主动健康检查和熔断策略来屏蔽故障实例/服务。
根据地域、环境类型进行流量调度。
具备架构级别全面的服务治理能力，对业务弹性、系统可观测性以及自动化部署、运维等能力进行全面支持。
通过自适应的负载均衡、故障转移策略来提升异常情况下服务调用的成功率。
完备且成熟的服务治理能力，开始应用智能化的治理手段。
通过全局的监控来实时自动地发现和处理异常的实例/服务。
智能化的流量调度，自动化切流能力。
治理颗粒度不仅包括应用单元下实例级别的治理，还要支持以接口为级别的治理，同时也能支持不同治理粒度的混合治理能力。
02 微服务拆分标准落地，为服务拆分提供正式实践指南
《微服务拆分设计规范指南》（以下简称“指南”）标志国内首次有了可用于微服务拆分实践的正式指南。安畅作为指南起草单位之一，提供了包括微服务适用范围、参考组织架构、实施途径、开发规范、拆分案例等在内的大量内容，并得到了专家的一致认可。
目前企业上云主要有两种形式：直接上云和改造后上云，针对后者其中最主要的工作是将应用进行微服务化，针对大型复杂应用的开发，为了应对高并发和保证业务连续性，越来越多的系统采用了微服务架构。
不过，尽管微服务架构已发展了一段时间，用户在使用过程中依然存有诸多问题：微服务应该有多大？微服务应该怎么拆？这些看似最简单的问题由于一直没有定论，一直困扰着正在和将要使用微服务架构的用户。而指南的发布在一定程度上，从行业的视角上提出指导意见，为微服务架构的大规模应用奠定了基础。
安畅参与指南编写的资深微服务架构师樊超认为：指南中包含微服务拆分的六大原则和五个视角，六大原则分别是：围绕业务建模、微服务自治、去中心化、可独立部署、单一职责和最终一致性。五个视角分别是：应用架构、数据架构、技术架构、部署架构和应用质量体系。通过使用原则和视角，进一步给出了微服务拆分的方法和步骤，为了确保每个步骤能够真正落地，还为每个步骤提供了实践案例。除了拆分方法外，微服务架构的使用还面临着从企业文化、组织架构、流程规范等企业管理方面到研发体系、基础设施、技术能力等技术方面的多重影响。
除了拆分方法外，微服务架构的使用还面临着从企业文化、组织架构、流程规范等企业管理方面到研发体系、基础设施、技术能力等技术方面的多重影响。所以在《指南》中，对这些方面也有着深入的讨论。内容中提到：组织架构参考模型；接口规范、源码管理、部署管理等多个开发规范；运维能力评估等多个参考和建议。为微服务架构的落地提供了全面的指导。
应用现代化服务路径
应用现代化旅程有许多不同的路径， 无需在云中重新生成应用程序。可以重新托管应用程序，将其从本地服务器移至 IaaS 环境，使用PaaS、SaaS能力，也可以使用容器重构或采用微服务架构重新架构应用程序。实际过程中这些方式可以分开也可以同时进行，主要还是看企业的目标、决心以及现状，接下来我们从容器、微服务、DevOps、不可变基础设施角度来看应用现代化的实施过程。
01 采用容器技术
对于一家创业公司而言，常常有三个问题摆在面前：
如何高效、低成本地搭建系统，同时确保安全稳定？
如何敏捷构建和发布应用，满足业务需求？
如何提高团队开发效率，确保开发质量？
将应用“容器化”的过程，就是让应用能够运行在 Docker 容器或类似技术中，它们能将操作系统环境和应用封装在一起（完整的系统镜像）。由于容器能给应用提供近似于完整系统的环境，这就为在不修改，或者少量修改应用的情况下，对应用的部署进行现代化改造提供了一种思路。这也是应用的架构持续能保持“云友好”的基础。
容器化的好处：
-
部署更容易，使用新的容器镜像直接替换整个老版本。自动化部署也相对容易，甚至可以完全由 CI（Continuous Integration, 持续集成）来驱动。 -
部署失败时的回滚只要切换到之前的镜像。 -
应用升级更容易，因为现在没有可能出错的“中间步骤”了（不管它是否影响整个部署过程的成功）。 -
相同的容器镜像可以在不同的环境中充分测试，再直接部署到生产环境。这可以确保测试态与生产态的产品是完全一致的。 -
系统更容易从宕机中恢复，因为可以迅速在新硬件资源上启动装有这个应用的新容器，并附加到同一数据源上。 -
开发人员能在本地以容器的形式，在更逼真的环境里测试新功能。 -
硬件资源的利用更高效，在单一主机上现在可以运行多个容器应用，而以前不能。 -
·容器化是支持零停机升级、金丝雀部署、高可用和横向扩展的坚实基础。
▲容器化改造整体实施路线
02 采用微服务架构
从本质上来看，相对单体应用，微服务是以牺牲强一致性、提高部署复杂性为代价，换取更彻底的分布式特性，比如异构性和强隔离性。对应CAP理论，就是用Consistency换取Partition。异构性比较容易理解，通过定义统一的API规范（一般采用REST风格），每个微服务团队可以根据各自的能力矩阵选用最适合的技术栈，而不是所有人必须使用相同的技术栈。强隔离性指的是，对于一个典型的单体应用，隔离性最高只能体现到模块级别，由于共享同一个代码仓库，模块的边界往往比较模糊，需要人为定义很多规范来保证良好的隔离性，但无论如何强调，稍一疏忽，就会产生“越界”行为，时间愈长，维护隔离性的成本愈高。而到了微服务阶段，自带应用级别的隔离性，“越界”的成本大大提升，无需任何规范，架构本身就保证了隔离性。
另一方面，由于采用了分布式架构，微服务无法再简单的通过数据库事务来保证强一致性，而是通过消息中间件或者某种事务补偿机制来保证最终一致性。其次，在微服务阶段，随着应用数量的激增，一次发布往往涉及多个应用，加上异构性带来的部署方式的多样性，对团队的运维水平尤其是自动化水平提出了更高的要求，运维和开发的边界进一步模糊。
开发者需要思考：到底应该在应用的什么阶段使用微服务架构？
微服务化改造原则
单个服务内部应该是高内聚低耦合的，也就是单一服务内部应该只做自己相关的事情，不是自己职责的功能交由其他服务完成，服务之间应该有明显的边界。
微服务化改造应该是边改造边支持业务的发展的，不能为了改造而停止业务的迭代。因为要是停止了业务的迭代，那么等你改造完，可能已经被竞品超越了，从而丧失了市场的机会，最终可能是竹篮打水一场空。
微服务提供的接口应该是可扩展的，变更接口后应该兼容以前的接口。因为其他服务可能还在用旧接口，你的服务可能有很多微服务会调用，而不同的微服务可能是跨团队维护的，不可能要求所有其他微服务同步更新。
微服务化改造应该是先粗后细，在刚开始改造时，服务的划分应该粗略一些，然后随着业务的发展与微服务的认知，在逐步细化。因为刚开始时团队对于微服务的认识可能没有那么深刻，而且也不知道最终业务要怎么发展，划分的过细，服务之间的调用关系就会更复杂，调用链更长，从而导致服务响应时间也会变长，开发运维成本也会增多，而且过细服务之间的耦合可能也比较强，最后可能还得合并与重新拆分。
微服务化拆分顺序
微服务化改造应该是边改造边支持业务的发展，那么我们拆分服务就得有一个顺序，我们可以依据如下的顺序拆分服务：
1、优先拆分比较独立的与业务关系不大的边缘服务，如短信服务。这样可以给团队一个试错的机会，减少错误的发生；
2、优先拆分被依赖的服务，比如A依赖B，B又依赖C，那么应该优先拆分C，再拆分B，最后拆分A；如果先拆分A，那么A就依赖于一体式的系统了。
我们需要理清服务之间的调用关系，优先拆分边缘的独立性的服务，优先拆分被依赖的服务。拆分后的服务依赖关系应该是比较清晰，最好是一个树状结构，而不是一个复杂的网状结构。如果是网状结构，往往意味着服务之间的边界不够清晰，不满足高内聚低耦合。
微服务化后的问题与解决思路
▲微服务化拆分示例
微服务化后，请求的调用链条往往较长较复杂，如果调用链上的某个服务异常了（如crash、响应时间变长等），那么往往会导致上游服务的资源出现异常，最终导致上游服务也出现异常，然后继续传导，继而导致雪崩。为此我们需要引入限流、降级、熔断、超时控制、重试等服务治理功能，以保证系统的高可用。
微服务化后，请求的调用链条往往较长较复杂，那么如果调用链上的某个服务出现异常或者报错，如上所述调用链上的其他服务往往也会出现异常或者报错，那么我们怎么找到错误的源头呢？这时就需要调用链跟踪与服务监控功能了。
▲微服务架构
03 采用DevOps
云采用和 DevOps 并驾齐驱。DevOps 是人、过程和工具的结合，可为最终用户提供持续交付价值。Dev 和 Ops 的缩写是指将开发和操作规则结合到多领域的团队中，与共享和有效的做法和工具协同工作。
DevOps 代表了一种 IT文化的变化，专注在面向系统的方法的背景下，采用敏捷、精简的实践来提供快速的IT服务。聚合的 DevOps 循环可以快速执行构思并快速迭代反馈，同时保持最高质量水平。
▲DevOps 实践流程
DevOps的目标是增强研发团队和运维团队之间的合作，消除信息壁垒，强调沟通、协作和集成。DevOps的文化将研发团队的敏捷与创新的特性和运维团队带来的安全性、稳定性和良好的用户体验有机的结合起来。DevOps帮助团队达到更好的协作、更快的发布周期、更加迅速的解决问题、更好的管理非预期的工作。
基于我们大量的项目落地经验来看，DevOps 的落地包含三个主要方面：人、工具、流程；三个方面内容缺一不可。
▲DevOps概念以及其落地关键点
04 采用不可变基础设施
不可变基础设施里的“不可变”非常类似于程序设计中的“不可变”概念。程序设计中不可变变量（例如：Java 中的String类）就是在完成赋值后就不能发生更改，如果需要变那么只能创建新的变量来整体替换旧的，由于不可变这种特性所以才可以在并发环境下安全的使用。不可变基础设施在部署完成以后，便成为一种只读状态，不可对其进行任何更改。如果需要更新或修改，就使用新的环境或服务器去替代旧的。不可变基础设施带来了更一致、更可靠、更可预测的设计理念，可以缓解或完全避免可变基础设施中遇到的各种常见问题。
跟不可变基础设施相对的，我们称之为可变基础设施。在以往传统的开发运维体系中，软件开发完成后，需要工程师或管理员通过SSH 连接到他们的服务器上，然后进行一些脚本安装、deb/rpm 包的安装工作，并逐个机器调整对应的配置参数及文件。后续还会根据需要对该环境进行不断更改，比如 kernel 升级、配置更新、打补丁等。随着这种类似变更的操作越来越多，没有人能弄清楚这个环境具体经历了哪些操作，而后续的变更也经常会遇到各种意想不到的诡异事情，比如软件包的循环依赖、参数的配置不一致、版本漂移等问题。
传统可变基础架构中的服务器是不可替代的，独特的系统必须始终保持运行。通过这种方式，它们就像宠物一样：独一无二，无法模仿，并且倾向于手工制作。失去一个可能是毁灭性的。另一方面，不可变基础架构中的服务器是一次性的，易于复制或使用自动化工具进行扩展。通过这种方式，他们就像牛一样：牛群中的众多群体中没有一个人是独一无二或不可或缺的。
随着虚拟化技术、云计算基础设施的引入，极大的降低了获取标准化基础设施的成本。同时，容器技术的引入也让我们可以方便的打包构建应用及其运行时的依赖环境，这样我们就可以方便的构建不可变的，可版本化管理的服务。
在应用现代化的过程中，实现不可变基础设施的关键点如下：
使用云端虚拟化基础设施作为构建基础。
通过容器技术来打包及整体构建服务运行环境。
实现容器镜像的自动化构建及版本化管理。
通过持续部署系统，进行自动化部署。
数字化转型下半场
关注企业应用现代化
以上是关于深度解读|持续拥抱云原生 加速企业应用现代化的主要内容，如果未能解决你的问题，请参考以下文章