微服务基本概念汇总

雨点打透心脏的1/2处 2022-09-03 00:08 222阅读 0赞

# 1.什么是微服务？ #

> 单个轻量级服务一般为一个**单独微服务**，微服务讲究的是 专注某个功能的实现，比如登录系统只专注于用户登录方面功能的实现，讲究的是**职责单一，开箱即用，可以独立运行**。微服务架构系统是一个**分布式的系统**，按照业务进行划分服务单元模块，**解决单个系统的不足**，满足越来越**复杂的业务需求**。
> 
> 微服务就是一个独立的职责单一的服务应用程序。在 intellij idea 工具里面就是用maven开发的一个个独立的module，具体就是使用springboot 开发的一个小的模块，处理单一专业的业务逻辑，一个模块只做一个事情。

# 2.微服务之间如何独立通讯的? #

>     同步通信：dobbo通过 **RPC 远程过程调用、springcloud通过 REST  接口json调用** 等。
> 
>     异步：消息队列，如：**RabbitMq、ActiveM、Kafka** 等。

# 3.SpringCloud 和 Dubbo 有哪些区别? #

> 首先，他们都是**分布式管理框架**。
> 
> Dubbo
> 
> 1.  二进制传输 RPC通信，占用带宽会少一点。
> 2.  dubbo 开发难度较大，所依赖的 jar 包有很多问题大型工程无法解决
> 
> SpringCloud
> 
> 1.  是http 传输的REST方式通信，带宽会多一点，同时使用http协议一般会使用JSON报文，消耗会更大。
> 2.  接口协议约定比较松散，需要强有力的行政措施来限制接口无序升级。
> 3.  SpringCloud 对第三方的继承可以一键式生成，天然集成。
> 
> **最大的区别:**  
>     Spring Cloud抛弃了Dubbo 的RPC通信，采用的是基于HTTP的REST方式。
> 
>     严格来说，这两种方式各有优劣。虽然在一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，SpringCloud 不存在代码级别的强依赖，这在强调快速演化的微服务环境下，**显得更为合适。**

# 4.SpringBoot 和 SpringCloud 之间关系？ #

> SpringBoot：专注于快速方便的开发**单个个体微服务**（关注微观）；  
> SpringCloud：关注全局的微服务协调治理框架，将SpringBoot开发的一个个单体微服务组合并管理起来（关注宏观）；
> 
> **SpringBoot可以离开SpringCloud独立使用，但是SpringCloud不可以离开SpringBoot，属于依赖关系。**

# 5.什么是服务限流？什么是熔断？什么是服务降级？ #

> [Sentinel实现熔断与限流][Sentinel]
> 
> **服务限流：**在大数据量高并发访问时，经常会出现服务或接口面对暴涨的请求而不可用的情况，甚至引发连锁反映导致整个系统崩溃。此时你需要使用的技术手段之一就是限流，当请求达到一定的并发数或速率，就进行等待、排队、降级、拒绝服务等。在限流时，**常见的两种算法是漏桶和令牌桶算法算法。**
> 
> **服务熔断：**作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。
> 
> **服务降级：**从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

# 6.微服务的优缺点是什么？ #

> **优点：**松耦合，聚焦单一业务功能，无关开发语言，团队规模降低。在开发中，不需要了解多有业务，只专注于当前功能，便利集中，功能小而精。微服务一个功能受损，对其他功能影响并不是太大，可以快速定位问题。微服务只专注于当前业务逻辑代码，不会和 html、css 或其他界面进行混合。可以灵活搭配技术，独立性比较舒服。
> 
> **缺点：**随着服务数量增加，管理复杂，部署复杂，服务器需要增多，服务通信和调用压力增大，运维工程师压力增大，人力资源增多，系统依赖增强，数据一致性，性能监控。  
>

# 7.eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？ #

> **zookeeper 是CP原则，强一致性和分区容错性**。zookeeper当主节点故障时，zk会在剩余节点重新选择主节点，耗时过长，虽然最终能够恢复，但是选取主节点期间会导致服务不可用，这是不能容忍的。  
> **eureka 是AP 原则 可用性和分区容错性。** eureka各个节点是平等的，一个节点挂掉，其他节点仍会正常保证服务。

# 8.你所知道微服务的技术栈有哪些？ #

