【微服务】初识（day1）

基础概念

集群

集群是将一个系统完整的部署到多个服务器，每个服务器提供系统的所有服务，多个服务器可以通过负载均衡完成任务，每个服务器都可以称为集群的节点。

分布式

分布式是将一个系统拆分为多个子系统，多个子系统部署在多个服务器上，多个服务器上的子系统协同完成一个特定任务。

其实，并不需要特别区分集群和分布式的细微概念。如果非要细究的话，分布式强调的是物理形态，即工作在不同服务器上并且通过网络通信配合完成任务；集群强调的是逻辑逻辑，即是否为了完成特定服务目标。

主从

集群中，通常有一个程序需要承担更多的责任，该程序称为主程序，其他承担附属职业被称为从。例如，在MySQL集群中，通常只有一台服务器承担写责任（增删改），而其他的服务器都承担读责任，因此承担写责任的服务器称为主，而其他负责读的服务器成为从。

微服务

简单来说，微服务就是很小的服务，小到一个服务器只对应一个单一的功能，只做一件事，并且这个服务可以单独部署运行。

本质上，微服务是分布式架构的一种扩展，只不过微服务的拆分粒度更小、服务器更独立。可以理解为：微服务是一种经过良好架构设计的分布式架构方案。

微服务之间的通信方式有REST和RPC两种。

中间件

中间件是一种用户不同应用程序之间相互通信的软件，即处于不同技术、工具和数据库之间的桥梁。例如RabbitMQ就是一个典型的中间件程序。

亿级高并发架构演进之路

单机架构

单机架构表示应用服务和数据库服务都在一台主机上。在互联网早期，访问量比较小的时候，单机架构足以满足要求。

如下图就是单机架构图，可以看到应用和数据库在单个机器上就可以协作完成业务运作。

优点：部署简单、成本低

缺点：存在严重的性能瓶颈，并且数据库服务和应用服务互相竞争资源 

应用数据分离架构

应用数据分离架构表示应用服务和数据库服务进行拆分，即两个服务使用不同的服务器进行工作。

出现原因是单机架构存在严重的资源竞争，导致请求响应过慢。

如下图就是应用数据分离架构图，可以看到，应用服务和数据库服务在各自的服务器上通过网络协作来完成工作。 

优点：

 成本相对可控

 性能相比单机有提升

 数据库单独隔离，不会因为应用出现问题把数据库搞坏，有一定的容灾能力

缺点：

 硬件成本变高

 性能有瓶颈，无法应对海量并发 

应用服务集群架构

当上述两种架构无法解决问题时，就出现了两种解决方案：横向扩展（水平扩展）和纵向扩展（垂直扩展）。垂直扩展表示购买性能更优、价格更高的应用服务器来应对更高的流量，这种方案并不需要对软件做任何的改变，但是硬件性能提升和价格并不是线性的，即两倍性能的机子价格并不是两倍，而可能是三倍、四倍、五倍、六倍等等。水平扩展指的是调整软件架构，将用户流量分担到不同的应用服务器上，来提升系统的承载能力，这种方案在价格上相对较低，并且提升空间也比较大，但是给系统带来了更多的复杂性，需要技术团队有更丰富的经验。

水平扩展需要将用户流量分担到不同的应用服务器上，这时就需要引入一个新的组件——负载均衡。常见的负载均衡算法有：

公平轮询算法Round-Robin：非常公平的将请求依次分发给不同的应用服务器。

非公平轮询算法Weight-Round-Robin：为不同的服务器赋予不同的权重，能者多劳。

一致性哈希散列算法：通过计算用户的特征值（例如IP地址）得到哈希值，根据哈希结果做分发，优点是确保来自相同用户的请求总是分发给指定的服务器。

应用服务集群架构表示将应用服务部署在多个机子上，以集群方式进行运行，并且引入负载均衡组件，保证每个机子都能收到请求。

出现原因是单个应用已经不足以支持海量的并发请求，高并发时请求响应变慢。

如下图就是应用服务集群架构图，从下图可以看出，应用不再是一个，而是变成多个，通过负载均衡来支持海量数据并发。

