SpringCloud之旅第一篇-微服务概念

2019-05-22 06:30:37来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

一、单体架构的问题

微服务为什么会出现?在学习Springboot的时候知道Springboot极大的简化了我们的开发,我们可以快速的进行业务开发,Springboot单体应用在项目的开发初期能够满足我们需求,这种单体架构优点非常的明显:

  1. 容易测试:本地就可以起完整的系统,不需要外部依赖。

  2. 容易开发:我们只需引入依赖,选择框架便可快速开发。

  3. 易于部署:单体架构部署也较简单,直接打包即可。

  4. 易于水平伸缩:这里的收缩时指当我们需要多个服务器时也比较方便

在项目刚开始的时候我们可以快速的开发,一个长寿的项目,需求不断增加,原先的模块也再不断优化,这个时候单体架构的缺点开始显现:

  1. 代码膨胀,难以维护:代码越来越多,开发人员也就越来越多,一旦出现bug,定位、修复成本很高,而且人员太多,代码都放在一起,容易引起冲突,且由于业务集中在一起,业务复杂,很难全局把握,改一个bug可能会再多出两个bug。

  2. 构建、部署成本大:项目太大,构建和部署就会非常慢,效率低下。

  3. 上手困难:互联网企业人员更迭快,代码过于集中,导致业务非常复杂,新人想要上手变得非常困难。

  4. 技术创新困难:代码过于集中,我们很难使用到新技术,因为改动实在太大,容易出现问题。

  5. 可扩展性差:这里的可扩展性是指因为项目都必须部署在一台服务器中,那项目所要的资源会越来越大,这样我们只能扩展硬件(集群可以分散压力,但是单个应用所要的资源还是不能少的)。

二、微服务出现

微服务的出现就是为了解决这些问题,看看是如何解决的,微服务将系统拆分成一个个小服务(一般是按照模块进行拆分,比如用户服务、支付服务、订单服务、出入库服务等),那么即使业务量增加,我们也可以通过新增服务的形式来解决,这样代码就不会膨胀,构建、部署也不是问题。由于服务不在一个框架中,那么我们可以很方便的对某一个服务进行技术创新,对一个服务的进行技术升级改动不会太大,而当我们有新技术产生时,我们就可以也可以应用到新服务中。

微服务并没有明确的定义,下面是一种比较通用的理解:

使用一套小服务来开发单个应用的方式,每个服务运行在独立的进程里,一般采用轻量级的通讯机制互联,并且它们可以通过自动化方式部署。

通过定义我们可以知道微服务的特征:

  • 微服务是由一系列的小服务共同组成的。

  • 每个微服务都有自己独立的进程。

  • 每个服务都是独立的业务开发,单一原则

  • 每个服务都能独立的部署(一般部署在容器中)。

  • 微服务之间通过轻量级通信机制进行通信

  • 分布式的管理。

三、微服务架构图

讲到这里,对微服务的概念应该有了一定的了解,下面画的一个比较简单的微服务架构图

 

图中可以看出每个微服务都有自己独立的数据库,每个服务都会暴露自己的REST API 给外部调用,服务之间会存在互相调用关系,而每个服务都有可能被客户端直接调用,另外我们看到还有一个API Gateway,这是统一个服务接口,它通常可以有以下作用:

 1. 提供统一服务入口,让微服务对前台透明

 2. 聚合后台的服务,节省流量,提升性能

 3. 提供安全,过滤,流控等API管理功能

四、优缺点

凡是都有两面性,一个技术也不可能只有优点而没有缺点,微服务的优点很多,微服务的优点其实就是单体架构的缺点的反面,因为微服务本身就是来解决单体架构问题的

  1. 独立性:微服务从构建、部署,扩容、缩容、甚至数据库都是独立的,服务只要管理好自己就可以,这样就极大的降低了系统的复杂性。服务完全独立独立之后,从构建到部署,到后期的扩容缩容都会变得简单,基本就解决单体架构上碰到的很多问题。

  2. 敏捷性:敏捷性是针对开发人员来讲的,服务拆分之后,可以独立专一开发,开发人员可以通过API快速的了解本服务的业务,互相之间并不影响。

  3. 技术栈灵活:微服务可以完全独立的拥有技术栈,只需要保证提供的服务API不变,内部使用何种技术栈很灵活。

  4. 高效的团队:微服务的团队会比较小,那沟通就会变得更加高效。

