深入微服务架构,探索最佳设计,实现微服务架构最大优势

52 篇文章 4 订阅

前言

在之前咱们有介绍过,使用微服务架构有很多好处,并且在各个方面都有其独特的优势,但是,每一件事情都不是绝对的,使用微服务架构同时也充满着挑战。因此,我们必须在开始进行微服务架构设计时,进行全盘考虑,权衡利弊,才能做出合理的选择,取得最佳的设计效果。

在微服务架构设计中,对复杂系统进行拆分之后,会不会产生一些新的问题呢?比如微服务之间的相互调用和通信会不会很复杂?由于每个微服务都有独立的数据库,那么分散的数据管理怎么保证数据的一致性?如果单个微服务的功能变更,会不会影响到多个微服务的正常运行?诚然,这些问题是确实存在的,总结起来包括如下几点:

  • 微服务的粗细粒度不好把握。
  • 分布式的微服务增加了服务之间相互调用及其通信的复杂性。
  • 分散的数据管理难以保证数据的一致性。
  • 由多个微服务组成的系统会增加集成测试的复杂性。
  • 单个服务的变更可能会影响到多个服务。
  • 部署的复杂性。

那么应该如何做才能解决上面提到的问题,并且能充分发挥微服务架构的优势,以达到一种扬长避短的目的呢?

 

合理划分微服务

微服务架构设计的首要任务就是怎么合理地划分微服务,即怎么围绕业务功能来创建微服务。在进行微服务划分时,有关微服务粗细粒度的考虑,建议在平台创建的初始阶段,可以使用粗粒度的方法按业务功能进行划分。然后,随着业务的发展及其运营的情况,再依据发展规模考虑是否继续细分。下面将使用水平划分法和垂直划分法两种方法相结合的方式来创建微服务。

一方面, 在水平方向上,按业务功能不同来划分微服务,并把这次划分所创建的微服务称为Rest API微服务。Rest API微服务负责业务功能的行为设计,主要完成数据管理方面的工作,并通过使用Rest协议对外提供接口服务。

另一方面,在垂直方向上,再以Rest API微服务为基础实现前后端分离设计,创建Web UI微服务。Web UI微服务不直接访问数据,而只专注于人机交互界面的设计,它的数据存取将通过调用Rest API微服务来完成。

这样,经过两次微服务划分,我们就可以创建出Rest API和Web UI两种类型的微服务,也就是说,我们只要使用两种类型的微服务,就可以构成一个复杂的业务系统。

使用Rest API和Web UI微服务,再结合高性能和高并发的设计,并通过微服务的多副本发布,就可以构成一-个能适应任何规模访问的多维的稳定牢固的网格结构,并且这个网格结构还具有自由伸缩的特性,可以根据业务的发展规模进行缩编或者进行扩充,这样也就可以非常容易地搭建一个可持续扩 展的系统平台。

微服务治理

微服务架构的实施,将会产生出越来越多的微服务,而微服务的独立自主性及其设计的扁平化管理方法,都给每个微服务的开发、部署和更新提供了更大的灵活性,所以微服务的运行环境、服务间的相互调用将会变得越来越复杂。因此必须有一些组件和服务来对运行中的微服务进行有效治理,才能在一个庞大的分 布式环境中保证每个微服务的运行和服务间的调用处在一种有序而不杂乱、稳定而高效的状态之中。

Spring Cloud工具套件使用了基于Netlix OSS的一-些基础组件来实现微服务治理,这些组件主要包括:

注册管理服务组件Eureka,提供服务注册和发现的功能。负载均衡服务组件Ribbon,提供负载均衡调度管理的功能。边缘代理服务组件Zul,提供网关服务和动态路由的功能。断路器组件Hystrix,提供容错机制、服务降级、故障转移等功能。聚合服务事件流组件Turbine,可用来监控集群中服务的运行情况。日志收集组件Sleuth,可以通过日志收集提供对服务间调用进行跟踪管理的功能。配置管理服务组件Config,提供统- -的配置管理服务功能。通过Spring Cloud的工具组件进行微服务治理,微服务的运行就将处在一种有序可控的范围之中,微服务之间的相互调用和通信就会变得非常简单,并且快速而高效。

Rest API微服务设计

 

通过围绕业务功能使用水平划分方法划分出来的Rest API 微服务是一个独立的小应用,这种小应用具有独立的数据库,可以独立部署和独立运行。也就是说,每个Rest API微服务是完全独立自主的。

Rest API微服务需要实现两方面的功能:一方面,对内实现数据管理的功能;另一方面,对外提供API调用。

Rest API微服务的实现所体现出来的设计容易、开发简单、访问高效的特点,非常适合使用敏捷开发方法,也可以适应快速迭代和多副本发布的要求。

在我们的微服务架构设计中,Rest API微服务就相当于数据库调用的一个中间件,它的调用性能将对整个系统的性能起到决定性的作用。所以,高性能的Rest API微服务设计,就是微服务架构最佳设计中的一个重点所在。

Web UI微服务设计

