简介： 新一代的技术架构是什么？如何变革？是很多互联 企业面临的问题。而云原生架构则是这个问题最好的答案，因为云原生架构对云计算服务方式与互联 架构进行整体性升级，深刻改变着整个商业世界的 IT 根基。
云原生架构是什么
回顾过去十年，数字化转型驱动着技术创新和商业元素的不断融合和重构，可以说，现在已经不是由商业模式决定采用何种技术架构，而是由技术架构决定企业的商业模式。所以无论是行业巨头还是中小微企业都面临着数字化转型带来的未知机遇和挑战。机遇是商业模式的创新，挑战来自对整体技术架构的变革。
新一代的技术架构是什么？如何变革？是很多互联 企业面临的问题。而云原生架构则是这个问题最好的答案，因为云原生架构对云计算服务方式与互联 架构进行整体性升级，深刻改变着整个商业世界的 IT 根基。
虽然云原生的概念由来已久，很多人并不理解什么是云原生。从技术的角度来讲，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、 可观测性、灰度等），使业务不再受非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。简单的说，就是帮助企业的业务功能迭代更快、系统能承受住各种量级的流量冲击的同时，构建系统的成本更低。
传统架构与云原生架构的区别
上图展示了在代码中通常包括的三部分内容，即业务代码、第三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码。“三方软件”是业务代码中依赖的所有三方库，包括业务库和基础库。“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。
这三部分中只有业务代码是对业务真正带来价值的，另外两个部分都只算附属物，但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强，使得今天的软件构建变得越来越复杂，对开发人员的技能要求也越来越高。云原生架构相比较传统架构前进了一大步，即从业务代码中剥离了大量非功能性特性到 IaaS 和 PaaS 中，从而减少业务代码开发人员的技术关注范围，通过云服务的专业性提升应用的非功能性能力。
这便是云原生架构的核心思路。
为什么需要云原生架构
解释完什么是云原生架构后，大家可能会有进一步的思考，即当今互联 企业为什么需要云原生架构。分析下SaaS的市场规模可以发现，2019年SaaS市场规模为360亿元，2020年仍保持可观上涨趋势，2022年SaaS市场规模预计破千亿。
纵观中国企业级SaaS行业发展历程，大体分为四个阶段：2015年之前，中国市场和绝大多数中国企业对“什么是SaaS”缺乏基本认知，基于私有部署的传统软件形式仍为主流，企业级SaaS市场方兴未艾。到了2015年，随着云计算技术的进一步成熟，中国企业级SaaS行业进入快速成长阶段，这个慢赛道逐渐为公众所知。
时至今日，在疫情、经济、社会环境的大背景下。互联 企业开始寻求新的商业模式，一些抓住机会的SaaS企业实现了快速响应，结果是其业务呈现成倍增长，比如：
所以，在“如何活下去”成为热门议题的背景下，快速响应能力成为企业之间的核心竞争优势，SaaS企业需要及时满足市场的新需求。而这正是前几年中国SaaS企业为了快速占领市场、盲目跟风、一味借鉴国外产品所产生的天生缺陷。为弥补这些缺陷，SaaS厂商需要根据市场的需求快速调整产品服务方向，业务功能要多元化，业务体系需要新的枝杈，在技术上也有更大的挑战。
除了市场带来的压力，SaaS企业自身也有诸多痛点：
SaaS企业解决以上的外忧内患的核心就是专注在业务。要做好一款SaaS产品，对于业务渠道、竞争格局、用户体验等诸多方面都有更加严苛的要求，甚至从市场运营、产品经理到研发、运维都要专注在业务，所有这些角色的本职工作都应该为行业业务服务，行业的深度分析，快速响应市场，稳定的产品质量这些是必须要具备的。但这就要求技术具备更快的迭代速度，业务推出速度从按周提升到按小时，每月上线业务量从“几十 / 月”提升到“几百 / 天”，并且不可接受业务中断。
另一个互联 企业需要云原生转型的原因是中国的刘易斯拐点已经到来。刘易斯拐点，即劳动力过剩向短缺的转折点，是指在工业化进程中，随着农村富余劳动力向非农产业的逐步转移，农村富余劳动力逐渐减少，最终达到瓶颈状态。用大白话说就是中国的人口红利已经逐渐消退，企业劳动力成本不断增加，加上2020年疫情的影响，成本因素越来越成为企业的重要考量。而SaaS产品订阅制付费、通用性强、低部署成本的特点，便成了企业降本增效的新选择。这是SaaS企业在市场中的机会，而且对于SaaS企业本身来说，同样有降本增效的需求，而且内部降本增效做得越好，SaaS产品在市场上的竞争力会更加明显。
以上这些现状的解法和云原生架构和核心能力不谋而合：
如何落地云原生架构
在聊如何落地云原生架构之前，我们先来看一看云原生架构成熟度模型（SESORA）：
云原生架构成熟度模型
云原生架构成熟度模型有六个评判维度，可以将成熟度划分为4个级别。我会从自动化能力、无服务化能力、弹性能力、可观测性、韧性能力这五个维度，贯穿说明如何落地云原生架构。
传统架构
上图展示的是一个较传统的Java+SpringCloud架构应用服务侧的部署架构。除了SLB，基本上所有的组件都部署在ECS上。下面我们来一起看看如何将这个架构转型为云原生架构。
无服务化（Serverless）
Serverless的概念是什么在这篇文章不在赘述，可以参阅这篇文章进行了解。使用ECS集群部署服务的架构有两个显著的短板：
所以首先我们要将服务的部署方式Serverless化，我们可以选择Serverless App Engine（SAE）作为服务应用的发布、部署平台。SAE是面向应用的Serverless PaaS平台，能够帮助用户免运维IaaS、按需使用、按量计费，做到低门槛服务应用云原生化，并且支持多种语言和高弹性能力。
命名空间
打开SAE控制台，我们首先创建命名空间，SAE的命名空间可以将其下的应用进行 络和资源的逻辑隔离，通常我们可使用命名空间来区分开发环境、测试环境、预发环境、生产环境。
创建应用
创建好命名空间后，我们进入应用列表，即可选择不同的命名空间，看到其下的应用或者创建应用：
选择对应的命名空间，然后创建应用：
配置完基本信息后，下一步进入应用部署配置：
我使用Jar包的方式部署完应用后，在对应命名空间下就可以看到刚刚创建的应用了：
点击应用名称可以查看应用详情：
绑定SLB
因为ServiceA在架构中是对外提供接口的服务，所以需要对该服务绑定公 SLB暴露IP和做负载均衡，在SAE中，绑定SLB非常简单，在详情页中，即可看到应用访问设置：
添加SLB时可以选择新建也可以选择已经创建好的SLB：
服务/配置中心
对于微服务架构，服务中心和配置中心是必不可少的，大家常用到一般是Nacos、Eureka、ZooKeeper三种。对于云原生架构来讲，根据不同的场景，服务/配置中心可以有以下几种选择：
对于现状就是使用Nacos的客户而言，转型云原生架构，服务/配置中心如上面表格所示有两种选择：
对于现状是使用Eureka和ZooKeeper的客户而言，建议直接使用MSE Eureka和MSE ZooKeeper。
这里我简单介绍一下MSE。微服务引擎MSE（Microservice Engine）是一个面向业界主流开源微服务框架Spring Cloud和Dubbo一站式微服务平台，提供治理中心、托管的注册中心和托管的配置中心。这里我们用到的是MSE的托管注册中心和托管配置中心。
MSE有三块核心的功能点：
通过命名空间逻辑隔离不同环境。配置变更实时推送并且可追踪。
手动扩缩
在控制台右上方有手动扩缩操作按钮，然后选择要扩缩到的实例数即可：
当进行扩缩时，我们可以看到具体实例的变更状态：
自动扩缩
在控制台右上角有自动扩缩操作按钮，然后可以看到创建扩缩规则的界面。SAE自动扩缩提供时间策略和指标策略两种。
上图是时间策略，即设置好具体的时间节点，在这个时间节点要将应用的实例数扩到几个或者缩到几个。这种策略适合流量高峰期有相对明确时间节点的场景，比如在线教育的客户，通常流量高峰在晚上8点开始，11点逐渐结束，这种情况下，通过定时策略在7点半左右把应用的实例数扩起来，然后11点之后逐渐把应用实例数缩回正常。
上图是指标策略，目前提供CPU使用率、内存使用率、应用的QPS阀值、应用接口平均响应时间（RT）阀值四种指标，这四种指标可以配合使用。当这四种指标其中有一种达到阀值后就会触发扩容，会对应用实例进行逐渐扩容。当指标小于阀值后触发缩容。这种策略适合流量高峰时间不固定的场景，比如市场营销，游戏运营。
成本优化
对于弹性能力，大家可能更多的是关注它能让系统快速支撑流量脉冲，增加系统横向扩展的能力。其实因为SAE有极致的弹性能力，再加上按分钟、按量计费的模式，对整体的资源成本是有一定优化的。
可观测性（Observability）
应用侧的可观测性分两个维度，一是纵向的Metrics指标，比如主机的CPU、内存、磁盘各项指标，Pod的CPU、内存各项指标，JVM的Full GC、堆内存、非堆内存各项指标。另一个维度是横向的请求调用链路监测，上游服务到下游服务的调用、上游接口到下游接口的调用。
在监控微服务架构时，通常需要从三个角度来看：
而SAE对应用的监控也都覆盖了上述这两个维度和三个角度。
应用整体健康状况
进入应用详情页，点击左侧菜单中的应用监控/应用总览，便可以看到应用的整体状况：
应用实例节点健康状况
进入应用详情页，点击左侧菜单中的应用监控/应用详情，便可以看到应用每个节点的信息：
应用实例节点健康状况
进入应用详情页，点击左侧菜单中的应用监控/应用详情，便可以看到应用每个节点的信息：
从上图可以看到，左侧会列出当前应用的所有实例节点，包括该节点的平均响应时间、请求次数、错误数、异常数。如果我们按照影响时间降序排序，比较靠上的节点就是响应时间较慢的节点，然后我们就需要分析是什么原因导致这些节点的响应时间较慢。所以，右侧会提供了一些检查维度来帮助我们分析排查问题。
比如查看JVM指标：
应用接口健康状况
进入应用详情页，点击左侧菜单中的应用监控/接口调用，便可以看到应用每个接口的信息：
接口监控和应用实例节点监控的思路一致，左侧会列出所有请求过的接口，同样显示了响应时间、请求数、错误数，右侧同样提供了一些检查维度来帮助我们分析接口RT高的原因。
比如查看SQL调用分析：
纵向Metrics指标
在上述三个角度中，其实已经涵盖了绝大多数Metrics指标，比如有应用健康状态的指标、JVM的指标、SQL指标、NoSQL指标等。
横向调用链路
在很多时候，我们单纯的看Metrics指标是无法确定问题的根本原因的，因为会涉及到不同服务之间的调用，不同接口之间的调用，所以需要查看服务和服务之间、接口和接口之间的调用关系以及具体的代码信息。在这个维度上，SAE集成的ARMS的监控能力便可以实现。我们在应用监控/接口调用/接口快照中可以看到有请求的接口快照，通过TraceID便可以查看该接口的整体调用链路：
从上面这个图我们可以看出很多信息：
除了上述这些显性的信息以外，还有一些隐性的信息：
声明：本站部分文章内容及图片转载于互联 、内容不代表本站观点，如有内容涉及侵权，请您立即联系本站处理，非常感谢！