第一章 微服务架构介绍

第一章 微服务架构介绍

本章将会概要性地介绍微服务架构：

• 微服务架构是如何演进的
• 微服务架构的主要流派
• 当前主流的云原生应用与微服务之间的关系等

1.1 微服务架构的出现

分布式云平台的应用环境使得微服务代替单体应用成为互联网大型系统的架构选择

1.1.1 单体应用架构

传统的单体应用

Web应用程序发展的早期，大部分Web工程是将所有的功能模块打包到一起部署和运行

单体应用的实现架构类似:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F9YHy0bd-1603527978635)(08115EB291E147E19AF31EAE622249B8)]
采用分层架构，按照调用顺序，从上到下为表示层、业务层、数据访问（ DAO）层、 DB 层

• 表示层负责用户体验
• 业务层负责业务逻辑
• 定义了应用的业务逻辑，是整个应用的核心
• 数据访问层负责 DB 层的数据存取， 实现增删改查的功能

在单体应用中，所有这些模块都集成在一起，这样的系统架构就叫做单体应用架构，或称为巨石型应用架构
中小型项目中使用单体应用架构，能体现出其优势
单体应用的整体性能主要依赖硬件资源和逻辑代码实现
优点：
集成非常简洁
易于调试
开发和部署都很简单
可以轻松实现应用扩展
主要有如下不足：

• 可靠性：每个 bug 都可能会影响到整个应用的可靠性
• 复杂性高：单体应用巨大的代码库可能会令人望而生畏，特别是对团队新成员来说
• 应用难以理解和迭代，进而导致开发速度减慢
• 持续部署困难：巨大的单体应用本身就是频繁部署的一大障碍
• 为了更新一个组件， 必须重新部署整个应用
• 扩展能力受限：单体架构只能进行一维扩展
• 一方面，它可以通过运行多个应用服 务实例来增加业务容量，实现扩展
• 另一方面，不同的应用组件有不同的资源需 求： 有的是 CPU 密集型的，有的是内存密集型的
• 阻碍技术创新： 单体应用往往使用统一的技术平台或方案解决所有问题

1.1.2 SOA 架构

面向服务的架构
Gartner于20世纪90年代中期提出的
核心主体是服务，其目标是通过服务的流程化来实现业务的灵活性

• 服务就像 一堆“元器件”，这些元器件通过封装形成标准服务，它们有相同的接口和语义表达规则
• 服务要组装成一个流程和应用，还需要有效的“管理”，包括如何注册服务、 如何发现服 务、如何包装服务的安全性和可靠性

以上两点称之为SOA治理
完整的SOA架构由五大部分组成：基础设施服务、企业服务总线、关键服务组件、开发工具、管理工具等

• 基础设施：为整个SOA组件和框架提供一个可靠的运行环境，以及服务组件容器
• 它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑
• 企业服务总线： 提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内 容的路由等功能
• 屏蔽了服务的物理位置、协议和数据格式
• 关键服务组件： SOA 在各种业务服务组件的分类
• 开发工具和管理工具：提供完善的、可视化的服务开发和流程编排工具
• 包括服务的设计、开发、 配置、部署、监控、重构等完整的SOA项目开发生命周期

接口采用中立的方式进行定义，它应该独立于实现服务的硬件平台、操作系统和编程语言
目的是要将紧捐合的系统，划分为面向业务的、 粗粒度、松搞合、无状态的服务
服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构的系统
基于这些基础的服务，可以将业务过程用类似 BPEL （业务流程执 行语言）流程的方式编排起来， BPEL 反映的是业务处理的过程
企业还需要一些服务治理的工具， 比如服务注册库、监控管理等

1.1.3 微服务架构

最早是由 Martin Fowler与James Lewis于2014年共同提出

了解细节的读者可以阅览 https://martinfowler.com/articles/microservices.html

根据其描述，微服务的定义可以概括如下：

微服务架构是一种使用 一系列粒度较小的服务来开发单个应用的方式；每个服务运行在自己的进程中；服务间采用轻量级的方式进行通信（通常是 HTTPAPI)；这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采 用不同的编程语言编写，使用不同的数据存储技术

1. 组成

其中一些常用的组件及其概念如下：

