云原生架构总览

Posted 2023-04-04 Pandaconda

云原生

第1章 云原生架构总览

1.1 云技术发展历程

1.2 云原生的定义

云原生出现的背景

如今企业大都处于下图中黄色和红色的板块，所以将软件迁移到云上就成为了极大的趋势。

云原生定义 - Pivotal 当前论述

Pivotal 官方网站对云原生最新论述如下：

• 云原生是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势。
• 云原生关注如何创建和部署应用程序，而不是在何处。
• 虽然现在有云影响了几乎每个行业的基础设施投资思想，但类似云的交付模式并不仅限于公有云环境，它适用于公有云和私有云。
• 云原生结合了 DevOps、持续交付、微服务和容器的概念。
• 当公司以云原生方式构建和运营应用程序时，它们可以更快地将新想法推向市场并更快地响应客户需求。

云原生定义 - CNCF 当前定义

2018 年更新后的定义论述如下：

• 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API 。

云原生核心理念

解耦软件开发，提高灵活性和可维护性：

• 基于容器镜像的软件分层，清晰的依赖管理
• 剥离程序、配置和微服务，让开发者聚焦业务开发
• 拆分应用程序为微服务并明确依赖描述

多云支持，避免厂商锁定：

• 厂商基于标准接口提供服务，互操作性强
• 开源为主，丰富的标准软件生态 - 用户选择多
• 支持在所有公有云。私有云或混合云部署

避免侵入式定制：

• 基于 Kubernetes 的松耦合平台架构，易扩展
• Kubernetes 已被公认是 paltform for platform

提高工作效率和资源利用率：

• 通过中心编排过程动态管理和调度应用/微服务

云原生的技术版图

代表技术

一、容器技术

容器可以将应用本身及其依赖打包，使得应用可以实现“一次封装，到处运行”。

容器也可以理解成一种沙盒技术，沙盒在计算机安全领域中是一种安全机制，为运行中的程序提供的隔离环境。

核心： 提供应用的可移植性，提升业务敏捷。

二、Kubernetes 的声明式 API

面向开发者提供全新分布式原语。

核心： 针对期望状态结果给出声明，而不是过程。

三、服务网格

核心： 剥离业务代码和分布式框架。

四、微服务

核心： 加快企业应用架构升级

五、DevOps

**核心：**促进开发运维一体化

1.3 云原生应用

云原生应用综合理解

• 基于云原生的相关技术，设计运行在云上的，充分发挥云优势的应用。
• 一般采用容器的打包、分发、部署的形式，应用内（间）采用微服务的架构，充分利用云提供的组件服务，采用 DevOps 的组织架构和方法， 通过 CI/CD 工具链，实现产品和服务的持续交付。

传统应用与云原生应用的区别

云原生应用 12 要素

1.4 云原生架构原则及常用模式

云原生架构演进原则

单体架构

单体架构的问题不在于不可拆分上，在于无法隔离和自治。应用规模越大，局限性越明显。

微服务架构

微服务独立性和敏捷性更好，架构持续演进更容易，更适合云原生应用。

Serverless 架构

Serverless（无服务器架构） 指的是由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发，完全被第三方管理，Serverless 是在传统容器技术和服务网格上发展起来，更侧重让使用者只关心自己的业务逻辑即可。

Serverless 与微服务的关系

微服务向 Serverless 演进，并长期共存。

1.5 华为云云原生解决方案

华为云云原生服务

云原生基础设施底座

基于云原生基础设施的多云管理解决方案

多集群、多区域、多云统一应用管理能力，实现更大规模业务支撑能力，更灵活的弹性与容灾能力。

• 多云容器平台（MCP）： 基于多集群联邦技术完成多个不同区域、不同云的 K8s 集群与应用统一管理
• 应用服务网络（ASM）： 完成多个不同区域、不同云的 Kubernetes 集群上所部属应用的全局治理

基于云原生基础设施的高性能计算解决方案

基于云原生基础设施的边云协同解决方案

安全保障

华为云 DevSecOps 为应用开发提供了安全保障。

价值

企业级微服务管理平台，加速微服务应用开发和高可用运维。

1.6 云原生未来发展趋势

Kubernetes 编排统一化，编排对象不断扩展延伸

服务治理 Mesh 化，加速传统应用转型

• 根据 CNCF 调查数据，38% 的单位再生产中使用服务网格，42% 的调查对象在评估服务网格，11% 计划在未来 12 个月使用，因此预计在未来年份中，服务网格为成为一个增长领域。
• Istio 、Conul 、Linkerd 是 Service Mesh 领域最受欢迎的三大解决方案。

应用服务 Serverless 化，更加聚焦业务的核心价值