Web UI微服务是一个前端设计, 它也可以使用Node.js、Angularjis或Vuejis等前端设计工具来进行开发。这里推荐使用Spring- Boot-Web来开发Web UI 微服务,因为这样会更为简便和快速,并且与Spring Cloud工具也能够取得更多的默契和更多方面的搭配。

Web UI微服务的设计,包含了两个方面的功能:一方面实现对Rest API微服务的调用;另一方面是用户界面设计。Web UI微服务将面对最终用户,所以它必须能够适应规模化的访问。

微服务之间调用规则设计

 

为了保证各个微服务的独立性,并减少通信的复杂性,提高微服务之间的调用效率,我们对微服务之间的调用,做出了如下几种约定。

1.通过Web UI调用Rest API

服务之间的调用,主要是指Web UI微服务对Rest API微服务的调用。一个Web UI在一次调用之中,可以同时调用多个Rest API,并且这种调用将通过高并发设计来实现,即多个调用将会由不同的线程所执行,所以即使是多个调用,也不会影响程序的执行效率。

2. Rest API之间只能通过MQ进行互相通信

为了保证Rest API的高性能特性,同时避免因为一个Rest API的功能变更对其他Rest API的影响,所以禁止在Rest API之间进行相互调用。Rest API之间如果需要进行通信,可以使用异步消息来实现,即通过消息总线实现异步通信。

3. Web UI之间可使用与之对应的实例进行相互跳转

Web UI之间不进行相互调用,但可以进行相互跳转,这种跳转不是直接使用地址栏的链接来进行的,而是通过注册实例实现跳转,当一个注册实例有多个副本时,将可进行负载均衡管理。

数据最终一致性设计

集中式的数据管理可以在一个事务中完成,所以能保证数据的高一致性。对于微服务的多服务架构,数据将由不同的微服务进行分散管理,所以要保证数据的一致性,必须有合理的设计。

假如我们有商品和订单两个微服务,那么在订单服务中生成订单时,将需要在商品服务中进行库存减少的操作,而在订单服务中进行订单查询时,将有可能需要在商品服务中查询订单相关的商品信息,这就涉及不同微服务中数据一致性的问题。

我们可以依据CAP原理的BASE理论来实现数据最终一致性设计。CAP ( Consistency, Availability, Partition tolerance)即一致性、可用性、分区容错性三者不可兼得。

BASE ( Basically Available, Soft state, Eventually consistent)即基本可用、软状态、最终一致性。

BASE 是对CAP中一致性和可用性进行权衡的结果。

数据最终一致性设计具体的实现主要由两种类型的操作完成: 一种是通过调用各个Rest API实现实时同步操作;另一种是使用消息通道以事件响应的方式进行异步处理。

比如在商品服务和订单服务的例子中,当用户下单时,即同时调用两个服务的RestAPI,一方面,通过订单服务的Rest API生成订单,另一方面通过商品服务的Rest API更新库存数量。而当订单状态修改时,即由订单服务的Rest API发布一个异步消息,商品服务的Rest API通过订阅消息来执行相应的更新操作。

分布式集群架构设计

通过微服务的治理环境,使用多副本发布的每个微服务,最终都将被自动纳入到微服务的负载均衡管理体系之中,这些微服务应用与我们搭建的数据库集群、分布式文件系统等集群一起构成一个分布式架构的集群体系

微服务分布式集群体系结构

这个集群体系将由很多不同的服务器所组成,这些服务器既可以分布在同一个局域网之中,也可以进行跨区域、跨机房分布,组成一个庞大的分布式体系结构。总之,使用分布式集群架构设计,可以搭建一个稳定可靠并可持续扩展的系统平台。

微服务运行环境安全设计

系统的安全设计包括防火墙设计、防攻击设计、访问控制设计、数据保密设计等各个方面的内容。而防火墙设计是系统安全的第一道屏障,我们将使用防火墙为微服务架构的服务器组建提供-一个安全可靠的分布式环境

微服务运行环境安全设计网络拓扑结构

使用防火墙,我们可以组建一个局域网环境,在这个局域网环境之中,各种服务器的组建将会更加容易,服务器的配置会更加简单,服务之间的通信也会更加方便和快速。

使用防火墙,我们还可以将不同区域、不同地房的服务器通过VPN连接起来,提供一种更加安全的访问方式。

后记

本文介绍了怎么围绕业务功能来进行合理地划分微服务的方法,并在此基础上创建了两种类型的微服务,即专门用来存取数据的Rest API微服务和主要实现前端设计的Web UI微服务,使用这两种类型的微服务,通过微服务治理,并结合使用数据库集群设计、缓存设计、分布式文件系统设计、微服务的集群设计、安全的分布式环境设计等一系列分布式的架构设计,就可以构建成一个微服务架构的最佳设计,并在微服务架构本身所体现出来的优势和缺点之间进行权衡与调整,最终充分发挥微服务架构的绝对优势。

予人玫瑰,手有余香。喜欢小编的整理的话,请多多点赞评论分享啊,关注小编,你们的支持就是小编最大的动力!!!

  • 11
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值