软考笔记--云原生架构相关技术

一.容器技术

1.容器技术的背景与价值

容器作为标准化软件单元，它将应用及其所有依赖项打包，是应用不受环境所限制，在不同计算环境之间快速，可靠地运行。Decker容器基于操作系统虚拟化技术，共享操作系统内核、轻量、没有资源损耗，秒级启动，极大提升了系统的仪你改一下部署密度和弹性。Docker提供了创新的应用打包规范，Docker镜像，解耦了应用与运行环境，使应用可以在不同的计算机环境一致，可靠地运行。

随后开源的kubernetes，成为分布式资源调度和自动化运维的标准。Kubernetes屏蔽了IaaS层基础架构的差异性并凭借优良的可移植性，帮助应用一致地运行在包括数据中心、云、边缘计算在内的不同环境。企业可以通过Kubernetes, 结合自身业务特征来设计自身云架构，从而更好地支持多云/混合云，免去被厂商锁定的顾虑。

2.容器编排

Kubernetes已经成为容器编排的标准，被广泛用于自动部署，扩展和管理容器化应用Kubernetes提供了分布式应用管理的核心能力。

资源调度：根据应用请求的资源量CPU，内存或者GPU等设备资源，在集群中选择合适的节点来运行应用。

应用部署与管理：支持应用的自动发布与应用的回滚，以及应用相关的配置的管理。

自动修复：kubernetes能检测这个集群中所有的宿主机，当宿主机或这系统出现故障，节点健康检查会自动进行应用迁移；k8s也支持应用的自愈。

服务发现与负载均衡：通过Service资源出现各种应用服务，结合DNS和多种负债均衡机制，支持容器化应用之间的相互通信。

弹性伸缩：k8s可以监测业务上所承担的负载，可以对这个业务进行扩容。

声明式API：开发者可以关注于应用自身，而非系统执行细节。

可扩展性架构：所有K8S组件都是基于一直的、开发的API实现和交互。

可移植性：K8S通过一些列抽象如负载均衡服务器，CNI，CSI，帮助业务应用可以屏蔽底层基础设施的实现差异。

二.云原生微服务

1.微服务发展背景

为了解决由单体应用模型衍生的过度集中式项目迭代流程，微服务模式应运而生。 微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”,多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。在云原生时代，云原生微服务体系将充分利用云资源的高可用和安全体系，让应用获得更有保障的弹性、可用性与安全性。

2.微服务设计约束

设计一个优秀的微服务系统应该遵循以下设计约束：

(1)微服务个体约束

微服务的“微” 并不是为了微而微，而是按照问题域对单体应用做合理拆分。进一步，微服务也应具备正交分解特性，在职责划分上专注于特定业务并将之做好，即SOLID原则中单一职责原则 (Single Responsibility Principle,SRP)。 如果当一个微服务修改或者发布时，不应该影响到同一系统里另一个微服务的业务交互。

（2）微服务与微服务之间的横向关系

在合理划分好微服务间的边界后，主要从微服务的可发现性和可交互性处理服务间的横向关系。

（3）微服务与数据层之间的纵向约束

在微服务领域，提侣数据存储隔离 (Data Storage Segregation,DSS) 原则，即数据是微服 务的私有资产，对于该数据的访问都必须通过当前微服务提供的API来访问。

（4）全局视角下的微服务分布式约束

从微服务系统设计一开始，就需要考虑以下因素：高效运维整个系统，从技术上要准备全自动化的CI/CD流水线满足对开发效率的诉求，并在这个基础上支持蓝绿、金丝雀等不同发布策略，以满足对业务发布稳定性的诉求。

3.主要微服务技术

阿里巴巴的Apache Dubbo开源高性能RPC框架，了Spring Cloud Alibaba (分布式应用框架)、Nacos (注册中心&配置中心)、 Sentinel (流控防护)、 Seata (分布式事务)、 Chaosblade (故障注入)。

Spring Cloud作为开发者的主要微服务选择之一，为开发者提供了分布式系统需要的配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、 全局锁、决策竞选、 分布式会话与集群状态管理等能力和开发工具。

Eclipse MicroProfile作为Java微服务开发的基础编程模型，它致力于定义企业Java微服务规范。

 蚂蚁金服开源的一套用于快速构建金融级分布式架构的中间件SOFAStack(Scalable Open Financial Architecture Stack)。

三.无服务技术

1.技术特点

随着以kubernetes为代表的云原生技术成为云计算的容器界面，kubernetes成为云计算的新一代操作系统。面向特定领域的后端云服务（BaaS）则是这个操作系统上的服务APi，当这些BaaS日趋完善时，无服务技术Serverless因为屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一，Serverless计算包含以下技术：

（1）全托管的计算服务，客户只需要编写代码构件应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发，运维，安全，高可用等工作。

（2）通用性，结合云BssSAPI的能力，能够支撑云上所有重要类型的应用。

（3）自动弹性伸缩性，让用户无需为资源使用提前进行规划。

按量计费，让企业使用成本降低，无需为闲置资源付费。

2.技术关注点

（1）计算资源弹性调度

为了实现精准、实时的实例伸缩和放置，必须把应用负载的特征作为资源调度依据，使用“白盒”调度策略，由Serverless平台负责管理应用所需的计算资源。

（2）负载均衡和流控

资源调度服务是serverless系统的关键链路。为了支持每秒近百万次的资源调度请求，系统需要对资源调度服务的负载进行分片，横向扩展到多台机器上，避免单点瓶颈。

（3）安全性

Serverless计算平台的定位是通用计算服务，要能执行任意用户代码，因此安全是不可逾越 的底线。

四.服务网络

1.技术特点

服务网络（ServiceMesh）是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台开发效率并加速业务探索和创新。因为大量非功能性从业务进程剥离到另外进程中，服务网格以无侵入的方式实现了应用轻量化。

2.主要技术

服务网格Istio开源项目，清晰定义了数据平面和管理平面。Istio为微服务架构提供了流量管理机制，同时亦为其他增值功能创造了基础。Istio利用久经考验的 LyftEnvoy代理进行构建，可在无需对应用程序代码作出任何发动的前提下实现可视性与控制能力。

除了Istio外，也有Linkerd、Consul 这样相对小众的ServiceMesh 解决方案。 Linkerd在数据平面采用了 Rust编程语言实现了linkerd-proxy, 控制平面与 Istio一样采用G o语言编写。最新的性能测试数据显示， Linkerd在时延、资源消耗方面比 Istio更具优势。

Conduit作为Kubernetes 的超轻量级ServiceMesh, 其目标是成为最快、最轻、最简单且最安全的ServiceMesh。 它使用Rust构建了快速、安全的数据平面，用 G o 开发了简单强大的控制平面，总体设计围绕着性能、安全性和可用性进行。它能透明地管理服务之间的通信，提供可测性、可靠性、安全性和弹性的支持。