初步认识云原生与微服务

发布时间:2023-07-27 18:30

文章目录

  • 云原生与微服务
    • 云原生架构
      • 云计算的历史
      • 云原生是什么
        • 云原生出现的背景
        • 云原生的定义
      • 云原生的基础架构
        • 微服务
        • 容器
        • 服务网格
        • DevOps
    • 微服务概述
      • 系统架构的演进
      • 常见的微服务框架
        • Go语言中的Go Kit 与 Go Micro框架
      • 微服务设计的六大原则

云原生与微服务

云原生架构

云计算的历史

  • 经历了三个阶段:
    1. 虚拟化的出现
    2. 虚拟化在云计算中的应用
    3. 容器化的出现

云计算的基础:虚拟化技术

  1. 分时技术

    计算机从最开始只是个只能由一个人操作的机器,自从time-sharing(分时)技术的提出,实现了多人同时使用同一台计算机的需求。

  2. 虚拟化技术

    当一台机器可以由多人操作后,这台机器上的硬件设备资源如何共享呢?虚拟机化技术(将所有硬件接口虚拟化)的提出实现了多个用户共享同一高性能计算设备的资源。

  3. 互联网的提出

    分时与虚拟化也只能实现多人在同一台机器上操作,上世纪60年代互联系统的提出与实现,实现了互联网的前身,允许不同位置的计算机进行网络连接和资源共享。

  4. 大型机,小型机,X86的出现

    当同时拥有操作系统,虚拟共享,互联网后,各种类型的服务器开始出现,公共计算推出舞台

  5. 虚拟机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,负载均衡,熔断等。

    非侵入式架构:以代理的形式,与应用程序部署在一起,接管应用程序的网络且对其透明,开发者只需关注自身业务即可,以服务网格为代表。

\"初步认识云原生与微服务_第1张图片\"

DevOps

  • DevOps是一组过程,方法与系统的统称,用于促进开发,运营,质量部门之间的沟通
  • 包含三个部分:开发,测试和运维
  • 标志是“持续”实践,包括持续集成,持续测试,持续交付和持续部署

微服务概述

系统架构的演进

\"初步认识云原生与微服务_第2张图片\"

单体架构

  • 远古架构,又称为巨石架构,一个应用包含所有业务代码。

  • 优点

    易于搭建,开发,测试,适合个人小项目

    缺点

    不易扩展,进行局部改动就需重新部署

垂直分层架构

  • 为了提高机器利用率和性能,单体架构会演化为垂直架构。

  • 将大应用拆分成一个个单体结构的应用,MVC模式就是典型的垂直分层架构。

  • 优点

    项目架构简单,前期开发成本低并且周期短,是小型项目的首选。

    缺点

    拆分后的单体架构之间存在数据冗余,耦合性加大等问题。系统性能扩展只能通过扩展集群结点实现,成本高有瓶颈。

SOA面向服务架构

  • 当垂直架构拆分应用越来越多,就会出现多个应用都依赖的业务逻辑组件,这时就会出现云服务商提供自身的PaaS组件服务。

  • 其他小型企业可以使用这些PaaS服务,SOA架构诞生。

  • SOA架构的关键是建立企业服务总线,外部应用通过企业服务总线调用服务。
    \"初步认识云原生与微服务_第3张图片\"

    • SOA服务架构都具有平台独立的自我描述XML文档
    • 每个服务都使用该文档描述自身提供的能力,并将自身注册到服务登记中心(Registry)上
    • 服务消费者(Service Consumer)从服务登记中心寻找并调用某一服务。
  • 服务消费者通过发送消息给服务总线转发至适当的服务实现。

  • 该架构提供一个业务规则引擎(Enterprise Service Engine),该引擎容许业务规则被合并在一个服务里或多个服务里。

    提供服务管理基础架构,用来管理服务,提供类似审核,列表,日志等功能

  • 优点

    1. 将重复的功能抽取为服务,提高开发效率,提高系统的可重用性和可维护性
    2. 可以针对不同的服务的特点制定集群及优化方案
    3. 采用ESB减少系统中的接口耦合
    4. 借助现有的应用来组合产生新服务的敏捷方式,

    缺点

    • 一般场景不适用,适合大型软件服务企业对外提供服务的场景
    • 业务总线也容易导致系统的单点风险并拖累整体性能

微服务架构

  • 特点

    1. 系统服务层完全独立出来,并将服务层抽取为一个一个的微服务
    2. 微服务遵循单一原则
    3. 采用RESTful等轻量协议通信
    4. 一般使用容器部署
    5. 每个微服务都有自己独立的业务开发活动和周期
  • 优点

    1. 有利于资源重复利用,提高开发效率
    2. 提高了系统的可维护性
    3. 适合敏捷迭代

    缺点

    1. 如果服务拆分过多,链路过长,不利于系统维护
    2. 可能形成复杂依赖链条,造成雪崩效应
    3. 服务实例之间交互需要处理分布式事务,调用幂等和重试等问题,开发成本高

云原生架构

  • 云原生四要素:微服务,容器化,DevOps和持续交付

  • 云原生的PaaS产品可以为整个服务开发发布运维过程提供支持:

    Codeless:提供源码托管功能,开发人员不需要关心代码库的问题

    Applicationless: 工程师不需要申请发布权限,也不需要知道代码如何发布

    Serverless: 工程师不需要关心机器资源,弹性扩容

常见的微服务框架

Go语言中的Go Kit 与 Go Micro框架

Go 语言的独特优势

  1. 简单易用
  2. 强类型的静态语言,却具备动态语言的开发效率和优势
  3. 原生支持并发
  4. 丰富的标准库
  5. 部署方便

Go kit 微服务框架

  • 该框架主要由三个部分组成:

    1. 传输层:用于网络通信,服务通常使用HTTP或gRPC等网络传输方式,或使用NATS等发布订阅系统相互通信

    2. 接口层:服务器和客户端的基本构件块。每个接口定义为端点,以便于在服务器和客户端之间进行网络通信。

      每个端点使用传输层通过使用HTTP或gRPC等具体通信模式对外提供服务。

    3. 服务层:具体的业务逻辑实现。

Go Micro 微服务框架

  • 组件化的框架,每一个基础功能都有对应的接口抽象,方便扩展。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mJwUmNEg-1627951496316)(https://i.loli.net/2021/08/02/IxAnpfj8ZKCySVX.png)]

  • 上层基于下层功能继续向上提供服务

微服务设计的六大原则

  1. 高内聚,低耦合
    • 单一职责
    • 轻量级通信
    • 服务间的契约
  2. 高度自治
    • 能独立开发,部署,发布
    • 进程隔离
    • 独立的代码库,流水线
  3. 以业务为中心
    • 每个服务代表了特定的业务逻辑
    • 能更快的响应业务的变化
    • 围绕业务组织团队
  4. 弹性设计
    • 容错
    • 服务降级
  5. 日志与监控
    • 日志聚合
    • 监控和警告
  6. 自动化
    • 持续集成
      高内聚,低耦合
    • 单一职责
    • 轻量级通信
    • 服务间的契约
  7. 高度自治
    • 能独立开发,部署,发布
    • 进程隔离
    • 独立的代码库,流水线
  8. 以业务为中心
    • 每个服务代表了特定的业务逻辑
    • 能更快的响应业务的变化
    • 围绕业务组织团队
  9. 弹性设计
    • 容错
    • 服务降级
  10. 日志与监控
    • 日志聚合
    • 监控和警告
  11. 自动化
    • 持续集成
    • 持续交付

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号