SpringCloud基础教程(一)-微服务与SpringCloud

 个人博客：兰陵笑笑生,欢迎浏览博客！

 近年来，随着互联网公司自身的业务体系愈来愈大，系统复杂度愈来愈高，致使咱们不得不将服务进行拆分，微服务的概念也是迅速在互联网发酵。咱们也迫切的须要一套框架、一个生态系统可以健全、稳定的为咱们解决问题。本章就简单的介绍一下微服务的概念，以及Spring Cloud的生态组件。

1、微服务架构简介

 微服务架构风格是将单体应用程序开发为一组小型服务的方法，每一个服务运行在本身的进程中，服务之间经过轻量级的通信机制(一般是HTTP资源api).。每个服务是围绕这个业务能力构建，而且能够独立的部署、可独立扩展。不一样的服务可使用不一样的语言来编写，也可使用不一样的数据存储。总结以下：

• 服务功能单一

• 可独立部署、独立扩展

• 可跨语言编程

• 服务间良好的通讯机制

 在https://spring.io/ 官方网站介绍Spring Cloud时，以图的方式展示了微服的架构图：图中包含了网关，各个微服务单元，服务注册，服务配置等

 

2、SpingCloud 简介

 在微服务的发展过程当中，随着分布式水平的提升，系统会变得愈来愈复杂，系统发生的错误率随着系统的复杂性呈指数型增加、所以微服务也出现了反对的声音，认为微服务增长了系统的维护、部署难度、致使一些功能模块和代码很难反复的使用。有没有一种框架能够尽量的解决上述的问题呢。有，就是Spring Cloud。

这里就介绍一下SpringCloud中微服务经常使用的功能

2.1 注册与发现

 服务的发现是微服务架构中很重要的一个组件，在微服务中，系统之间的依赖很是的频繁，服务调用方A服务调用B服务、C服务等多个服务，这些被调用方为了保证自身的高可用、一般都是以集群的模式部署。若是咱们将被调用方的这些信息若是写在了A服务中、这样的配置是会很复杂的，同时若是咱们动态的调整服务提供方，这样是不利于服务的管理的。所以咱们迫切须要一种服务发现的机制。全部的服务启动时就向注册中心提交自身的信息。好比URL地址、PORT端口等信息。调用方只须要从注册中心请求指定的服务便可、目前的落地的技术有Eureka、Consul、Zookeeper、 Nacos 等 。Eureka是Netflix开源的一款产品、是SpringCloud生态的的重要的一个组件之一。zookeeper是Apache的分布式应用程序协调服务，也是一款经典的 服务注册中心产品、常常是和Dubbo配合使用。 Consul 是 HashiCorp 公司推出的开源产品， 与Eureka相比，保证了强一致性却牺牲了可用性。Nacos 是alibba 2018年开源的、基于了阿里巴巴大规模的生产经验，也是给了用户一个新的选择。关于这些后期会有详细的文章介绍，这里只作一个全面的介绍。

2.2 配置管理

 对于传统的单体应用，一个配置文件就能够解决配置问题，可是在微服务中，多个机器部署的时候，修改配置文件是一个至关繁琐的问题。为此、这个时候就须要引入一个组件。SpringCloud提供了这样的组件：Spring Cloud Config.固然国内大的互联网公司都有本身的配置中心、好比百度的DisConf、淘宝的Diamond等等。固然因为各方面的缘由，这些产品可能存在一些其余问题。而Spring Cloud Conf是可以和Spring无缝集成。对于大多数的中小企业来讲，这样的配置也是够的。

2.3 服务调用方式

 在微服架构中，少不了的就是服务间的调用，调用的方式Spring Cloud采用的是基于HTTP的REST方式。Dubbo采用的事RPC方式。在面临微服务基础框架选型时，Spring Cloud和Dubbo只能二选一。这也是你们老是将两者作对比的缘由。Dubbo的定位是一款RPC框架，而Spring Cloud的目标是提供微服一站式解决方案。因此Dubbo和Spring Cloud并非彻底的竞争关系。

2.4 负载均衡

 LB 即负载均衡，也是微服务或分布式集群中经常使用的一种应用。简单来说就是将用户的请求平摊的分配到多个服务上，从而达到高可用的目的。经常使用的负载均衡有软件Nginx，LVS，硬件F5等。在Sping Coud生态中，Sping Coud Netflix Ribbon 是基于Netflix Ribbon实现的一套客户端负载均衡的工具。负载均衡的算法有不少，好比轮询、随机、权重等等。

2.5 服务熔断

 在微服务架构中，是存在着不少的服务的，并且服务之间的调用可能跨网络，由于网络的不可靠性等缘由出现调用故障和延迟，若是此时调用方的请求不断的增长，长时间的等待会造成调用方占用不少的资源，甚至形成系统崩溃和瘫痪，即所谓的"雪崩效应"。为了解决这样的问题，须要对故障和延迟进行隔离和管理，便出现了断路器。它的做用就是在发生没法访问、超时、异常等问题时，会经过服务降级的方式，熔断该节点的调用，快速返回“错误”的信息、可处理的备选响应，从而保证故障的蔓延等问题。Hystrix提供了熔断模式和隔离模式用来解决雪崩效应，Hystrix是在服务访问失败时下降阻塞的影响范围，避免整个服务被拖垮。

2.6 服务路由与网关

 在微服务架构模式下，后端服务的实例通常是动态的，对应客户端来讲很难动态的发现改动的服务实例地址，为此，一般会引入网关API Gateway。 从而简化内部服务的相互调用的复杂度。在Spring Cloud生态中Zull就是一个落地的技术。Zull是Netfix开源的一个基于JVM的路由和服务器负载均衡器，其做用就是服务转发。固然也是能够做为资源统一访问入口。同时。也能够在网关作一些权限的校验。

2.7 调用链路追踪

 在微服务架构的生产实践中，常常会遇到这样的案例：客户反馈问题，开发、应急和运维人员从入口服务A开始查起，肯定服务A没有问题，而后将问题传递到B服务，依次查询下去，这样的排查多了不少的没必要要，基于调用链的服务治理系统能够解决以上的问题。Spring Cloud Sleuth就是Sping Cloud生态中实现调用链追踪的一个子项目，能够结合Zipkin很好的事项故障快速定位问题。

三 、总结

 

 在微服务架构的实践过程当中，Spring Cloud 以其独有的生态迅速的扩张，覆盖了整个互联网公司。固然Spring Cloud中的组件不只仅包含了刚才介绍的，还包括了安全、任务、消息总线、批处理等各类组件。如上图。

 本章简单介绍了微服务的架构以及Spring Cloud的生态，在以后的章节中，我将详细的介绍各个功能的具体实现。

 以上就是本期的分享，你还能够关注本博客的#Spring Cloud基础教程系列!#

本文由博客一文多发平台 OpenWrite 发布！

个人博客地址兰陵笑笑生,欢迎浏览！