*  反向代理：Nginx，可做动静分离部署
 *  统一网关：基于spring-cloud-gateway，配合JWT进行的简单的验权操作
 *  分布式事务：Seata，阿里内部分布式事务产品不断迭代演进而来。
 *  降级、限流：Hysrix/Sentinel
 *  服务管理：Nacos
 *  分布式配置中心：Nacos
 *  客户端负载均衡：OpenFeign
 *  异步消息：RocketMQ，阿里开源，交由Apache孵化
 *  链路跟踪：Skywalking，华为开源，交由Apache孵化
 *  分布式缓存：Redis
 *  健康监控：spring-boot-admin
 *  分布式锁：Redission
 *  代码简化：Lambok，mybatis-plus，mybatis-generator
 *  RPC框架：Apache dubbo gRPC

> 做Java，绕不开Spring。用Java做微服务开发，也绕不开Spring Cloud。
> 
> 但随着Dubbo的重启，并交给Apache开源社区维护后，Dubbo生态越来越完善。
> 
> 虽然拿Spring Cloud与Dubbo作比较不合适，但不少朋友在技术选型时会纠结选择Dubbo还是Spring Cloud，**当Spring-Cloud-Alibaba的出现，将Dubbo生态完美的与Spring Cloud生态融合在一起。你不用再纠结选择Dubbo还是Spring Cloud，两者可以兼容的很好。**

# 9.单体应用之痛 #

> 为什么要用微服务？微服务真的那么好吗？在认识这些之前，得了解单体架构的弊端。
> 
> 以MVC架构为例，业务通常是通过部署一个WAR包到Tomcat中，然后启动Tomcat，监听某个端口即可对外提供服务。早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本都可控。
> 
> 然而随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题。大致有以下几个方面：
> 
>  *  **「部署效率低下」**
>  *  **「团队协作开发成本高」**
>  *  **「系统高可用性差」**
>  *  **「线上发布变慢」**

# 10、面向服务（SOA） #

> 面向服务就是把传统的单机应用中通过JAR包依赖产生的本地方法调用，**改造成**通过RPC接口产生的远程方法调用。

# 11、微服务架构演进 #

> 微服务可以理解为面向服务的进一步发展。
> 
> 在SOA的基础上，微服务主要有了以下的发展：
> 
>  *  **「服务拆分粒度更细」**。微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。【消息发送(微信、短信、App通知)】
>  *  **「服务独立部署」**。每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署**多个Docker实例**，每个Docker实例可以部署一个微服务的代码。
>  *  **「服务独立维护」**。每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。
>  *  **「服务治理能力要求高」**。因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。
> 
> 总结来说，微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，**每个拆分出来的服务各自独立打包部署**，并交由小团队进行开发和运维，从而极大地提高了应用交付的效率，并被各大互联网公司所普遍采用。
> 
> 这里附上一张架构演进简略示意图：
> 
> ![图片][5d007b6ad33037d77342b5cd9cc94d4c.png]
> 
> 微服务架构演进略图

# 12、微服务如何拆分 #

> ## 12.1、微服务拆分的两种方式 ##
> 
> 微服务拆分具体该如何实施呢？
> 
> 一个最有效的手段就是将不同的功能模块服务化，独立部署和运维。以社交App为例，可以认为首页信息流是一个服务，评论是一个服务，消息通知是一个服务，个人主页也是一个服务。
> 
> 这种服务化拆分方式是**「纵向拆分」**，是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。
> 
> 还有一种服务化拆分方式是**「横向拆分」**，是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。
> 
> 仍然社交App举例，无论是首页信息流、评论、消息箱还是个人主页，都需要显示用户的昵称。假如用户的昵称功能有产品需求的变更，你需要上线几乎所有的服务，这个成本就有点高了。显而易见，如果我把用户的昵称功能单独部署成一个独立的服务，那么有什么变更我只需要上线这个服务即可，其他服务不受影响，开发和上线成本就大大降低了。
> 
> ## 12.2、微服务拆分需要解决的问题 ##
> 
> 必须要认识到，微服务架构也是有成本的，架构复杂度提升，也会带来一些新的问题，这些微服务架构必须要解决的问题：
> 
>  *  **「服务如何定义」**。对于单体应用来说，不同功能模块之前相互交互时，通常是以类库的方式来提供各个模块的功能。对于微服务来说，每个服务都运行在各自的进程之中，应该以何种形式向外界传达自己的信息呢？**答案就是接口**，无论采用哪种通讯协议，是HTTP还是RPC，服务之间的调用都通过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值。
>  *  **「服务如何发布和订阅」**。单体应用由于部署在同一个WAR包里，接口之间的调用属于进程内的调用。而拆分为微服务独立部署后，服务提供者该如何对外暴露自己的地址，服务调用者该如何查询所需要调用的服务的地址呢？这个时候你就需要一个类似登记处的地方，能够记录每个服务提供者的地址以供服务调用者查询，在微服务架构里，这个地方就是**注册中心**。
>  *  **「服务如何监控」**。通常对于一个服务，我们最关心的是QPS（调用量）、AvgTime（平均耗时）以及P999（99.9%的请求性能在多少毫秒以内）这些指标。这时候你就需要一种通用的监控方案，能够覆盖业务埋点、数据收集、数据处理，最后到数据展示的全链路功能。
>  *  **「服务如何治理」**。可以想象，拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了。比如一个服务的性能有问题时，依赖的服务都势必会受到影响。可以设定一个调用性能阈值，如果一段时间内一直超过这个值，那么依赖服务的调用可以直接返回，这就是**熔断**，也是服务治理最常用的手段之一。
>  *  **「故障如何定位」**。在单体应用拆分为微服务之后，一次用户调用可能依赖多个服务，每个服务又部署在不同的节点上，如果用户调用出现问题，你需要有一种解决方案能够将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联所有路径，从而进行故障定位。**链路跟踪：Skywalking**

