详解单体架构 微服务 微服务架构 微服务各个组件 分布式 集群 负载均衡

一、前言

1. 为什么淘汰了单体架构，使用微服务？
2. 集群是什么东东，和分布式有什么联系？
3. 什么是微服务，分布式，两者有什么关系？
4. 微服务之间是如何通信的
5. SpringCloud和Dubbo有哪些区别
   本质区别：服务之间的通信机制的不同，Dubbo是基于RPC，springcloud是基于http的restful API。
6. springboot和SpringCloud，请你谈谈对他们的理解
7. 什么是服务熔断？什么是服务降级？
8. 微服务的优缺点分别是什么？说一下你在项目开发中碰到的坑
9. 你所知道的微服务栈有哪些？列举一二
10. Eureka和Zookeeper都可以提供服务注册与发现的功能，请说说这两个的区别？

二、单体架构

1、概念

  单体架构另一种架构风格,比较原始的架构。将所有功能都部署在一个web
容器中运行的系统。项目打包后，所有服务都在同一个war包中,部署在一
个web容器中,共用一个数据库。

2、优缺点

 （1）优点：
 	1.容易测试 
 	2.容易部署
 （2）缺点：
 ①随着系统业务量的增加，系统过于庞大和复杂，代码都耦合在一起，代码可读性差，维护起来比较难。
 ②因为应用太大，每启动一次都需要很长的时间，因此从编辑到构建、运行再到测试这个周期花费的时间越来越长，开发效率低。
 ③后续增加新的业务，不能做到按需扩展，只能扩展整个系统，扩展性不高。
 ④会因为一个模块的错误导致整个系统宕机，稳定性不高。
 ⑤部署不灵活，修改了某个模块的代码，需要将整个系统重新构建部署。
 ⑥随着系统用户量的增加，用户高并发访问数量有限。

三、微服务概述

1、微服务概念

  简单的来说，就是将一个系统的不同模块转变成不同的服务，每一个服务
只负责一件事。微服务强调的是一个个的个体，每一个个体完成一个具体的
任务或功能，专业的事交给专业的模块来做，一个模块就做一件事情。比如
说一个电子商务系统，订单模块只负责订单，登陆模块只负责登陆，这每一
个模块就是一个微服务。

2、微服务架构

   是一种架构模式，是soa架构的最终产物，微服务架构一定是分布式架构。一个大型复杂的软件
应用系统应该由一个或多个微服务组成。系统中的各个微服务之间是松耦合的，各个微服务可被独立部署，
都有自己独立的进程，可以有自己的数据库，而且服务可以使用不同的技术加以实现(技术异构)，
可以不因为某个模块的升级和bug影响现有的系统业务。在spring cloud中服务之间通过一些轻量级交互机制
来通信，比如http（包括restTemplate和Feign），而在springcloud Alibaba中已经将dubbo（RPC框架）整合了，
性能更好。

下图可以很好的描述了服务化

3、微服务的优缺点

（1）优点：
	1.单一职责,逻辑清晰:每个服务即一个业务模块,逻辑清晰,让人容
易理解。
	2.简化部署:修改了某个服务的代码,无需整个系统重新构建部署,
只需要独构建部署某个服务。
	3.灵活扩展:某部分业务请求压力大,则可通过扩展某块服务,因此
具有更好的扩展性。
	4.技术异构:因为微服务间松耦合，不同的微服务可以选择不同的
技术栈进行开发。同时，在应用新技术时，可以仅针对一个微服务
进行快速改造，而不会影响系统中的其它微服务，有利于系统的演进。
	5.高可靠:微服务间独立部署，一个微服务的异常不会导致其它微
服务同时异常。
（2）缺点：
	1.复杂度高:开发人员要处理分布式系统的复杂性
	2.运维复杂:增加了运维人员的工作量，以前只要部署一个war包，
现在可能需要部署多个war包 (k8s+docker+jenkis自动化部署)。
运维人员需要对系统有细致的了解才对够更好的运维系统.
	3.性能监控麻烦：系统由多个独立运行的微服务构成，需要一个设计良