• Serverless 作为下一代云计算范式，基于 Serverless 的应用生命周期将出现重大的改变，整个过程无需关注底层服务器资源的调度，并且应用天生具备高可用高弹性。

云原生服务部署形态多元化，多云将成为主流

• 尽管云已是大势所趋，但对于企业客户而言，有些业务出于对数据主权、安全隐私的考量，会采用混合云架构。一些企业为了满足安全合规、成本优化、提升地域覆盖性等需求，会选择多个云厂商。
  

思考题

答案：A

答案：ABCD

本章总结

本章内容主要介绍了云原生发展的背景和相关定义，并对云原生应用的典型架构进行分析。同时，对华为云云原生解决方案进行了相关阐述。

缩略语

• CNCF：Cloud Native Computing Foundation ，云原生计算基金会，成立与 2015 年 7 月，隶属于 Linux 基金会，是云原生的重要推动着。
• ISV：independent software vendor ，独立软件供应商。
• CI/CD：continuous integration and continuous delivery ，持续集成和持续交付。
• AOM：Application Operations Management ，应用运维管理服务。
• APM：application performance management ，应用性能管理。
• LTS：Log Tank Service ，云日志服务。

《JAVA生态圈技术总结》之 微服务架构蓝图总览

目录导航

• 一、微服务定义
• • 1.1 定义一
  • 1.2 定义二
• 二、微服务利弊
• • 2.1 优点
  • 2.2 缺点
• 三、微服务的适用性
• • 3.1 康威法则
  • 3.2 生产力
  • 3.3 架构演进
• 四、服务分层
• 五、服务注册发现
• 六、微服务网关
• 七、微服务配置中心
• 八、微服务通信
• 九、服务监控
• • 9.1 监控体系
  • 9.2 监控架构
• 9.3 全链路监控
• 十、断路器与流量控制
• 十一、DevOps（云原生架构系列）
• 十二、容器云

一、微服务定义

1.1 定义一

• 微服务是一种架构风格，将单体应用划分成一组小的服务，尽量符合单一职责的原则，使得服务之间相互协作，实现业务功能；
• 每个服务都运行在独立的进程、虚拟机、容器、服务器中，服务之间采用轻量级的通信机制（HTTP/JSON）进行协作；
• 每个服务围绕各自的业务能力进行构建，并且能够通过自动化机制独立地部署，相互之间无部署依赖；
• 每个服务可以使用不同的技术栈进行开发；

1.2 定义二

微服务是一种基于有界上下文的，松散耦合的面向服务的架构。

二、微服务利弊

2.1 优点

• 划分了业务模块，具有更强的业务边界；
• 每个微服务都是可以独立部署的，互不影响；
• 允许技术多样性；

2.2 缺点

• 带来了分布式系统的复杂性；
• 带来了最终一致性的难题；
• 带来了运维的复杂性；
• 带来了测试复杂性；

三、微服务的适用性

什么场景下适用微服务？什么阶段时适用微服务？

3.1 康威法则

设计的微服务系统的组织，其产生的架构设计应等价于组织间的沟通结构。

这句话的意思是说，原始组织之间的结构最好能映射到设计的微服务系统架构上。比如一个系统包含订单、商品、用户等功能，现实中分别由A、B、C三个小组进行开发维护，那么如果要拆分为微服务的架构，最好就能拆分为订单服务、商品服务、用户服务三个微服务，对应A、B、C三个现实的小组结构。

3.2 生产力

微服务并不是适合任何阶段，最好的方式就是随着项目的扩大或者团队的扩大时，逐步演进到微服务。因为单体应用会随着规模的扩大而逐渐增加内耗，导致生产力降低。微服务的目标是在规模扩大时，使得生产力能维持在一个稳定的水准之上。

微服务与单体的生产力比较：

微服务生产力超过单体的拐点，一般来说是指当团队人数规模达到百人时。当然，这也不是绝对的，需要团队负责人自己视情况进行评估。

3.3 架构演进

如果在项目一开始就设计微服务的架构，一路上会遇到极大的困难与风险。比如业务模块边界的划分、无法预估的业务或者技术复杂性，这些都会耗费更多的人力和时间，甚至最终导致项目失败。

建议的方式就是由单体演进，我们可以在单体阶段不断摸索和沉淀业务和技术上的问题，随着越来越清晰的认知，再加上日渐增加的复杂度，可以考虑逐步拆分部分服务出来，朝着微服务架构的方向演进。

架构演进：

四、服务分层

微服务架构中服务与服务各有不同，相互之间也应该按照层级的方式进行编排。有的与业务无关的服务天然属于底层基础服务，有的与业务有关联的服务则属于聚合了基础服务的聚合服务。

服务分层：

在常见的公司微服务总体架构中，一般的架构表现就如下所示：

微服务总体架构：

有了各个层级的服务之后，中台的概念和战略就显得很自然。

