Spring 必会之微服务篇（1）

目次

引入
单体架构
集群和分布式架构 
微服务架构
挑战
Spring Cloud
介绍
实现方案
Spring Cloud Alibaba

---

引入

单体架构

当我们刚开始学开发的时间，基本都是单体架构，就是把一个项目的所有业务的实现功能都打包在一个 war 包或者 Jar 包中。这种架构开发简单，部署简单，一个项目就包含了所有的功能，省去了多个项目之间的交互和调用斲丧，直接部署在一个服务即可:

集群和分布式架构 

但是随着网站的用户量越来越大，对应的需求也会越来越多，流量也会越来越大服务大概就会面对一些题目：

• 后端服务器的压力过大，导致负载变高，出现用户无法访问或者访问失败的情况；
  
• 业务场景逐渐复杂，为了满意用户需求，单体应用也会越来越大，各个业务代码之间的耦合度也会越来越高。任何一个题目，都必要项目的重新构建和发布，降低了应用的可用性；
  
• 一个微笑的题目，大概会导致整个服务都挂掉
  

那有题目出现我们肯定也要有对应的解决方案，可以从以下两个方面进行优化：

• 横向拓展：添加服务器，把单台机器变为多台机器的集群；（集群架构）
  
• 纵向拓展：把一个应用按照业务拆分为多个小项目，这个架构也叫垂直架构；（分布式架构）以单体结构规模的项目为单位进行垂直分别，也就是将一个大项目拆分为一个个单体结构项目，项目和项目之间相对比力独立，接口多为数据同步功能。
  

这两种方案也引出下面要说的集群和分布式：

• 集群（cluster）：将一个系统完整的部署到多个服务器上，每个服务器都能提供系统所有的服务，多个服务器之间通过负载均衡调度完成使命，每一个服务器称为集群节点（node）；
  
• 分布式（distributed）：将一个系统拆分为多个子系统，多个子系统部署在多个服务器上，多个服务器上的子系统协同合作完成一个特定使命；
  

区别和联系：

• 概念上：集群是多个盘算机做同样的事情，分布式是多个盘算机做不同的事情；
  
• 功能上：集群的每个结点功能是雷同的，而且可以替代的，分布式也是多个结点组成的系统，但是每个节点完成的业务是不一样的，一个结点出现题目整改服务都会挂掉；
  
• 关系上：分布式和集群在实践中会配合利用，比如分布式的某个结点大概由一个集群来代替，分布式结构大多是建立在集群上的，所以现实的分布式架构设计中并不会把分布式和集群单独区分，统称：分布式架构；
  

微服务架构

虽然分布式架构已经按照业务拆分为一个个小的项目，但是还是会有一些重复功能的开发，比如订单系统，电商平台和付出系统都会涉及到；
在分布式架构下，当部署的服务越来越多的时间，重复的代码就会越来越多，服务之间的调用关系也越来越复杂。因此我们可以把一些通用的，会被多个上层服务调用的共享业务，提取成独立底子服务，组成一个个微小的服务，这就是微服务；可以把微服务明白为一个很小的服务，小到一个服务只对应一个单一的功能而且可以单独部署运行，服务之间通过 REST 和 RPC 协议通讯；
从这个角度来看的话，微服务架构就是分布式架构的一种拓展，这种架构模式下它拆分的粒度更小，服务更加独立，分布式就是微服务拆分的过程，微服务就是分布式架构的一种最佳实践方案：微服务是一种经过精良架构设计的分布式架构方案；
   分布式架构侧重于压力的分散，强调的是服务的分散化。微服务侧重于能力的分散，更强调服务的专业化和精致分工，从实践的角度来看，微服务架构通常是分布式架构，反之则未必成立，所以选择微服务通常意味着必要解决分布式架构的各种困难。
  微服务架构，首先是服务化，就是将单体架构中的功能模块从单体应用中拆分出来，独立部署多个服务。同时要满意以下特点：

• 单一职责：一个微服务负责一部分业务功能，而且其焦点数据不依赖于其它模块；
  
• 团队治理：每一个微服务都有本身独立的开发，测试，发布，运维人员，团队规模适中；
  
• 服务自治：每个微服务都独立打包部署，访问本身独立的数据库，并做好服务隔离；
  

所以，微服务架构解决了单体架构存在的题目，特别得当大型项目的开发，因此被各人广泛接纳。
挑战