优点：

 应用满足高可用，不会因为一个服务出现问题而导致整个站点挂掉的情况出现

 应用服务具备一定的高性能，如果不访问数据库，应用相关处理通过扩展可以支持海量请求快速响应

 应用服务有一定扩展能力，支持横向扩展

缺点：

 数据库成为性能瓶颈，无法应对海量数据的查询

 数据库是单点，没有高可用

 运维工作增多，部署时需要同时部署多个应用，需要开发对应的工具应对快速部署

 硬件成本变高 

读写分离/主从分离架构

读写分离/主从分离架构表示将数据库应用进行集群化部署，将读写操作分散到不同的节点上，即给数据库服务搭建主从集群，一主一从/一主多从都可以，主机负责写操作、从机负责读操作。

出现原因是应用可以高并发工作，但是数据库成为了性能瓶颈，而互联网应用一般读多写少，因此数据库压力主要来源于读操作的，那么我们就可以把读操作和写操作分开。

如下图为主从分离/读写分离架构图，从下图可以看出，数据库服务不再是一个，而是变成了多个。数据库主机负责写操作，从机负责读操作，数据库主机通过复制将数据同步到从机。

优点：

 数据库的性能提升

 读取被其他服务器承担，写的性能简介提升

 数据库有从库，数据库的可用性提高了

缺点：

 热点数据的频繁读取导致数据库负载很高

 当同步挂掉，或者同步延迟比较大时，写库和读库的数据不一致

 服务器成本需要进一步提高 

冷热分离架构

冷热分离架构表示引入缓存，实行冷热分离，将热点数据放到缓存中快速响应。

出现原因：海量的请求导致数据库负载过高，响应再度变慢。

如下图是冷热分离架构图，可以看出增加了缓存服务器，对于热点数据全部放到缓存中，不常用的数据再去查询数据库。

优点：

 大幅度降低对数据库的访问请求，性能提升非常明显

缺点：

 带来了缓存一致性、缓存失效、缓存击穿等多种问题

服务器成本进一步提升

业务体量变大后，数据不断增加，数据库单库单表体量太大，数据查询变慢，导致数据库再度成为性能瓶颈。

垂直分库架构

垂直分库表示将库中的表按照业务的耦合程度进行拆分，分成不同的库进行处理。

垂直分表表示将标准的字段按照冷热程度进行拆分，常用的字段分到一个表中，不常用的字段分到另一个表中。

水平分库表示库里面的表都相同，但是存储不同的数据，即假设有两亿条数据，并且数据的格式相同，一个库中存储一亿条数据。

水平分表表示表的字段相同，但是存储的数据不同，即原本一个表中的数据分开存储。

简单来说，无论是库还是表的拆分。水平拆分指的是将数据进行分开存储，不做其他处理。垂直拆分指的是将原有的结构进行改变。

垂直分库架构表示将数据库、数据表进行拆分，数据库服务分布式存储、分布式处理、分布式查询，也可以理解为分布式数据库架构。

出现原因：单机的写库逐渐到达性能瓶颈，需要拆分数据库。数据表的数据量太大，处理压力太大，需要进行分表。为了解决运维难度，业界逐渐研发了分布式数据库、分布式数据表，例如MyCat技术栈。

如下图为垂直分库架构图，可以看出，数据库由多个主从库或存储集群构成，支持分布式大规模处理。

 优点：

 数据库吞吐量大幅度提升，不再是性能瓶颈

缺点：

 跨库join、分布式事务等问题，这些都需要去解决，不过目前的mpp（大规模并行处理）都有对应解决方案

 数据库和缓存结合目前能够扛住海量的请求，但是应用的代码整体耦合在一起，修改一行代码就会需要整体服务重新发布

微服务架构

微服务架构表示将服务按照业务板块进行拆分，使单个应用的职责更加请求，相互之间可以做到独立升级迭代。

