传统架构 vs 云原生架构，谈谈为什么我们需要云原生架构？

点击上方“程序猿技术大咖”，关注并选择“设为星标”

回复“加群”获取入群讨论资格！

云原生架构是什么

---

回顾过去十年，数字化转型驱动着技术创新和商业元素的不断融合和重构，可以说，现在已经不是由商业模式决定采用何种技术架构，而是由技术架构决定企业的商业模式。所以无论是行业巨头还是中小微企业都面临着数字化转型带来的未知机遇和挑战。机遇是商业模式的创新，挑战来自对整体技术架构的变革。

新一代的技术架构是什么何变革多互联网企业面临的问题。而云原生架构则是这个问题最好的答案，因为云原生架构对云计算服务方式与互联网架构进行整体性升级，深刻改变着整个商业世界的 IT 根基。

虽然云原生的概念由来已久，很多人并不理解什么是云原生。从技术的角度来讲，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、 可观测性、灰度等），使业务不再受非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。简单的说，就是帮助企业的业务功能迭代更快、系统能承受住各种量级的流量冲击的同时，构建系统的成本更低。

纵观中国企业级 SaaS 行业发展历程，大体分为四个阶段：2015 年之前，中国市场和绝大多数中国企业对“什么是 SaaS”缺乏基本认知，基于私有部署的传统软件形式仍为主流，企业级 SaaS 市场方兴未艾。到了 2015 年，随着云计算技术的进一步成熟，中国企业级 SaaS 行业进入快速成长阶段，这个慢赛道逐渐为公众所知。

时至今日，在疫情、经济、社会环境的大背景下。互联网企业开始寻求新的商业模式，一些抓住机会的 SaaS 企业实现了快速响应，结果是其业务呈现成倍增长，比如：

• 餐饮 SaaS 厂商帮助线下餐饮门店开发小程序点餐系统，实现无接触点餐。

• 电商零售领域的 ERP 厂商帮助企业建立会员管理系统。

• 营销 SaaS 厂商通过流量平台帮助企业在线营销，远程触达客户。

所以，在“如何活下去”成为热门议题的背景下，快速响应能力成为企业之间的核心竞争优势，SaaS 企业需要及时满足市场的新需求。而这正是前几年中国 SaaS 企业为了快速占领市场、盲目跟风、一味借鉴国外产品所产生的天生缺陷。为弥补这些缺陷，SaaS 厂商需要根据市场的需求快速调整产品服务方向，业务功能要多元化，业务体系需要新的枝杈，在技术上也有更大的挑战。

除了市场带来的压力，SaaS 企业自身也有诸多痛点：

• 大多 SaaS 产品只做所谓的通用能力，或者只是一味模仿国外产品，一旦深入到行业属性比较重的场景时便无法满足需求，所以被贴上了“半成品”的标签，导致市场接受程度不如预期。

• 产品模块单一、功能相似的 SaaS 产品很容易陷入价格竞争，最后只能以亏损获得网络效应，但会终食恶果。

• 市场对 SaaS 产品的定制化需求过多，使得 SaaS 企业缺乏对产品打磨的精力，把一个 SaaS 型公司做成了项目型公司。

SaaS 企业解决以上的外忧内患的核心就是专注在业务。要做好一款 SaaS 产品，对于业务渠道、竞争格局、用户体验等诸多方面都有更加严苛的要求，甚至从市场运营、产品经理到研发、运维都要专注在业务，所有这些角色的本职工作都应该为行业业务服务，行业的深度分析，快速响应市场，稳定的产品质量这些是必须要具备的。

但这就要求技术具备更快的迭代速度，业务推出速度从按周提升到按小时，每月上线业务量从“几十 / 月”提升到“几百 / 天”，并且不可接受业务中断。