# 3、微服务技术选型 #

对于大部分公司而言，自研来解决微服务架构的一些问题，成本是很难接受的。不过，幸运的是，有不少业界开源方案可供选择。

前几年比较火的是阿里的Dubbo，后来一度停止维护，最近两年又起死回生，重新焕发生机。

后来又出现了Spring体系下的微服务方案Spring Cloud，并迅速流行起来。

Spring Cloud本身不是新的框架，它是一系列框架的有机组合，利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发。并非所有组件都由Spring提供，Netflix扮演了重要的角色。

`注册中心`Eureka【Nacos】、`熔断器`Hystrix【Sentinel】、`负载均衡组件`Ribbon【OpenFeign】、`网关`Zuul【Gateway】等重要组件均由Netflix提供。

![图片][6724ce08930241b3f04cdb0964dff99a.png]

SpingCloud微服务架构

# 4、为什么要使用SpringCloud   Alibaba #

SpringCloud生态已经如此完善了。什么是SpringClou Alibaba? 为什么要使用SpringCloud Alibaba?

来自阿里云的说法：

> ❝
> 
> Spring Cloud 本身是一套微服务规范，并不是一个拿来即可用的框架，而 Spring Cloud Alibaba 的开源为开发者们提供了这套规范的实现方式。同时，Spring Cloud Alibaba 提供的完整的微服务组件、中文文档和本地化的开源服务提高了开发者们接入微服务的速率，并降低了后续的运维难度。
> 
> ❞

简单说，Spring Cloud Alibaba是阿里开源的一套Sping Cloud规范的实现。

那么，第二点，为什么要使用SpringCloud Alibaba？

因为上面提到的SpringCloud官方版，或者说**SpringCloud Netflix版一些重要组件如注册中心Euraka、Ribbon已经不再迭代更新了。**

SpringCloud Alibaba恰逢其会开源孵化毕业，所以这两年热度迅速提升，甚至可以说是"SpringCloud2.0"。

来自阿里SpringCloud Alibaba总体结构图：

![图片][36271daff09a94e9b035ce3f4aae245e.png]

和SpringCloud Netflix的主要区别：

![图片][085b25a33b7e37b5474db5901ccd0d75.png]

Spring Cloud Alibaba 各版本兼容表:

![图片][dfd1f3bbf55e01cfd38af34c41b1e1c8.png]

好了微服务和SpringCloub Alibaba的简介到此结束！

[Sentinel]: http://www.macrozheng.com/#/cloud/sentinel?id=spring-cloud-alibaba%EF%BC%9Asentinel%E5%AE%9E%E7%8E%B0%E7%86%94%E6%96%AD%E4%B8%8E%E9%99%90%E6%B5%81
[5d007b6ad33037d77342b5cd9cc94d4c.png]: /images/20220829/4d23b8c5de714571b8369b91998cb72e.png
[6724ce08930241b3f04cdb0964dff99a.png]: /images/20220829/f93b8741d166487fa5f85470dfcbc901.png
[36271daff09a94e9b035ce3f4aae245e.png]: /images/20220829/d81a3cd6142c4fb5a6a83b55908a7cc9.png
[085b25a33b7e37b5474db5901ccd0d75.png]: /images/20220829/409ece686190486986222375c9915ea5.png
[dfd1f3bbf55e01cfd38af34c41b1e1c8.png]: /images/20220829/65df79019cd943e8a40d7c1a6c0bdf1d.png