出现原因：

 扩展性差，应用程序无法轻松扩展，因为每次需要更新应用时，都需要重新构建整个系统

 持续开发困难，一个很小的代码改动，也需要重新部署整个应用，无法频繁并轻松的发布版本

 不可靠，即系统的一个功能不起作用，可能导致整个系统无法工作

 不灵活，无法使用不同的技术构建单体应用程序

 代码维护难，所有的功能耦合在一起，新人不知道从何下手

下图是微服务架构图，可以看出，一个应用拆分成了多个微服务，多个服务相互之间协作支持整个应用。

 优点：

 灵活度高，服务可以独立测试、部署、升级、发布

 独立扩展，每个服务都可以各自进行扩展

 提高容错性，一个服务出现问题并不会让整个系统瘫痪

 新技术的应用容易，支持多种编程语言，

缺点：

 运维复杂度高，业务不断扩展，应用和服务都会不断增多，导致部署变得复杂，并且同一台服务器上部署多个服务还要解决运行环境冲突的问题。此外，对于如大促这种需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将十分困难。

 资源使用变多，所有这些独立运行的微服务都需要占用内存和CPU

 处理故障困难，一个请求跨多个服务调用，需要查看不同服务的日志完成问题定位

容器编排架构

容器编排架构就是借助容器化技术（Docker）将应用/服务打包为镜像，通过容器编排工具（K8s）来动态分发和部署镜像，服务以容器化方式运行。

出现原因：

 微服务拆分细，服务多部署工作量大，而且配置复杂，容易出错

 微服务数量多扩容麻烦，而且容易出错，每次缩容后又扩容需要重新配置服务对应的环境参数信息

 微服务之间运行环境可能冲突，需要更多的资源来进行部署或者通过修改配置来解决冲突。

如下图是容器编排架构图，可以看出，将每个服务打包到容器中，相互协作来完成系统功能，通过容器编排工具完成部署运维。

 优点：

 部署运维快速简单，一条命令就可以完成几百个服务的部署或者扩缩容

 隔离性好，容器与容器之间文件系统，网络等互相隔离，不会产生环境冲突

 支持滚动更新，版本间切换都可以通过一个命令完成升级或者回滚

缺点：

 技术栈变多，对研发团队要求高

 机器还是需要公司自身来管理，在非大促的时候，还是需要闲置大量机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低，可以通过购买云厂商服务器来解决。

总结

1. 单体架构：应用互联网发展初期，将应用服务和数据库服务都集成在一个主机上提供服务。
2. 应用数据分离架构：用户量增多，导致应用服务和数据库服务互相竞争资源，因此将应用服务和数据服务放到不同的主机上给用户提供服务。
3. 应用集群架构：用户量再次增多，一个应用服务无法处理所有请求，因此将应用服务以集群的方式进行部署，通过负载均衡，把请求分发给集群中的服务。
4. 读写分离/主从分离架构：应用服务可以相对支持高可用、高并发、高性能的场景，但是数据库还是那么一个，因此采用主从分离架构。即将数据库服务分成多个，一个主机负责写数据（增删改），其余从机负责读取数据。
5. 冷热分离架构：不仅生活中存在二八原则，在数据库服务中也同样存在二八原则，即百分之二十的热点数据就可以支持百分之八十的应用。所以，引入缓存服务，将常用的热点数据放入缓存中，不常用的数据再到数据库中查询，减少数据库的请求。
6. 垂直分库架构：数据库 + 缓存可以支持极高的请求了，但是数据量过多，导致查询速度变慢，因此出现分库分表架构，将库拆分，将表拆分。
7. 微服务架构：集群化应用可以解决高可用、高并发，但是太过耦合，所以采用微服务架构，将服务进行拆分。
8. 容器编排架构：微服务拆分之后，虽然容错性高、灵活度高，但是给运维人员带来了繁重的工作。试想一个应用就有上百个服务需要部署，这是非常头大的。此时引入了容器化技术和容器编排技术，可以通过简单的命令将上百个服务轻松部署。

架构的发展并不是大佬每天闲着没事研究出来的，而是由于现有的架构无法支撑用户的要求，因此逐渐发展出来。因此，架构的出现也是随着业务的发展而出现，因此我们在实际工作中，不仅要了解新技术，更要关注一些复杂业务的实现。