另一个互联网企业需要云原生转型的原因是中国的刘易斯拐点已经到来。刘易斯拐点，即劳动力过剩向短缺的转折点，是指在工业化进程中，随着农村富余劳动力向非农产业的逐步转移，农村富余劳动力逐渐减少，最终达到瓶颈状态。用大白话说就是中国的人口红利已经逐渐消退，企业劳动力成本不断增加，加上 2020 年疫情的影响，成本因素越来越成为企业的重要考量。

而 SaaS 产品订阅制付费、通用性强、低部署成本的特点，便成了企业降本增效的新选择。这是 SaaS 企业在市场中的机会，而且对于 SaaS 企业本身来说，同样有降本增效的需求，而且内部降本增效做得越好，SaaS 产品在市场上的竞争力会更加明显。

以上这些现状的解法和云原生架构和核心能力不谋而合：

• 云原生将三方软件和非功能性能力的完全兜底，可以极大程度解放企业研发、运维人员的精力，并使其可以专注在业务上。

• 系统的横向扩展性、高可用性、健壮性、SLA 由云原生架构兜底，解决了 SaaS 产品最忌讳的稳定性问题。

• 将一些自建的组件迁移至云原生架构中，对传统的部署方式和资源进行云原生化，GitOps 的落地，在资源成本和人力成本方面都有进一步的优化。

如何落地云原生架构

---

在聊如何落地云原生架构之前，我们先来看一看云原生架构成熟度模型（SESORA）：

上图展示的是一个较传统的 Java+SpringCloud 架构应用服务侧的部署架构。除了 SLB，基本上所有的组件都部署在 ECS 上。下面我们来一起看看如何将这个架构转型为云原生架构。

无服务化（Serverless）

Serverless 的概念是什么在这篇文章不再赘述，可以参阅这篇文章进行了解。使用 ECS 集群部署服务的架构有两个显著的短板：

• 运维成本高：ECS 的各项状态、高可用都需要运维同学维护。

• 弹性能力不足：每次有大促活动时，都需要提前购买 ECS，扩展服务的节点数，然后再释放，并且这种情况只适用于定时定点的活动，如果是不定时的流量脉冲则无法应对。

所以首先我们要将服务的部署方式 Serverless 化，我们可以选择 Serverless App Engine（SAE）作为服务应用的发布、部署平台。SAE 是面向应用的 Serverless PaaS 平台，能够帮助用户免运维 IaaS、按需使用、按量计费，做到低门槛服务应用云原生化，并且支持多种语言和高弹性能力。

1、命名空间

打开 SAE 控制台，我们首先创建命名空间，SAE 的命名空间可以将其下的应用进行网络和资源的逻辑隔离，通常我们可使用命名空间来区分开发环境、测试环境、预发环境、生产环境。

选择对应的命名空间，然后创建应用：

• 技术栈语言：Java 语言支持镜像、War 包、Jar 包三种部署方式，其他语言支持镜像部署方式。以 Java Jar 包方式为例：

• • 应用运行环境：默认标准 Java 应用运行环境即可。

  • Java 环境：目前支持 JDK7 和 JDK8。

  • 文件上传方式：支持手动上传 Jar 包或者配置可以下载 Jar 包的地址。

• 版本：支持时间戳和手动输入。

• 启动命令设置：配置 JVM 参数。

• 环境变量设置：设置容器环境中的一些变量，便于应用部署后灵活的变更容器配置。

• Host 绑定设置：设置 Host 绑定，便于通过域名访问应用。

• 应用健康检查设置：用于判断容器和用户业务是否正常运行。

• 应用生命周期管理设置：容器侧的生命周期脚本定义，管理应用在容器在运行前和关闭前的一些动作，比如环境准备、优雅下线等。

• 日志收集服务：和 SLS 日志服务集成，统一管理日志。

• 持久化存储：绑定 NAS。

• 配置管理：通过挂载配置文件的方式向容器中注入配置信息。

我使用 Jar 包的方式部署完应用后，在对应命名空间下就可以看到刚刚创建的应用了：

3、绑定 SLB

