精华内容
下载资源
问答
  • 公众号关注「奇妙的 Linux 世界」设为「星标」,每天带你玩转 Linux !现在越多越多的公司并没有自己自建的机房,都采用了厂商的服务器,通常我们认为采用类似架构的系统为架构。...

    公众号关注 「奇妙的 Linux 世界」

    设为「星标」,每天带你玩转 Linux !



    现在越多越多的公司并没有自己自建的机房,都采用了云厂商的服务器,通常我们认为采用类似架构的系统为云化架构。尤其是现在 Kubernetes 已经被越来越多的公司和云计算公司采用,这样对于采用云化架构的公司来说,使用云计算公司的服务器变得越来越简单,同时从一个云迁移到另一云也没有太多的适配成本。

    而使用云原生架构的公司如何画自己系统的架构图呢?今天要推荐的一个开源项目 Diagrams,就是帮助大家更好的描绘云原生架构,而且不需要使用任何的设计工具,只需要写代码就可以了,对于写代码当然是工程师擅长的。

    Diagrams 目前支持主流的云厂商,包括 AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud 等。同时支持一些内置的架构图组件、SaaS 和主流的编程框架和语言。

    我们来看下实际的效果:

    由于 Diagrams 采用代码的形式描绘云化架构图,所以所有的变更都可以方便的使用版本控制系统去管理,比如使用 Git 管理。

    从代码的结构来看整体使用起来也比较简单,基本是先声明所有的节点,再根据指向关系链接成对应的架构图,非常的方便。

    更多项目详情请查项目地址:https://github.com/mingrammer/diagrams

    本文转载自:「 GitHub精选 」,原文:https://tinyurl.com/m4ua8be4 ,版权归原作者所有。欢迎投稿,投稿邮箱: editor@hi-linux.com。


    你可能还喜欢

    点击下方图片即可阅读

    如何提高 Grafana 海量数据场景下的图表访问速度

    更多有趣的互联网新鲜事,关注「奇妙的互联网」视频号全了解!

    展开全文
  • 一、云原生架构原则 云原生架构本身作为一种架构,也有若干架构原则作为应用架构的核心架构控制面,通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。 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 方案,大家还在等什么呢?一起实践起来吧。


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

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

    展开全文
  • 云原生全景详解

    2021-07-29 00:08:45
    带你了解云原生技术图谱如果你研究过云原生应用程序和相关技术,大概率你遇到过 CNCF 的云原生全景。这张全景技术之多规模之大无疑会让人感到震惊,该如何去理解这张图呢?如果把它拆开来一次...

    带你了解云原生技术图谱

    如果你研究过云原生应用程序和相关技术,大概率你遇到过 CNCF 的云原生全景图。这张全景图技术之多规模之大无疑会让人感到震惊,该如何去理解这张图呢?

    如果把它拆开来一次只分析一小块内容,你会发现整个全景图没有那么复杂。事实上,该全景图按照功能有序地组织在一起,一旦你了解了每个类别代表的内容,你就可以轻松游走于全景图中。

    本章节我们将把整个全景图拆解开来,并对整个全景图进行综述。在后续章节中,我们将聚焦在每一层(or 每一列),对每个类别解决的问题和原理进行更为详细的解读。

    云原生全景图的 4 层

    首先,我们剥离掉所有单个的技术,仅查看类别(如下图)。图中有不同的“行”,像建筑的不同层,每层都有自己的子类别。最底层提供了构建云原生基础设施的工具。往上,你可以开始添加运行和管理应用程序所需的工具,比如运行时和调度层。在最上层,有定义和开发应用程序的工具,比如数据库、镜像构建和 CI/CD 工具(我们将在后文讨论)。

    好了,现在你应该记住了云原生全景图始于基础设施,往上的每一层都更接近实际的应用程序。这就是每层代表的意思(后面我们会讨论上图右边的两“列”)。下面我们就从最底层开始,逐层进行解析。

    供应层 (Provisioning)

    供应指的是为云原生应用准备标准基础环境所涉及的工具。它包含了基础设施的创建、管理、配置流程的自动化,以及容器镜像的扫描、签名和存储等。供应层通过提供设置和实施策略,在应用程序和平台中构建身份验证和授权,以及处理密钥分发等等的工具,也拓展到了安全领域。

    供应层包括:

    • 自动化和部署工具:帮助工程师在无需人工干预情况下即可构建计算环境;

    • 容器注册表:存储应用程序的可执行文件;

    • 不同安全领域的安全和合规框架;

      密钥管理解决方案:通过加密确保只有授权的用户才能访问特定的应用程序。

    • 这些工具使工程师可以编写基础设施参数,使系统可以按需搭建新环境,确保了一致性和安全性。

    运行时层(Runtime)

    接下来是运行时层。这个词可能会让你感到迷惑。像很多 IT 术语一样,运行时没有严格的定义,且可以根据语境有不同的用法。狭义上讲,运行时是特定机器上准备运行应用程序的沙盒——也就是保障应用程序正常运行所需的最低配置。广义上讲,运行时是运行一个应用程序所需的所有工具。

    在 CNCF 云原生全景图中,运行时保障了容器化应用程序组件的运行和通信, 包括:

    • 云原生存储:为容器化应用提供虚拟磁盘或持久化存储;

    • 容器运行时:为容器提供隔离、资源和安全;

    • 云网络:分布式系统的节点(机器或进程)通过其连接和通信。

    编排和管理层(Orchestration and Management)

    一旦按照安全和合规性标准(供应层)自动化基础设施供应,并安装了应用程序运行所需的工具(运行时层),工程师就需要弄清楚如何编排和管理应用程序。编排和管理层将所有容器化服务(应用程序组件)作为一个群组管理。这些容器化服务需要相互识别和通信,并需要进行协调。这一层可为云原生应用提供自动化和弹性能力,使云原生应用天然具有可扩展性。

    这一层包含:

    • 编排和调度:部署和管理容器集群,确保它们具有弹性伸缩能力,相互之间低耦合,并且可扩展。事实上,编排工具(绝大多数情况下就是 Kubernetes)通过管理容器和操作环境构成了集群;

    • 协调和服务发现:使得服务(应用程序组件)之间可以相互定位和通信;

    • 远程进程调用(RPC):使跨节点服务间通信的技术;

    • 服务代理:服务间通信的中介。服务代理的唯一目的就是对服务之间的通信进行更多控制,而不会对通信本身添加任何内容。服务代理对下面将提到的服务网格(Service Mesh)至关重要。

    • API 网关:一个抽象层,外部应用可通过 API 网关进行通信;

    • Service Mesh:某种程度上类似于 API 网关,它是应用程序进行通信的专用基础架构层,提供基于策略的内部服务间通信。此外,它还可能包含流量加密、服务发现、应用程序监控等内容。

    应用定义和开发层 (Application Definition and Developement)

    现在,我们来到了最顶层。应用定义和开发层,顾名思义,聚集了让工程师构建和运行应用程序的工具。上述所有内容都是关于构建可靠、安全的环境,以及提供全部所需的应用程序依赖。

    这一层包括:

    • 数据库:使应用程序能以有序的方式收集数据;

    • 流和消息传递:使应用程序能发送和接收消息(事件和流)。它不是网络层,而是让消息成为队列并处理消息的工具;

    • 应用程序定义和镜像构建:用于配置、维护和运行容器镜像(应用程序的可执行文件)的服务;

    • 持续集成和持续交付(CI/CD):使开发者可自动测试代码是否与代码库(应用程序的其余部分)兼容。如果团队足够成熟,甚至可以自动部署代码到生产环境。

    贯穿所有层的工具

    接下来我们将进入到云原生全景图右侧贯穿所有层的两列。可观察性和分析(Observability&analysis)是监控各层的工具,平台则将各层中不同的技术捆绑为一个解决方案。

    可观察性和分析(Observability and Analysis)

    为了限制服务中断并降低解决问题的平均时间(MRRT),你需要监控和分析应用层序的方方面面,以便在出现异常时可立即发现并纠正。复杂环境中容易出现故障,这些工具可快速识别并解决故障,从而降低故障带来的影响。由于这一类别贯穿并监控各层,因此它在侧面,而不是嵌入到某一层中。

    这这一类别你将发现:

    • 日志工具:收集事件日志(有关进程的信息);

    • 监控方案:收集指标(以数字表示的系统参数,例如 RAM 可用性);

    • 追踪工具:追踪比监控更进了一步,它们监控用户请求的传播,与服务网格相关。

    • 混沌工程(Chaos Engineering):在生产环境中测试软件的工具,可识别缺陷并进行修复,减少其对服务交付的影响。

    平台类(Platform)

    可以看到,图中每一个模块解决一个特定的问题。但我们知道,仅有存储并不能提供应用程序所需的全部功能。你还需要编排工具,容器运行时,服务发现,网络,API 网关等等。平台覆盖多层,将不同的工具组合在一起,以解决更大的问题。

    配置和微调不同的模块使其安全可靠,并确保它利用的技术都能及时更新、所有漏洞都打了补丁,这并不是一件容易的事情。使用平台时,用户不用额外担心这些细节问题。

    你可能会注意到,所有的类别都围绕着 Kubernetes 展开。这是因为 Kubernetes 虽然只是云原生景观图这张拼图中的一块,但它却是云原生技术栈的核心。顺便说一下,CNCF 刚创建时,Kubernetes 就是其中的第一个种子项目,后来才有了其他项目。

    平台可分为四类:

    • Kubernetes 发行版:采用未经修改的开放源代码(尽管有人对其进行了修改),并根据市场需要增加了其他功能;

    • 托管的 Kubernetes:类似于 Kubernetes 发行版,但是由提供商托管;

    • Kubernetes 安装程序:自动执行 Kubernetes 的安装和配置过程;

    • PaaS/容器服务:类似于托管的 Kubernetes,但是包含了一套更广泛的应用部署工具(通常是来自云原生景观图)。

    小结

    在每个类别中,针对相同或相似的问题,都有不同的工具可选择。有一些是适用于新现实的预云原生技术,还有一些则是全新的。区别在于它们的实现和设计方法。没有完美的技术符合你的所有需求。大多数情况下,技术受设计和架构选择的限制——始终需要权衡取舍。

    在选择技术栈时,工程师必须仔细考虑每种能力和需要权衡取舍的地方,以确定最合适的选项。虽然这样会让情况变得更复杂,但在选择应用程序所需的最适合的数据存储、基础设施管理、消息系统等方案时,这样做是最可行的办法。现在,构建一个系统比云原生之前的时代容易多了。如果构建恰当,云原生技术将提供更强大的灵活性。在现如今快速变化的技术生态中,这可能是最重要的能力之一。

    下面详细介绍云原生全景图的每一层。

    供应层

    云原生全景图的最底层是供应层(provisioning)。这一层包含构建云原生基础设施的工具,如基础设施的创建、管理、配置流程的自动化,以及容器镜像的扫描、签名和存储等。供应层也跟安全相关,该层中的一些工具可用于设置和实施策略,将身份验证和授权内置到应用程序和平台中,以及处理 secret 分发等。

    接下来让我们看一下供应层的每个类别,它所扮演的角色以及这些技术如何帮助应用程序适应新的云原生环境。

    自动化和配置

    是什么

    自动化和配置工具可加快计算资源(虚拟机、网络、防火墙规则、负载均衡器等)的创建和配置过程。这些工具可以处理基础设施构建过程中不同部分的内容,大多数工具都可与该空间中其他项目和产品集成。

    解决的问题

    传统上,IT 流程依赖高强度的手动发布过程,周期冗长,通常可达 3-6 个月。这些周期伴随着许多人工流程和管控,让生产环境的变更非常缓慢。这种缓慢的发布周期和静态的环境与云原生开发不匹配。为了缩短开发周期,必须动态配置基础设施且无需人工干预。

    如何解决问题

    供应层的这些工具使工程师无需人工干预即可构建计算环境。通过代码化环境设置,只需点击按钮即可实现环境配置。手动设置容易出错,但是一旦进行了编码,环境创建就会与所需的确切状态相匹配,这是一个巨大的优势。

    尽管不同工具实现的方法不同,但它们都是通过自动化来简化配置资源过程中的人工操作。

    对应工具

    当我们从老式的人工驱动构建方式过渡到云环境所需的按需扩展模式时,会发现以前的模式和工具已经无法满足需求,组织也无法维持一个需要创建、配置和管理服务器的 7×24 员工队伍。Terraform 之类的自动化工具减少了扩展数服务器和相关网络以及防火墙规则所需的工作量。Puppet,Chef 和 Ansible 之类的工具可以在服务器和应用程序启动时以编程方式配置它们,并允许开发人员使用它们。

    一些工具直接与 AWS 或 vSphere 等平台提供的基础设施 API 进行交互,还有一些工具则侧重于配置单个计算机以使其成为 Kubernetes 集群的一部分。Chef 和 Terraform 这类的工具可以进行互操作以配置环境。OpenStack 这类工具可提供 IaaS 环境让其他工具使用。

    从根本上讲,在这一层,你需要一个或多个工具来为 Kubernetes 集群搭建计算环境、CPU、内存、存储和网络。此外,你还需要其中的一些工具来创建和管理 Kubernetes 集群本身。

    在撰写本文时,该领域中有三个 CNCF 项目:KubeEdge(一个沙盒项目)以及 Kubespray 和 Kops(后两个是 Kubernetes 子项目,虽然未在全景图中列出,但它们也属于 CNCF)。此类别中的大多数工具都提供开源和付费版本。

    Container Registry

    是什么

    在定义 Container Registry 之前,我们首先讨论三个紧密相关的概念:

    • 容器是执行流程的一组技术约束。容器内启动的进程会相信它们正在自己的专用计算机上运行,而不是在与其他进程(类似于虚拟机)共享的计算机上运行。简而言之,容器可以使你在任何环境中都能控制自己的代码运行。

    • 镜像是运行容器及其过程所需的一组存档文件。你可以将其视为模板的一种形式,可以在其上创建无限数量的容器。

    • 仓库是存储镜像的空间。

    回到 Container Registry,这是分类和存储仓库的专用 Web 应用程序。

    镜像包含执行程序(在容器内)所需的信息,并存储在仓库中,仓库被分类和分组。构建、运行和管理容器的工具需要访问(通过引用仓库)这些镜像。

    解决的问题

    云原生应用程序被打包后以容器的方式运行。Container Registry 负责存储和提供这些容器镜像。

    如何解决

    通过在一个地方集中存储所有容器镜像,这些容器镜像可以很容易地被应用程序的开发者访问。

    对应工具

    Container Registry 要么存储和分发镜像,要么以某种方式增强现有仓库。本质上,它是一种 Web API,允许容器引擎存储和检索镜像。许多 Container Registry 提供接口,使容器扫描/签名工具来增强所存储镜像的安全性。有些 Container Registry 能以特别有效的方式分发或复制图像。任何使用容器的环境都需要使用一个或多个仓库。

    该空间中的工具可以提供集成功能,以扫描,签名和检查它们存储的镜像。在撰写本文时,Dragonfly 和 Harbor 是该领域中的 CNCF 项目,而 Harbor 最近成为了第一个遵循 OCI 的仓库。主要的云提供商都提供自己的托管仓库,其他仓库可以独立部署,也可以通过 Helm 之类的工具直接部署到 Kubernetes 集群中。

    安全和合规

    是什么

    云原生应用程序的目标是快速迭代。为了定期发布代码,必须确保代码和操作环境是安全的,并且只能由获得授权的工程师访问。这一部分的工具和项目可以用安全的方式创建和运行现代应用程序。

    解决什么问题

    这些工具和项目可为平台和应用程序加强、监控和实施安全性。它们使你能在容器和 Kubernetes 环境中设置策略(用于合规性),深入了解存在的漏洞,捕获错误配置,并加固容器和集群。

    如何解决

    为了安全地运行容器,必须对其进行扫描以查找已知漏洞,并对其进行签名以确保它们未被篡改。Kubernetes 默认的访问控制比较宽松,对于想攻击系统的人来说, Kubernetes 集群很容易成为目标。该空间中的工具和项目有助于增强群集,并在系统运行异常时提供工具来检测。

    对应工具

    为了在动态、快速发展的环境中安全运行,我们必须将安全性视为平台和应用程序开发生命周期的一部分。这部分的工具种类繁多,可解决安全领域不同方面的问题。大多数工具属于以下类别:

    • 审计和合规

    • 生产环境强化工具的路径:

      • 代码扫描

      • 漏洞扫描

      • 镜像签名

    • 策略制定和执行

    • 网络层安全

    其中的一些工具和项目很少会被直接使用。例如 Trivy、Claire 和 Notary,它们会被 Registry 或其他扫描工具所利用。还有一些工具是现代应用程序平台的关键强化组件,例如 Falco 或 Open Policy Agent(OPA)。

    该领域有许多成熟的供应商提供解决方案,也有很多创业公司的业务是把 Kubernetes 原生框架推向市场。在撰写本文时,Falco、Notary/TUF 和 OPA 是该领域中仅有的 CNCF 项目。

    密钥和身份管理

    是什么

    在进入到密钥管理之前,我们首先定义一下密钥。密钥是用于加密或签名数据的字符串。和现实中的钥匙一样,密钥锁定(加密)数据,只有拥有正确密钥的人才能解锁(解密)数据。

    随着应用程序和操作开始适应新的云原生环境,安全工具也在不断发展以满足新的需求。此类别中的工具和项目可用于安全地存储密码和其他 secrets(例如 API 密钥,加密密钥等敏感数据)、从微服务环境中安全删除密码和 secret 等。

    解决的问题

    云原生环境是高度动态的,需要完全编程(无人参与)和自动化的按需 secret 分发。应用程序还必须知道给定的请求是否来自有效来源(身份验证),以及该请求是否有权执行操作(授权)。通常将其称为 AuthN 和 AuthZ。

    如何解决

    每个工具或项目实施的方法不同,但他们都提供:

    • 安全分发 secret 或密钥的方法。

    • 身份认证或(和)授权的服务或规范。

    对应的工具

    此类别中的工具可以分为两组:

    • 一些工具专注于密钥生成、存储、管理和轮转。

    • 另一些专注于单点登录和身份管理。

    拿 Vault 来说,它是一个通用的密钥管理工具,可管理不同类型的密钥。而 Keycloak 则是一个身份代理工具,可用于管理不同服务的访问密钥。

    在撰写本文时,SPIFFE/SPIRE 是该领域中唯一的 CNCF 项目。

    供应层专注于构建云原生平台和应用程序的基础,其中的工具涉及基础设施供应、容器注册表以及安全性。本章节详细介绍了云原生全景图的最底层。

    运行时层

    本章节我们将一起了解运行时层(runtime),这一层包含了容器在云原生环境中运行所需的一切。即:启动容器的代码,也叫运行时引擎;使容器获得持久化存储的工具;以及管理容器环境网络的工具。

    但是注意,不要将这一层的资源与基础设施和供应层的网络和存储弄混淆,后者的工作是让容器平台运行起来。容器直接使用运行时层的工具来启动或停止,存储数据,以及相互通信。

    云原生存储

    是什么

    存储是存放一个应用程序持久数据的地方,也叫做持久卷(persistent volume)。轻松访问持久卷对于应用程序可靠运行至关重要。通常,当我们说持久数据的时候,我们是指数据库、消息之类的,或其他任何在应用重新启动时不会丢失的信息。

    解决的问题

    云原生架构具有高度的灵活性和弹性,这使得重启应用时存储持久数据变得很有挑战性。容器化应用程序在扩容、缩容或自动恢复时,会不断地创建或删除实例,并随着时间改变物理位置。因此,必须以与节点无关的方式提供云原生存储。但是,要存储数据,就需要硬件(具体来说是磁盘)。磁盘和其他硬件一样,受到基础设施的限制。这是第一个大的挑战。

    第二个挑战是存储接口。该接口在数据中心之间可能会发生很大的变化(在以前,不同的基础设施都有自己的存储解决方案,并带有自己的接口),这使得可移植性变得非常困难。

    最后,由于云的弹性,存储必须以自动化方式进行配置,因为手动配置和自动扩展不兼容。面临以上这些问题,云原生存储就是为新的云原生环境量身定制的。

    如何解决

    该类别的工具可以:

    • 为容器提供云原生存储选项;

    • 标准化容器与存储提供者之间的接口;

    • 通过备份和还原操作提供数据保护。

    云原生存储意味着使用兼容云原生环境的容器存储接口(也就是下一个类别中的工具),并且可以自动配置,通过消除人力瓶颈从而实现了自动扩展和自我恢复。

    对应工具

    容器存储接口(CSI)在很大程度上使云原生存储变成了可能。CSI 允许使用标准 API 向容器提供文件和块存储。该领域中有很多工具,既有开源的也有供应商提供的,都可利用 CSI 为容器提供按需存储。

    除了这一及其重要的功能,还有一些其他的工具和技术旨在解决云原生空间中的存储问题。Minio 是一个受欢迎的项目,它提供了兼容 S3 的 API 用于对象存储。Velero 之类的工具可帮助简化 Kubernetes 集群本身以及应用程序使用的持久化数据的备份和还原过程。

    容器运行时

    是什么

    前面我们提到过,容器是一组用于执行应用程序的技术约束。容器化的应用程序相信自己正在专用计算机上运行,而忽略了它们其实是与其他进程(类似于虚拟机)共享资源。

    容器运行时是执行容器化(或“隔离”)应用的软件。如果没有运行时,将只有容器镜像——指定容器化应用程序外观的文件。运行时将在容器中启动应用程序,并为其提供所需的资源。

    解决的问题

    容器镜像(带有应用程序规范的文件)必须以标准化、安全和隔离的方式启动:

    • 标准化:无论它们在何处运行,都需要标准操作规则;

    • 安全:访问权限应该要注意设置;

    • 隔离:该应用程序不应影响其他应用程序或受到其他应用程序的影响(例如,位于同一位置的应用程序崩溃)。隔离基本上起到保护作用。

    此外,必须为应用程序提供 CPU、存储、内存等资源。

    如何解决

    容器运行时可以完成所有这些工作。它以标准化方式在所有环境中启动应用程序,并设置安全边界。安全边界是运行时和其他工具不同的地方,CRI-O 或 gVisor 等运行时强化了它们的安全性边界。运行时还为容器设置资源限制。没有资源限制,应用程序可能会根据需要消耗资源,这样就有可能占用其他应用程序的资源。因此设置资源限制是很必要的。

    对应的工具

    不是所有此类别中的工具都一样。Containerd(Docker 产品的一部分)和 CRI-O 是标准的容器运行时实现。有一些工具可以将容器的使用扩展到其他技术,例如 Kata,它允许将容器作为 VM 运行。其他工具旨在解决与容器相关的特定问题,例如 gVisor,它在容器和 OS 之间提供了额外的安全层。

    云原生网络

    是什么

    容器通过云原生网络实现相互之间及和基础设施层之间的通信。分布式应用程序具有多个组件,这些组件将网络用于不同目的。此类别中的工具将虚拟网络覆盖在现有网络之上,专门用于应用程序进行通信,称为覆盖网络(overlay network)。

    解决什么问题

    通常我们将在容器中运行的代码称为应用程序,但实际上,大多数容器中仅包含大型应用程序的一小部分特定功能。诸如 Netflix 或 Gmail 之类的现代应用程序实际上由许多较小的组件组成,每个组件都在自己的容器中运行。为了使所有这些独立的部分正常运行组成一个完整的应用,容器之间需要相互通信。此类别的工具就提供该专用通信网络。

    此外,这些容器之间交换的消息可能是私密的、敏感的或者非常重要的。这导致了其他要求:例如为各种组件提供隔离,检查流量以识别网络问题的能力。在某些情况下,可能还需要拓展这些网络及网络策略(如防火墙和访问规则),以便应用程序可以连接到容器网络外部运行的 VM 或服务。

    如何解决

    此类别中的项目和产品使用 CNCF 中的项目——容器网络接口(Container Network Interface, CNI)为容器化应用提供网络功能。某些工具(例如 Flannel)仅为容器提供基本连接。其他工具(如 NSX-T)提供了完整的软件定义网络层,可为每个 Kubernetes 名称空间创建一个隔离的虚拟网络。

    容器网络至少应该能为 Pod(Kubernetes 中运行容器化应用的地方)分配 IP 地址,以允许其他进程访问。

    对应工具

    CNI 标准化了网络层为 Pod 提供功能的方式,这在很大程度上实现了该领域的多样性和创新性。为 Kubernetes 环境选择网络非常关键,有许多工具可选。Weave Net,Antrea,Calico 和 Flannel 均提供有效的开源网络层,它们的功能各不相同,应根据特定需求进行选择。

    此外,许多供应商已准备好使用软件定义网络(SDN)工具来支持和扩展 Kubernetes 网络,这些工具可使你深入了解网络流量,执行网络策略,甚至将容器网络和策略扩展到更广泛的数据中心。

    本文是对运行时层的概述,该层提供了容器在云原生环境中运行所需的工具,包括:

    • 存储:使应用程序轻松快速访问运行所需的数据;

    • 容器运行时:执行应用程序代码;

    • 网络:确保容器化应用程序之间的通信。

    在下一章节中,我们将探索编排和管理层,该层处理的是如何将所有容器化应用程序作为一个组进行管理。

    编排和管理层

    编排和管理层是 CNCF 云原生全景图的第三层。在使用这一层的工具之前,工程师大概已经按照安全合规标准自动配置了基础设施,并为应用程序设置了运行时(运行时层)。现在,他们必须弄清楚如何将所有应用程序组件作为整体来编排和管理。这些组件必须相互识别以进行通信,并通过协调实现共同的目标。编排和管理层的工具可实现自动化和弹性伸缩,基于此云原生应用程序天然具有可扩展性。

    编排和调度

    是什么

    编排和调度是指在集群中运行和管理容器(一种打包和运送应用的新方式)。集群是通过网络连接的一组机器(物理机或虚拟机均可)。

    容器编排器(和调度器)与电脑上管理所有应用程序(如微软 360、Zoom、Slack 等)的操作系统类似。操作系统执行你想使用的应用程序,并规划哪个应用程序该在何时使用电脑的 CPU 和其他硬件资源。

    虽然在一台机器上运行所有东西很棒,但如今大多数应用程序的大小远非一台机器所能处理,大多数现代的应用程序都是分布式的,这就需要一种软件能够管理在不同机器上运行的组件。简单来说,你需要一个“集群操作系统”。这就是编排工具。

    你可能已经注意到了,在本系列的前几篇文章中,容器频繁出现。容器可以让应用程序运行在不同的环境中,这种能力是关键。容器编排器(大多数情况下是指 Kubernetes)也是如此。容器和 Kubernetes 是云原生架构的核心,所以我们总是听到别人提起它们。

    解决的问题

    在云原生架构中,应用程序被分解成很多小的组件或服务,每个组件或服务都放在一个容器里。你可能已经听说过微服务,指的就是这种情况。现在,你拥有的不再是一个大型的应用程序,而是多个小型的服务,每个服务都需要资源、要被监控,在出现问题的时候也需要修复。对单个服务来说手动执行这些操作是可行的,但当你有上百个容器时,你就需要自动化的流程。

    如何解决

    容器编排器自动化了容器管理的过程。这在实际操作中意味着什么?让我们以 Kubernetes 来回答这个问题,因为 Kubernetes 是事实上的容器编排器。

    Kubernetes 做的事情是“期望状态协调”:将集群中容器的当前状态与期望状态匹配。工程师在文件中指定所需状态,例如:服务 A 的 10 个实例在三个节点(即:机器)上运行,可访问 B 数据库,等等。该状态需持续与实际状态进行比较。如果预期状态与实际状态不匹配,Kubernetes 会通过创建或销毁对象来进行协调(例如:如果某个容器崩溃了,Kubernetes 会启动一个新的容器)。

    简而言之,Kubernetes 允许你将集群视为一台计算机。它仅关注环境并为你处理实现细节。

    对应工具

    Kubernetes 与其他容器编排器(Docker Swarm,Mesos 等)都是编排调度工具,其基本目的是允许将多个不同的计算机作为一个资源池进行管理,并以声明式的方式管理它们,即不必告诉 Kubernetes 如何做,而是提供要完成的工作的定义。这样可以在一个或多个 YAML 文件中维护所需的状态,并将其应用于其他 Kubernetes 集群。然后,编排器本身会创建缺失的内容或删除无需存在的东西。

    虽然 Kubernetes 不是 CNCF 托管的唯一编排器(Crossplane 和 Volcano 是另外两个孵化项目),但它是最常用的,项目也有大量积极的维护者。

    协调和服务发现

    是什么

    现代应用程序由多个单独的服务组成,这些服务之间需要相互协作才能为最终用户提供价值。要进行协作,这些服务通过网络进行通信(我们在运行时层已经讨论过)。要通信,服务需要能相互定位。服务发现就是解决这个问题的。

    解决的问题

    云原生架构是动态的,总是在不断变化。当一个节点上的某个容器崩溃时,一个新的容器会在另一个节点上启动来替代它。或者,当一个应用程序扩展时,它的副本会散布在整个网络中。没有一个地方可以提供特定服务,一切的位置在不断变化。此类别的工具跟踪网络中的服务,以便服务在需要时可以相互查找。

    如何解决

    服务发现工具可提供一个公共的位置来查找和识别单个的服务。该类别中有两种工具:

    • 服务发现引擎:类似数据库的工具,存储的信息包括:存在什么哪些服务以及如何定位它们;

    • 名称解析工具(如 CoreDNS):接收服务位置请求并返回网络地址信息。

    注:在 Kubernetes 中,为了使 Pod 可达,引入了一个称为“Service”的新抽象层。Service 为动态变化的 Pod 组提供了单一稳定的地址。

    请注意,“Service” 在不同的语境中有不同的含义,可能会造成混淆。“services” 通常指位于容器/Pod 中的服务,是实际应用程序中具有特定功能的应用组件或微服务(例如:iPhone 的面部识别算法)。

    而 Kubernetes 的 Service 是一种抽象,可帮助 Pod 相互查找和定位。它是服务(功能上的)作为进程或 Pod 的入口点。在 Kubernetes 中,当你创建了一个 Service (抽象),你就创建了一组 Pod,这些 Pod 一起通过单一 endpoint (入口)提供一个服务(功能)。

    对应工具

    随着分布式系统变得越来越普遍,传统的 DNS 流程和负载均衡器已经无法跟上不断变化的 Endpoint 信息,因此有了服务发现工具。它们可用来处理快速对自身进行注册和注销的各个应用程序实例。一些服务发现工具(例如 etcd 和 CoreDNS)是 Kubernetes 原生的,其他一些工具有自定义的库或工具让服务有效运行。CoreDNS 和 etcd 是 CNCF 项目,并且内置在 Kubernetes 中。

    远程进程调用

    是什么

    远程进程调用(RPC,Remote Procedure Call)是一种使应用程序相互通信的特殊技术。它代表了应用程序相互之间构建通信的一种方法。

    解决的问题

    现代应用程序由众多单独的服务组成,这些服务必须通过通信才能进行协作。RPC 是应用程序之间进行通信的一种方法。

    如何解决

    RPC 可以一种紧耦合且高度自觉的方式处理服务之间的通信。它允许带宽高效的通信,并且许多语言支持 RPC 接口实现。RPC 不是解决此问题的唯一方法,也不是最常见的方法。

    对应工具

    RPC 为服务之间的通信提供了高度结构化且紧密耦合的接口。gRPC 是非常流行的 RPC 实现,已被 CNCF 采用。

    服务代理

    是什么

    服务代理工具用于拦截进出某个服务的流量,对其应用一些逻辑,然后转发该流量到另一个服务。服务代理的本质是一种“中间人”,收集网络流量的信息并对其应用规则。简单如充当负载均衡器将流量转发到单个应用程序,也可复杂如并排运行的代理网格,由单个的容器化应用程序处理所有网络连接。

    服务代理本身很有用,尤其是在将流量从更广泛的网络引到 Kubernetes 集群时。服务代理同时也为其他系统(如 API 网关或服务网格)搭建了基础,我们将在下文讨论。

    解决的问题

    应用程序应以受控方式发送和接收网络流量。为了跟踪流量并对其进行转换或重定向,我们需要收集数据。传统上,开启数据收集和网络流量管理的代码嵌入在每个应用程序中。服务代理可以使我们“外部化”该功能,使其无需再存在于应用程序中,而是嵌入到平台层(应用程序运行的地方)。

    这是非常强大的功能,因为它使开发人员可以完全专注于编写应用程序逻辑,而处理流量的通用任务由平台团队管理(这是平台团队的首要职责)。通过从单个公共位置集中分配和管理全局所需的服务功能(例如路由或 TLS 终止),服务之间的通信将更加可靠,安全和高效。

    如何解决

    代理充当用户和服务之间或不同服务之间的守门员。通过这种独特的定位,他们可以洞悉正在发生的通信类型。根据洞察,他们可以确定将特定请求发送到哪里,甚至完全拒绝该请求。

    代理收集关键数据,管理路由(在服务之间平均分配流量或在某些服务发生故障时重新路由),加密连接和缓存内容(减少资源消耗)。

    对应工具

    服务代理的工作原理是拦截服务之间的流量,对它们执行一些逻辑,然后可能会允许流量继续前进。通过将一组集中控制的功能放入此代理,管理员可以完成几件事。他们可以收集有关服务间通信的详细指标,防止服务过载,并将其他通用标准应用于服务。服务代理是服务网格等其他工具的基础,因为它们提供了对所有网络流量实施更高级别策略的方法。

    请注意,CNCF 将负载均衡器和 ingress provider 包括在此类别中。Envoy,Contour 和 BFE 都是 CNCF 项目。

    API 网关

    是什么

    人们通常通过网页或(桌面)应用程序之类的 GUI(图形用户界面)与计算机程序进行交互,计算机则通过 API(应用程序编程接口)相互进行交互。但是,请勿将 API 与 API 网关混淆。

    API 网关允许组织将关键功能(例如授权或限制应用程序之间的请求数量)移动到集中管理的位置。它还用作(通常是外部的)API 使用者的通用接口。

    通过 API 网关,组织可以集中控制(限制或启用)应用程序之间的交互并跟踪它们,从而实现 拒绝请求、身份验证之类的功能,并防止服务被过度使用(也称为速率限制)。

    解决的问题

    尽管大多数容器和核心应用程序都具有 API,但 API 网关不仅仅是 API。API 网关简化了组织管理规则和将规则应用于所有交互的方式。

    API 网关允许开发人员编写和维护较少的自定义代码。他们还使团队能够查看和控制用户与应用程序本身之间的交互。

    如何解决

    API 网关位于用户和应用程序之间。它充当中介,将来自用户的消息(请求)转发给适当的服务。但是在交出请求之前,它会评估用户的请求是否被允许,并详细记录发出请求的人以及发出的请求数量。

    简而言之,API 网关为应用程序用户提供了具有通用用户界面的单入口点。它还可以将原本在应用程序中实现的任务移交给网关,从而为开发人员节省时间和金钱。

    对应工具

    像该层中的许多类别一样,API 网关从应用程序中删除自定义代码,并将其带入中央系统。API 网关的工作原理是拦截对后端服务的调用,执行某种增值活动,例如验证授权、收集指标或转换请求,然后执行它认为适当的操作。API 网关是一组下游应用程序的通用入口点,同时为团队提供了可以注入业务逻辑以处理授权,速率限制和拒绝请求的地方。它们使应用开发者可以从客户那里提取对下游 API 的更改,并将添加新客户之类的任务交给网关。

    服务网格

    是什么

    如果你已经了解了一些云原生相关的知识,则“服务网格”这个术语可能已经听说过。最近服务网格引起了很多关注。TNS 的长期贡献者 Janakiram MSV 表示,“在 Kubernetes 之后,服务网格技术已成为云原生技术栈中最关键的部分。” 服务网格管理服务之间的流量(即通信)。它们使平台团队能够无需更改任何代码即可在集群内运行的所有服务之间统一添加可靠性,可观察性和安全性功能。

    解决什么问题

    在云原生环境中,我们要处理很多服务,这些服务都需要通信。这意味着在本来不可靠且通常很慢的网络上需要来回传输更多流量。为了应对这些新挑战,工程师必须实施额外的功能。在服务网格之前,必须将该功能编码到每个单独的应用程序中。这些代码通常会成为技术债,并导致失败或漏洞。

    如何解决

    服务网格在平台层的所有服务之间统一增加了可靠性,可观察性和安全性,而无需触及应用程序代码。它们与任何编程语言兼容,使开发团队可以专注于编写业务逻辑。

    注:传统上必须将这些服务网格功能编码到每个服务中,因此每次发布或更新新服务时,开发人员都必须确保这些功能也能使用,会导致很多人为错误。事实上,开发人员更喜欢专注于业务逻辑(产生价值的功能),而不是建立可靠性,可观察性和安全性功能。但对于平台所有者来说,可靠性、可观察性和安全是核心功能,对于他们所做的一切至关重要。让开发人员负责添加平台所有者需要的功能本身很难。服务网格和 API 网关解决了这个问题,因为它们是由平台所有者实现并普遍应用于所有服务的。

    对应工具

    服务网格通过服务代理将集群上运行的所有服务绑定在一起,从而创建了服务的网格。这些是通过服务网格控制平面进行管理和控制的。服务网格允许平台所有者在不要求开发人员编写自定义逻辑的情况下执行常见操作或在应用程序上收集数据。本质上,服务网格是通过向服务代理的网络或网格提供命令和控制信号来管理服务间通信的基础结构层。它的能力在于无需修改应用程序即可提供关键系统功能。

    某些服务网格将通用服务代理(请参见上文)用于其数据平面。另外一些则使用专用代理。例如,Linkerd 使用 Linkerd2-proxy “微型代理”来获得性能和资源消耗方面的优势。这些代理通过边车(sidecar) 统一地附加到每个服务上。Sidecar 是指代理在自己的容器中运行但存在于同一个 Pod 中,就像摩托车边车一样,它是一个单独的模块,附着在摩托车上。

    服务网格提供了许多有用的功能,包括显示详细指标,加密所有流量,限制服务可授权的操作,为其他工具提供额外插件等等。更多详细信息,请查看服务网格接口规范:https://smi-spec.io/

    小结

    编排和管理层的工具旨在将独立的容器化应用作为一个组进行管理。编排和调度工具可以看作是集群操作系统,用于管理整个集群中的容器化应用程序。协调和服务发现,服务代理和服务网格确保服务可以找到彼此并进行有效通信,彼此协作以成为一个流畅的应用程序。API 网关是一个附加层,可对服务通信加以更多控制,尤其是对外部应用程序之间的通信。在下一章节中,我们将讨论应用程序定义和开发层——CNCF 全景图的最后一层。它涵盖数据库、数据流和消息传递、应用程序定义和镜像构建,以及持续集成和交付。

    应用程序定义和开发层

    现在我们来到了云原生全景图的最上层。应用程序定义和开发层,顾名思义,聚焦在帮助工程师构建应用程序并使其运行的工具上。本文前面的内容都是关于构建可靠安全的环境以及提供所有必需的应用程序依赖,应用程序定义和开发层则是关于构建软件。

    数据库

    是什么

    数据库管理系统是一个应用程序,可帮助其他应用程序高效地存储和检索数据。

    数据库能保障数据存储,仅授权的用户能访问数据,并且允许用户通过专门的请求来检索数据。尽管数据库类型繁多,但它们的总体目标都是相同的。

    解决的问题

    大多数应用程序都需要有效的方式来存储和检索数据,并且保证数据安全。数据库使用成熟的技术以结构化的方式进行此操作。

    如何解决

    数据库提供存储和检索应用程序数据的通用接口。开发人员使用这些标准接口,并用一种简单的查询语言来存储、查询和检索信息。同时,数据库允许用户连续备份和保存数据以及加密和管理数据访问权限。

    对应工具

    我们已经了解了数据库管理系统是一种用于存储和检索数据的应用程序。它使用一种通用的语言和界面,并且可以被多种语言和框架轻松使用。

    常见的两种数据库类型为:结构化查询语言(SQL)数据库和 NoSQL 数据库。应用程序该使用哪种数据库应该由其需求来驱动。

    Kubernetes 支持有状态的应用程序,近年来使用 Kubernetes 的使用越来越广泛,我们已经看到了利用容器化技术的新一代数据库。这些新的云原生数据库旨在将 Kubernetes 的扩展性和可用性优势引入数据库。YugaByte 和 Couchbase 之类的工具是典型的云原生数据库,Vitess 和 TiKV 是该领域的 CNCF 项目。

    注意:查看此类别时会发现以 DB 结尾的多个名称(例如 MongoDB、CockroachDB、FaunaDB),你可能会猜测它们代表数据库。还有以 SQL 结尾的各种名称(例如 MySQL 或 MemSQL)。一些是已经适应了云原生环境的“老派”数据库,还有一些是兼容 SQL 的 NoSQL 数据库,例如 YugaByte 和 Vitess。

    数据流和消息传递

    是什么

    数据流和消息传递工具通过在系统之间传输消息(即事件)来实现服务到服务的通信。单个服务连接到消息传递服务以发布事件和(或)从其他服务读取消息。这种动态变化创造了一个环境,在这个环境中单个应用要么是发布者,即可编写事件;要么是订阅事件的订阅者,或者更可能是两者兼而有之。

    解决的问题

    随着服务激增,应用程序环境变得越来越复杂,应用程序之间的通信编排也更具挑战性。数据流或消息平台提供了一个中心位置来发布和读取系统中发生的所有事件,从而使应用程序可以一起工作,而不必相互了解。

    如何解决

    当一个服务执行其他服务应该知道的事情时,它会将事件“发布”到数据流或消息传递工具。需要了解这些事件类型的服务将订阅并监视数据流或消息传递工具。这就是“发布-订阅”的本质。

    通过引入管理通信的“中间层”可以使服务彼此解耦。服务只是监视事件、采取行动并发布新事件,这样能建立高度分离的体系结构。在此体系结构中,服务可以协作而无需彼此了解。这种解耦使工程师能够添加新功能,而无需更新下游应用程序(消费者)或发送大量查询。系统的解耦程度越高,更改的灵活性和适应性就越高,而这正是工程师在系统中所追求的。

    对应工具

    数据流和消息传递工具早在云原生技术成为现实之前就已经存在了。为了集中管理关键业务事件,组织建立了大型的企业级服务总线。但是,当我们在云原生环境中谈论数据流和消息传递时,通常是指 NATS、RabbitMQ、Kafka 或云提供的消息队列之类的工具。

    消息传递和数据流传输系统为编排系统进行通信提供了一个中心位置。消息总线提供了所有应用程序都可以访问的公共位置,应用程序都可以通过发布消息来告诉其服务它们在做什么,或者通过订阅消息来查看正在发生的事情。

    NATS 和 Cloudevents 项目都是这个领域的孵化项目,NATS 提供了一个成熟的消息传递系统,而 Cloudevents 则致力于标准化系统之间的消息格式。Strimzi,Pravega 和 Tremor 是沙盒项目,每个项目都针对数据流和消息传递的独特用例进行了量身定制。

    应用程序定义和镜像构建

    是什么

    应用程序定义和镜像构建是一个广泛的类别,可以分为两个主要的子类别:

    • 聚焦于开发的工具:可帮助将应用程序代码构建到容器和(或)Kubernetes 中;

    • 聚焦于运维的工具:以标准化的方式部署应用。

    无论是加快或简化开发环境,提供标准化的方式来部署第三方应用程序,还是简化编写新的 Kubernetes 扩展的过程,此类别的工具都可以优化 Kubernetes 开发和运维人员的体验。

    解决的问题

    Kubernetes(或者容器化环境)非常灵活且功能强大。这种灵活性也带来了复杂性,主要体现在对于各种新用例有众多配置选项。开发人员必须将代码容器化,并在类生产环境中进行开发。在快速的发布计划周期下,运维人员需要以一种标准化的方法来将应用程序部署到容器环境中。

    如何解决

    该领域的工具旨在解决开发或运维人员面临的一些挑战。对于开发者,有一些工具可以简化扩展 Kubernetes 的过程以构建、部署和连接应用程序。许多项目和产品可以存储或部署预打包的应用程序,使运维人员可以快速部署 Kafka 之类的流服务或安装 Linkerd 之类的服务网格。

    开发云原生应用程序带来了一系列全新的挑战,因此需要大量多样化的工具来简化应用程序的构建和部署。当你需要解决环境中的开发和运维问题时,可以看看此类别中的工具。

    对应的工具

    应用程序定义和构建工具涵盖了广泛的功能,比如使用 KubeVirt 将 Kubernetes 扩展到虚拟机,或使用 Telepresence 之类的工具将开发环境移植到 Kubernetes 中来加速应用程序开发等。从整体上讲,该领域中的工具可以解决开发人员面临的正确编写、打包、测试或运行自定义应用程序的问题,也可以解决运维人员面临的部署和管理应用程序的问题。

    Helm 是该类别中唯一一个毕业的项目,为许多应用程序部署模式奠定了基础。Helm 允许 Kubernetes 用户部署和自定义一些流行的第三方应用程序,Artifact Hub(CNCF 沙箱项目)和 Bitnami 等项目已采用 Helm 来提供精选的应用程序目录。Helm 也足够灵活,允许用户自定义自己的应用程序部署。

    Operator Framework 是一个孵化项目,旨在简化构建和部署 Operator 的过程。Operator 不在本文讨论范围之内,但请注意,它类似于 Helm,有助于部署和管理应用程序。Cloud Native Buildpacks 是另一个孵化项目,旨在简化将应用程序代码构建到容器中的过程。

    持续集成和持续交付

    是什么

    持续集成(CI)和持续交付(CD)工具可通过嵌入式质量保证实现快速高效的开发过程。CI 通过立即构建和测试代码来自动化代码变更,确保生成可部署的制品。CD 则更进一步,推动该制品进入部署阶段。

    成熟的 CI/CD 系统会监视源代码中的变更,自动构建和测试代码,然后将其从开发阶段转移到生产阶段。在此过程中,CI/CD 系统必须通过各种测试或验证来决定该过程是继续还是失败。

    解决的问题

    构建和部署应用程序是一个困难重重且容易出错的过程,特别是当过程中涉及很多人为干预和手动步骤时。如果不将代码集成到代码库中,开发人员在软件上花的时间越长,识别错误所花费的时间就越长,问题修复也就越困难。通过定期集成代码,可以及早发现错误并更轻松地排除故障。毕竟,在几行代码中查找错误比在几百行代码中查找错误要容易得多。

    尽管 Kubernetes 之类的工具为运行和管理应用程序提供了极大的灵活性,它们也为 CI/CD 工具带来了新的挑战和机遇。云原生 CI/CD 系统能够利用 Kubernetes 本身来构建、运行和管理 CI/CD 流程(通常称为流水线)。Kubernetes 还提供应用程序运行状况的信息,从而使云原生 CI/CD 工具能够更轻松地确定给定的变更是否成功,是否需要回滚。

    如何解决

    CI 工具可确保开发人员引入的任何代码更改或更新都能自动、连续地与其他更改进行构建、验证并集成。开发人员每次添加更新时都会触发自动测试,确保只有良好的代码才能将其导入系统。CD 扩展了 CI,能将 CI 流程的结果推送到类生产和生产环境中。

    假设开发人员更改了 Web 应用的代码。CI 系统会看到代码更改,然后构建并测试该 Web 应用的新版本。CD 系统获取该新版本,并将其部署到开发、测试、预生产以及最终生产环境中。在流程的每个步骤之后测试已部署的应用程序时,它会执行此操作。这些系统一起构成了该 Web 应用的 CI/CD 管道。

    对应工具

    随着时间的流逝,市面上已经有了许多工具来帮助将代码从存储库移至运行最终应用程序的生产环境。像大多数其他计算领域一样,云原生开发的到来改变了 CI/CD 系统。类似 Jenkins (可能是市场上使用最广泛的 CI 工具)的传统工具已经通过完善迭代,以更好地适应 Kubernetes 生态系统。Flux 和 Argo 等公司率先开发了一种称为 GitOps 的持续交付的新方法。

    通常,该领域的项目和产品是:

    • CI 系统;

    • CD 系统;

    • 帮助 CD 系统确定代码是否准备好投入生产的工具;和(或)

    • 前三者的合集(Spinnaker 和 Argo 就是如此)。

    Argo 和 Brigade 是该领域中仅有的 CNCF 项目,但是你可以找到由持续交付基金会(Continuous Delivery Foundation)托管的更多项目。在此空间中寻找工具,可以帮助组织自动化生产路径。

    小结

    应用程序定义和开发层中的工具使工程师能够构建云原生应用程序。该层的工具包括:

    • 数据库:存储和检索数据;

    • 数据流和消息传递工具:实现相互分离、精心设计的架构;

    • 应用程序定义和镜像构建工具:包含可改善开发人员和操作员体验的多种技术;

    • CI/CD 工具:确保代码处于可部署状态,并帮助工程师及早发现错误,从而确保代码质量。

    托管 Kubernetes 和 PaaS 解决什么问题

    在之前的内容中,我们讨论了 CNCF 云原生全景图的各层:供应层、运行时层、编排管理层以及应用定义和开发层。本章节我们将聚焦在平台层。

    正如我们在本系列文章中看到的那样,每个类别都解决了特定的问题。仅仅存储并不能提供管理应用程序所需的全部功能,你还需要编排管理、容器运行时、服务发现、网络、API 网关等工具。平台将来自不同层的工具捆绑在一起,以解决更大的问题。

    平台里其实没有新的工具。你当然可以构建自己的平台,事实上,许多组织都这样做。但是,可靠、安全地配置和微调不同的模块,同时确保始终更新所有技术并修补漏洞,这不是一件容易的事。你需要一支专门的团队来构建和维护它。如果没有所需的专业知识,那么使用平台可能会更好。对于某些组织,尤其是工程团队规模较小的组织,平台是采用云原生技术的唯一方法。

    你可能已经注意到了,所有的平台都是围绕 Kubernetes 来演化的,因为 Kubernetes 是云原生技术栈的核心。

    Kubernetes 发行版

    是什么

    发行版是指供应商以 Kubernetes 为核心(采用未经修改的开源代码,尽管有些人对其进行了修改),并将其打包以进行重新发行。通常这个过程需要查找和验证 Kubernetes 软件,并提供集群安装和升级的机制。许多 Kubernetes 发行版都包含其他闭源或开源的应用程序。

    解决的问题

    开源 Kubernetes 并未指定特定的安装工具,而是将许多设置配置选项提供给用户。此外,有限的社区资源(包括社区论坛、StackOverflow、Slack 或 Discord 等)已经不能解决所有的问题。

    随着 Kubernetes 的普及,Kubernetes 的使用变得越来越容易,但是查找和使用开源安装程序可能会面临挑战。用户需要了解使用哪个版本,在何处获取,以及特定组件是否能兼容。此外,还需要决定集群上部署什么软件,要使用哪些设置来确保平台的安全性、稳定性和高性能。所有这些都需要丰富的 Kubernetes 专业知识,而这些知识可能并不容易获得。

    如何解决

    Kubernetes 发行版提供了一种安装 Kubernetes 的可靠方式,并提供了合理的默认值以创建更好、更安全的操作环境。Kubernetes 发行版为供应商和项目提供了所需的掌控度和可预测性,以帮助他们支持客户部署、维护和升级 Kubernetes 集群。

    这种可预测性使发行版提供商在客户遇到生产问题时可为其提供支持。发行版常常提供经过测试和受支持的升级路径,使用户的 Kubernetes 集群保持最新的版本。此外,发行版通常提供可在 Kubernetes 上部署的软件,从而使其更易于使用。

    对应的工具

    如果你已经安装了 Kubernetes,那你可能已经使用了 kubeadm 之类的工具来启动和运行集群。即便如此,你可能还需要 CNI(容器网络接口)来安装和配置它。然后,你可能已经添加了一些存储类,一个处理日志消息的工具,可能还需要个 ingress controller,以及更多其他的工具。Kubernetes 发行版将自动执行部分或全部设置。它还将根据自己对最佳实践或智能默认值的理解提供配置设置。此外,大多数发行版都将捆绑一些经过测试的扩展或附件,以确保用户可以尽快使用新集群。

    我们以 Kublr 为例。它以 Kubernetes 为核心,主要捆绑了来自供应层、运行时层、编排管理层的工具。所有模块都预先配置了一些选项并且开箱即用。不同的平台聚焦不同的功能。就 Kublr 而言,重点是在运维方面,而其他平台则可能聚焦在开发工具上。

    此类别中有很多工具选项。如下图所示,企业可以选择和供应商达成技术合作,比如国外的 Canonical、VMware、Mirantis、SUSE,国内的网易、火山引擎和京东,它们都可以提供出色的开源和商业工具,建议在评估发行版时仔细考虑自己的需求。

    托管 Kubernetes

    是什么

    托管 Kubernetes 是由 Amazon Web Services(AWS)、DigitalOcean、Azure 或 Google 等基础设施提供商(云厂商)提供的服务,允许客户按需启动 Kubernetes 集群。云厂商负责管理 Kubernetes 集群的一部分,通常称为控制平面。托管 Kubernetes 服务与发行版相似,但由云厂商在其基础架构上进行管理。

    解决的问题

    托管 Kubernetes 使团队只需在云厂商开设一个账户即可开始使用 Kubernetes。它解决了 Kubernetes 入门五个过程中的“五 W”问题:

    • Who:云厂商;

    • What:他们托管的 Kubernetes 产品;

    • When:现在;

    • Where:云厂商的基础架构上;

    • Why:由你决定。

    如何解决

    由于 Kuberentes 托管服务提供商负责管理所有细节,因此托管的 Kubernetes 服务是开始云原生之路的最简单方法。用户所需要做的就是开发自己的应用程序并将其部署在托管的 Kubernetes 服务上,这非常方便。托管产品允许用户启动 Kubernetes 集群并立即开始*,同时对集群可用性承担一些责任。值得注意的是,这些服务的额外便利性会造成灵活性的降低:托管的 Kubernetes 服务和云厂商绑定,且用户无法访问 Kubernetes 控制平面,因此某些配置选项会受到限制。

    AWS 的 EKS 略有例外,因为它还要求用户采取一些其他步骤来准备集群。

    对应的工具

    托管 Kubernetes 是由供应商(通常是基础架构托管提供商)提供的按需使用的 Kubernetes 集群,供应商负责配置群集和管理 Kubernetes 控制平面。再次说明,值得注意的例外是 EKS,其上的单个节点配置由客户端决定。

    托管 Kubernetes 服务使组织可以将基础架构组件管理外包出去,这样可以快速配置新集群并降低运营风险。主要的权衡取舍在于可能需要为控制平面管理付费,并且用户的管理权限有限。与自己搭建 Kubernetes 群集相比,托管服务在配置 Kubernetes 群集方面有更严格的限制。

    在这个领域中有许多供应商和项目,在撰写本文时,尚无 CNCF 项目。

    Kubernetes 安装程序

    是什么

    Kubernetes 安装程序可帮助你在机器上安装 Kubernetes,它们可自动化 Kubernetes 的安装和配置过程,甚至可以帮助升级。Kubernetes 安装程序通常与 Kubernetes 发行版或托管 Kubernetes 产品结合使用或由它们使用。

    解决的问题

    与 Kubernetes 发行版相似,Kubernetes 安装程序可简化 Kubernetes 的上手过程。开源的 Kubernetes 依赖于 kubeadm 之类的安装程序。截至本文撰写之时,kubeadm 可用于启动和运行 Kubernetes 集群,是 CKA(Kubernetes 管理员认证) 测试的一部分。

    如何解决

    Kubernetes 安装程序简化了 Kubernetes 的安装过程。像发行版一样,它们为源代码和版本提供经过审核的源。它们还经常自带 Kubernetes 环境配置。像 kind (Docker 中的 Kubernetes)这样的 Kubernetes 安装程序允许通过单个命令获得 Kubernetes 集群。

    对应的工具

    无论是在 Docker 上本地安装 Kubernetes,启动和配置新的虚拟机,还是准备新的物理服务器,都需要一个工具来处理各种 Kubernetes 组件的准备工作。

    Kubernetes 安装程序可简化该过程。有些处理节点启动,还有一些仅配置已供应的节点。它们都提供不同程度的自动化,并且适合不同的用例。开始使用 Kubernetes 安装程序时,应先了解自己的需求,然后选择可以满足这些需求的安装程序。在撰写本文时,kubeadm 是 Kubernetes 生态系统中至关重要的工具,已包含在 CKA 测试中。Minikube、kind、kops 和 kubespray 都是 CNCF 中的 Kubernetes 安装程序项目。

    PaaS/容器服务

    是什么

    PaaS(平台即服务)是一种环境,允许用户运行应用程序而不必了解底层计算资源。此类别中的 PaaS 和容器服务是一种机制,可为开发人员托管 PaaS 或托管他们可以使用的服务。

    解决的问题

    在本篇文章中,我们讨论了有关“云原生”的工具和技术。PaaS 连接了此领域中的许多技术,可为开发人员提供直接价值。它回答了以下问题:

    • 我如何在各种环境中运行应用程序?

    • 一旦应用程序运行起来,我的团队和用户将如何与它们交互?

    如何解决

    PaaS 为组合运行应用程序所需的开源和闭源工具提供了选择。许多 PaaS 产品包含处理 PaaS 安装和升级的工具,以及将应用程序代码转换为正在运行的应用程序的机制。此外,PaaS 可以处理应用程序实例的运行时需求,包括按需扩展单个组件以及可视化单个应用程序的性能和日志消息。

    对应的工具

    组织正在采用云原生技术来实现特定的业务或目标。与构建自定义应用程序平台相比,PaaS 可快速让组织实现价值。Heroku 或 Cloud Foundry Application Runtime 之类的工具可帮助组织快速启动并运行新的应用程序,它们可提供运行云原生应用程序所需的工具。任何 PaaS 都有自身的限制。大多数只支持一种语言或一部分应用程序类型,其自带的一些工具选项可能并不适合你的需求。无状态应用程序通常在 PaaS 中表现出色,而数据库等有状态应用程序通常不太适合 PaaS。目前在这个领域没有 CNCF 项目,但是大多数产品都是开源的。

    小结

    如文中所介绍,有多种工具可帮助简化 Kubernetes 的采用。Kubernetes 发行版、托管 Kubernetes 服务、Kubernetes 安装程序以及 PaaS 都承担了一些安装和配置的工作,可进行预打包。每个解决方案都有其自己的特点。

    在采用上述任何一种方法之前,需要进行一些研究,以确定适合自己需求的最佳解决方案。你可能需要考虑:

    • 我会遇到一些需要掌控控制平面的场景吗?如果有,托管解决方案可能不是一个很好的选择。

    • 我有没有一个小型团队来管理“标准”工作负载,并需要分流尽可能多的操作任务?如果有,托管解决方案可能非常合适你。

    • 便携性对我来说重要吗?

    • 生产就绪情况如何?

    还有更多问题需要考虑。没有一个“最佳工具”,但是对于你的特定需求,肯定可以选择一个有效工具。希望本文能帮助你将搜索范围缩小到正确的区域。

    可观察性是什么,有哪些相关工具

    终于我们来到了云原生全景图详解的最后一章节。本章节将向大家介绍云原生全景图中的可观察性和分析这一“列”。

    首先我们定义一下可观察性和分析(Observability & analysis)。可观察性是一种系统特性,描述了通过外部输出可以理解系统的程度。通过衡量 CPU 时间、内存、磁盘空间、延迟、error 等指标,可以或多或少地观察到计算机系统的状态。分析则是尝试理解这些可用于观察的数据。

    为了确保服务不会中断,我们需要观察和分析应用程序的各个方面,以便立即发现并修复异常情况。这就是可观察性和分析这个类别要做的事情。它贯穿并观察所有层,因此在整个全景图的侧面而不是嵌在某一层。

    此类别中的工具包括日志记录 (logging)、监控 (monitoring)、追踪(tracing) 和混沌工程(chaos engineering)。虽然混沌工程在这里列出,但它更多的是一种可靠性工具,而不是可观察性或分析工具。

    日志记录

    是什么

    应用程序会输出稳定的日志消息流,以描述自身在何时做了什么。这些日志消息会捕获系统中发生的各种事件,例如失败或成功的操作、审计信息或运行状况。日志记录工具将收集、存储和分析这些消息,以追溯错误报告和相关数据。日志记录(loging)、度量(metrics)、追踪(tracing) 是可观察性的三大支柱。

    解决的问题

    收集、存储和分析日志是构建现代平台的关键部分,日志记录可帮助执行这其中的某一项或全部任务。一些工具可处理从收集到分析全方位的工作,还有一些工具则专注于单个任务(例如收集)。所有日志记录工具都旨在帮助组织更好地控制日志消息。

    如何解决

    在收集、存储和分析应用程序的日志消息时,我们将了解应用程序在任何给定时间的通信内容。但请注意,日志代表应用程序有意输出的消息,它们不一定能查明给定问题的根本原因。尽管如此,随时收集和保留日志消息是一项非常强大的功能,它将帮助团队诊断问题并满足合规性要求。

    常用工具

    尽管收集、存储和处理日志消息不是什么新鲜事,但云原生模式和 Kubernetes 的出现极大地改变了我们处理日志的方式。适用于虚拟机和物理机的传统日志记录方法(例如将日志写入文件)不适用于容器化的应用程序,因为在这些容器化应用程序中,文件系统的生命周期可能并不会比应用程序持久。在云原生环境中,诸如 Fluentd 之类的日志收集工具与应用程序容器一起运行,并直接从应用程序收集消息,然后将消息转发到中央日志存储以进行汇总和分析。

    CNCF 中的日志记录工具只有 Fluentd。

    监控

    是什么

    监控是指对应用程序进行检测,收集、聚合和分析日志和指标,以增进我们对应用程序行为的理解。日志描述了特定的事件,而指标则是在给定时间点对系统的度量。日志和 metrics 是两种不同的事物,但是要全面了解系统的运行状况,二者都是必需的。监控的内容包括观察磁盘空间、CPU 使用率、单个节点上的内存消耗,以及执行详细的综合事务以查看系统或应用程序是否正确且及时地进行了响应等。有许多不同的方法可用来监控系统和应用程序。

    解决的问题

    在运行应用程序或平台时,我们希望它完成既定的任务,并确保只有被授权的用户才能访问。通过监控,我们可以知道应用程序/平台是否在正常、安全且高效地运行,是否仅有被授权的用户可以访问。

    如何解决

    良好的监控方法使运维人员能够在发生事故时迅速做出响应,甚至可以自动响应。监控可以让我们洞察系统当前运行的状况,监测到问题进行修复。它能跟踪应用程序运行状况、用户行为等内容,是有效运行应用程序的重要组成部分。

    常用工具

    云原生环境中的监控和传统应用程序的监控类似。我们需要跟踪指标、日志和事件以了解应用程序的运行状况。主要区别在于云原生环境中的某些托管对象是临时的,它们可能不会持久,因此将监控系统与自动生成的资源名称联系在一起并不是一个好策略。CNCF 中有许多监控工具,最主要的是 Prometheus(已经从 CNCF 毕业)。

    追踪

    是什么

    在微服务架构中,服务之间不断通过网络相互通信。追踪是日志记录的一种专门用法,可以跟踪请求在分布式系统中移动的路径。

    解决的问题

    了解微服务应用程序在某个时间点的行为是一项极具挑战的任务。尽管有许多工具可以提供服务行为相关的洞察,但我们可能难以通过单个服务的行为来理解整个应用程序的运行情况。

    如何解决

    追踪对应用程序发送的消息添加唯一标识符,可解决上述问题。该唯一标识符可以跟随/追踪各个事务在系统中移动的路径,可以通过追踪的信息了解应用程序的运行状况,以及调试有问题的微服务或行为。

    常用工具

    追踪是一种功能强大的调试工具,可以对分布式应用程序的行为进行故障排除和 fine-tune。要实现追踪也需要一些成本,比如需要修改应用程序代码以发出跟踪数据,并且所有 Span 都需要由应用程序数据路径中的基础架构组件传播。CNCF 中的追踪工具有 Jaeger 和 Open Tracing。

    混沌工程

    是什么

    混沌工程(chaos engineering)是指有意将故障引入系统以创建更具弹性的应用程序和工程团队的实践。混乱工程工具以一种可控的方式在系统中引入故障,并针对应用程序的特定实例运行特定的实验。

    解决的问题

    复杂的系统会出现故障。故障的原因有多种,给分布式系统带来的后果也很难预测。一些组织已经接受了这一点,他们愿意采用混沌工程技术,不去试图防止故障的发生,而是设法练习从故障中恢复。这被称为优化平均修复时间(MTTR)。

    如何解决

    在云原生环境中,应用程序必须动态适应故障——这是一个相对较新的概念。这意味着当出现故障时,系统不会完全崩溃,而是可以优雅地降级或恢复。混沌工程工具可以在生产环境的系统上进行实验,以确保在发生真正的故障时系统也能应对。

    简言之,对一个系统进行混沌工程实验,是为了确保该系统可以承受意外情况。使用混沌工程工具,不必等待故障发生后再进行应对,而是可以在可控条件下为系统注入故障,以发现漏洞并在变更覆盖这些漏洞之前加以修复。

    常用工具

    混沌工程工具和实践对于应用程序的高可用至关重要。分布式系统通常过于复杂,而且任何变更过程都无法完全确定其对环境的影响。通过有意引入混沌工程实践,团队可以练习从故障中恢复,并将这个过程自动化。CNCF 中的混沌工程工具有 Chaos Mesh 和 Litmus Chaos。还有一些其他的开源和闭源的混沌工程工具。

    小结

    可观察性和分析这一列的工具可用于了解系统的运行状况,并确保系统即使在恶劣的条件下也能正常运行。日志记录工具可捕获应用程序发出的事件消息,监控工具可监测日志和指标,追踪工具可跟踪单个请求的路径。结合使用这些工具,理想情况下可以 360 度全方位查看系统中正在发生的事情。混沌工程提供了一种安全的方法来保证系统可以承受意外事件,基本上可以确保系统的健康运行。

    文章来源:K8sMeetup社区,点击查看原文

    展开全文
  • ACNA 的概念阿里巴巴为大量各行各业的企业客户提供了基于阿里服务的解决方案和最佳实践,以帮助企业完成数字化转型,并积累了大量经验和教训。阿里巴巴将企业的核心关注点、企业组织与 IT 文...
  • 数字化转型的十年,也是云计算高速发展的十年,这期间新技术不断演进、优秀开源项目大量涌现,云原生领域进入“火箭式”发展阶段。通过树立技术标准与构建开发者生态,开源将云计算实施逐渐标准化,大幅降低了开发者...
  • 什么是云原生架构? 什么是K8S?K8S的优势、解决了哪些问题? 为什么要使用云原生和K8S
  • 快速了解云原生架构

    千次阅读 2021-02-01 11:09:23
    简介: 云原生架构本质上也是一种软件架构,最大的特点是在云环境下运行,也算是微服务的一种延伸。 起源 1. 云原生(Cloud Native)的由来 云原生的概念最早开始于 2010 年,在当时 Paul Fremantle 的一篇博客中...
  • 简介:作为一种架构模式,云原生架构通过若干原则来对应用架构进行核心控制。这些原则可以帮助技术主管和架构师在进行技术选型时更加高效、准确,下面将展开具体介绍。 服务化原则 在软件开发过程中,当代码数量与...
  • 先来看架构图吧: 基本业务介绍 这个项目的业务是通过调用证券公司的 API 服务,按照指令特定顺序完成指定证券的交易。在这个项目中有几套这样的指令,用户可以通过 UI 来直接操作。这些指令使用人工操作证券公司的...
  • 云原生及k8s架构

    千次阅读 2021-10-28 11:15:23
    云原生及k8s架构,相关生态介绍 1.云计算简介 云计算是分布式计算的一种,指通过网络(云)将巨大的数据计算处理程序分解成无数个小程序,然后,通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给...
  • 企业架构可以助力企业数字化转型的规划和建设,其中企业IT架构是承接企业IT战略、对齐业务架构,以及具体IT项目落地的核心枢纽。...企业IT架构主要经历了如1所示的集中式架构、SOA、微服务架构及云原生架构的演
  • 架构 资源依赖架构图 架构效果图 注册发现中心Eureka为软件实现,需要在配置文件里配置所有Eureka server信息,Eureka server间进行信息同步。因此,架构方案选择在每个可用区创建独立的ECS部署Eureka server,同时...
  • 来源 |K8s中文社区作者:Catherine Paganini翻译:Sarah(K8sMeetup)如果你研究过云原生应用程序和相关技术,大概率你遇到过 CNCF 的云原生全景。这张...
  • 和传统3层金字塔自动化不一样,云原生架构下的自动化,由于服务内部相对简单,而服务拓扑复杂,所以测试的重点是在系统端到端测试,实际的分层测试的比重更像一个倒过来的金字塔。 而由于端到端成本过高,考虑到投入...
  • FreeWheel是美国传媒巨头康卡斯特(Comcast)集团旗下的高端视频广告技术供应商,90%以上的美国主流电视媒体和运营商都在使用FreeWheel的广告平台和技术。...目前,云原生计算基金会(CNCF)对“云原生
  • 王启军,云原生技术架构专家,曾任当当架构师,主导电商平台架构设计,包括订单、支付、价格、库存、物流等。曾就职于搜狐,负责手机微博的研发。十余年的技术历练,也曾作为技术负责人带领过近百人的团...
  • 一份3万字的云原生路线手册待你打开 欢迎使用Markdown编辑器 在今天的腾讯2020 Techo Park开发者大会上,腾讯云正式发布“云原生最佳实践路线”,同时发布的还有一份3万多字的《腾讯云原生路线手册》。手册中...
  • 10年多的工作历程,让我有幸经历了大范围的技术演变,特别是云计算和云原生技术从朦胧到普及,对工程师和架构师的要求也发生了不少变化。趁着自己入职11周年的日子,结合我自己在百度的成长历程,总结下我认为在...
  • 微服务概述 微服务的概念来源于Martin Fowler 的一篇知名博文 :MicroServices。...目前不仅各大互联网公司已经在大规模地应用微服务架构,而且传统行业也逐渐接受了这种架构模式,纷纷开始采用
  • 成为云原生时代的架构师 在今天的业务环境下,能更好地利用好云原生基础设施,更好地进行业务规划、高效高质地分析和管理领域模型,用领域模型指导架构设计和开发实践,是云原生时代架构师的重要技能。 这次云效和...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 38,222
精华内容 15,288
关键字:

云原生架构图