微服务入门

微服务介绍

写这篇文章的初衷:希望带大家认识微服务,同时通过写博客的方式记录下自己对微服务的理解,希望大家看完文章能有所收获,也希望大家指出文章中描述不清或者错误的地方


前言

本篇文章主要介绍什么是微服务,为什么要使用微服务,现在微服务主要使用的架构


微服务是什么

微服务是一种开发软件的架构和组织方法,一个大型的应用由小型独立服务组成,这些独立的服务可以由不同团队去开发,部署和维护,各个服务之间通过定制的API去通信,完成服务与服务的交流。
这里大家如果不理解也没关系,可以继续往下看,等看完整篇文章再回过头来看,就很好理解这段话了。

使用微服务的好处

其实从上面的介绍就可以看出微服务一些特性,自主性和专用性;

专用性体现:主要体现在服务的划分,一个大的系统往往多个小型的服务去构成,这些服务都只负责自己负责的功能,可以实现功能的解耦和复用。所以服务的划分很重要!!!

举例:大家都比较熟悉的电商系统的用户服务,订单服务,库存服务等

自主性体现:因为是独立的服务,所以各个服务的技术选择,开发,部署都是独立的,这样可以由不同团队去负责开发,从而大大减少开发时间,也能是我们的技术选择以及服务部署更加灵活,扩展更加方便。

上面说到了把一个应用拆分成多个服务的好处,可能大家不是很理解,接下来我们可以比较一下现在的微服务架构和以前传统架构的区别,来看看为什么要使用微服务,这里涉及到一个架构演变的过程

单体架构:

早期的架构,简单来说,就是一个war包或者jar包包含一个应用的所有功能。在这里插入图片描述

优点:能够快速开发和上线,运维成本低
缺点:耦合度高,不适合长期运营,只能满足用户量少,业务量小的应用

这里解释一下,单一架构的应用如果业务单一,用户量也不大的话,可以理解为整个应用比较简单,那么开发,部署包括运维成本都是很低的;但如果业务变化快,用户持续增长的话,就会暴露出很多问题。首先,业务的扩张会导致整个应用的代码量上升,后期一个war包的大小可能是好几GB大小,这时候因为业务变动,简单的修改也会导致整个应用的重新部署,上线。这个部署的过程会耗费大量的人力和时间。

垂直架构:
我们知道技术是用来支撑业务的,当上面提到的业务量上升时,我们就需要一个更好的架构来解决单一架构所面临的问题,接下来我们介绍垂直应用架构。如下图我们将之前的单体架构根据业务进行垂直拆分。
在这里插入图片描述

优点:通过系统的垂直拆分,业务解耦,解决了单一架构面临的耦合度高,不易扩展的问题

通过对业务的垂直拆分,我们可以让不同的系统由不同的团队去开发,部署和维护,这样就可以解决上面单一架构牵一发而动全身的问题,一定程度上实现了应用的解耦,是我们的业务能够更好的去扩张。同时可以通过多个tomcat服务器的部署减轻我们硬件的压力。

缺点:可能会出现大量重复代码,各个系统之间独立存在,无法通信。

1.大量重复代码:因为日常开发中我们肯定会遇到两个系统都存在相同的业务逻辑,假设我们库存系统中有一个查询商品数量的功能,但是我们在商品系统要完成下单,也要知道商品的数量,商品数量为零时,就会下单失败,那么这个查询商品数量的功能商品系统中也要有,就会出现业务逻辑上的重复。
2.各个系统之间独立存在,无法通信;通俗一点说,就是各个系统的业务和数据都是独立的,无法创造共同价值。

SOA:面向服务的架构
上面介绍了垂直架构,以及它的优缺点,既然有缺点,就会有新的更好的架构出现,下面介绍SOA,面向服务的架构。前面我们介绍的两种架构都只提到了系统,而SOA是面向服务的,它本质上也是一种思想的体现,类似于面向对象。上面我们提到的垂直架构的缺点,会在SOA中得到解决。

在这里插入图片描述