因为 ServiceA 在架构中是对外提供接口的服务，所以需要对该服务绑定公网 SLB 暴露 IP 和做负载均衡，在 SAE 中，绑定 SLB 非常简单，在详情页中，即可看到应用访问设置：

4、服务/配置中心

对于微服务架构，服务中心和配置中心是必不可少的，大家常用到一般是 Nacos、Eureka、ZooKeeper 三种。对于云原生架构来讲，根据不同的场景，服务/配置中心可以有以下几种选择：

• 对服务/配置中心高可用要求比较高的情况下，建议使用 MSE Nacos，它的优势是独享集群，并且节点规格和节点数量可以根据实际情况动态的进行调整。唯一不足的一点就是需要修改 Nacos 的接入点，算是有一点代码侵入。

对于现状是使用 Eureka 和 ZooKeeper 的客户而言，建议直接使用 MSE Eureka 和 MSE ZooKeeper。

这里我简单介绍一下 MSE。微服务引擎 MSE（Microservice Engine）是一个面向业界主流开源微服务框架 Spring Cloud 和 Dubbo 一站式微服务平台，提供治理中心、托管的注册中心和托管的配置中心。这里我们用到的是 MSE 的托管注册中心和托管配置中心。

• 通过命名空间逻辑隔离不同环境。

弹性能力（Elasticity）

云原生架构成熟度模型中的弹性能力同样依托于 SAE 来实现，因为 Serverless 的底层实现原理，所以在 SAE 中的应用实例数（节点数）扩缩速度非常快，可达到秒级。

进入应用详情页的实例部署信息，可以看到应用的具体实例：

当进行扩缩时，我们可以看到具体实例的变更状态：

2、自动扩缩

在控制台右上角有自动扩缩操作按钮，然后可以看到创建扩缩规则的界面。SAE 自动扩缩提供时间策略和指标策略两种。

上图是指标策略，目前提供 CPU 使用率、内存使用率、应用的 QPS 阈值、应用接口平均响应时间（RT）阈值四种指标，这四种指标可以配合使用。当这四种指标其中有一种达到阈值后就会触发扩容，会对应用实例进行逐渐扩容。当指标小于阈值后触发缩容。这种策略适合流量高峰时间不固定的场景，比如市场营销，游戏运营。

3、成本优化

对于弹性能力，大家可能更多的是关注它能让系统快速支撑流量脉冲，增加系统横向扩展的能力。其实因为SAE有极致的弹性能力，再加上按分钟、按量计费的模式，对整体的资源成本是有一定优化的。

• 总请求量：可以一目了然的看到请求量是否明显的异常，比如骤降或者陡升。

• 平均响应时间：应用整体接口的平均响应时间，这个指标直接反映最真实的应用健康状况。

• Full GC：JVM 里比较重要的指标，也是会直接影响系统性能的因素。

• 慢 SQL：智能抓取执行时间大于 500ms 的 SQL。

• 一些曲线视图：帮助我们掌握不同时段的应用情况。

2、应用实例节点健康状况

进入应用详情页，点击左侧菜单中的应用监控/应用详情，便可以看到应用每个节点的信息：

3、应用接口健康状况

进入应用详情页，点击左侧菜单中的应用监控/接口调用，便可以看到应用每个接口的信息：

4、纵向 Metrics 指标

在上述三个角度中，其实已经涵盖了绝大多数 Metrics 指标，比如有应用健康状态的指标、JVM 的指标、SQL 指标、NoSQL 指标等。

5、横向调用链路

在很多时候，我们单纯的看 Metrics 指标是无法确定问题的根本原因的，因为会涉及到不同服务之间的调用，不同接口之间的调用，所以需要查看服务和服务之间、接口和接口之间的调用关系以及具体的代码信息。在这个维度上，SAE 集成的 ARMS 的监控能力便可以实现。我们在应用监控/接口调用/接口快照中可以看到有请求的接口快照，通过 TraceID 便可以查看该接口的整体调用链路：