好的监控系统对各个微服务的运行状态进行监控
	4.无法避免的重复工作:少部分共用功能无法提取成微服务时，各
个微服务对于这部分功能通常需要重复开发，或至少要做代码
复制，以避免微服务间的耦合，增加了开发成本。
	5.影响性能:由于服务拆分开来，部署到不同的平台或网络，可能
会引起微服务间的调用延迟问题，服务间的调用延迟可能带来整体
系统的响应缓慢问题，服务间通信成本。

4、应用场景

   单体架构和微服务架构各有各的有优缺点,使用哪种架构,还需根据具体项
目背景及需求决定
其中,在以下几点中的,不适合使用微服务:
1.开发周期长,迭代稳定:若旧项目比较稳定,不考虑使用微服务,成本太高
2.并发量低,可用性要求不高:一些用户量低的内部系统,比如OA系统
3.复杂度较小:使用微服务就是杀鸡用牛刀

五、微服务技术栈

1、技术栈

微服务条目	落地技术
服务开发	SpringBoot、Spring、SpringMVC
服务配置与管理	Netflix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Consul、Zookeeper等
服务调用	Rest、RPC、gRPC
服务熔断器	Hystric、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用（客户端调用服务的简化根据）	Fegin等
消息队列	Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理	SpringCloudConfig、Chef等
服务路由（API网关）	Zuul等
服务监控	Zabbix、Nagios、Metrics、Spector等
全链路跟踪	Zipkin、Brave、Dapper等
服务部署	Docker、OpenStack、Kubernetes等
数据流操作开发包	SpringCloud Stream（封装与Redis，Rabbit，kafka等发送接收消息）
事件消息总线	Spring Cloud Bus
…	…

2、微服务框架

• 阿里Dubbo/HSF
• 京东JSP
• 新浪微博Motan
• 当当网Dubbox
• SpringCloud Netflix
• SpringCloud Alibaba

3、各种微服务框架对比

springcloud netflix vs Dubbo
1、最大的区别：SpringCloud抛弃了Dubbo的远程过程通信的RPC方式，采用的是基于Http的Rest API方式。
2、Dubbo只是实现了服务治理，其它组件如配置管理和服务跟踪等组件需要依赖其它框架，使用门槛较高。
3、SpringCloud，是一个解决微服务架构实施的综合性解决框架，整合了诸多被广泛实践和证明过的框架，包括了服务治理的方方面面，如服务追踪、断路器、回退机制、消息总线、服务调用等组件，使用门槛较低。SpringCloud比Dubbo功能更强大，而且能够与SpringFramework、springboot、SpringData、SpringBatch等其他spring项目完美融合。
总的来说，Dubbo始终是一款RPC框架，SpringCloud的目标是微服务架构下的一站式解决方案

4、微服务架构图

服务网关：微服务统一入口，提供路由，鉴权，过滤，限流等功能。
注册中心：所有微服务都注册到注册中心，负责服务注册和服务发现。
配置中心：对各个微服务yml文件集中式存储和动态的管理。
服务通信：负责微服务之间的通信，提供各个微服务之间的数据交互。
服务监控：对各个微服务实时监控（每秒的请求数，成功数等），提供服务熔断和服务降级解决雪崩效应。

（1）注册中心：Eureka vs Zookeeper vs Nacos

1.Zookeeper：满足CP定理，有控制台管理，无负载均衡策略，无雪崩保护；不支持Dubbo集成和K8S集成；
2.Eureka：满足AP定理，有控制台管理，euraka是需要创建springboot项目，然后部署项目；负载均衡策略Ribbon；有雪崩保护；不支持Dubbo集成和K8S集成
3.Nacos：AP和CP可切换，直接从阿里巴巴nacos的官网下载jar包，启动服务；负载均衡策略权重/metadata/Selector；有雪崩保护；支持Dubbo集成和K8S集成；

（2）配置中心：Config vs Nacos

阿里的Nacos config比Config的读写性能高很多，而且Config依赖Git场景不适合开放的大规模自动化运维API，Config不带运维管理界面，需要自行开发。

（3）服务网关：Zuul vs Gateway