没有最好的架构,只有最适合的架构,既然有这么多优点,那缺点肯定也有不少

  1. 服务的拆分:服务如何拆分其实是非常重要且复杂的,服务拆分的太大或太小都不合适,这需要我们有非常丰富的经验,而这个在单体中是不存在的。

  2. 数据一致性:单体架构中只有一个数据库,我们可以通过事务解决多表之间数据的一致性,而在微服务中,每个服务中都有自己独立的数据库,要保证服务之间的数据一致性也是一个大的挑战。

  3. 服务间通信成本:服务间互相通信也需要时间成本。

  4. 测试复杂性提高:服务之间存在依赖,那么测试时就必须启动这些依赖,这就增加了复杂度。

  5. 运维部署复杂性提高:微服务应用由大量服务组成,每个服务会起多个实例,要进行配置,部署,扩展和监控。此外,还需要实现服务发现机制

五、技术点

要实现微服务,我们需要解决以下几个技术点:

  • 客户端访问服务:这个上面架构图中已经给出,使用API Gateway。

  • 服务通信:服务与服务之间的通信有两种方式,同步与异步

    同步通信中又分为两种:Http与RPC,http访问很好理解,相信一般的系统也会调用外部的一些服务,这些基本都是使用http,因为http可以跨语言,跨客户端,相对使用较广,如http Client ,而RPC也有自己的优点,首先是效率更高,更安全可控,特别是内部服务互相调用时,用统一的RPC框架,服务的侵入性更低,调用服务甚至就像调用自己的服务一样简单,如dubbo(注:dubbo只能使用java语言)。

    异步通信是通过消息队列来实现,异步通信的好处是可以降低服务之间的耦合,有削峰的好处,而且使用消息队列可以方便的实现数据的最终一致性。

  • 服务治理:为了服务的高可用,微服务一般都有多个拷贝,做负载均衡,而这个时候就必须知道服务的状态,一个服务随时有可能下线,下线之后后续有可能重新启动,这些都需要我们一个服务治理功能,也即是服务的注册与发现。

      

 

        产品服务启动了三个,他们都会去注册中心进行注册,注册成功后,会通过心跳包告诉注册中心是否在线或者下线,而订单服务要去调用产品服务,会先去注册中心进行查询,查询出相应的地址然后再去调用产品服务。

  • 服务崩溃处理:在运行期间会出现服务崩溃的情况,比如网络原因,阻塞原因,这个时候服务并不是下线,还是能够被找到,我们必须妥善要进行处理,否则可能会导致整个系统的崩溃,处理的方式有:

    1. 重试机制

    2. 熔断机制

    3. 降级机制

    4. 限流机制

六、解决方案

以上都是微服务的一些概念,既然有天上飞的概念,就有落地的实现,现在主流的微服务架构有两套解决方案:Dubbo+ZookeeperSpringCloud

我司现在两种方案都在用,总体来说两种方案都可以很方便的进行微服务开发,其中的区别在于SpringCloud组件多,功能完备,全家桶式,基本微服务中会遇到的问题都有相应的解决方案,在通信方面SpringCloud使用的是http。

而Dubbo+Zookeeper使用的是RPC,组件较少,功能非完备(但是我们可以自己去找相应的解决方案),并且现在交由Apache进行孵化,后面应该会实现功能的完备。

就个人来说,认为Dubbo+Zookeeper的侵入性更少,且调用过程更简单,更加类似服务之间的调用,两种方案后续就会进行学习。


原文链接:https://www.cnblogs.com/yuanqinnan/p/10887808.html
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:Spring Cloud(8):Sleuth和Zipkin的使用

下一篇:Java面向对象之封装