云原生与微服务概念笔记

云原生与微服务概念入门。

云原生与微服务概念笔记

参考书籍:

朱荣鑫,黄迪璇,张天. Go语言高并发与微服务实战[M]. 北京:中国铁道出版社有限公司,2020.

1 云原生架构

1.1 云计算的历史

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

虚拟化是云计算的基石。

  • 1955年,MIT的John McCarthy提出time-sharing技术。
  • 1959年6月,Christopher Strachey在国际信息处理大会发表《Time Sharing in Large Fast Computer》论文,提出虚拟化概念。
  • 1965年8月,IBM推出TSS(Time Sharing System)和VMM(Virtual Machine Monitor),是最原始的虚拟机技术。
  • 20世纪60年代中期,美科学家HCR Licklider提出计算机互联系统,Bob Taylor和Larry Robert开发ARPANET
  • 1978年,IBM获得RAID专利,融物理设备为LUN(Logical Unit Number),首次将虚拟化引入存储。
  • 1990,Unity Computing概念复苏,亦称Grid Computing,旨在实现公共计算服务给全世界用户使用。
  • 1998年,VMware成立并首次引入x86虚拟化技术。
  • 2000年,IEEE颁布**VPN(Virtual Private Network)**标准草案。
  • 2002年,Amazon上线**AWS(Amazon.com Web Service)**,旨在商品目录以SOAP接口开放。
  • 2005年,开源虚拟机Xen 3.0发布,支持Intel VT和IA64。
  • 2006年10月,以色列创业公司Qumranet宣布KVM诞生,且KVM模块的源码成为Linux内核源码的一部分。
  • 2009年4月,VMware推出首款云操作系统VMware vSphere。

1.1.2 基于虚拟机的云计算

虚拟化技术成熟,云计算市场出现。

  • 2006年,AWS推出S3(Simple Storage Service)和EC2(Elastic Compute Cloud)。
  • 2007年,IBM发布云计算商业解决方案,推出Blue Cloud计划。
  • 2008年,Google App Engine发布,用于Web开发和托管。
  • 2009年,Heroku推出首款公有云PaaS(Platform as a Service)。
  • 2010年,微软推出Azure。
  • 2010年,Rackspace Hosting和NASA推出OpenStack开源云软件计划。
  • 2011年,Pivotal推出开源PaaS——Cloud Foundry。
  • 2013年,Docker发布,其使用LXC并封装一些新功能。
  • 2014年,AWS推出Lambda,在AWS中直接运行代码而无需考虑服务器配置和管理,即FaaS(Function as a Service)、Serverless。

云计算模式:

  1. IaaS:Infrastructure as a Service,提供基础资源。
  2. SaaS:Software as a Service,提供搭建、实施、维护等一系列的软件服务。拿来即用。
  3. PaaS:Platform as a Service,是SaaS的延申,抽象硬件和操作系统,对外提供运行时环境作为部署平台,便于扩展。
类型 传统IT IaaS PaaS SaaS
应用程序 × × ×
数据 × × ×
运行时 × ×
中间件 × ×
操作系统 × ×
虚拟化 ×
服务器 ×
存储 ×
网络 ×
  • ×表示云计算厂商不负责,√表示云计算厂商负责。

1.1.3 容器化和容器编排

容器化本质上是虚拟化的改进。

虚拟化通过Hypervisor分离操作系统,容器化共享操作系统。

LXC(Linux Container)侧重容器运行环境的资源隔离和限制,类似进程沙箱,而没有容器镜像打包技术,所以没有普及。

Docker在LXC的基础之上,建立了一套镜像打包和运行机制,将应用程序和依赖项打包成镜像文件,换别的Docker中也能运行,实现Build, Ship and Run。

容器编排技术经过Mesos、Swarm和Kubernetes三家竞争,最后随着Kubernetes的成熟及其与Docker的融合,PaaS技术的主流路线过渡到了Kubernetes Docker。2018年,Kubernetes占据统治地位。

1.1.4 云计算演进总结

企业降低对IT基础设施的直接投入,而是通过上云来获取计算和存储能力,按时按需计费。

云计算降低了IT支出,降低了行业技术壁垒。

1.2 云原生是什么