从上面这个图我们可以看出很多信息：

• 该接口在服务级别的完整请求链路，比如 ikf（前端）-> ikf-web(java 服务)-> ikf-blog(java 服务)-> ikf-blog(java 服务)。

• 每个服务的状态情况，比如状态一列是红点，说明在这个环节是有异常出现的。

• 在每个服务中请求的接口名称。

• 每个服务的请求耗时。

除了上述这些显性的信息以外，还有一些隐性的信息：

• 上游服务 ikf-web 的总耗时是 2008ms，但下游服务 ikf-blog 的总耗时是 5052ms，而且耗时起点是一样的，说明 ikf-web 到 ikf-blog 是一个异步调用。

• 既然 ikf-web 到 ikf-blog 是异步调用，然而 ikf-web 的耗时有 2s 之多，说明 ikf-web 服务中的接口也有问题。

• 在 ikf-blog 服务中，又有内部接口被调用，因为从调用链上出现了两个 ikf-blog，并且这个内部调用是同步调用，而且问题出现在最后一个接口调用上。

从以上这些信息可以帮我们缩小和圈定问题根因出现在哪个环节的范围，然后我们可以点击方法栈一列的放大镜，查看具体的方法栈代码信息：

韧性能力（Resilience）

对于云原生架构的韧性能力，我会从优雅上下线、多AZ部署、限流降级三个方面来聊一聊。

1、优雅上下线

一个好的产品，要能快速应对用户对产品功能、能力具有普适性的反馈和意见，能快速响应市场需求的变化。那么产品的功能就需要快速的做迭代和优化，从 IT 层面来看，就是要有快速、高效、高质量的发布变更流程，能够随时进行生产环境的服务发布。

但是这会带来一个核心问题，即频繁的服务发布，并且不能影响用户体验，用户的请求不能断流。所以这就要求我们的系统部署架构中有优雅上下线的能力。

以微服务架构来说明，虽然开源的产品有能力和方案做到近似优雅上下线，但也是近似做到，当发布服务节点较多的情况下依然会有断流的情况。所以开源方案有诸多问题：

• 注册中心不可靠、通知不及时。

• 客户端轮训不实时、客户端缓存。

• 自定义镜像非1号进程，Sigterm 信号无法传递。

• 无默认优雅下线方案，需要添加 actuator 组建。

在无服务化/服务配置中心章节中，我阐述了 SAE 自带的服务中心和 MSE 的服务中心，无论使用那种方案，我们都对优雅上下线做了进一步的优化。

当该接口的 QPS 达到 50 后，单个机器超过 50 的请求将快速失败。比如我们对一个有 6 个节点的应用进行压测时，可以看到每个节点的 QPS 情况：

• toolkit_profile.yaml：配置 RegionID、AccessKey ID、AccessKey Secret。

• toolkit_package.yaml：配置比如应用部署包类型、部署包地址、镜像地址。

• toolkit_deploy.yaml：配置比如 SAE 应用的 ID、应用所属命名空间 ID、应用名称、发布方式等。

更详细的配置信息可以参阅该文档。

然后在 Jenkins 的任务中，对 Maven 设置如下的命令即可：

这样就可以很容易的将 SAE 的部署流程集成到基于 Gitlab 和 Jenkins 的 CICD 方案里了。

云原生架构成熟度模型（SESORA）在我阐述的这五个维度一共是 15 分，基于 SAE 的云原生架构在这五个维度会达到 12 分：

• 无服务化：3分

• 弹性能力：3分

• 可观测性：2分

• 韧性能力：2分

• 自动化能力：2分

对于上手、实践、落地快捷简单，又能达到比较好的云原生架构成熟度的 SAE 方案，大家还在等什么呢起实践起来吧。

---

感谢您的阅读，也欢迎您发表关于这篇文章的任何建议，关注我，技术不迷茫！

喜欢就点个”在看”呗，留言、转发朋友圈

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92728 人正在系统学习中

来源：xcbeyond