精华内容
下载资源
问答
  • 一、云原生架构原则 云原生架构本身作为一种架构,也有若干架构原则作为应用架构的核心架构控制面,通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。 1.1 服务化原则 当代码规模超出...

    一、云原生架构原则

    云原生架构本身作为一种架构,也有若干架构原则作为应用架构的核心架构控制面,通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。

    1.1 服务化原则

    当代码规模超出小团队的合作范围时,就有必要进行服务化拆分了,包括拆分为微服务架构、小服务(Mini Service)架构,通过服务化架构把不同生命周期的模块分离出来,分别进行业务迭代,避免迭代频繁模块被慢速模块拖慢,从而加快整体的进度和稳定性。同时服务化架构以面向接口编程,服务内部的功能高度内聚,模块间通过公共功能模块的提取增加软件的复用程度。

    分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等,本质上都是基于服务流量(而非网络流量)的控制策略,所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系,标准化服务流量的传输,从而帮助业务模块进行基于服务流量的策略控制和治理,不管这些服务是基于什么语言开发的。

    1.2 弹性原则

    大部分系统部署上线需要根据业务量的估算,准备一定规模的机器,从提出采购申请,到供应商洽谈、机器部署上电、软件部署、性能压测,往往需要好几个月甚至一年的周期;而这期间如果业务发生变化了,重新调整也非常困难。弹性则是指系统的部署规模可以随着业务量的变化自动伸缩,无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间,让企业不用操心额外软硬件资源的成本支出(闲置成本),降低了企业的 IT 成本,更关键的是当业务规模面临海量突发性扩张的时候,不再因为平时软硬件资源储备不足而“说不”,保障了企业收益。

    1.3 可观测原则

    今天大部分企业的软件规模都在不断增长,原来单机可以对应用做完所有调试,但在分布式环境下需要对多个主机上的信息做关联,才可能回答清楚服务为什么宕机、哪些服务违反了其定义的 SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等,这些都要求系统具备更强的可观测能力。可观测性与监控、业务探活、APM 等系统提供的能力不同,前者是在云这样的分布式系统中,主动通过日志、链路跟踪和度量等手段,让一次 APP 点击背后的多次服务调用的耗时、返回值和参数都清晰可见,甚至可以下钻到每次三方软件调用、SQL 请求、节点拓扑、网络响应等,这样的能力可以使运维、开发和业务人员实时掌握软件运行情况,并结合多个维度的数据指标,获得前所未有的关联分析能力,不断对业务健康度和用户体验进行数字化衡量和持续优化。

    1.4 韧性原则

    当业务上线后,最不能接受的就是业务不可用,让用户无法正常使用软件,影响体验和收入。韧性代表了当软件所依赖的软硬件组件出现各种异常时,软件表现出来的抵御能力,这些异常通常包括硬件故障、硬件资源瓶颈(如 CPU/ 网卡带宽耗尽)、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件 bug、黑客攻击等对业务不可用带来致命影响的因素。韧性从多个维度诠释了软件持续提供业务服务的能力,核心目标是提升软件的 MTBF(Mean TimeBetween Failure,平均无故障时间)。从架构设计上,韧性包括服务异步化能力、重试 / 限流 / 降级 /熔断 / 反压、主从模式、集群模式、AZ 内的高可用、单元化、跨 region 容灾、异地多活容灾等。

    1.5 所有过程自动化原则

    技术往往是把“双刃剑”,容器、微服务、DevOps、大量第三方组件的使用,在降低分布式复杂性和提升迭代速度的同时,因为整体增大了软件技术栈的复杂度和组件规模,所以不可避免地带来了软件交付的复杂性,如果这里控制不当,应用就无法体会到云原生技术的优势。通过 IaC(Infrastructure as Code)、GitOps、OAM(Open Application Model)、Kubernetes operator 和大量自动化交付工具在 CI/CD 流水线中的实践,一方面标准化企业内部的软件交付过程,另一方面在标准化的基础上进行自动化,通过配置数据自描述和面向终态的交付过程,让自动化工具理解交付目标和环境差异,实现整个软件交付和运维的自动化。

    1.6 零信任原则

    零信任安全针对传统边界安全架构思想进行了重新评估和审视,并对安全架构思路给出了新建议。其核心思想是,默认情况下不应该信任网络内部和外部的任何人 / 设备 / 系统,需要基于认证和授权重构访问控制的信任基础,诸如 IP 地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆,引导安全体系架构从“网络中心化”走向“身份中心化”,其本质诉求是以身份为中心进行访问控制。

    零信任第一个核心问题就是 Identity,赋予不同的 Entity 不同的 Identity,解决是谁在什么环境下访问某个具体的资源的问题。在研发、测试和运维微服务场景下,Identity 及其相关策略不仅是安全的基础,更是众多(资源,服务,环境)隔离机制的基础;在员工访问企业内部应用的场景下,Identity 及其相关策略提供了灵活的机制来提供随时随地的接入服务。

    1.7 架构持续演进原则

    今天技术和业务的演进速度非常快,很少有一开始就清晰定义了架构并在整个软件生命周期里面都适用,相反往往还需要对架构进行一定范围内的重构,因此云原生架构本身也应该和必须是一个具备持续演进能力的架构,而不是一个封闭式架构。除了增量迭代、目标选取等因素外,还需要考虑组织(例如架构控制委员会)层面的架构治理和风险控制,特别是在业务高速迭代情况下的架构、业务、实现平衡关系。云原生架构对于新建应用而言的架构控制策略相对容易选择(通常是选择弹性、敏捷、成本的维度),但对于存量应用向云原生架构迁移,则需要从架构上考虑遗留应用的迁出成本 / 风险和到云上的迁入成本/ 风险,以及技术上通过微服务 / 应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用和流量进行细颗粒度控制。

    二、主要架构模式

    云原生架构有非常多的架构模式,这里选取一些对应用收益更大的主要架构模式进行讨论。

    2.1 服务化架构模式

    服务化架构是云时代构建云原生应用的标准架构模式,要求以应用模块为颗粒度划分一个软件,以接口契约(例如 IDL)定义彼此业务关系,以标准协议(HTTP、gRPC 等)确保彼此的互联互通,结合DDD(领域模型驱动)、TDD(测试驱动开发)、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务(Mini Service)模式,其中小服务可以看做是一组关系非常密切的服务的组合,这组服务会共享数据,小服务模式通常适用于非常大型的软件系统,避免接口的颗粒度太细而导致过多的调用损耗(特别是服务间调用和数据一致性处理)和治理复杂度。

    通过服务化架构,把代码模块关系和部署关系进行分离,每个接口可以部署不同数量的实例,单独扩缩容,从而使得整体的部署更经济。此外,由于在进程级实现了模块的分离,每个接口都可以单独升级,从而提升了整体的迭代效率。但也需要注意,服务拆分导致要维护的模块数量增多,如果缺乏服务的自动化能力和治理能力,会让模块管理和组织技能不匹配,反而导致开发和运维效率的降低。

    2.2 Mesh 化架构模式

    Mesh 化架构是把中间件框架(比如 RPC、缓存、异步消息等)从业务进程中分离,让中间件 SDK与业务代码进一步解耦,从而使得中间件升级对业务进程没有影响,甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务进程中只保留很“薄”的 Client 部分,Client 通常很少变化,只负责与Mesh 进程通讯,原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成。整个架构如下图所示。

     

    实施 Mesh 化架构后,大量分布式架构模式(熔断、限流、降级、重试、反压、隔仓……)都由Mesh 进程完成,即使在业务代码的制品中并没有使用这些三方软件包;同时获得更好的安全性(比如零信任架构能力)、按流量进行动态环境隔离、基于流量做冒烟 / 回归测试等。

    2.3 Serverless 模式

    和大部分计算模式不同,Serverless 将“部署”这个动作从运维中“收走”,使开发者不用关心应用在哪里运行,更不用关心装什么 OS、怎么配置网络、需要多少 CPU …… 从架构抽象上看,当业务流量到来 / 业务事件发生时,云会启动或调度一个已启动的业务进程进行处理,处理完成后云自动会关闭/ 调度业务进程,等待下一次触发,也就是把应用的整个运行时都委托给云。

    今天 Serverless 还没有达到任何类型的应用都适用的地步,因此架构决策者需要关心应用类型是否适合于 Serverless 运算。如果应用是有状态的,云在进行调度时可能导致上下文丢失,毕竟Serverless 的调度不会帮助应用做状态同步;如果应用是长时间后台运行的密集型计算任务,会得不到太多 Serverless 的优势;如果应用涉及到频繁的外部 I/O(网络或者存储,以及服务间调用),也因为繁重的 I/O 负担、时延大而不适合。Serverless 非常适合于事件驱动的数据计算任务、计算时间短的请求 / 响应应用、没有复杂相互调用的长周期任务。

    2.4 存储计算分离模式

    分布式环境中的 CAP 困难主要是针对有状态应用,因为无状态应用不存在 C(一致性)这个维度,因此可以获得很好的 A(可用性)和 P(分区容错性),因而获得更好的弹性。在云环境中,推荐把各类暂态数据(如 session)、结构化和非结构化持久数据都采用云服务来保存,从而实现存储计算分离。但仍然有一些状态如果保存到远端缓存,会造成交易性能的明显下降,比如交易会话数据太大、需要不断根据上下文重新获取等,则可以考虑通过采用 Event Log + 快照(或 Check Point)的方式,实现重启后快速增量恢复服务,减少不可用对业务的影响时长。

    2.5 分布式事务模式

    微服务模式提倡每个服务使用私有的数据源,而不是像单体这样共享数据源,但往往大颗粒度的业务需要访问多个微服务,必然带来分布式事务问题,否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。

    • 传统采用 XA 模式,虽然具备很强的一致性,但是性能差;
    • 基于消息的最终一致性(BASE)通常有很高的性能,但是通用性有限,且消息端只能成功而不能触发消息生产端的事务回滚;
    • TCC 模式完全由应用层来控制事务,事务隔离性可控,也可以做到比较高效;但是对业务的侵入性非常强,设计开发维护等成本很高;
    • SAGA 模式与 TCC 模式的优缺点类似但没有 try 这个阶段,而是每个正向事务都对应一个补偿事务,也是开发维护成本高;
    • 开源项目 SEATA 的 AT 模式非常高性能且无代码开发工作量,且可以自动执行回滚操作,同时也存在一些使用场景限制。

    2.6 可观测的架构

    可观测架构包括 Logging、Tracing、Metrics 三个方面,其中 Logging 提供多个级别(verbose/debug/warning/error/fatal)的详细信息跟踪,由应用开发者主动提供;Tracing 提供一个请求从前端到后端的完整调用链路跟踪,对于分布式场景尤其有用;Metrics 则提供对系统量化的多维度度量。

    架构决策者需要选择合适的、支持可观测的开源框架(比如 OpenTracing、OpenTelemetry),并规范上下文的可观测数据规范(例如方法名、用户信息、地理位置、请求参数等),规划这些可观测数据在哪些服务和技术组件中传播,利用日志和 tracing 信息中的 span id/trace id,确保进行分布式链路分析时有足够的信息进行快速关联分析。

    由于建立可观测性的主要目标是对服务 SLO(Service Level Objective)进行度量,从而优化SLA,因此架构设计上需要为各个组件定义清晰的 SLO,包括并发度、耗时、可用时长、容量等。

    2.7 事件驱动架构

    事件驱动架构(EDA,Event Driven Architecture)本质上是一种应用 / 组件间的集成架构模式,典型的事件驱动架构如下图:

     

    事件和传统的消息不同,事件具有 schema,所以可以校验 event 的有效性,同时 EDA 具备 QoS保障机制,也能够对事件处理失败进行响应。事件驱动架构不仅用于(微)服务解耦,还可应用于下面的场景中:

    • 增强服务韧性:由于服务间是异步集成的,也就是下游的任何处理失败甚至宕机都不会被上游感知,自然也就不会对上游带来影响;
    • CQRS(Command Query Responsibility Segregation):把对服务状态有影响的命令用事件来发起,而对服务状态没有影响的查询才使用同步调用的 API 接口;结合 EDA 中的 Event Sourcing 可以用于维护数据变更的一致性,当需要重新构建服务状态时,把 EDA 中的事件重新“播放”一遍即可;
    • 数据变化通知:在服务架构下,往往一个服务中的数据发生变化,另外的服务会感兴趣,比如用户订单完成后,积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级;
    • 构建开放式接口:在 EDA 下,事件的提供者并不用关心有哪些订阅者,不像服务调用的场景 —— 数据的产生者需要知道数据的消费者在哪里并调用它,因此保持了接口的开放性;
    • 事件流处理:应用于大量事件流(而非离散事件)的数据分析场景,典型应用是基于 Kafka 的日志处理;基于事件触发的响应:在 IoT 时代大量传感器产生的数据,不会像人机交互一样需要等待处理结果的返回,天然适合用 EDA 来构建数据处理应用。

    三、典型的云原生架构反模式

    技术往往像一把双刃剑,阿里在自己和帮助客户做云原生架构演进的时候,会充分考虑根据不同的场景选择不同的技术,下面是我们总结的一些典型云原生架构反模式。

    3.1 庞大的单体应用

    庞大单体应用的最大问题在于缺乏依赖隔离,包括代码耦合带来的责任不清、模块间接口缺乏治理而带来变更影响扩散、不同模块间的开发进度和发布时间要求难以协调、一个子模块不稳定导致整个应用都变慢、扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容…… 因此当业务模块可能存在多人开发的时候,就需要考虑通过服务化进行一定的拆分,梳理聚合根,通过业务关系确定主要的服务模块以及这些模块的边界、清晰定义模块之间的接口,并让组织关系和架构关系匹配。

    阿里巴巴在淘宝业务快速发展阶段,就遇到过上百人维护一个核心单体应用,造成了源码冲突、多团队间协同代价高的严重问题。为了支撑不断增长的流量,该应用需要不断增加机器,很快后端数据库连接很快就到达了上限。在还没有“微服务”概念的 2008 年,阿里巴巴决定进行服务化架构拆分,当时思路就是微服务架构,第一个服务从用户中心开始建设,后续交易、类目、店铺、商品、评价中心等服务陆续从单体中独立出来,服务之间通过远程调用通信,每个中心由独立团队专门维护,从而解决了研发协同问题,以及按规模持续水平扩展的问题。

    3.2 单体应用“硬拆”为微服务

    服务的拆分需要适度,过分服务化拆分反而会导致新架构与组织能力的不匹配,让架构升级得不到技术红利,典型的例子包括:

    • 小规模软件的服务拆分:软件规模不大,团队人数也少,但是为了微服务而微服务,强行把耦合度高、代码量少的模块进行服务化拆分,一次性的发布需要拆分为多个模块分开发布和维护;
    • 数据依赖:服务虽然拆分为多个,但是这些服务的数据是紧密耦合的,于是让这些服务共享数据库,导致数据的变化往往被扇出到多个服务中,造成服务间数据依赖;
    • 性能降低:当耦合性很强的模块被拆分为多个微服务后,原来的本地调用变成了分布式调用,从而让响应时间变大了上千倍,导致整个服务链路性能急剧下降。

    3.3 缺乏自动化能力的微服务

    软件架构中非常重要的一个维度就是处理软件复杂度问题,一旦问题规模提升了很多,那就必须重新考虑与之适应的新方案。在很多软件组织中,开发、测试和运维的工作单位都是以进程为单位,比如把整个用户管理作为一个单独的模块进行打包、发布和运行;而进行了微服务拆分后,这个用户管理模块可能被分为用户信息管理、基本信息管理、积分管理、订单管理等多个模块,由于仍然是每个模块分别打包、发布和运行,开发、测试和运维人员的人均负责模块数就直线上升,造成了人均工作量增大,也就增加了软件的开发成本。

    实际上,当软件规模进一步变大后,自动化能力的缺失还会带来更大的危害。由于接口增多会带来测试用例的增加,更多的软件模块排队等待测试和发布,如果缺乏自动化会造成软件发布时间变长,在多环境发布或异地发布时更是需要专家来处理环境差异带来的影响。同时更多的进程运行于一个环境中,缺乏自动化的人工运维容易给环境带来不可重现的影响,而一旦发生人为运维错误又不容易“快速止血”,造成了故障处理时间变长,以及使得日常运维操作都需要专家才能完成。所有这些问题导致软件交付时间变长、风险提升以及运维成本的增加。

     

     

     

     

    展开全文
  • 云原生架构是什么回顾过去十年,数字化转型驱动着技术创新和商业元素的不断融合和重构,可以说,现在已经不是由商业模式决定采用何种技术架构,而是由技术架构决定企业的商业模式。所以无论是行业巨头还...

    云原生架构是什么


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

    新一代的技术架构是什么?如何变革?是很多互联网企业面临的问题。而云原生架构则是这个问题最好的答案,因为云原生架构对云计算服务方式与互联网架构进行整体性升级,深刻改变着整个商业世界的 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 个级别。我会从自动化能力、无服务化能力、弹性能力、可观测性、韧性能力这五个维度,贯穿说明如何落地云原生架构。

    传统架构

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

    无服务化(Serverless)

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

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

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

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

    1、命名空间

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

    2、创建应用

    创建好命名空间后,我们进入应用列表,即可选择不同的命名空间,看到其下的应用或者创建应用:

    选择对应的命名空间,然后创建应用:

    • 应用名称:服务名称,用户自行输入。

    • 专有网络配置:

      • 自动配置:自动帮用户配置 VPC、Vswitch、安全组。这些组件都会新创建。

      • 自定义配置:用户选择命名空间,VPC,VSwitch 以及安全组。一般选择自定义配置,因为咱们的服务所属的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 包的方式部署完应用后,在对应命名空间下就可以看到刚刚创建的应用了:

    点击应用名称可以查看应用详情:

    3、绑定 SLB

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

    添加 SLB 时可以选择新建也可以选择已经创建好的 SLB:

    4、服务/配置中心

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

    对于现状就是使用 Nacos 的客户而言,转型云原生架构,服务/配置中心如上面表格所示有两种选择:

    • 需要快速转型,对服务/配置中心高可用要求不是特别极致的情况下,建议直接使用 SAE 自带的 Nacos 即可,代码不需要做改动,直接在 SAE 中创建应用即可。SAE 控制台提供的配置管理在界面操作和功能上和开源 Nacos 的控制台基本一致。

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

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

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

    MSE 有三块核心的功能点:

    • 支持三大主流服务中心,节点规格和数量灵活搭配,可在运行时动态调整节点规格/数量。

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

    • 配置变更实时推送并且可追踪。


    弹性能力(Elasticity)


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

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

    SAE 提供了两种扩缩应用实例数的方式,手动方式和自动方式。


    1、手动扩缩

    在控制台右上方有手动扩缩操作按钮,然后选择要扩缩到的实例数即可:

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

    2、自动扩缩

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

    上图是时间策略,即设置好具体的时间节点,在这个时间节点要将应用的实例数扩到几个或者缩到几个。这种策略适合流量高峰期有相对明确时间节点的场景,比如在线教育的客户,通常流量高峰在晚上 8 点开始,11 点逐渐结束,这种情况下,通过定时策略在 7 点半左右把应用的实例数扩起来,然后 11 点之后逐渐把应用实例数缩回正常。

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

    3、成本优化

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

    可观测性(Observability)

    应用侧的可观测性分两个维度,一是纵向的 Metrics 指标,比如主机的 CPU、内存、磁盘各项指标,Pod 的 CPU、内存各项指标,JVM 的 Full GC、堆内存、非堆内存各项指标。另一个维度是横向的请求调用链路监测,上游服务到下游服务的调用、上游接口到下游接口的调用。

    在监控微服务架构时,通常需要从三个角度来看:

    • 应用的整体健康状况。

    • 应用每个实例的健康状况。

    • 应用每个接口的健康状况。

    而SAE对应用的监控也都覆盖了上述这两个维度和三个角度。

    1、应用整体健康状况

    进入应用详情页,点击左侧菜单中的应用监控/应用总览,便可以看到应用的整体状况:

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

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

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

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

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

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

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

    从上图可以看到,左侧会列出当前应用的所有实例节点,包括该节点的平均响应时间、请求次数、错误数、异常数。如果我们按照影响时间降序排序,比较靠上的节点就是响应时间较慢的节点,然后我们就需要分析是什么原因导致这些节点的响应时间较慢。所以,右侧会提供了一些检查维度来帮助我们分析排查问题。

    比如查看 JVM 指标:

    3、应用接口健康状况

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

    接口监控和应用实例节点监控的思路一致,左侧会列出所有请求过的接口,同样显示了响应时间、请求数、错误数,右侧同样提供了一些检查维度来帮助我们分析接口 RT 高的原因。

    比如查看 SQL 调用分析:


    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,并且这个内部调用是同步调用,而且问题出现在最后一个接口调用上。

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

    从方法栈这里我们又可以得到很多显性信息:

    • 具体的方法。

    • 每个方法的耗时。

    • 方法产生的具体异常信息。

    • 数据库操作的具体 SQL 语句,甚至 SQL 上的 Binding Value。

    当然除了显性信息外,还有一个比较重要的隐性信息,比如我们可以看到BlogController.findBlogByIsSelection(int isSelection)这个方法的耗时是 5s,但是该方法内部的数据库操作的耗时很少,只有 1ms,说明耗时是属于业务代码的,毕竟业务代码我们是抓不到也不会去抓取信息的。这时我们可以有两种方式去定位具体问题:

    • 从方法栈信息中已经知道了具体的服务和具体的方法,那么直接打开 IDE 查看、分析代码。

    • 查看方法栈页签旁边的线程剖析,也基本可以确定问题所在。比如上图这个情况,我们查看线程剖析后会发现他的耗时是因为java.lang.Thread.sleep( ):-2 [3000ms]


    韧性能力(Resilience)

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

    1、优雅上下线

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

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

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

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

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

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

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

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

    从上图可以看到,部署在 SAE 的应用具有主动通知服务中心和服务消费者的能力,再结合 Liveness 应用实例探活和 Readiness 应用业务探活的机制,能让我们的服务在进行部署和因为其他原因挂掉时不会影响用户的正常访问。


    2、多 AZ 部署

    本着鸡蛋不能放在一个篮子里的原则,一个应用的多个节点,应该分布在不同的可用区,这样整体应用的高可用和健壮性才是足够好的。SAE 支持设置多个交换机(VSwitch),每个交换机可以在不同的可用区,这样在部署、扩容应用的节点时会随机从可选的可用区拉起实例:

    这就避免了当某个可用区出现问题挂掉时,整体系统因为在一个可用区而挂掉,这也是最基本的同城多活的实践。


    3、限流降级

    限流降级是系统断臂求生的能力,在遇到突发的流量脉冲时,可以及时限制流量,避免整个系统被击穿,或者当流量超出预期时,及时切断非核心业务,释放资源来支撑核心业务。

    目前对于 Java 应用,SAE 也支持限流降级的能力,首先对应用的所有接口的请求指标进行抓取和监控:

    然后我们可以针对每一个接口设置流控、隔离、熔断的规则,比如我对 /checkHealth 接口设置一条流控规则:

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

    当开启流控规则后,可以立即看到限流的效果:

    可以看到 QPS 被精准的控制到 50,超过 50 的请求直接返回失败。

    自动化能力(Automation)

    在自动化能力方面,我主要从 CICD 流程这个维度来聊一聊。大家从上面章节的截图可以看到,有很多是 SAE 控制台的截图,在实际应用中肯定不会通过控制台来一个一个发布应用,必然都是通过 CICD 流程来做自动化的应用打包和发布流程。

    SAE 在这个方面提供两种实现自动化运维的方式。


    1、基于 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_profile=toolkit_profile.yaml -Dtoolkit_package=toolkit_package.yaml -Dtoolkit_deploy=toolkit_deploy.yaml 
    ‍
    
    

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

    2、基于 Open API

    还有一些企业会自己研发运维平台,运维赋能研发,由研发同学在运维平台上进行运维操作。面对这种场景,SAE 提供了丰富的 Open API,可以将 SAE 控制台上 90% 的能力通过 Open API 集成到客户自己的运维平台中。详细的 OpenAPI 说明可以参与该文档。

    总结


    基于 SAE 武装过系统后,整体的部署架构会变成这样:

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

    • 无服务化:3分

    • 弹性能力:3分

    • 可观测性:2分

    • 韧性能力:2分

    • 自动化能力:2分

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

    云原生产品2月月报:如何提升业务稳定性?| 文末答题有奖

    游戏打包过程枯燥且工作繁琐,如何提升打包效率?看鲸旗游戏新思路

    函数计算镜像加速:从分钟到秒的跨越

    点个在看,让更多人看见

    展开全文
  • 云原生架构及其应用

    千次阅读 2020-12-19 00:04:28
      本文以该系统为例,主要论述了云原生架构在项目中的具体应用。系统以Spring Cloud微服务框架开发,分为前端Web服务、平台保障服务、业务服务三部分。前端Web服务由负载均衡与服务器集群结合,实现高并发的前台...

      声明:本文为本人2020软考系统架构设计师考试中所写论文(52分)的回忆版本,不保证内容的原创性与正确性,仅供参考,请勿照抄和用于学术论文等正规场合,因不当使用产生后果一律自负。

    摘要

      2019年3月,我单位联合某高校研发了《程序在线评测比赛考试系统》。系统以程序代码在线提交自动评测功能为核心,分为题库模块、评测机模块、实验作业模块、考试模块、比赛模块、抄袭判定模块、用户管理模块等,支持对接教务平台。在项目中我担任系统架构师,负责架构设计工作。
      本文以该系统为例,主要论述了云原生架构在项目中的具体应用。系统以Spring Cloud微服务框架开发,分为前端Web服务、平台保障服务、业务服务三部分。前端Web服务由负载均衡与服务器集群结合,实现高并发的前台界面;平台保障服务以Eureka为中心,由API网关、服务注册中心、监控平台等构成,实现基础服务框架;业务服务划分为多个微服务,基于Docker容器,协同工作实现具体业务功能。最终系统顺利上线,获得用户一致好评。

    正文

      笔者在一个专为高校建设计算机专业智能教学一体化平台的单位任职,过往成果有《计算机组成原理仿真实验系统》等。2019年3月,我单位联合某大学研发了《程序在线评测比赛考试系统》项目(以下简称为“OJ系统”),以取代原有传统的编程上机考试平台。
      系统以程序代码的在线提交自动评测功能为核心,主要分为题库模块、评测机模块、实验作业模块、考试模块、比赛模块、抄袭判定模块、用户管理模块等。题库模块主要负责试题和测试用例的管理,用户根据试题要求编写程序代码提交到系统,系统将测试用例与程序代码发送给评测机模块,由评测机自动编译、执行、判分,并将结果发送给其他相关模块进行统计;实验作业模块用于在线布置作业,从题库中选取试题,设置截止日期等要求;考试模块用于学生在线考试,按教师预先设置的参数自动从题库随机抽题生成试卷,以及向教务平台上传考试成绩;比赛模块主要用于ACM竞赛的培训;抄袭判定模块用于鉴定代码与他人代码雷同率;用户管理模块负责用户信息的管理。在这个项目中,我担任了系统架构师的职务,主要负责系统的架构设计相关工作。
      云原生架构以微服务和容器技术为代表,有服务化、强韧性、可观测性和自动化四类设计原则。通过服务化的设计原则,应用被分解为多个服务,可分别选择不同的技术,单个服务模块很容易开发、理解和维护,无需协调其他服务对本服务的影响;通过强韧性的设计原则,微服务可以分布式云化部署,负载均衡管理请求的分发,避免单机失败对整体服务的影响,以及弹性调整资源容量;通过可观测性的设计原则,能够对系统进行健康检查、指标监控、日志管理和链路追踪,提高系统运维、管理和排错能力;通过自动化的设计原则,可实现系统的自动化部署、自动化扩展伸缩、自动化运维、持续交付和集成,有效减少人工操作的工作量。
      OJ系统基于Spring Cloud微服务框架开发,将平台服务划分为三类,分别为前端Web服务、平台保障服务、业务服务。下面针对这三类服务展开具体说明。

    1. 前端Web服务

      前端Web服务主要提供给用户使用的界面,分为前置Nginx负载均衡服务器、前端网站Nginx集群。当用户通过网络访问系统时,首先会访问到前置的Nginx负载均衡服务器,负载均衡服务器会将请求转发到前端网站的Nginx集群,前端网站通过发起http请求来和后端交互,具体是通过Ajax方式来调用后端REST API接口。用户访问网站通过前置的Nginx负载均衡服务器来转发到前端网站集群,以起到将用户请求进行分流的作用。当前端网站集群中的部分服务发生故障时,系统仍可正常地对外提供服务。前置Nginx负载均衡服务器使用软件反向代理的方式来实现负载均衡,部署为路由模式,系统内部网络与外部网络分属于不同的逻辑网络,以实现系统内部与外部网络的隔离。在负载均衡算法的选择上,使用最小连接法,每当用户的请求来临时,任务分发单元会将任务平滑分配给最小连接数的前端网站节点,这样的架构以廉价且透明的方式扩展了服务器和网络的带宽,可以大大提升系统的并发量,同时保证网站前端整体的稳定性和可靠性。

    2. 平台保障服务

      平台保障服务用以实现后端微服务的基础框架,包括API路由网关、服务注册中心、服务监控组件。API网关收到前端的请求,不会直接调用后端的业务服务,而是首先会从服务注册中心根据当前请求来获取对应的服务配置,随后通过服务配置再调用已注册的服务。当后端微服务存在多个实例时,将采取负载均衡的方式调用。服务注册中心是整个云原生架构体系的核心部分,由Spring Cloud的Eureka组件来实现,专门提供微服务的服务注册和发现功能,涉及三种角色:服务提供者、服务消费者和服务注册中心。API路由网关、所有业务服务,以及服务监控平台组件都注册到服务注册中心。通过服务注册中心两两互相注册、API路由网关向服务注册中心注册多个实例等方式,来实现后端整体服务的高可靠性。服务监控平台通过注册到服务注册中心,获取所有注册到服务注册中心的后端业务服务,从而监控到所有后端业务服务的运行状态信息,最后收集并展示整个微服务系统的运行状态,更进一步保证整个后端的服务质量。

    3. 业务服务

      业务服务按功能模块,相应划分为题库服务、评测机服务、考试服务、比赛服务、抄袭判定服务等。各服务单独打包,基于Docker容器,连同运行环境一起封装,根据实际情况可在一台或多台物理机同时部署多个实例,服务启动后会将自身信息注册到服务注册中心。服务间协同工作,通过松耦合的服务发现机制,动态调用对方REST API接口。对于压力较大的服务,如评测机服务、抄袭判定服务等,将部署为多实例集群。以在线考试功能为例,用户进入考试时,考试服务核验考生信息通过,调用题库服务,题库服务返回试题,由考试服务组合成试卷,返回前端显示。用户交卷时,提交的程序代码到达考试服务,考试服务拆分后分发给题库服务,题库服务将程序代码和测试用例送入MQ队列排队。然后由负载均衡机制,依次将队列中待评测程序分发给评测机服务编译、执行、判分,完成评测后,题库服务统计试题通过率,考试服务统计成绩并向前端显示。在此期间服务请求者无需了解其他服务对数据如何具体处理和分析。

    总结

      系统自2019年10月正式上线已运行一年有余,在学校的日常教学考试和竞赛培训中投入使用,至今已有3000名以上的学生用户,评测了70000份以上的程序代码,获得了单位同事领导和学校教师们的一致好评。在开发和试运行过程中,主要遇到了两个问题。一是跨域问题。OJ系统前后端分离,前端通过Ajax访问后端服务。由于浏览器同源策略的限制,导致前端UI无法正常访问不同端口和IP的后端服务。我们利用Spring Boot后端的Cors跨域机制解决了该问题。二是评测机宕机问题。评测机服务需要执行用户提交的代码,部分用户短时间内提交了大量不安全代码,导致评测机集群中所有实例全部宕机。我们引入心跳机制、快照回滚机制,以及基于机器学习技术的预判断机制,使评测机宕机时能够在10秒内自动重置恢复运行,最终解决了该问题。
      实践证明,OJ系统项目能够顺利上线,并且稳定运行,与系统采用了合适的架构设计密不可分。经过这次云原生架构的方法和实施的效果后,我也看到了自己身上的不足之处,在未来还会不断更新知识,完善本系统在各方面的设计,使整个OJ系统能够更加好用,更有效地服务于高校师生。

    展开全文
  • ACNA 的概念阿里巴巴为大量各行各业的企业客户提供了基于阿里服务的解决方案和最佳实践,以帮助企业完成数字化转型,并积累了大量经验和教训。阿里巴巴将企业的核心关注点、企业组织与 IT 文...

    ACNA 的概念

    阿里巴巴为大量各行各业的企业客户提供了基于阿里云服务的解决方案和最佳实践,以帮助企业完成数字化转型,并积累了大量经验和教训。阿里巴巴将企业的核心关注点、企业组织与 IT 文化、工程实施能力等多个方面与架构技术相结合,形成了阿里巴巴独有的云原生架构设计方法— ACNA(Alibaba Cloud Native Architecting )。这套方法在阿里云官方最近出版的畅销书《阿里云云原生架构实践》中有更详尽的介绍。

    (1)ACNA 的作用与目的

    1)提升研发团队的能力,实现成本、进度计划、功能和质量等目标。

    2)指导研发团队控制研发和运维过程,优化 IT 组织结构并打造更加高效的软件工程流程机制。

    3)引导研发团队,在确定云原生架构的成熟度以及定位云原生化方面关键问题的过程中选择改进策略。

    (2)ACNA 的实现步骤

    1)确定企业当前所处的云原生架构成熟度级别。

    2)了解会对改进生产质量和优化过程起关键作用的因素。

    3)将工作重点集中在有限的几个关键目标上,从而有效达到优化现有研发流程的效果,进而持续改进产品。

    ACNA 是一个“ 4+1 ”的架构设计流程,其中,“ 4 ”代表架构设计的关键视角,包括企业战略视角(ACNA-S1)、业务发展视角(ACNA-S2)、组织能力视角(ACNA-S3)和云原生技术架构视角(ACNA-S4);“ 1 ”表示云原生架构的架构持续演进闭环(ACNA-S5)。4 个关键视角和 1 个闭环的关系(命名为 ACNA-G1 ),如图 1 所示。

    图 1   ACNA-G1:ACNA 架构设计流程关系示意图

    ACNA 除了是一种架构设计方法,还包含对云原生架构的评估体系、成熟度衡量体系、行业应用最佳实践、技术和产品体系、架构原则、实施指导等。本书的其他章节将分别详细讲解云原生的技术和产品体系、架构原则、最佳实践等方面,这里主要介绍云原生架构的成熟度衡量体系和实施指导两个方面。

    ACNA-S1:企业战略视角

    任何架构都必须服务于企业战略,云原生架构也不例外!与以往架构的升级有所不同,云原生架构的升级不仅是技术的升级,更是对企业核心业务生产流程(即通过软件开发和运营构建数字化业务)的一次重构,云原生架构升级的意义,如同工业时代用更自动化的流水线替换手工作坊一样深刻。

    企业必须清楚业务战略与云 IT 战略之间的关系,即云 IT 战略只是对业务战略进行必要的技术支撑,还是云 IT 战略本身也是业务战略的一部分。通常,高科技公司会对云计算提出更高的需求,比如,通过大量使用云厂商提供的 AI 技术为用户提供智能化的用户体验,以及使用 IoT(物联网)和音视频技术为用户建立更广泛、生动的连接。

    实际上,在数字化转型的今天,越来越多的企业认为云 IT 战略应该在企业业务战略中扮演技术赋能业务创新的重要角色,云 IT 已经变成了“ Cloud First ”,甚至“ Cloud Only ”,只是在全部采用公有云还是采用混合云的策略上存在一些差别。基于云 IT 战略,云原生架构可以帮助企业实现泛在接入技术,构建数字化生态系统,还可以从技术的角度确保数字化业务的快速迭代,构建面向用户体验管理的数字基础设施,持续优化 IT 成本,降低业务风险。

    ACNA-S2:业务发展视角

    阿里巴巴在为企业提供云服务和咨询的过程中发现,数字化业务对技术架构的主要诉求是保证业务连续性、业务快速上线、业务成本控制,以及科技赋能业务创新。业务连续性诉求主要是指数字化业务必须能够为用户持续提供服务,不能因为软硬件故障或 Bug 导致业务不可用,还要能够防止黑客攻击、数据中心不可用、自然灾害等意外事故发生。此外,当业务规模快速增长时,软硬件资源的购买和部署一定要及时,以便企业能够更好地拓展新用户。

    市场瞬息万变,相较于传统业务,数字化业务具有更灵活的特性,这就要求企业具备更快的“业务到市场”的能力,包括新业务快速构建、现有业务快速更新等。云原生架构能够深刻理解企业对这些能力的诉求,并在产品、工具、流程等多个层面进行不同程度的处理。需要注意的是,这些诉求同时对组织结构带来新的要求,可能会要求应用进行彻底重构(比如微服务化)。

    云计算必须为企业释放成本红利,帮助企业从原来的 CaPex 模式转变为 OpEx 模式,即不用事先购买大批软硬件资源,而是用多少支付多少;同时,大量采用云原生架构也会降低企业的开发和运维成本。有数据显示,通过容器平台技术可使运维支出成本降低 30%。

    传统模式下,如果要使用高科技赋能业务,则会经历一个冗长的选型、POC、试点和推广的过程,而如果选择使用云厂商和第三方提供的云服务,则可以更快速地应用新技术进行创新。因为这些云服务具备更快的连接速度和更低的试错成本,且在不同技术的集成上具备统一平台和统一技术依赖的优势。

    ACNA-S3:组织能力视角

    云原生架构升级是对企业的整个 IT 架构的彻底升级,每个组织在进行云原生架构升级时,必须根据企业自身的情况量体裁衣,其中,组织能力和技术栈处于同等重要的地位。云原生架构涉及的架构升级对企业中的开发、测试和运维等相关人员都带来了巨大的影响,技术架构的升级和实现需要企业中相关组织的积极参与和配合。特别是在架构持续演进的过程中,需要类似“架构治理委员会”这样的组织负责云原生的规划和落地,并不断检查和评估架构设计与执行之间是否存在偏差。

    此外,云原生架构的设计还需要考虑组织结构的改变。前面提到一个非常重要的云原生架构原则就是服务化(包括微服务、小服务等),这个领域的一个典型原则就是康威定律,要求企业的技术架构与沟通架构必须保持一致,否则会导致畸形的服务化架构,甚至导致组织沟通成本上升和“扯皮”现象增多的问题。

    企业需要考虑的另外一个很重要的问题就是,企业接受改变的程度如何,或者说,企业能够快速进行组织结构调整,并保持业务稳定性的能力如何。云原生架构升级要求大量的企业 IT 人员也进行技术体系的升级和岗位职能的重新设计,这势必导致原本处于稳定和舒适区的技术领导者和底层员工必须破而再立,所以组织改变的风险不得不慎重考虑。

    ACNA-S4:云原生技术架构视角

    从技术架构的维度看,ACNA 认为架构维度包含七个重要的领域,具体说明如下。

    (1)服务化能力

    用微服务或小服务构建业务,分离大块业务中具备不同业务迭代周期的模块,业务以标准化 API 等方式对模块进行集成和编排;服务间采用事件驱动的方式集成,减少相互依赖;通过可度量建设不断提升服务的 SLA(Service Level Agreement,服务等级协议)能力。

    (2)弹性能力

    利用云资源的特性,根据业务峰值和资源负载情况来自动扩充或收缩系统的规模,业务不再需要进行容量评估、按量付费。

    (3)无服务器化程度

    在业务中,应尽量使用云服务,而不是自己持有第三方服务,特别是自己维护开源软件的模式;应用的设计应尽量变换成无状态模式,把有状态的部分保存到云服务中。进一步采用 Serverless 技术体系重构应用运行时,让软件的底层运维逐渐“消失”。

    (4)可观测性

    IT 设施需要得到持续治理,任何 IT 设施中的软硬件发生错误后都要具备快速修复的能力,以避免影响业务,这就需要系统具备全面的可观测性,内容涉及对传统的日志方式、监控、APM、链路跟踪、服务质量(Quality of Service,QoS)度量等多个方面。

    (5)韧性能力

    韧性能力除了包括服务化中常用的熔断、限流、降级、自动重试、背压等特性之外,还包括高可用、容灾、异步化等特性。

    (6)自动化水平

    关注开发、测试和运维三个过程的敏捷性,推荐使用容器技术自动化软件构建过程、使用 OAM 标准化软件交付过程、使用 IaC(Infrastructureas Code ,基础设施即代码)和 GitOps 等自动化 CI/CD 流水线和运维过程。

    (7)安全能力

    关注业务的数字化安全,在利用云服务加固业务运行环境的同时,采用安全软件生命周期开发,使应用符合 ISO27001、PCI/DSS、等级保护等安全要求。安全能力是基础维度,要求在架构评测中关注,但它不会参与评分。

    ACNA-S5:架构持续演进闭环

    云原生架构演进是一个不断迭代的过程,每一次迭代都要经历从企业战略、业务诉求到架构设计与实施这样一个完整的闭环,整体关系(命名为 ACNA-G2)如图2所示。

    图 2  ACNA-G2:架构持续演进闭环

    下面就来详细介绍架构持续演进闭环的关键输入和实现过程。

    1.  关键输入

    1)企业战略视角(ACNA-S1):包括数字化战略诉求、技术战略(特别是云战略)诉求、企业架构诉求等,建议量化描述创新效率提升百分比、IT 成本降低值、风险成本降低值等。

    2)业务发展视角(ACNA-S2):包括新业务(特别是数字化业务)的技术诉求、BI/AI(商业智能 / 人工智能)诉求、IoT(物联网)诉求、用户体验诉求等,建议量化描述业务迭代速度提升值、用户体验改善百分比、业务开发效率提升百分比等。

    2.  关键过程

    1)识别业务痛点和架构债务(ACNA-S5-P1):明确并量化业务痛点(比如,云上云下一套部署、端到端的可观测性等);技术债务依据各企业的具体情况而有所不同,通常包含容器化改造、CI/CD 完善、微服务改造、老应用下线、遗留系统集成方案、非 x86 架构的转移等。

    2)确定架构迭代目标(ACNA-S5-P2):建议每次迭代不超过 1 年,并通过 OKR(ObjectiveandKey Result,目标与关键成果法)的方式,在目标中描述本次迭代的业务目标,在关键成果中量化业务价值和技术价值。注意,在确定迭代目标的时候,要充分识别架构升级的利益相关者(Stakeholder)及其价值诉求,避免出现项目很成功但是得不到业务方认同的情况。

    3)评估架构风险(ACNA-S5-P3):风险和价值往往是一对矛盾体,不要因为风险大而不做云原生架构升级,也不要因为迫切升级而忽视风险,建议在风险和价值间获得平衡。P3 阶段的重点是识别风险类别和风险点,它们会根据企业所在行业和企业自身特性的不同而不同。风险类别通常包括组织风险、市场风险、技术风险、设计实现风险、实施落地风险、运维风险、IT 文化风险、财务风险、数据风险、合规风险等。

    4)选取云原生技术(ACNA-S5-P4):P4 阶段需要从云原生技术栈中选取在本次迭代中需要采用的云原生技术,也需要把采用该技术可能造成的风险和带来的价值放在首位考虑。

    5)制订迭代计划(ACNA-S5-P5):P5 阶段需要充分考虑是否每个里程碑都能够得到各参与方的认同,一定要避免先闭门开发然后期望产出一个高价值产品的情况,因为像云原生架构升级这样的项目,需要与各参与方深度合作,且在执行过程中很可能出现改变计划和目标的情况。

    6)架构评审和设计评审(ACNA-S5-P6):P6 阶段作为改变企业整个生产流水线的重要架构升级,需要在技术上进行架构评审和重要设计评审,让重要设计在各参与方之间得到认同,这也是减少整体风险的重要手段。

    7)架构风险控制(ACNA-S5-P7):在 P3 阶段确定了风险点之后,就需要马上设定这些风险的监控方法和预警阈值,并在架构升级的过程中不断监控这些阈值的变化情况,做到实时风险评估和预警。整体而言,在整个实施过程中,企业需要建立“识别—监控—评估—预警—改进”的风控闭环。

    8)迭代验收和复盘(ACNA-S5-P8):为了让云原生架构升级的下一个迭代取得成功,即使本次迭代已经成功验收,也需要团队客观、深入地对本次迭代的得失进行复盘,特别是在组织能力、项目和产品的管理能力等软技能。

    云原生架构成熟度模型

    云原生架构成熟度模型是一种能够帮助企业找到当前软件架构与成熟的云原生架构之间的差距,从而在后续的架构优化迭代中进行针对性改善的评估模型。ACNA 参考 CMM(Capability Maturity Model,能力成熟度模型)的定义,从主要的架构维度定义了云原生架构的成熟度模型。我们需要注意到,ACNA 的云原生架构成熟度评估模型不会帮助企业从通用技术架构、应用架构或信息架构的维度进行评估,因此它并没有帮助实施者梳理架构的核心利益相关者和架构交付合同。同时,评估模型本身也没有对团队核心人员技能以及组织的流程、文化和流水线建设进行评估,而是从基于云的现代化应用这   一特定的软件技术架构进行评估。虽然这样的评估范围相对较小,但是更专业,可操作性更强。

    此外,ACNA 云原生架构成熟度模型的评估对象不是企业或架构实施人员,而是某个具体软件所采用的架构。因此,对于一个企业而言,可能部分软件的评估结果是零级(初始级),部分软件的评估结果是中级(发展级),这完全取决于每个软件自身的架构情况。

    6 个评估维度

    ACNA 云原生架构设计共包含 6 个关键架构维度(Service + Elasticity + Serverless + Observability + Resilience + Automation,简写为 SESORA),在此我们先定义关键维度的成熟度级别,如图 3 所示(命名为 ACNA-T1)。

    图 3   ACNA-T1:云原生架构成熟度模型:关键指标维度

    结合云原生架构的四个不同成熟阶段,我们定义了整个架构的成熟度模型,如图 4 所示。

    图 4   云原生架构成熟度模型

    评估模型的实施指导和工作表

    评估模型实施指导的整个工作流程(命名为 ACNA-T2)如表 5 所示。

    表5    ACNA-T2:云原生架构评估模型实施指导的工作流程

    为了统一 ACNA 评估模型的产出,我们给出了统一的《云原生架构评估表》(命名为 ACNA-T3 ),以让用户对结果有一致的认知,如表 6 所示。

    表6   ACNA-T3:云原生架构评估表

    服务化能力的评估

    服务化能力的评估(命名为 ACNA-T4-1)如表 7 所示。

    表 7   ACNA-T4-1:服务化能力评估表

    弹性能力的评估

    弹性能力的评估(命名为 ACNA-T4-2)如表 8 所示。

    图8    ACNA-T4-2:弹性能力评估表

    无服务器化程度的评估

    无服务器化(Serverless)程度的评估(命名为 ACNA-T4-3)如表 9 所示。

    表9   ACNA-T4-3:无服务器化程度评估表

    可观测性的评估

    可观测性的评估(命名为 ACNA-T4-4)如表 10 所示。

    表10    ACNA-T4-4:可观测性评估表

    韧性能力的评估

    韧性能力的评估(命名为 ACNA-T4-5)如表 11 所示。

    表11    ACNA-T4-5:韧性能力评估表

    自动化能力的评估

    自动化能力的评估(命名为 ACNA-T4-6)如表 12 所示。

    表12    ACNA-T4-6:自动化能力评估表

    更多信息

    《阿里云云原生架构实践》由阿里云官方出品,阿里云智能总裁张建锋、阿里巴巴首席技术官程立联袂推荐;从设计原则、模式/反模式、技术选项、设计方法、行业案例等多个维度全面总结阿里云云原生架构的方法论和实践经验。

    展开全文
  • 什么是云原生架构? 什么是K8S?K8S的优势、解决了哪些问题? 为什么要使用云原生和K8S
  • 快速了解云原生架构

    千次阅读 2021-02-01 11:09:23
    简介: 云原生架构本质上也是一种软件架构,最大的特点是在云环境下运行,也算是微服务的一种延伸。 起源 1. 云原生(Cloud Native)的由来 云原生的概念最早开始于 2010 年,在当时 Paul Fremantle 的一篇博客中...
  • 陈浪交,腾讯云容器产品架构师团队负责人,负责腾讯云容器产品的售前、售后相关工作。本文整理自腾讯云容器产品,容器解决方案架构团队的陈浪交在 Techo 开发者大会云原生专题的分享内容——一...
  • 简介:作为一种架构模式,云原生架构通过若干原则来对应用架构进行核心控制。这些原则可以帮助技术主管和架构师在进行技术选型时更加高效、准确,下面将展开具体介绍。 服务化原则 在软件开发过程中,当代码数量与...
  • 把应用迁移到云上就是云原生架构吗?什么才是云原生架构?为什么要作云原生架构?本文告诉你,除了把应用搬到云上,要实现云原生,你还要做很多。
  • 我承诺一周内完成项目,为了高质量的尽快完成项目,我使用了云原生的方案。 通过分析这个云原生方案,可以让读者了解到,如何通过一些云服务来快速实现安全、可扩展的应用。 先来看架构图吧: 基本业务介绍 这个...
  • 数字化转型的十年,也是云计算高速发展的十年,这期间新技术不断演进、优秀开源项目大量涌现,云原生领域进入“火箭式”发展阶段。通过树立技术标准与构建开发者生态,开源将云计算实施逐渐标准化,大幅降低了开发者...
  • 简介:云原生和边缘计算是近两年都非常火的技术话题了,在第十届云计算标准和应用大会上,阿里云高级技术专家熊鹰分享了《基于融合、协同系统的边缘云原生架构演进和实践》,希望通过介绍现在阿里云在边缘计算和边缘...
  • 奈学p7云原生架构

    2021-10-25 09:02:58
    云原生的概念主要是基于容器云,其主要原则是,软件产品从设计、开发到交付,全流程都考虑适配容器云的环境。传统的开发,是本地开发与测试,测试环境再次测试,然后部署上线,如果有上容器的需求,那么再编写...
  • 公众号关注「奇妙的 Linux 世界」设为「星标」,每天带你玩转 Linux !现在越多越多的公司并没有自己自建的机房,都采用了厂商的服务器,通常我们认为采用类似架构的系统为架构。...
  • 快速了解云原生架构 作者:潘义文(空易) 原文链接 简介: 云原生架构本质上也是一种软件架构,最大的特点是在云环境下运行,也算是微服务的一种延伸。 1. 云原生(Cloud Native)的由来 云原生的概念最早开始于 ...
  • 本书亮点阿里云官方出品,阿里云智能总裁、阿里巴巴首席技术官等推荐,全面总结阿里云云原生架构方法论与实践经验。读者对象开发人员:本书可帮助开发人员熟悉云原生架构的相关技术,使之能够从宏观架构...
  • 未来的软件,从诞生起,就是生在云上,长在云上的。这个说法绝对不是没有根据的,看看现在的互联网大厂在做的事情,你就知道了:阿里宣布成立云原生技术委员会,并投入数十亿大力推动阿里经济体全面云...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 64,663
精华内容 25,865
关键字:

云原生架构