• 服务注册与发现： 服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址
• 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点
• 并且，服务节点选择的过程对服务调用方来说是透明的
• 服务网关：服务网关是服务调用的唯一人口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、 A/B测试、负载限流等功能
• 配置中心：将本地化的配置信息（Properties、XML、YAML等形式）注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程序包的迁移
• 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够 在统一的界面中使用系统
• 调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调 用关系展示出来
• 在系统出错时，可以方便地找到出错点。
• 支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化
• Docker 等工具可以给微服务架构的部署带来较多的便利
• 如果没有合适的支撑平台或工具，微服务架构就 无法发挥它最大的功效

2. 优点

首先， 通过将巨大单体式应用分解为多个服务的方法解决了复杂性问题

单个服务变得很容易开发、理解和维护

其次，微服务架构模式使得团队并行开发得以推进，每个服务都可以由专门开发团队来开发

不同团队的开发者可以自由选择开发技术，提供 API 服务

再次，微服务架构模式中每个微服务独立都是部署的

理想情况下，开发者不需要协 调其他服务部署对本服务的影响
可以加快部署速度

最后，微服务架构模式使得每个服务易于独立扩展

3. 挑战

在实践中也会呈现出其复杂性，具体如下 ：

• 运维要求较高。 更多的服务意味着需要更多的运维投入
• 分布式固有的复杂性。 使用微服务构建的是分布式系统
• 接口调整成本高。 微服务之间通过接口进行通信
• 重复劳动。 很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一 个微服务的程度
• 可测试性的挑战。 在动态环境下，服务间的交互会产生非常微妙的行为，难以进行 可视化及全面测试

1.2 微服务架构的流派

常见的微服务架构方案有四种，分别是 ZeroC IceGrid、 基于消息队列、Docker Swarm和 Spring Cloud

1. ZeroC IceGrid

基于RPC框架Ice发展而来的一种微服务架构

Ice不仅仅是一个 RPC 框架，它还为网络应用程序提供了一些补充服务
Ice是一个全面的 RPC 框架， 支持 C＋＋、C＃、Java JavaScript、Python等语言

IceGrid具有定位、部署和管理 Ice服务器的功能， 具有良好的性能与分布式能力
下面具体介绍 IceGrid 的功能：

• Ice的DNS
• 允许Ice客户端通过简单的名称来查找Ice对象
• Ice 客户端可以通过提供此对象的完整寻址信息来访问服务器中的Ice对象 硬编码虽然很简单，但缺乏灵活性
• IceGrid 提供了对这种寻址信息使用符号名称的选项
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j2jg63gH-1603527978642)(8875B52B61904FC59F766644D5E084AA)]
• 服务器部署。 若直接通过IP地址＋端口号的方式，当Ice客户端尝试连接到未运行的服务器时，连接将会失败
• 可以配置 IceGrid 以各种方式启动服务 器： 手动（通过管理命令）、按需（无论何时请求服务器）和 IceGrid始终保持服务器运行
• 服务器的复制。 IceGrid 允许部署同一服务器的多个副本，并可以配置 IceGrid 将符号名称解析到此服务器副本的策略
• 可以在所有副本中对客户端进行负载平衡，或者使用主 备配置，客户端只要保持可用状态，就使用主备配置
• 管理和监控。 IceGrid 的管理工具可以完全控制已部署的应用程序
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vNns1DE1-1603527978645)(1537B785218F4691B796D4115EAB1C15)]

Ice Grid 当前最新的版本为3.7.1 ，在3.6版本之后增加了容器化的运行方式
当前国内选用这种 微服务架构方案的公司非常少
流行时间并不是很久

2. 基于消息队列

所谓通信轻量级，是指通信协议与语言无关、 与平台无关
微服务之间的通信方式有两种：同步和异步
同步方式有RPC,REST等；
微服务之间采用发布消息与监听消息的方式来实现服务之间的交互
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NVqdwXfP-1603527978648)(6185568E073543E0A7976607CC022314)]
基于消息队列的微服务架构是全异步通信模式的一种设计，各个组件之间没有直接的捐合关系，也不存在服务接口与服务调用的说法
案例并不多
成本较高且风险较大
需要项目组自己从零开始去设计实现一个微服务架构基础平台

3. Docker Swarm

用来提供容器集群服务
目的是 更好地帮助用户管理多个Docker Engine，方便用户使用
通过把多个 Docker Engine 聚集在一起，形成一个大的Docker Engine，对外提供容器的集群服务
同时这个集群对外提供Swarm API，用户可以像使用 Docker Engine 一样使用 Docker 集群
Docker 三剑客包括： Machine、 Compose 和 Swarm
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6H98MimD-1603527978650)(B5A59AA43BE948AC91E85EE11AC4F034)]
通过 Machine可以在不同云平台上创建包含 docker-engine 的主机