SpringCloud

在Java后端技术栈中，一般是离不开Spring家族的，同样，微服务架构也是和Spring家族息息相关。值得提及的是，SpringCloud并不是实现了所有的微服务架构，他只是把一些比较优秀的微服务架构进行了整合。它基于自己的风格，对这些组件进行封装，屏蔽掉了原来复杂的配置和实现原理，为开发者提供了开箱即用的微服务开发体验。在SpringCLoud中，比较优秀的微服务框架有SpringCloudNetflix和SpringCloudAlibaba两家。

SpringCloud声称要做分布式微服务架构的一站式解决方案，其中的组件有：

• 分布式版本配置
• 服务注册和发现
• 路由
• 服务调用
• 负载均衡
• 断路器
• 分布式消息

SpringCloudNetflix

SpringCloudNetflix是NetFlix OSS在SpringCloud规范下的实现，包含的组件及其主要功能大致如下：

• Eureka：服务注册和发现
• Zuul：服务网关
• Ribbon：负载均衡
• Feign：服务调用
• Hystrix：断路器，例如熔断、限流等
• Hystrix Dashboard：监控面板

在很长一段时间内，SpringCloud一度被泛指为SpringCloudNetflix。SpringCloud一直以来把Netflix套件作为官方默认的一站式解决方案。然而，2018时其公司宣布其核心组件进入维护状态，不再进行更新，SpringCloud也被迫宣布删除这些维护模块。

不过，Eureka仍在活跃范围中，利用是Netflix公司将其开源处理。

SpringCloudAlibaba

SpringCloudAlibaba是阿里巴巴集团下的开源组件在SpringCloud规范下的实现。

如果说Netflix的产品是SpringCloud的第一代实现，那么可以说阿里巴巴的产品就是SpringCloud的第一代实现，主要是由Nacos、Sentinel、Seata等组件组成。

微服务的优点

1. 易开发和维护，每个微服务负责的业务比较清晰，体量小，开发和维护成本低。
2. 容错性高，一个服务发生故障，可以使故障隔离在单个服务中，不影响整体服务架构。
3. 扩展性好，每个服务都是独立运行的，我们可以结合项目实际情况进行扩展，按需伸缩。
4. 技术选型灵活，每个微服务都是单独的团队来运维，可以根据业务特点和团队特点，选择合适的技术栈。

微服务的挑战

1. 服务依赖，随着服务数量的增多，服务之间的关系也会变得复杂。一个服务的更改，需要考虑对其他服务的影响。
2. 运维成本，一个业务流程可能设计多个微服务共同完成，有更多的服务需要编译、部署、运行，甚至可能是不同的编程语言，不同的运行环境，当然也需要集群来处理故障转移等。这对于运维人员来说，挑战无疑是巨大的。
3. 开发和测试，一个业务流程可能涉及到多个微服务共同完成，服务调用会引入网络延迟，不可靠的网络，如何进行容错处理等问题。这对于开发和测试而言，难度也会提升。
4. 服务监控，在一个单体结构中，很容易实现服务的监控，因为所有的功能都在一个服务器中。微服务架构下，不仅需要对整个链路进行监控，还需要对每一个服务实现监控。
5. 负载均衡，微服务架构中的服务实例数量可能非常巨大，因此需要有效的服务发现和负载均衡机制来管理请求流量和保证高可用性。

服务拆分原则

单一职责原则

单一职责原则原本是面向对象设计中的一个基本原则，它指的是一个类应该专注于单一功能。不要存在多余一个导致类变更的原因。

在微服务架构中，一个微服务也应该只负责一个功能或者业务领域，每个服务应该有清晰的定义和边界，只关注自己的特定业务领域。

服务自治

服务自治是指每个微服务都应该具备高度自治的能力，即每个服务都要做到能独立开发、独立测试、独立构建、独立部署、独立运行。

单向依赖

微服务之间要做到单向依赖，严禁循环依赖、双向依赖。

 如果一些业务场景中存在循环依赖或者双向依赖，采用其他方式解决，比如分布式消息等。