1.2.1 云原生出现的背景

移动互联网,业务高速发展,快速迭代。

1.2.2 云原生的定义

Pivotal(云原生应用提出者):

  1. DevOps
  2. 持续集成
  3. 微服务架构
  4. 容器化

CNCF(Cloud Native Computing Foundation):

  1. 应用容器化
  2. 面向微服务架构
  3. 应用支持容器的编排调度

Mission of the Cloud Native Computing Foundation

The Foundation’s mission is to make cloud native computing ubiquitous. The CNCF Cloud Native Definition v1.0 says:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

1.2.3 云原生与12因素

2012年,Heroku提出12-Factors云应用设计理念。

  1. Codebase:基准代码。用一个代码库做版本控制和多次部署。
  2. Dependencies:依赖。显式声明依赖关系,通过工具(Maven, Bundler, NPM等)隔离依赖,目的是不依赖于部署环境。
  3. Config:配置。通过操作系统级的环境变量将配置信息应用到各个部署环境。
  4. Backing services:后端服务。视后端服务为附加资源。
  5. Build, release, run:严格分离构建和运行。
  6. Process:进程。应用程序作为一个或多个无状态进程执行。任何持久化数据都存储于后端服务。
  7. Port binding:端口绑定。完全自我加载,不依赖网络服务器即可提供网络服务。通过监听端口来服务发来的请求。
  8. Concurrency:并发。通过进程模型进行扩展。水平向外扩展应用进程。
  9. Disposability:易处理。快速启动、优雅终止可最大化健壮性。包括,快速而有弹性的扩展、对变更的部署和宕机恢复能力。
  10. Dev/prod parity:开发环境与线上环境等价。尽可能保持开发、预发布和线上环境的相似,实现持续交付与部署。
  11. Logs:日志。视日志为事件流,通过集中式服务收集、聚合、检索和分析日志。
  12. Admin processes:管理进程。后台管理任务当作一次性进程执行,如:数据库迁移任务。

核心思想:

  1. 使用声明式格式来搭建自动化。(学习成本低)
  2. 和底层操作系统保持简洁的契约。(可移植性强)
  3. 适合在现代的云平台上部署。(避免额外的管理需求)
  4. 最小化开发与生产的分歧。(持续部署、灵活性强)
  5. 在工具、架构和开发实践不产生重大变化的前提下实现扩展。

1.3 云原生的基础架构

云原生应用利用微服务、服务网络、容器、DevOps和声明式API等代表性技术,来构建容错性好、易于管理和便于观察的松耦合系统。

1.3.1 微服务

将明确定义的功能分成更小的服务,服务之间是松耦合的,每个服务可以独立迭代。

优点:降低系统复杂度、独立部署、独立扩展、跨语言编程。

缺点:需要构建、测试、部署、运行数十个独立的服务,支持多种语言和环境,还引入了分布式系统的复杂性,如:网络延迟、容错性、消息序列化、不可靠网络、异步机制、版本化和差异化。

1.3.2 容器

将微服务和所需的所有配置、依赖关系和环境变量打包成容器镜像,轻松移植到新的服务器节点。

人力运维部署成本太大,在Docker基础之上,引入Kubernetes可以实现容器集群的自动化部署、自动扩缩容和维护等功能。

Kubernetes不仅支持Docker,还支持Rocket等其他容器技术。

1.3.3 服务网络

微服务技术架构有:

  1. 侵入式架构:服务框架嵌入程序代码,开发者组合各种组件(如:RPC、负载均衡、熔断等)。
  2. 非侵入式架构:以代理的形式,与应用程序部署在一起,接管应用程序网络并对其透明,开发者只关心自身业务。

服务网络(Service Mesh)对运行于其上的云原生应用是透明的。

服务网格是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中,Service Mesh 通常以轻量级网络代理阵列的形式实现,这些代理与应用程序代码部署在一起,对应用程序来说无需感知代理的存在。

开源的服务网络软件:Istio、Linkerd、Envoy、Dubbo Mesh等。Service Mesh可以运行在Kubernetes上。

1.3.4 DevOps

DevOps包含三个部分:

  1. 开发
  2. 测试
  3. 运维

