SpringCloud(1)

SpringCloud概述

1.认识微服务

下面的图表示了服务架构从单体应用逐渐转变为微服务应用的过程.

1.1单体架构:业务的所有功能实现都打包在一个war包或者Jar包中,这种实现方式就称为单体架构.一个电商系统,包括:用户管理,商品管理,订单管理,支付管理,库存管理,物流管理等.项目早期会把这些模块写在一个web项目中,之后统一部署到一个web服务器中.这种结构开发简单,部署简单,一个项目就包含了所有的功能,省去了多个项目之间的交互和调用消耗.直接部署在一个服务器即可.

1.2 集群和分布式架构:当网站的用户量越来越大,需求也就会越来越多,流量也会越来越大,服务可能就会面临下面的问题:后端服务器的压力越来越大,负载越来越高,甚至出现无法访问的情况.业务场景逐渐复杂,为了满足用户的需求,单体应用也会越来越大,各个代码之间的耦合度也会越来越高.任何一个问题,都需要整个项目重新构件,发布.一个微小的问题,可能会导致整个应用挂掉.为了解决这两方面的问题,可以用两个方面进行优化,横向:添加服务器,把单台机器变成多台机器的集群.纵向:把一个应用,按照业务进行拆分,拆分成多个项目,此架构也成为垂直架构.

以单体结构规模的项目为单位进行垂直划分,也就是将一个大项目拆分成一个一个单体结构项目,项目和项目之间比较独立,接口为数据同步功能.

1.3.集群和分布式

集群:是将一个系统完整的部署到多个服务器上,每个服务器都能提供系统的所有服务,多个服务器通过负载均衡调度完成任务.每个服务器称为集群的结点.

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

集群和分布式的区别和联系:概念上,集群是多个计算机做相同的事情,分布式是多个计算机做不同的事情.功能上.集群的每一个结点功能是相同的,并且是可以替代的,分布式也是多个结点组成的系统,但是每个结点完成的业务时不同的,一个结点出现问题,这个业务就不可访问了.关系上,分布式和集群在实践中,很多时候是相互配合使用的,比如分布式的某一个结点,可能会由一个集群来替代,分布式架构大多是建立在集群上的.所以实际的分布式架构设计中并不会把分布式和集群单独区分,而是统称分布式架构.

1.4 微服务架构

从上面的图可以看出,在按照业务进行拆分后,会有一些重复的功能开发,比如订单系统,电商平台和支付系统都会涉及.

在分布式架构下,当部署的服务越来越多,重复的代码就会越来越多,服务的调用关系也会越来越复杂.我们可以把一些通用的,会被多个上层服务调用的共享业务,提取成独立的基础服务,组成一个个微笑的服务,这就是微服务.

简单来说,微服务就是很小的服务,小到一个服务只对应一个单一的功能,只做一件事,这个服务可以单独部署运行.微服务之间可以采用REST和RPC进行通信.从这个角度来看,微服务架构是分布式架构的一种扩展,这种结构模式下它拆分粒度更小,服务更独立.可以理解为:微服务是一种经过良好架构设计的分布式架构方案.分布式架构和为微服务架构:分布式:服务拆分,拆了就行.微服务:指的是非常微笑的服务,更细丽都的垂直拆分,通常不能再拆的服务.分布式架构侧重于压力的分散,强调的是服务的分散化,微服务侧重于能力的分散,更强调服务的专业化和精细分工,从实践的角度来说,微服务架构通常是分布式架构,反之未必成立,所以,选择微服务通常意味着需要解决分布式架构的各种难题.

1.4微服务带来的挑战

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

缺点:服务依赖. 随着服务的数量增多, 服务之间的关系也会变得更加复杂. ⼀个服务的更改, 需要考虑对其 他服务的影响.运维成本. ⼀个业务流程会涉及多个微服务共同完成, 有更多的服务需要编译, 部署, 运⾏, 甚⾄可能 是不同的编程语⾔, 不同的运⾏环境, 当然也需要集群来处理故障转移等. 这对于运维⼈员⽽⾔, 挑战是巨⼤的.服务监控,在一个单体结构中,很容易实现服务的监控,因为所有的功能都在一个服务中,微服务架构下,不仅需要对整个链路进行监控,还需要对每一个服务实现监控.负载均衡,微服务架构中的服务实例数量可能非常庞大,因此需要有效的服务发现和负载均衡机制来管理请求流量和保证高可用性.

2.微服务解决方案-Spring Cloud

Spring Cloud就是分布式微服务架构的一站式解决方案,是微服务架构落地的多种技术的集合.比如: