初步认识云原生与微服务

云原生与微服务

云原生架构

云计算的历史

• 经历了三个阶段：
  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，负载均衡，熔断等。

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

DevOps

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

微服务概述

系统架构的演进

单体架构

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

• 优点：

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

  缺点：

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

垂直分层架构

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

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

• 优点：

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

  缺点：

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

SOA面向服务架构

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

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

• SOA架构的关键是建立企业服务总线，外部应用通过企业服务总线调用服务。
  

  • 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. 自动化
    • 持续集成
    • 持续交付