文章目录
- 云原生与微服务
- 云原生架构
- 云计算的历史
- 云原生是什么
- 云原生出现的背景
- 云原生的定义
- 云原生的基础架构
- 微服务
- 容器
- 服务网格
- DevOps
- 微服务概述
- 系统架构的演进
- 常见的微服务框架
- Go语言中的Go Kit 与 Go Micro框架
- 微服务设计的六大原则
云原生与微服务
云原生架构
云计算的历史
- 经历了三个阶段：
- 虚拟化的出现
- 虚拟化在云计算中的应用
- 容器化的出现
云计算的基础：虚拟化技术
- 分时技术
计算机从最开始只是个只能由一个人操作的机器，自从time-sharing（分时）技术的提出，实现了多人同时使用同一台计算机的需求。 - 虚拟化技术
当一台机器可以由多人操作后，这台机器上的硬件设备资源如何共享呢？虚拟机化技术（将所有硬件接口虚拟化）的提出实现了多个用户共享同一高性能计算设备的资源。 - 互联网的提出
分时与虚拟化也只能实现多人在同一台机器上操作，上世纪60年代互联系统的提出与实现，实现了互联网的前身，允许不同位置的计算机进行网络连接和资源共享。 - 大型机，小型机，X86的出现
当同时拥有操作系统，虚拟共享，互联网后，各种类型的服务器开始出现，公共计算推出舞台 - 虚拟机VMware出现
虚拟机可以在windows和X86机器上运行，正式拉开云计算的序幕。
虚拟化在云计算中的应用
- 亚马逊AWS的推出宣布着云计算时代的开始，国内外一些传统的IT厂商纷纷转型云计算，比如国内的阿里云，腾讯云。
- 随着云计算的出现，传统IT开发也发生了变革，AWS最早推出
FAAS（Function as a Service）功能服务化，运行AWS中运行代码而无需配置或管理服务器，研发只需要关注业务代码，而不再关注技术架构。 - 云计算的几个重要里程碑：
IaaS: (Instructure as a Service), 基础设施服务，云服务的底层，主要提供一些基础资源。SaaS:(Software as a service) 软件服务，软件的开发，管理，部署都交给第三方，不需要关心技术问题，拿来即用。PaaS: 平台服务（platform as a service）开发者只需要关注自己的业务逻辑，不需要关注底层。
容器的出现与容器编排大战
- 虚拟化是硬件级别分离应用程序，容器化是在操作系统级别分离程序
- Docker是容器化的一种方式，k8s 也是容器化编排的一种方式，只不过Docker加 k8s 打赢了早期的容器编排大战，后来成为了容器编排的主流。
云原生是什么
- 云计算已经成为企业发展的“战术”的一部分，云原生是云计算的下半场。
云原生出现的背景
- 快速迭代的背景下，微服务和云原生的概念开始流行，通过服务的拆分，每个小团队服务一个服务，增加内聚，减少频繁的开会，提高沟通效率。
- 但快速交付意味着更新频率变高，容易造成服务的故障，云原生通过工具和方法减少更新导致的故障问题，保证服务的高可用。
云原生的定义
- 云原生应用架构的几个主要特征：
符合12因素应用
面向微服务架构
敏捷架构
基于API的协作和抗脆弱性 - 云原生的4个要点：DevOps, 持续集成， 微服务架构和容器化
云原生的基础架构
- 云原生是一系列云计算技术体系和企业管理方法的集合，既包含了实现云原生化的方法论，也包含了落地实践的关键技术。
- 云原生应用利用微服务，服务网格，容器，DevOps和声明式API等代表性技术，构建容错性好，易于管理和便于观察的松耦合系统。
微服务
- 拆分服务，单独迭代
- 优点：
降低系统复杂度，独立部署，独立扩展和跨语言编程等优点
缺点：
引入了分布式系统的复杂性，如网络延迟，容错性，消息序列化，不可靠网络，异步机制，版本化和差异化的工作负载等。
其他问题：
服务的可测试性，异步机制，调用链路过长等。
容器
- 为了解决微服务大量应用部署的问题，引用容器。
- 为了解决容器的管理和调度问题，引入了k8s，实现容器集群的自动化部署，Zion给扩缩容和维护等功能
服务网格
- 微服务主要有两种实践方式：
侵入式架构：服务框架嵌入程序代码，开发者组合各种组件，如RPC，负载均衡，熔断等。
非侵入式架构：以代理的形式，与应用程序部署在一起，接管应用程序的网络且对其透明，开发者只需关注自身业务即可，以服务网格为代表。
DevOps
- DevOps是一组过程，方法与系统的统称，用于促进开发，运营，质量部门之间的沟通
- 包含三个部分：开发，测试和运维
- 标志是“持续”实践，包括持续集成，持续测试，持续交付和持续部署
微服务概述
系统架构的演进
单体架构
- 远古架构，又称为巨石架构，一个应用包含所有业务代码。
- 优点：
易于搭建，开发，测试，适合个人小项目
缺点：
不易扩展，进行局部改动就需重新部署
垂直分层架构
- 为了提高机器利用率和性能，单体架构会演化为垂直架构。
- 将大应用拆分成一个个单体结构的应用，MVC模式就是典型的垂直分层架构。
- 优点：
项目架构简单，前期开发成本低并且周期短，是小型项目的首选。
缺点：
拆分后的单体架构之间存在数据冗余，耦合性加大等问题。系统性能扩展只能通过扩展集群结点实现，成本高有瓶颈。
SOA面向服务架构
- 当垂直架构拆分应用越来越多，就会出现多个应用都依赖的业务逻辑组件，这时就会出现云服务商提供自身的PaaS组件服务。
- 其他小型企业可以使用这些PaaS服务，SOA架构诞生。
- SOA架构的关键是建立企业服务总线，外部应用通过企业服务总线调用服务。
- SOA服务架构都具有平台独立的自我描述XML文档。
- 每个服务都使用该文档描述自身提供的能力，并将自身注册到服务登记中心（Registry）上
- 服务消费者（Service Consumer）从服务登记中心寻找并调用某一服务。
- 服务消费者通过发送消息给服务总线转发至适当的服务实现。
- 该架构提供一个业务规则引擎（Enterprise Service Engine），该引擎容许业务规则被合并在一个服务里或多个服务里。
提供服务管理基础架构，用来管理服务，提供类似审核，列表，日志等功能 - 优点：
- 将重复的功能抽取为服务，提高开发效率，提高系统的可重用性和可维护性
- 可以针对不同的服务的特点制定集群及优化方案
- 采用ESB减少系统中的接口耦合
- 借助现有的应用来组合产生新服务的敏捷方式，
缺点：
- 一般场景不适用，适合大型软件服务企业对外提供服务的场景
- 业务总线也容易导致系统的单点风险并拖累整体性能
微服务架构
- 特点：
- 系统服务层完全独立出来，并将服务层抽取为一个一个的微服务
- 微服务遵循单一原则
- 采用RESTful等轻量协议通信
- 一般使用容器部署
- 每个微服务都有自己独立的业务开发活动和周期
- 优点：
- 有利于资源重复利用，提高开发效率
- 提高了系统的可维护性
- 适合敏捷迭代
缺点：
- 如果服务拆分过多，链路过长，不利于系统维护
- 可能形成复杂依赖链条，造成雪崩效应
- 服务实例之间交互需要处理分布式事务，调用幂等和重试等问题，开发成本高
云原生架构
- 云原生四要素：微服务，容器化，DevOps和持续交付
- 云原生的PaaS产品可以为整个服务开发，发布和运维过程提供支持：
Codeless：提供源码托管功能，开发人员不需要关心代码库的问题Applicationless: 工程师不需要申请发布权限，也不需要知道代码如何发布Serverless: 工程师不需要关心机器资源，弹性扩容
常见的微服务框架
Go语言中的Go Kit 与 Go Micro框架
Go 语言的独特优势
- 简单易用
- 强类型的静态语言，却具备动态语言的开发效率和优势
- 原生支持并发
- 丰富的标准库
- 部署方便
Go kit 微服务框架
- 该框架主要由三个部分组成：
- 传输层：用于网络通信，服务通常使用HTTP或gRPC等网络传输方式，或使用NATS等发布订阅系统相互通信
- 接口层：服务器和客户端的基本构件块。每个接口定义为端点，以便于在服务器和客户端之间进行网络通信。
每个端点使用传输层通过使用HTTP或gRPC等具体通信模式对外提供服务。 - 服务层：具体的业务逻辑实现。
Go Micro 微服务框架
- 组件化的框架，每一个基础功能都有对应的接口抽象，方便扩展。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mJwUmNEg-1627951496316)(https://i.loli.net/2021/08/02/IxAnpfj8ZKCySVX.png)] - 上层基于下层功能继续向上提供服务
微服务设计的六大原则
- 高内聚，低耦合
- 单一职责
- 轻量级通信
- 服务间的契约
- 高度自治
- 能独立开发，部署，发布
- 进程隔离
- 独立的代码库，流水线
- 以业务为中心
- 每个服务代表了特定的业务逻辑
- 能更快的响应业务的变化
- 围绕业务组织团队
- 弹性设计
- 容错
- 服务降级
- 日志与监控
- 日志聚合
- 监控和警告
- 自动化
- 持续集成
高内聚，低耦合 - 单一职责
- 轻量级通信
- 服务间的契约
- 高度自治
- 能独立开发，部署，发布
- 进程隔离
- 独立的代码库，流水线
- 以业务为中心
- 每个服务代表了特定的业务逻辑
- 能更快的响应业务的变化
- 围绕业务组织团队
- 弹性设计
- 容错
- 服务降级
- 日志与监控
- 日志聚合
- 监控和警告
- 自动化
- 持续集成
- 持续交付