1.Zuul：使用的是阻塞式的 API，不支持长连接。
底层是servlet，Zuul处理的是http请求
没有提供异步支持，流控等均由hystrix支持
2.Gateway：比zuul多依赖了spring-webflux（是基于响应式流的，可以用来建立异步、非阻塞、事件驱动的服务。默认采用Reactor作为响应式流的实现库，也提供对RxJava的支持。），在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件

（4）微服务通信：Fegin vs Dubbo

1.从原理上看，Fegin是基于Http的Rest API方式，Dubbo是远程过程通信的RPC方式。
2.从使用方面看，Http接口只关注服务提供方，对于客户端怎么调用，调用方式怎样并不关心，而RPC服务则需要客户端接口与服务端保持一致。
3.从性能角度看，由于Http携带的信息过多，导致传输速度比RPC低。
4.从灵活性看：Rest相比RPC更灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。
5.从一定程度上来说，http的Rest API方式牺牲了服务调用的性能，但也避免了原生RPC带来的问题。

（5）负载均衡：Ribbon vs Dubbo

1.Dubbo负载均衡：支持4种（随机，轮询，最少活跃，hash），引入了JVM预热时间加权、权重自定义配置的规则，同时支持控制台动态配置权重值参数，所以是最灵活的。
2.Ribbon负载均衡：支持6种，不支持权重：轮询、随机、最少连接数、最短响应时间（随机+响应时间加权）、过滤异常节点+轮询，负载策略最全的。

（6）断路器：Hystric vs Sentinel

1.Hystrix断路器，负责解决雪崩效应，进行服务熔断，服务降级和资源隔离。
2.Sentinel，主要负责多样化的流量控制，熔断降级，系统负载保护，实时监控和控制台。
总的来说，sentinel的功能更强大。

六、分布式相关知识

1、分布式

   （1） 一个业务拆分多个子业务，部署到不同的服务器上。也就是将一个大
    的系统划分为多个业务模块，多个业务模块分别部署到不同的服务器上，
    各个业务模块之间通过接口进行数据交互。以缩短单个任务的执行时间
    来提升效率，保证服务的高性能。
    （2）分布式需要做好分布式事务管理。
	（3）分布式存在两个问题：任务分解（鲤鱼模型）和节点通信（通过RPC
	框架或消息通信件解决）

2、集群

（1）将同一个业务，部署到多个服务器上。就是在集群模式里，不同服务器
部署、同一个业务，实现服务的负载均衡。通过单位时间内执行的任务数来
提升效率，保证服务的高可用。
（2）集群需要做好session共享。一般配置nginx的负载均衡容器实现，静
态资源缓存session共享可以附带实现，Nginx支持5000个并发量。
（3）负载均衡器是集群的解决方案之一，是通过添加服务器达到解决高并发
的问题

3、负载均衡

指在集群中，将多个数据请求分散在不同单元上进行执行，主要为了提高系统容错能力和加强系统对数据的处理能力。
（1）当一台服务器的性能达极限时，我们可以使用服务器集群来提高网站的整体性
能。那么，在服务器集群中，需要一台服务器充当调度者的角色，用户所有请
求都会首先由它接收，调度者再根据每台服务器的负载情况将请求分配给某一
台服务器去处理
（2）常用的负载均衡器有软负载（Nginx,LVS,HAProxy)和硬负载(F5)，硬负载的成本太高，所以常用软负载。

7、总结

单体架构转分布式架构呢，必定会引入一定其他的组件，多加个一组件，虽然可以解决一定的问题，但是系统的复杂性也就会越大，我们必须根据具体业务需求，做好技术选型，还要全面考虑因为这个组件目前可能引起的问题以及后续引起的问题，和这些问题的解决方案。

小伙伴可以看下面文章详细了解微服务各个组件：

IntelliJ idea从零开始搭建微服务spring cloud框架
一篇对MySQL语句执行顺序的介绍

对SpringCloud有兴趣的，关注一下小编的博客，随后更新
如果看到这里，说明你喜欢这篇文章，请转发，点赞。关注微信公众号微信搜索[老板再来一杯时光]回复[进群]或者扫描下方二维码即可进入无广告交流群！回复[java]即可获取java基础经典面试一份！