【Spring cloud】认识微服务

🍃前言

本篇文章将从架构的演变过程来简单介绍一下微服务，大致分为一下几个部分

以及微服务架构所带来的挑战。

很多创业公司早期或者传统企业会把业务的所有功能实现都打包在⼀个项⽬,这就是单体架构.

业务的所有功能实现都打包在⼀个war包或者Jar包中,这种⽅式就称为单体架构

以电商系统举例，电商系统包括：⽤⼾管理,商品管理,订单管理,⽀付管理,库存管理,物流管理等等,项⽬早期我们会把这些模块都写在⼀个web项⽬中,然后统⼀部署到⼀个Web服务器中

在这里插入图片描述

这种架构开发简单,部署简单,⼀个项⽬就包含了所有的功能,省去了多个项⽬之间的交互和调⽤消耗。直接部署在⼀个服务器即可。

当⽹站的⽤⼾量越来越⼤,需求也会越来越多,流量也会越来越⼤,服务可能就会⾯临以下问题:

我们从以下两个⽅⾯进⾏优化:

在这里插入图片描述

以单体结构规模的项⽬为单位进⾏垂直划分。也就是将⼀个⼤项⽬拆分成⼀个⼀个单体结构项⽬。项⽬和项⽬之间相对⽐较独⽴,接⼝多为数据同步功能

那什么是集群，什么又是分布式呢？

把他们放在一起讲，那么他们肯定是有联系和区别的。

集群和分布式区别和联系如下：

从概念上：集群是多个计算机做同样的事,分布式是多个计算机做不同的事
从功能上：集群的每⼀个节点功能是相同的，并且可以替代的。分布式也是多个节点组成的系统，但是每个节点完成的业务是不同的⼀，个节点出现问题，这个业务就不可访问了
从关系上：分布式和集群在实践中，很多时候是互相配合使⽤的。⽐如分布式的某⼀个节点,可能由⼀个集群来代替。分布式架构⼤多是建⽴在集群上的。所以实际的分布式架构设计中并不会把分布式和集群单独区分，⽽是统称：分布式架构

当我们上面所讲的电商平台的业务拆开来时，会有⼀些重复的功能开发，⽐如订单系统，电商平台和⽀付系统都会涉及。

在这里插入图片描述

在分布式架构下,当部署的服务越来越多,重复的代码就会越来越多,服务的调⽤关系也会越来越复杂.

我们可以把⼀些通⽤的，会被多个上层服务调⽤的共享业务，提取成独⽴的基础服务，组成⼀个个微⼩的服务。这就是微服务。

从这个⻆度来看,微服务架构是分布式架构的⼀种拓展,这种架构模式下它拆分粒度更⼩,服务更独⽴.可以理解为：微服务是⼀种经过良好架构设计的分布式架构⽅案

那么这与分布式架构有什么区别呢？

分布式架构侧重于压⼒的分散，强调的是服务的分散化。微服务侧重于能⼒的分散，更强调服务的专业化和精细分⼯。

从实践的⻆度来看，微服务架构通常是分布式服务架构，反之则未必成⽴。所以，选择微服务通常意味着需要解决分布式架构的各种难题。

随着产品的复杂性和流量的增加,技术架构也在不断的发⽣变化。不论是早期的单体架构，还是现在⼴泛使⽤的微服务架构,都是为了更好的服务产品解决问题.

微服务架构带来好处的同时,也⾯临着⼀些挑战,从单体服务转向微服务意味着管理更加复杂。

接下来我们从优势和挑战两个⽅⾯分析⼀下微服务架构

优势：

挑战：

虽然微服务具备很多的优势,但由于服务数的增加,服务治理也是我们⾯临的巨⼤挑战.
服务依赖.随着服务的数量增多,服务之间的关系也会变得更加复杂.⼀个服务的更改,需要考虑对其他服务的影响.
运维成本.⼀个业务流程会涉及多个微服务共同完成,有更多的服务需要译,部署,运⾏,甚⾄可能是不同的编程语⾔,不同的运⾏环境,当然也需要集群来处理故障转移等.这对于运维⼈员⽽⾔,挑战是巨⼤的.
开发和测试.⼀个业务流程可能涉及多个微服务共同完成,服务调⽤引⼊⽹络延迟,不可靠的⽹络,如何进⾏容错处理等问题.这对开发和测试⽽⾔,难度也会提升.
服务监控.在⼀个单体结构中,很容易实现服务的监控.因为所有功能都在⼀个服务中,微服务架构下,不仅需要对整个链路进⾏监控,还需要对每⼀个服务实现监控.
负载均衡.微服务架构中的服务实例数量可能⾮常庞⼤，因此需要有效的服务发现和负载均衡机制来管理请求流量和保证⾼可⽤性
…

选择微服务架构的话,以上这些问题都需要我们解决,我们是⾃⼰研发还是选择市场上⽐较成熟的技术拿来⽤呢?

全球的互联⽹公司都在积极尝试⾃⼰的微服务落地⽅案。在Java领域，最引⼈注⽬的就是Spring Cloud了，关于Spring cloud这部分，后续文章再一一介绍。