从上图可以看出,我们系统都是通过ESB(下面会介绍)去调用我们的服务,之前垂直架构遇到的相同业务逻辑的重复开发的问题就可以解决了,我们可以将重复的业务逻辑抽出来作为一个独立的服务,需要这个服务的应用直接去调用就可以了。同时,通过ESB我们将服务的调用者和服务本身完成了解耦 ,也实现了各个系统之间的通信。

什么是ESB

这里的ESB(企业服务总线)其实是一个比较宽泛的概念,它的主要作用是用来管理服务和数据传输,服务提供者只需要将服务注册到ESB,需要这个服务的应用就可以通过ESB获查找到这个服务,也可以完成数据的传输,从而解决无法进行信息交换的问题。

例: 我们平常使用的dubbo+zookeeper的服务注册和调用也是ESB的一种实现

总结一下上面的内容:

在介绍微服务架构之前,我们总结一下上面的内容,从单一架构——>垂直架构——>再到SOA(面向服务的架构),我们发现架构都是为了贴合我们的实际业务去演进,当前的架构无法满足我们的业务的时候,我们就需要一个更适合业务的架构。这里其实我们需要思考下,SOA就一定比我们前面提到的架构好吗,其实这个问题需要结合我们业务去思考,没有最好的架构,只有最合适的架构,不贴和业务的技术架构都是耍流氓。所以微服务架构也不是盲目的去使用的,而是要考虑我们的业务是怎么样的,用户的体量是怎么样的。

微服务架构:
上面我们的已经介绍过了SOA,其实它提出的是一种全新的思想,面向服务,微服务架构本质上其实也是面向服务的思想的一种实现。它和SOA的区别首先从关注点出发去考虑,SOA是为了解决服务的复用和各系统之间的通信,而微服务更多关注的是服务的解耦,它的目的是降低我们业务的耦合度,也就是虽然都是面向服务的思想,但是微服务的拆分粒度更小,对业务的复用性要求更高。这样的服务拆分可以使我们在业务多变,数据量持续上升的场景下更好的去扩展我们的服务,也可以使我们整个系统的稳定性更高,同时对系统的构建,发布和运维也有更高的要求。
在这里插入图片描述

这里大家可能会发现服务的划分和SOA差不多,但其实微服务的划分可以更细,只是我这里没有画出来

到这里大家再回头看微服务的定义,应该都能理解什么是微服务架构了,也明白为什么要使用微服务架构,我们不妨总结一下微服务的优点:

1.技术选型灵活
2.可独立开发,部署,更灵活
3.复杂度可控,每个微服务只需关注自己的业务即可
4.可扩展性高
5.容错性高(后面讲到服务的降级,熔断会介绍)

这里我们也要抛出微服务所面临的一些挑战:

1.前期的准备工作变多,服务的拆分要优先规划好
2.问题排查变难,因为多个服务互相调用会形成一个调用链
3.服务的监控
4.分布式框架的复杂性,服务的高可用,数据的一致性都要考虑、
5.运维的成本,要保证几十个或者上百个服务的正常运行

既然有挑战,那也就会有解决这些问题的技术,接下来我们看一下一个简单的微服务技术架构应该什么样的
在这里插入图片描述
如上图我们会发现一个微服务架构中包括了服务本身,网关,注册中心,配置中心,链路监控,日志监控等等,这些我们都可以称之为微服务组件,这个架构中的每个组件都有自己作用,用来解决微服务架构所面临的挑战,
,例如网关可以实现负载均衡,服务的路由,限流,注册中心和配置中心可以用来治理我们的服务等等。

本篇总结:
本篇文章的最后向大家提到了微服务的组件,没有接触过微服务的同学可能看到最后不是很理解,不过没关系,本篇文章的主要目的是带大家了解微服务,如果大家看完后能理解什么微服务,别忘记给花荣点点赞啊,毕竟大家的支持才是我更新的动力;
下篇预告:
基于本篇最后提到的微服务技术架构和组成组件。下篇会为大家带来一个生产环境下的完整的微服务架构是什么样的,其中会有哪些组件,以及这些组件的介绍和起到的作用,后续也会持续更新微服务相关的内容,带着大家从微服务入门,到熟练掌握微服务,并运用到实际开发中,求关注~

  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值