中台战略：

五、服务注册发现

服务注册与发现是微服务架构得以运转的核心功能，它不提供任何业务功能，仅仅用来进行服务的发现和注册，并对服务的健康状态进行监控和管理。其核心的工作原理：

• 注册中心负责维护所有服务的地址信息，包括服务名称、IP地址、端口等；
• 提供服务方将自己的信息注册到注册中心上，并维持一个心跳以此来表明自己一直可用；
• 调用服务方想要调用某个服务时，询问注册中心该服务的地址，然后以负载均衡的方式发起调用；

现在注册中心比较多，主流的有Eureka、Consul、Zookeeper、Nacos等。

六、微服务网关

网关是整个系统对外暴露的唯一入口，它封装了系统内的所有微服务，对外看来，别人只知道也只能通过网关才可以和系统进行交互。网关对所有请求进行非业务功能的处理，然后再将请求发送给内部指定的微服务进行业务上的处理。总的来说，网关最主要的功能如下：

• 反向路由；
• 安全认证；
• 限流熔断；
• 日志监控；

现在常见的网关有Kong、Zuul、Spring Cloud Gateway等；

微服务网关：

在实际应用中，一个微服务体系架构的系统可以有多个网关用来应对不同的使用场景，比如公司内网网关、外网网关、提供给第三方调用的网关等；

多网关的使用：

七、微服务配置中心

微服务在启动和运行的过程中，经常会需要读取一些配置信息，这些配置信息拥有如下的特点：

• 独立于程序的只读内容；配置与程序应该分离，应用应该只会去读取配置，而不应该去修改配置；
• 伴随应用的整个生命周期；配置会被程序读取用来控制自己的行为逻辑；因此配置是可以被更改的；
• 拥有多种加载方式；可以通过硬编码、配置文件、环境变量、启动参数、数据库存储等方式被加载到应用内；
• 配置内容需要治理；不同的环境下，配置具有不同的内容，因此需要配置内容的治理；

如上这些特点和需求，催生了配置中心的出现。现在主流的配置中心有Spring Cloud Config、Nacos、Apollo等；

配置中心：

八、微服务通信

RPC和REST：

九、服务监控

9.1 监控体系

监控体系：

9.2 监控架构

监控架构：

9.3 全链路监控

在微服务架构中，一次调用请求可能贯穿多个服务，这些服务可能是由不同的团队使用不同的技术开发而成的，如果出现调用失败需要排查问题时，如何能快速地复现调用现场，发现问题出在哪个服务哪个服务器上就成了全链路监控需要解决的问题。

全链路监控的基本原理都是：

• 一次请求全过程中只有一个TraceID保持不变；
• 每贯穿一个服务，SpanID都不同，同时标注上一个SpanID；
• 按照时间序列将监控信息进行报错和展示；

全链路监控主流工具有CAT、Zipkin、Pinpoint、Skywalking等；

十、断路器与流量控制

在微服务架构体系中，服务之间的调用是很频繁的，一旦某些服务出现故障或者高延迟，会很可能造成级联故障，如果客户端还在不停重试，将会加剧问题的严重性，最终导致整个系统彻底崩溃。

断路器的设计与实现有助于防止多服务之间的级联故障，允许我们构建具有容错性和高弹性的微服务架构系统，当某些服务不可用时，提供服务熔断和服务降级功能，保证系统的其它部分仍能正常运行。

断路器的三个状态和含义如下：

• 关闭；此时所有调用都能访问到当前的服务。当调用次数或者故障数超过设定的阈值后，断路器变为打开状态；
• 打开；不再调用当前服务，而是返回预设的错误信息；
• 半开；打开一定时间后，断路器切换为半开状态，放一个请求调用当前服务，测试服务是否正常。如果正常，则变为关闭状态；如果还是异常，再次变为打开状态。

主流常见的断路器有Hystrix、Sentinel等；

十一、DevOps（云原生架构系列）

DevOps：

蓝绿发布：

十二、容器云

如果使用了容器技术，那么容器编排、发布、治理就成了避不开的话题。主流的技术如下：

• Docker、Docker Compose、Docker Swam 这里推荐我之前写过的文章《云原生之 Docker篇 Docker Compose介绍及使用入门》、《云原生之 Docker Swarm服务编排介绍及使用入门》
• K8s 后续会逐渐推出
• Mesos 后续会逐渐推出

各大容器云厂商基本都是使用基于k8s的容器治理方案，k8s也已经成为该领域事实上的标准了。

如上是自己在极客时间App上学习《微服务架构核心20讲》的笔记，该课程一天就能学完，没有实现微服务的细节，是高屋建瓴地讲解微服务架构的蓝图，带你鸟瞰整个微服务架构，推荐学习，这里引用老师说过的话。