DevOps

  1. Dev
    1. Plan
    2. Create
    3. Verify
    4. Package
  2. Ops
    1. Release
    2. Configure
    3. Monitor

1.4 小结

云原生将云目标从节约IT成本转向推动业务增长。

2 微服务概述

2.1 系统架构的演进

2.1.1 单体架构

巨石(Monolith)应用,易于测试、部署,但编译慢、局部改动就要重新部署、技术难扩展。

2.1.2 垂直分层架构

对单体架构垂直拆封,例如:用户界面层、业务逻辑层、数据访问层。

2.1.3 面向服务架构SOA(Service-Oriented Architecture)

每个服务登记到服务登记中心上。

服务消费者从服务登记中心寻找,通过发送消息由企业服务总线(Enterprise Service Bus)转换后发送给相应的服务来调用服务。

SOA是中心化架构,关注系统集成。

2.1.4 微服务架构

大型复杂软件有一个或多个微服务组成。微服务可独立部署、松耦合、仅关注完成单一职责。每个职责代表一个高内聚的业务能力。

微服务是去中心化架构,关注分散管理、代码重用、快速扩展。

微服务架构的特点:

  1. 系统服务曾分离为一个个的微服务。
  2. 微服务遵循单一原则。
  3. 微服务之间采用RESTful等轻量级协议通信。
  4. 微服务采用容器技术部署,运行在自己的独立进程中。
  5. 每个微服务都有独立的业务开发活动和周期。

如果拆分的服务过多,服务治理成本会极大升高,开发调试成本高。服务之间相互依赖,还可能形成复杂依赖链,异常时出现雪崩效应。

2.1.5 云原生架构

代表技术:

  1. 容器
  2. 服务网络
  3. 微服务
  4. 不可变基础设施
  5. 声明式API

四要素:

  1. 微服务
  2. 容器化
  3. DevOps
  4. 持续交付

云原生架构依托PaaS产品:

  1. Codeless:服务开发。
  2. Applicationless:服务发布。
  3. Serverless:服务运维。

2.2 常见的微服务框架

2.2.1 Java中的Spring Cloud与Dubbo框架

Spring Cloud将各家公司开发的比较成熟的服务框架组合起来,通过SprIng Boot风格再封装,屏蔽复杂配置和实现原理,对外提供简单易懂的工具包。

Dubbo框架是分布式服务框架,提供RPC方案和SOA服务治理方案,特点主要在:远程通信、集群容错、自动发现。

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

Go-kit(gokit.io)是Go语言工具包的集合。

Go-kit不仅是微服务工具包,也非常适合构建优雅的架构设计。

Go-kit应用程序架构:

  1. 传输层:网络通信,HTTP、gRPC等,或NATS发布订阅系统。
  2. 接口层:服务对外提供的接口方法定义为端点(Endpoint),端点使用传输层的通信对外提供服务。
  3. 服务层:业务逻辑,不考虑传输、编解码。

Go Micro是Go语言实现的插件化RPC微服务框架,包含组件:

  1. Registry:服务发现,解析服务名字到服务地址。
  2. Selector:基于Registry的负载均衡组件。
  3. Broker:发布和订阅组件。服务之间基于消息中间件的异步通信。
  4. Transport:服务之间的同步通信。
  5. Codec:服务之间的消息编解码组件。
  6. Server:服务主体。
  7. Client:提供访问微服务的客户端。

2.3 微服务设计的六大原则

  1. 高内聚低耦合
  2. 高度自治
  3. 以业务为中心
  4. 弹性设计
  5. 日志与监控
  6. 自动化

2.4 领域驱动设计

Domain Driven Design

分为4层:

  1. Interface
  2. Application
  3. Domain
  4. Infrastructure

业务系统

  • 核心域(Core Domain):如,秒杀操作。
  • 子域
    • 支撑子域(Generic Subdomain):如,活动管理领域(创建秒杀、查询秒杀)。
    • 通用子域(Common Subdomain):如,用户鉴权领域。

限界上下文和子域一一对应,一个限界上下文只使用一套通用语言,并保证其清晰简洁。

实际情况中,根据业务,有时将多个界限上下文合并。

随着微服务架构流行,组织内部产生许多小规模团队。组织架构从层级职能组织变成扁平的小团队集群。