基于Serverless的云原生转型实践介绍：什么是新一代技术架构？如何改变？这是很多互联网公司面临的问题。云原生架构是这个问题最好的答案，因为云原生架构从整体上升级了云计算服务方式和互联网架构，深刻改变了整个商业世界的IT基础。什么是云原生架构？回顾过去十年，数字化转型驱动技术创新与商业要素不断融合重构。可以说，不再是业务模型决定采用何种技术架构，而是技术架构决定了企业。商业模式。因此，无论是行业巨头还是中小微企业，都面临着数字化转型带来的未知机遇和挑战。机遇在于商业模式的创新，而挑战则来自于整体技术架构的变革。什么是新一代技术架构？如何改变？这是很多互联网公司面临的问题。云原生架构是这个问题最好的答案，因为云原生架构从整体上升级了云计算服务方式和互联网架构，深刻改变了整个商业世界的IT基础。虽然云原生的概念由来已久，但很多人并不了解什么是云原生。从技术角度看，云原生架构是基于云原生技术的架构原则和设计模式的集合，旨在最大限度剥离云应用中的非业务代码部分，让云设施接管原有的大量非功能性特性（如弹性、弹性、安全性、可观察性、灰度等）让业务不再受到非功能性业务中断的困扰，同时具有轻量的特点重量，敏捷性和高度自动化。简单来说，就是帮助企业在业务功能上更快迭代，系统能够承受各种量级的流量冲击，同时降低系统建设成本。传统架构和云原生架构的区别上图展示了代码中通常包含的三个部分，即业务代码、第三方软件和处理非功能特性的代码。“业务代码”是指实现业务逻辑的代码。“三方软件”是指业务代码所依赖的所有三方库，包括业务库和基础库。“处理非功能性代码”是指实现非功能性能力的代码，例如高可用性、安全性和可观察性。这三部分中，只有业务代码真正为业务带来价值，其他两部分只是附属物。但是，随着软件规模的增大，业务模块规模增大，部署环境增加，分布式复杂度增加，使得今天的软件构建越来越复杂，对开发人员的技能要求也越来越高。与传统架构相比，云原生架构向前迈进了一大步，将大量非功能性的特性从业务代码剥离到IaaS和PaaS，从而减少了业务代码开发人员的技术重心和通过云服务非功能性能力的专业性改进应用程序。这就是云原生架构的核心思想。为什么需要云原生架构在解释完什么是云原生架构之后，你可能会进一步思考为什么现在的互联网公司需要云原生架构。分析SaaS市场规模可发现，2019年SaaS市场规模为360亿元，2020年仍将保持可观的上升趋势，2022年SaaS市场规模有望突破1000亿元.纵观中国企业级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）：thecloud-nativearchitecturematuritymodelThecloud-nativearchitecturematuritymodel有六个评价维度，可以分为成熟度的4个等级。我将从自动化能力、免服务能力、弹性能力、可观察性和弹性能力五个维度来阐述如何实现云原生架构。传统架构上图展示了一个比较传统的Java+SpringCloud架构的应用服务端部署架构。除了SLB，基本上所有组件都部署在ECS上。我们来看看如何将这种架构转变为云原生架构。无服务器（Serverless）的概念本文不再赘述，大家可以参考本文了解更多。使用ECS集群部署服务的架构有两个显着的缺点：运维成本高：ECS的各种状态和高可用需要运维同学维护。弹性不足：每次有大的促销活动，都需要提前购买ECS，扩充服务节点数量，然后再释放。这种情况只适用于定点活动，无法应对不规则的流量脉动。.所以首先我们要把服务部署方式做到serverless。我们可以选择ServerlessAppEngine（SAE）作为服务应用的发布和部署平台。SAE是一个面向应用的ServerlessPaaS平台，可以帮助用户免去IaaS的运维，按需使用，按量收费，实现低门槛的服务应用云原生，支持多语言和高灵活性。命名空间打开SAE控制台，我们首先创建一个命名空间，SAE命名空间可以在逻辑上隔离其下应用的网络和资源，通常我们可以通过命名空间来区分开发环境、测试环境、预发布环境、生产环境环境。创建应用并创建命名空间后，我们可以进入应用列表，选择不同的命名空间，查看其下的应用或者创建应用：选择对应的命名空间，然后创建应用：应用名称：服务名称，用户输入.VPC配置：自动配置：自动为用户配置VPC、Vswitch和安全组。这些组件是新创建的。自定义配置：用户选择命名空间、VPC、VSwitch、安全组。一般选择自定义配置，因为我们服务所属的VPC必须和其他云资源的VPC相同，这样才能保证网络畅通。这里需要注意的是，在新的命名空间下首次创建应用时，该命名空间会与选择的VPC绑定，以后创建应用时，该命名空间对应的VPC是不能更改的。如果需要更改，可以输入命名空间的详细信息进行更改。应用实例数：应用（服务）节点的数量。这里的节点数是根据需要设置的，不是最终设置，因为以后可以手动或自动扩展节点数。VCPU/Memory：应用程序运行时所需的CPU和内存的规格。这里的规范是对单个实例个数的规范。即使选择了2C4G，那么如果有2个instance，就是4C8G。配置基本信息后，接下来就是进入应用部署配置：技术栈语言：Java语言支持镜像、war包、jar包三种部署方式，其他语言支持镜像部署方式。以JavaJar包方式为例：应用运行环境：默认的标准Java应用运行环境即可。Java环境：目前支持JDK7和JDK8。文件上传方式：支持手动上传Jar包或配置Jar包下载地址。版本：支持时间戳和手动录入。启动命令设置：配置JVM参数。环境变量设置：在容器环境中设置一些变量，方便应用部署后灵活更改容器配置。主机绑定设置：设置主机绑定，方便通过域名访问应用。应用健康检查设置：用于判断容器和用户服务是否正常运行。应用生命周期管理设置：容器端的生命周期脚本定义，管理应用在容器运行前和关闭前的一些动作，如环境准备、优雅下线等日志收集服务：与SLS集成日志服务统一管理日志。持久化存储：绑定NAS。配置管理：通过挂载配置文件，将配置信息注入到容器中。我使用Jar包部署应用后，可以在对应的命名空间中看到新建的应用：点击应用名称可以查看应用详情：==bindSLB因为ServiceA在架构中是提供接口的服务，所以需要将服务绑定到公网SLB，暴露IP，做负载均衡。在SAE中，绑定SLB非常简单。在详情页面可以看到应用访问设置：添加SLB时，可以选择创建或选择创建的SLB：服务/配置中心是微服务架构必不可少的，服务中心和配置中心是Nacos常用的，尤里卡和动物园管理员。对于云原生架构，根据不同的场景，服务/配置中心可以有以下几种选择：对于目前使用Nacos的客户，服务/配置中心有两种类型，如上表所示。选择：如果需要快速改造，对服务/配置中心的高可用要求不是特别极端，建议直接使用SAE自带的Nacos。无需更改代码，直接在SAE中创建应用即可。SAE控制台提供的配置管理在界面操作和功能上与开源的Nacos控制台基本一致。在对服务/配置中心有高可用需求的情况下，推荐使用MSENacos。它的优点是拥有专属的集群，节点规格和节点数量可以根据实际情况动态调整。唯一不足的是需要修改Nacos的接入点，有点代码入侵。对于目前使用Eureka和ZooKeeper的客户，建议直接使用MSEEureka和MSEZooKeeper。这里我简单介绍一下MSE。微服务引擎MSE（MicroserviceEngine）是面向业界主流开源微服务框架SpringCloud和Dubbo的一站式微服务平台，提供治理中心、托管注册中心、托管配置中心。这里我们使用MSE的托管注册中心和托管配置中心。MSE有3个核心功能点：支持三大主流服务中心，节点规格和数量灵活匹配，节点规格/数量运行时动态调整。通过名称空间逻辑分离环境。实时推送和跟踪配置更改。实时推送和跟踪配置更改。实时推送和跟踪配置更改。手动缩放控制台右上方有一个手动缩放操作按钮，然后选择要缩放到的实例数：缩放时，我们可以看到具体实例的变化状态：自动缩放在右上方控制台的一角有一个自动缩放操作按钮，然后可以看到创建缩放规则的界面。SAE自动伸缩提供了两种时间策略和索引策略。上图显示了时间策略，即设定一个特定的时间节点，在该时间节点应用实例的数量应该增加或减少到几个。该策略适用于流量高峰期时间节点比较明确的场景，比如在线教育客户。通常，交通高峰从晚上8:00开始。并逐渐在晚上11:00结束。扩大实例数，然后逐步缩减应用实例数，11:00后恢复正常。上图显示了指标策略。目前提供四项指标：CPU使用率、内存使用率、应用QPS阈值、应用接口平均响应时间（RT）阈值。这四个指标可以一起使用。当这四个指标之一达到阈值时，就会触发扩容，逐步扩容应用实例。当指标小于阈值时触发缩减。该策略适用于流量高峰时间不固定的场景，如营销、游戏运营等。成本优化对于弹性能力，大家可能更关注它，让系统快速支撑流量脉冲，增加系统横向扩展的能力。事实上，由于SAE具有极致的灵活性，加上按分钟计费、按量付费的模式，在一定程度上优化了整体资源成本。可观察性（Observability）应用端的可观察性分为两个维度。一是垂直指标，比如主机CPU、内存、磁盘指标，PodCPU、内存指标，JVMFullGC，堆内存和非堆内存的各种指标。另外一个维度是横向请求调用链路监控，上游服务对下游服务的调用，上游接口对下游接口的调用。在监控微服务架构时，通常需要从三个角度来看：应用程序的整体健康状况。应用程序每个实例的运行状况。应用每个接口的健康状况。SAE对应用的监控也涵盖了以上两个维度和三个角度。应用整体健康状态进入应用详情页面，点击左侧菜单中的应用监控/应用概览，可以看到应用的整体健康状态：总请求量：是否请求量一目了然明显异常，如突然下降或急剧上升。平均响应时间：应用程序整体界面的平均响应时间。该指标直接反映了最真实的应用健康状况。FullGC：JVM中的一个重要指标，也是直接影响系统性能的一个因素。慢SQL：智能抓取执行时间大于500ms的SQL。一些曲线图：帮助我们掌握不同时期的应用情况。应用实例节点健康状态进入应用详情页面，点击左侧菜单中的应用监控/应用详情，可以看到应用各个节点的信息：总请求量：一目了然明显异常，如暴跌或暴涨。平均响应时间：应用程序整体界面的平均响应时间。该指标直接反映了最真实的应用健康状况。FullGC：JVM中的一个重要指标，也是直接影响系统性能的一个因素。慢SQL：智能抓取执行时间大于500ms的SQL。一些曲线图：帮助我们掌握不同时期的应用情况。应用实例节点健康状态进入应用详情页面，点击左侧菜单中的应用监控/应用详情，可以看到该应用各个节点的信息：从上图可以看出，当前应用的所有实例左侧Node会列出，包括该节点的平均响应时间、请求数、错误数、异常数。如果我们按照影响时间从大到小的顺序排序，靠上的节点就是响应时间较慢的节点，那么我们需要分析是什么原因导致这些节点响应时间较慢。因此，右侧提供了一些检查维度，以帮助我们分析和排查问题。比如查看JVM指标：应用接口健康状态，进入应用详情页面，点击左侧菜单中的应用监控/接口调用，可以看到应用各个接口的信息：接口监控和应用实例节点监控都有同样的思路，左侧会列出所有请求的接口，同时会显示响应时间、请求数、错误数。右侧还提供了一些检查尺寸，帮助我们分析接口RT高的原因。比如查看SQL调用分析：上面三个视角的垂直指标其实涵盖了大部分指标，比如应用健康状态指标、JVM指标、SQL指标、NoSQL指标等。横向调用链路很多时候，我们并不能仅仅通过看Metrics指标来判断问题的根源，因为它涉及到不同服务之间的调用，不同接口之间的调用，所以我们需要排查服务之间，之间的调用关系接口和接口以及具体的代码信息。在这个维度上，可以实现SAE集成ARMS的监控能力。我们在应用监控/接口调用/接口快照中可以看到请求的接口快照，可以通过TraceID查看接口的整体调用链路：从上图我们可以看到很多信息：接口在服务中level完整的请求链接，比如ikf(前端)->ikf-web(java服务)->ikf-blog(java服务)->ikf-blog(java服务)各个服务的状态，比如status栏是一个红点，说明这个链接有异常。每个服务中请求的接口名称。每个服务请求都很耗时。除了以上显性信息外，还有一些隐性信息：上游服务ikf-web总耗时为2008ms，而下游服务ikf-blog总耗时为5052ms，耗时-消费起点相同，说明ikf-web对ikf-blog是异步调用。由于ikf-web到ikf-blog是异步调用，但是ikf-web耗时2s之多，说明ikf-web服务中的接口也有问题。在ikf-blog服务中调用了另一个内部接口，因为从调用链上出现了两个ikf-blog，而这个内部调用是同步调用，问题出现在最后一个接口调用上。以上信息可以帮助我们缩小并圈定出问题根源所在环节的范围，然后我们可以点击方法栈一栏的放大镜查看具体的方法栈代码信息：我们可以从方法栈中获取大量显式信息：具体方法。每种方法的时间。方法产生的具体异常信息。数据库操作的具体SQL语句，甚至是SQL上的BindingValue。当然，除了显性信息，还有一个比较重要的隐性信息。例如，我们可以看到BlogController.findBlogByIsSelection(intisSelection)方法耗时5秒，但该方法的内部数据库操作耗时很少。只有1ms，也就是说耗时是属于业务代码的。毕竟我们抓不到业务代码，也不会抓到信息。这时候，我们可以有两种方式来定位具体的问题：我们已经从方法栈信息中知道了具体的服务和具体的方法，然后直接打开IDE查看代码进行分析。查看方法栈选项卡旁边的线程分析，基本可以确定问题所在。比如上图的情况，我们查看线程分析后，会发现耗时是因为java.lang.Thread.sleep():-2[3000ms]。弹性：关于云原生架构的弹性，我会从优雅下线下线、多可用区部署、限流降级三个方面来谈。一个好的产品必须能够快速响应用户对产品功能和能力的普遍性反馈和意见，能够快速响应市场需求的变化。那么产品的功能就需要快速迭代优化。从IT的角度，需要有一个快速、高效、高质量的发布变更流程，可以随时在生产环境发布服务。但这会带来一个核心问题，就是频繁的服务发布不能影响用户体验，用户请求的流程不能中断。所以这就需要我们的系统部署架构要有优雅上线下线的能力。以微服务架构为例，虽然开源产品有能力和方案可以近似优雅的上线下线，但也是近似的。当发布服务节点较多时，仍然会出现中断。因此，开源方案存在诸多问题：注册中心不可靠，通知不及时。客户端轮训不是实时的，客户端缓存。如果自定义图像不是1号进程，则无法传输Sigterm信号。没有默认的优雅离线方案，需要添加执行器组件。在serviceless/服务配置中心一章，我讲解了SAE的服务中心和MSE的服务中心。无论采用哪种方案，我们都进一步优化了优美的线上线下。从上图可以看出，部署在SAE中的应用具有主动通知服务中心和服务消费者的能力，结合Liveness应用实例检测和Readiness应用业务检测的机制，可以使我们的服务部署成功并且由于其他原因挂掉，也不会影响用户的正常访问。多可用区部署是基于鸡蛋不能放在一个篮子里的原则。一个应用的多个节点应该分布在不同的可用区，这样整个应用的高可用和健壮性就足够了。SAE支持设置多个交换机（VSwitch），每个交换机可以在不同的可用区，所以在部署和扩展应用节点时，会从可选的可用区中随机拉取实例：这样可以避免当某个可用区出现问题时，整个系统挂掉是因为它在一个可用区。这也是同城多住最基本的做法。限流降级限流降级是系统在断臂情况下生存的能力。当遇到突发的流量脉冲时，及时限制流量，避免整个系统崩溃，或者当流量超出预期时，及时切断非核心业务，释放资源支持核心业务。目前，对于Java应用，SAE也支持限流降级的能力。首先，对应用所有接口的请求指标进行抓取和监控：然后我们可以为每个接口设置流控、隔离、熔断规则。比如我有/checkHealth接口设置了一个流控规则：当这个接口的QPS达到50时，单机超过50的请求会很快失败。比如我们对一个有6个节点的应用做压测，可以看到每个节点的QPS：开启流控规则后，马上可以看到限流的效果：可以看到QPS精确控制到50个，超过50个请求直接返回失败。自动化能力（Automation）在自动化能力方面，我主要从CICD流程的维度来谈。从以上章节的截图可以看出，SAE控制台的截图有很多。在实际应用中，肯定不会通过控制台一个一个的发布应用，必须通过CICD流程来完成应用的自动化打包发布过程。.对此，SAE提供了两种实现自动化运维的方式。基于Gitlab和Jenkins，目前很多企业的CICD流程都是基于Gitlab和Jenkins的，所以SAE也支持将发布的操作集成到这个方案中。这个方案的核心是SAE会提供一个Maven插件，对应的配置文件有3个。Maven插件会通过三个配置文件中的信息，将打包后的Jar/War或image发布到对应的SAE应用中。toolkit_profile.yaml：配置RegionID、AccessKeyID、AccessKeySecret。toolkit_package.yaml：应用部署包类型、部署包地址、镜像地址等配置。toolkit_deploy.yaml：配置SAE应用ID、应用所属命名空间ID、应用名称、发布方式等。更详细的配置信息可以参考这篇文档。然后在Jenkins任务中，为Maven设置如下命令：cleanpackagetoolkit:deploy-Dtoolkit_profile=toolkit_profile.yaml-Dtoolkit_package=toolkit_package.yaml-Dtoolkit_deploy=toolkit_deploy.yaml基于OpenAPI，一些公司会开发自己的维护平台、运维使能研发，研发学生在运维平台上进行运维操作。面对这种场景，SAE提供了丰富的OpenAPI，可以将SAE控制台90%的能力通过OpenAPI集成到客户自己的运维平台中。可以在本文档中找到详细的OpenAPI说明。基于SAE的系统武装起来之后，整体的部署架构会变成这样：云原生架构成熟度模型（SESORA）在我描述的五个维度上一共有15个点，而基于SAE的云原生架构在这些五个维度会达到12分：Serviceless：3分Elasticity：3分Observability：2分Resilience：2分Automationability：2分作者：纪元，阿里云解决方案架构师内容，未经允许不得转载