虽然微服务具有许多优势，但是由于服务数量的增长，服务治理也是要面对的一个巨大挑战：

• 服务依赖：随着服务数量增多，服务之间的关系也变得更加复杂，一个服务的更改必要考虑其对其他服务的影响；
  
• 运维本钱：一个业务流程会涉及到多个微服务共同完成，有更多的服务必要编译，部署，运行，甚至大概是不同的编程语言，不同的运行情况，固然也必要集群来处理故障转移；
  
• 开发和测试：服务之间调用引起网络延迟，不可靠网络，如何进行容错处理等题目，这对开发和测试而言，难度也很大；
  
• 服务监控：微服务架构下，不仅必要对整个链路进行监控，还必要对每个服务实现监控；
  
• 负载均衡：微服务架构中的服务实例数量大概会非常庞大，因此必要有效的服务发现和负载均衡机制来管理流量和包管高可用性；
  

而且我们在拆分服务的时间也会碰到许多题目，比如：

• 如果出现跨服务的业务该如那里理
  
• 页面请求到底该访问哪一个路径
  
• 如何实现各个服务之间的服务隔离
  

如果选择微服务架构的话，以上题目都必要我们本身解决，我们也可以拿市场上比力成熟的技术拿来用，在 Java 领域最被广泛利用的就是下面要讲的 Spring Cloud。
Spring Cloud

介绍

可以先辈入 Spring Cloud 的官网看看：Spring Cloud 官网
微服务拆分以后碰到的各种题目都有对应的解决方案和微服务组件，而 Spring Cloud 框架可以说是目前 Java 领域最全面的微服务组件的集合了。它提供了一些可以让开发人员快速构建分布式服务的工具，比如配置管理，服务发现，熔断，智能路由等，它们可以在任何分布式的情况中很好的工作；
简单来说，Spring Cloud 就是分布式微服务架构的一站式解决方案，是微服务架构落地的多种技术的集合：

• Distributed/versioned configuration 分布式版本配置
  
• Service registration and discovery 服务注册和发现
  
• Routing 路由
  
• Service-to-service calls 服务调用
  
• Loading balancing 负载均衡
  
• Circuit Breakers 熔断器
  
• Distributed messageing 分布式消息
  
• ......
  

   Spring Cloud 并不是 Spring 团队研发的框架，它只是把一些比力优秀的解决微服务架构中常见的题目的开源框架基于 Spring Cloud 规范进行了整合，并基于 Spring Boot 的风格，对这些组件进行封装，屏蔽掉了复杂的配置和实现原理，为开发者提供了开箱即用的微服务开发体验，这些开源技术的框架还是由各个公司来维护的，Spring Cloud 就是把这些管理起来的。
  实现方案

在 Spring Cloud 规范下，最为着名的两种实现方案就是：

• Spring Cloud Netflix
  
• Spring Cloud Alibaba
  

之前 Spring Cloud 一度利用 Spring Cloud Netflix 最为默认解决方案，但是由于 Netflix 公司在2018年左右宣布焦点组件 Hystrix，Ribbon，Zuul 等进入维护状态，所以 Spring Cloud 也被迫宣布删除这些维护模块。
   spring-cloud-netflix 也并没有从 Spring Cloud 的依赖中全部删除，只是从2020.0版本开始只管理 Eureka 组件。
  而且 Cloud 官方也提供了一些替换建议，有些还是自研的：

• Hystrix ---> Resilience4i
  
• Hystrix Dashboard/Turbine ---> Micrmeter + Monitoring System
  
• Ribbon ---> Spring Cloud Loadbalancer
  
• Zuul 1 ---> Spring Cloud Gateway
  
• Archaius ---> Spring Boot 外部配置 + Spring Cloud 配置
  

Spring Cloud Alibaba

Spring Cloud Alibaba 是阿里巴巴集团下的开源组件和云产物在 Spring Cloud 规范下实现。
如果说 Spring Cloud Netflix 是 Spring Cloud 的第一代实现，那么 Spring Cloud Alibaba 也可以看作是 Spring Cloud 的第二代实现，主要由 Nacos，Sentinel，Seate 等组件组成。
   利用的 Spring Cloud 版本要与你的 Spring 项目的版本与官网保持一致，利用官网指定的版本，不然会出题目：

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。