东莞高端模板建站,北京个人制作网站有哪些内容,网站建设服务器的选择方式包括哪些,温州平台网站建设简介#xff1a; 新一代的技术架构是什么#xff1f;如何变革#xff1f;是很多互联网企业面临的问题。而云原生架构则是这个问题最好的答案#xff0c;因为云原生架构对云计算服务方式与互联网架构进行整体性升级#xff0c;深刻改变着整个商业世界的 IT 根基。 云原生架… 简介 新一代的技术架构是什么如何变革是很多互联网企业面临的问题。而云原生架构则是这个问题最好的答案因为云原生架构对云计算服务方式与互联网架构进行整体性升级深刻改变着整个商业世界的 IT 根基。 云原生架构是什么 回顾过去十年数字化转型驱动着技术创新和商业元素的不断融合和重构可以说现在已经不是由商业模式决定采用何种技术架构而是由技术架构决定企业的商业模式。所以无论是行业巨头还是中小微企业都面临着数字化转型带来的未知机遇和挑战。机遇是商业模式的创新挑战来自对整体技术架构的变革。 新一代的技术架构是什么如何变革是很多互联网企业面临的问题。而云原生架构则是这个问题最好的答案因为云原生架构对云计算服务方式与互联网架构进行整体性升级深刻改变着整个商业世界的 IT 根基。 虽然云原生的概念由来已久很多人并不理解什么是云原生。从技术的角度来讲云原生架构是基于云原生技术的一组架构原则和设计模式的集合旨在将云应用中的非业务代码部分进行最大化的剥离从而让云设施接管应用中原有的大量非功能特性如弹性、韧性、安全、 可观测性、灰度等使业务不再受非功能性业务中断困扰的同时具备轻量、敏捷、高度自动化的特点。简单的说就是帮助企业的业务功能迭代更快、系统能承受住各种量级的流量冲击的同时构建系统的成本更低。 传统架构与云原生架构的区别
上图展示了在代码中通常包括的三部分内容即业务代码、第三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码。“三方软件”是业务代码中依赖的所有三方库包括业务库和基础库。“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。 这三部分中只有业务代码是对业务真正带来价值的另外两个部分都只算附属物但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强使得今天的软件构建变得越来越复杂对开发人员的技能要求也越来越高。云原生架构相比较传统架构前进了一大步即从业务代码中剥离了大量非功能性特性到 IaaS 和 PaaS 中从而减少业务代码开发人员的技术关注范围通过云服务的专业性提升应用的非功能性能力。 这便是云原生架构的核心思路。
为什么需要云原生架构
解释完什么是云原生架构后大家可能会有进一步的思考即当今互联网企业为什么需要云原生架构。分析下SaaS的市场规模可以发现2019年SaaS市场规模为360亿元2020年仍保持可观上涨趋势2022年SaaS市场规模预计破千亿。 纵观中国企业级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 云原生架构成熟度模型
云原生架构成熟度模型有六个评判维度可以将成熟度划分为4个级别。我会从自动化能力、无服务化能力、弹性能力、可观测性、韧性能力这五个维度贯穿说明如何落地云原生架构。 传统架构 上图展示的是一个较传统的JavaSpringCloud架构应用服务侧的部署架构。除了SLB基本上所有的组件都部署在ECS上。下面我们来一起看看如何将这个架构转型为云原生架构。 无服务化Serverless Serverless的概念是什么在这篇文章不在赘述可以参阅这篇文章进行了解。使用ECS集群部署服务的架构有两个显著的短板 运维成本高ECS的各项状态、高可用都需要运维同学维护。弹性能力不足每次有大促活动时都需要提前购买ECS扩展服务的节点数然后再释放并且这种情况只适用于定时定点的活动如果是不定时的流量脉冲则无法应对。所以首先我们要将服务的部署方式Serverless化我们可以选择Serverless App EngineSAE作为服务应用的发布、部署平台。SAE是面向应用的Serverless PaaS平台能够帮助用户免运维IaaS、按需使用、按量计费做到低门槛服务应用云原生化并且支持多种语言和高弹性能力。 命名空间
打开SAE控制台我们首先创建命名空间SAE的命名空间可以将其下的应用进行网络和资源的逻辑隔离通常我们可使用命名空间来区分开发环境、测试环境、预发环境、生产环境。 创建应用
创建好命名空间后我们进入应用列表即可选择不同的命名空间看到其下的应用或者创建应用 选择对应的命名空间然后创建应用
应用名称服务名称用户自行输入。专有网络配置自动配置自动帮用户配置VPC、Vswitch、安全组。这些组件都会新创建。自定义配置用户选择命名空间VPCVSwitch以及安全组。一般选择自定义配置因为咱们的服务所属的VPC肯定要和其他云资源的VPC是相同的这样才能保证网络畅通。这里需要注意的一点是当在新的命名空间下第一次创建好应用后该命名空间就会和所选的VPC进行绑定之后再创建应用时该命名空间对应的VPC不可更改。如果需要更改可以进入命名空间详情进行更改。
应用实例数应用服务节点数量这里的节点数量按需设置而且不是最终设定因为后续可以手动或者自动的扩缩节点数。VCPU/内存该应用在运行过程中需要的CPU和内存的规格。这里的规格是单个实例数的规格。既如果选择了2C4G那么有2个实例的话就是4C8G。配置完基本信息后下一步进入应用部署配置 技术栈语言Java语言支持镜像、War包、Jar包三种部署方式其他语言支持镜像部署方式。以Java Jar包方式为例应用运行环境默认标准Java应用运行环境即可。Java环境目前支持JDK7和JDK8。文件上传方式支持手动上传Jar包或者配置可以下载Jar包的地址。
版本支持时间戳和手动输入。启动命令设置配置JVM参数。环境变量设置设置容器环境中的一些变量便于应用部署后灵活的变更容器配置。Host绑定设置设置Host绑定便于通过域名访问应用。应用健康检查设置用于判断容器和用户业务是否正常运行。应用生命周期管理设置容器侧的生命周期脚本定义管理应用在容器在运行前和关闭前的一些动作比如环境准备、优雅下线等。日志收集服务和SLS日志服务集成统一管理日志。持久化存储绑定NAS。配置管理通过挂载配置文件的方式向容器中注入配置信息。我使用Jar包的方式部署完应用后在对应命名空间下就可以看到刚刚创建的应用了 点击应用名称可以查看应用详情 绑定SLB
因为ServiceA在架构中是对外提供接口的服务所以需要对该服务绑定公网SLB暴露IP和做负载均衡在SAE中绑定SLB非常简单在详情页中即可看到应用访问设置 添加SLB时可以选择新建也可以选择已经创建好的SLB 服务/配置中心
对于微服务架构服务中心和配置中心是必不可少的大家常用到一般是Nacos、Eureka、ZooKeeper三种。对于云原生架构来讲根据不同的场景服务/配置中心可以有以下几种选择 对于现状就是使用Nacos的客户而言转型云原生架构服务/配置中心如上面表格所示有两种选择 需要快速转型对服务/配置中心高可用要求不是特别极致的情况下建议直接使用SAE自带的Nacos即可代码不需要做改动直接在SAE中创建应用即可。SAE控制台提供的配置管理在界面操作和功能上和开源Nacos的控制台基本一致。对服务/配置中心高可用要求比较高的情况下建议使用MSE Nacos它的优势是独享集群并且节点规格和节点数量可以根据实际情况动态的进行调整。唯一不足的一点就是需要修改Nacos的接入点算是有一点代码侵入。对于现状是使用Eureka和ZooKeeper的客户而言建议直接使用MSE Eureka和MSE ZooKeeper。 这里我简单介绍一下MSE。微服务引擎MSEMicroservice Engine是一个面向业界主流开源微服务框架Spring Cloud和Dubbo一站式微服务平台提供治理中心、托管的注册中心和托管的配置中心。这里我们用到的是MSE的托管注册中心和托管配置中心。 MSE有三块核心的功能点 支持三大主流服务中心节点规格和数量灵活搭配可在运行时动态调整节点规格/数量。通过命名空间逻辑隔离不同环境。配置变更实时推送并且可追踪。 配置变更实时推送并且可追踪。配置变更实时推送并且可追踪。手动扩缩
在控制台右上方有手动扩缩操作按钮然后选择要扩缩到的实例数即可 当进行扩缩时我们可以看到具体实例的变更状态 自动扩缩
在控制台右上角有自动扩缩操作按钮然后可以看到创建扩缩规则的界面。SAE自动扩缩提供时间策略和指标策略两种。 上图是时间策略即设置好具体的时间节点在这个时间节点要将应用的实例数扩到几个或者缩到几个。这种策略适合流量高峰期有相对明确时间节点的场景比如在线教育的客户通常流量高峰在晚上8点开始11点逐渐结束这种情况下通过定时策略在7点半左右把应用的实例数扩起来然后11点之后逐渐把应用实例数缩回正常。 上图是指标策略目前提供CPU使用率、内存使用率、应用的QPS阀值、应用接口平均响应时间RT阀值四种指标这四种指标可以配合使用。当这四种指标其中有一种达到阀值后就会触发扩容会对应用实例进行逐渐扩容。当指标小于阀值后触发缩容。这种策略适合流量高峰时间不固定的场景比如市场营销游戏运营。 成本优化
对于弹性能力大家可能更多的是关注它能让系统快速支撑流量脉冲增加系统横向扩展的能力。其实因为SAE有极致的弹性能力再加上按分钟、按量计费的模式对整体的资源成本是有一定优化的。 可观测性Observability 应用侧的可观测性分两个维度一是纵向的Metrics指标比如主机的CPU、内存、磁盘各项指标Pod的CPU、内存各项指标JVM的Full GC、堆内存、非堆内存各项指标。另一个维度是横向的请求调用链路监测上游服务到下游服务的调用、上游接口到下游接口的调用。 在监控微服务架构时通常需要从三个角度来看
应用的整体健康状况。应用每个实例的健康状况。应用每个接口的健康状况。而SAE对应用的监控也都覆盖了上述这两个维度和三个角度。 应用整体健康状况
进入应用详情页点击左侧菜单中的应用监控/应用总览便可以看到应用的整体状况 总请求量可以一目了然的看到请求量是否明显的异常比如骤降或者陡升。平均响应时间应用整体接口的平均响应时间这个指标直接反映最真实的应用健康状况。Full GCJVM里比较重要的指标也是会直接影响系统性能的因素。慢SQL智能抓取执行时间大于500ms的SQL。一些曲线视图帮助我们掌握不同时段的应用情况。应用实例节点健康状况
进入应用详情页点击左侧菜单中的应用监控/应用详情便可以看到应用每个节点的信息 总请求量可以一目了然的看到请求量是否明显的异常比如骤降或者陡升。平均响应时间应用整体接口的平均响应时间这个指标直接反映最真实的应用健康状况。Full GCJVM里比较重要的指标也是会直接影响系统性能的因素。慢SQL智能抓取执行时间大于500ms的SQL。一些曲线视图帮助我们掌握不同时段的应用情况。应用实例节点健康状况
进入应用详情页点击左侧菜单中的应用监控/应用详情便可以看到应用每个节点的信息 从上图可以看到左侧会列出当前应用的所有实例节点包括该节点的平均响应时间、请求次数、错误数、异常数。如果我们按照影响时间降序排序比较靠上的节点就是响应时间较慢的节点然后我们就需要分析是什么原因导致这些节点的响应时间较慢。所以右侧会提供了一些检查维度来帮助我们分析排查问题。 比如查看JVM指标 应用接口健康状况
进入应用详情页点击左侧菜单中的应用监控/接口调用便可以看到应用每个接口的信息 接口监控和应用实例节点监控的思路一致左侧会列出所有请求过的接口同样显示了响应时间、请求数、错误数右侧同样提供了一些检查维度来帮助我们分析接口RT高的原因。 比如查看SQL调用分析 纵向Metrics指标
在上述三个角度中其实已经涵盖了绝大多数Metrics指标比如有应用健康状态的指标、JVM的指标、SQL指标、NoSQL指标等。
横向调用链路 在很多时候我们单纯的看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并且这个内部调用是同步调用而且问题出现在最后一个接口调用上。从以上这些信息可以帮我们缩小和圈定问题根因出现在哪个环节的范围然后我们可以点击方法栈一列的放大镜查看具体的方法栈代码信息 从方法栈这里我们又可以得到很多显性信息 具体的方法。每个方法的耗时。方法产生的具体异常信息。数据库操作的具体SQL语句甚至SQL上的Binding Value。当然除了显性信息外还有一个比较重要的隐性信息比如我们可以看到 BlogController.findBlogByIsSelection(int isSelection)这个方法的耗时是5s但是该方法内部的数据库操作的耗时很少只有1ms说明耗时是属于业务代码的毕竟业务代码我们是抓不到也不会去抓取信息的。这时我们可以有两种方式去定位具体问题 从方法栈信息中已经知道了具体的服务和具体的方法那么直接打开IDE查看、分析代码。查看方法栈页签旁边的线程剖析也基本可以确定问题所在。比如上图这个情况我们查看线程剖析后会发现他的耗时是因为java.lang.Thread.sleep( ):-2 [3000ms]。韧性能力Resilience
对于云原生架构的韧性能力我会从优雅上下线、多AZ部署、限流降级三个方面来聊一聊。
优雅上下线
一个好的产品要能快速应对用户对产品功能、能力具有普适性的反馈和意见能快速响应市场需求的变化。那么产品的功能就需要快速的做迭代和优化从IT层面来看就是要有快速、高效、高质量的发布变更流程能够随时进行生产环境的服务发布。 但是这会带来一个核心问题即频繁的服务发布并且不能影响用户体验用户的请求不能断流。所以这就要求我们的系统部署架构中有优雅上下线的能力。 以微服务架构来说明虽然开源的产品有能力和方案做到近似优雅上下线但也是近似做到当发布服务节点较多的情况下依然会有断流的情况。所以开源方案有诸多问题
注册中心不可靠、通知不及时。客户端轮训不实时、客户端缓存。自定义镜像非1号进程Sigterm信号无法传递。无默认优雅下线方案需要添加actuator组建。在无服务化/服务配置中心章节中我阐述了SAE自带的服务中心和MSE的服务中心无论使用那种方案我们都对优雅上下线做了进一步的优化。 从上图可以看到部署在SAE的应用具有主动通知服务中心和服务消费者的能力再结合Liveness应用实例探活和Readiness应用业务探活的机制能让我们的服务在进行部署和因为其他原因挂掉时不会影响用户的正常访问。
多AZ部署
本着鸡蛋不能放在一个篮子里的原则一个应用的多个节点应该分布在不同的可用区这样整体应用的高可用和健壮性才是足够好的。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插件同时对应有三个配置文件Maven插件通过这三个配置文件中的信息将打包好的Jar/War或者镜像发布到对应的SAE应用中。 toolkit_profile.yaml配置RegionID、AccessKey ID、AccessKey Secret。toolkit_package.yaml配置比如应用部署包类型、部署包地址、镜像地址。toolkit_deploy.yaml配置比如SAE应用的ID、应用所属命名空间ID、应用名称、发布方式等。更详细的配置信息可以参阅该文档。 然后在Jenkins的任务中对Maven设置如下的命令即可
clean package toolkit:deploy -Dtoolkit_profiletoolkit_profile.yaml -Dtoolkit_packagetoolkit_package.yaml -Dtoolkit_deploytoolkit_deploy.yaml 基于Open API
还有一些企业会自己研发运维平台运维赋能研发由研发同学在运维平台上进行运维操作。面对这种场景SAE提供了丰富的Open API可以将SAE控制台上90%的能力通过Open API集成到客户自己的运维平台中。详细的OpenAPI说明可以参与该文档。 总结 基于SAE武装过系统后整体的部署架构会变成这样 云原生架构成熟度模型SESORA在我阐述的这五个维度一共是15分基于SAE的云原生架构在这五个维度会达到12分 无服务化3分弹性能力3分可观测性2分韧性能力2分自动化能力2分
作者计缘阿里云解决方案架构师
原文链接
本文为阿里云原创内容未经允许不得转载
