这是我参与「第三届青训营 -后端场」笔记创作活动的第五篇笔记

本节课主要有以下四个部分：

1 微服务架构介绍

1.1 系统架构演变历史

互联网行业的发展：用户指数级的增加

硬件的发展:包括CPU MEM存储网络

需求的多样性:文本图片音频视频 VR

开发人员的急剧增加:早期的精英程序员，如今的易于上手的开发平台对程序员要求变低

计算机理论技术的发展:算法(Paxos Raft)，NosQL大数据等

单体架构

一个归档包（例如war格式或者Jar格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构，这是一种比较传统的架构风格。

1，模块相互影响：非核心功能可能会导致软件崩溃。

2，单个仓库的模块分工，依赖管理，开发流程很复杂，导致几乎无法分工。

垂直应用架构

分层设计开发的应用，就符合垂直应用架构。

不同业务线的模块存在冗余，无法复用。

分布式架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

SOA架构

SOA是Service-Oriented Architecture的英文缩写，就是面向服务的架构。这里的服务可以理解为service层业务服务。

微服务架构

微服务架构风格的开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API轻量的机制来相互通信。

这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。

1.2 微服务架构概览

1.3 微服务架构核心要素

1.4 小结

2 微服务架构原理及特点

2.1 基本状态

微服务类比

Hadoop分布式文件系统(HDFS)是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统（Distributed File System）。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。

HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求（requirements）这样可以实现流的形式访问（streaming access）文件系统中的数据。

服务间通信

2.2 服务注册及发现

问题：

对于网络通信功能(不管http还是 rpc)，我们知道是需要指定远程的ip port的。

既然服务之间存在通信关系，在实际代码层面，我们怎么写通信地址?

hardcode的方式指定下游实例地址有什么问题?

问题：

hardcode的方式指定下游实例地址有什么问题？

回答：

服务有多个实例，没法 hardcode(记住一个服务的所有实例都是运行同一份代码)服务实例 ip port本身是动态变化的

与DNS类似，引入一个中间层，即上层中的服务注册中心。

了解了服务发现的基本机制，我们来看看如何基于服务发现来实现平滑无损的服务实例上下线流程：

假设系统管理员需要下线serviceB的实例-3

不能直接下线，因为还有流量

因此管理员只能先把Service Registry中实例-3的记录删掉，过了一定的时间后，serviceA无法访问serviceB的实例-3，只能访问serviceB的前两个实例，这时再下线实例-3是安全的，因为已经没有流量了。但是由于下线了一个实例serviceB的前两个实例可能出现流量过大的情况，需要添加一个实例来缓解流量太大的问题，其步骤与下线一个实例相反。

2.3 流量特征

内部调用不使用http是因为http作为文本协议效率太低。

2.5 小结

3 核心服务治理功能

3.1 服务发布

服务发布的难点

蓝绿部署

蓝绿部署中，一共有两套系统：一套是正在提供服务系统(也就是上面说的旧版)，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。

蓝色系统不对外提供服务，用来做啥？

用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。

蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统, 切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。

蓝绿发布特点

蓝绿部署的目的是减少发布时的中断时间、能够快速撤回发布。
两套系统没有耦合的时候才能百分百保证不干扰。
简单、稳定，但是需要两倍的资源。

灰度发布(金丝雀发布)

一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。

发布流程:

相对于蓝绿发布需要一套完备的机器不同，滚动发布只需要一台机器(这儿这是为了理解，实际可能是多台)，我们只需要将部分功能部署在这台机器上，然后去替换正在运行的机器，如上图，将更新后的功能部署在Server1上，然后Server1去替换正在运行的Server，替换下来的物理机又可以继续部署Server2的新版本，然后去替换正在工作的Server2，以此类推，直到替换完所有的服务器，至此，服务更新完成。