Machine通过driver机制，支持多个平台 的 docker-engine 环境的部署

Swarm 将每一个主机上的 docker-engine 管理起来，对外提供容器集群服务
Compose 项目主要用来提供基于容器的应用的编排
用户通过 yaml 文件描 述由多个容器组成的应用，然后由Compose解析yaml文件，调用DockerAPI ，在Swarm集群上创建对应的容器
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wvv69fGM-1603527978652)(7DD6EC57820A4BAEA1CD4442D4FE9033)]
看到－个 Swarm 集群中有两种角色的节点：

• Manager：负责集群的管理、集群状态的维持及将任务（Task）调度到工作节点上等
• Worker ：承载运行在 Swarm 集群中的容器实例，每个节点主动汇报其上运行的任 务并维持同步状态

4. Spring Cloud

一个基于Spring Boot实现的云应用开发工具
是一系列框架的集合
以下为 Spring Cloud 的核心功能：

• 分布式／版本化配置
• 服务注册和发现
• 服务路由
• 服务和服务之间的调用
• 负载均衡
• 断路器
• 分布式消息传递

还有很多基础的功能没有列出，每个功能对应SpringCloud中的一个组件，包括SpringCloudConfig、SpringCloudNetflix(Eureka、Hystrix、Zuul、Archaius …）、 Spring Cloud Bus 等组件

1.3 云原生与微服务

CNCF，即云原生计算基金会
2015年由谷歌牵头 成立，基金会成员目前已有一百多个企业与机构，包括亚马逊、微软、思科等巨头
目前CNCF所托管的应用已达 14 个，知名的项目有 Kubernetes、 Prometheus、 Envoy 等

1. 云原生

三大特征，概括如下：

• 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原 生应用程序的维护
• 动态管理：通过集中式的编排调度系统来动态管理和调度
• 面向微服务：明确服务间的依赖，互相解耦

云原生由微服务架构、 DevOps 和以容器为代表的敏捷基础架构组成
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dBfCxnSu-1603527978654)(B16EE790B9904E918A46C5E6C501BD1F)]

2. 12 原则

12 原则（ 12-Factors）经常直译为 12 要素

12 原则由公有云 PaaS 的先驱Heroku于2012年提出（https://12factor.nct/），目的是告诉开发者如何利用云平台提供的便利来开发更 具可靠性和扩展性、更加易于维护的云原生应用

12 原则包括：

• 基准代码
• 显式声明依赖关系
• 在环境中存储配置
• 把后端服务当作附加资源
• 严格分离构建、发布和运行
• 无状态进程
• 通过端口绑定提供服务
• 通过进程模型进行扩展
• 快速启动和优雅终止
• 开发环境与线上环境等价
• 日志作为事件流
• 管理进程

另外还有补充的三点： API 声明管理、认证和授权、 监控与告警
已经不那么跟得上时代，也有人批 评 12 原则的提出从一开始就有过于依赖 Heroku 自身特性的倾向

3. 容器化

Docker 是一个开源引擎，可以轻松地为任何应用创建一个轻量级的、 可移植的、自给自足的容器
Docker 根本的想法是创建软件程序可移植的轻量容器，让其可以在任何安装了 Docker 的机器上运 行， 而不用关心底层操作系统
Docker 可以解决虚拟机能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题
其优势包括：

• 隔离应用依赖
• 创建应用镜像并进行复制
• 创建容易分发的、即启即用的应用
• 允许实例简单、快速地扩展
• 测试应用并随后销毁它们

最常见的编排框架有 Kubernetes、 Mesos、 Docker Swarm

4. DevOps

DevOps 是软件开发人员（ Dev）和 IT 运维技术人员（ Ops）之间的合作
目标是自动执行软件交付和基础架构更改流程，使得构建 、测试、发布软件能够更加地快捷和可靠
创造了一种文化和环境，可在其中快速、频繁且更可靠地构建、 测试和发布软件

5. 微服务

将单体业务系统分解为多个可独立部署的服务
微服务架构有以下优势：

• 当人们将业务领域分解为可独立部署的环境时，能够将相关的变更周期解耦
• 扩展更多的部署组件本身可以加快部署
• 可以加快采用新技术的步伐
• 微服务提供独立、高效的服务扩展