基于微服务体系的服务框架的设计

2019年第6期信息通信2019

(总第198期)INFORMATION&COMMUNICATIONS(Sum.No198)

基于微服务体系的服务框架的设计

周素青

(福建信息职业技术学院，福建福州350003)

摘要:与传统的单体架构相比，微服务架构有着基于独立服务、按需收缩、易于开发和维护等优点。文章针对传统单体架构和微服务架构的优劣对比的基础上，提出了如何从零开始构建微服务以及如何将现有的单体应用改遥成微服务的实施方案,通过该方案实现快速有效的模型迁移O

关键词:伸缩立方体;微服务;API Gateway;服务发现

中图分类号：TP39文献标识码:A文章编号：1673・1131(2019)06-0069-04

Title IWIWIWIWIWIWIWIWIWTmeTmeTmeTme

Zhou Suqing

(Fujian Polytechnic oflnfimnation Technology,fuzhou350003,China)

Abstract:Compared with traditional monolithic architecture,micro-service architecture has many advantages,such as indepen­dent service,shrinkage on demand,easy development and maintenance.Based on the comparison of t he advantages and disad­vantages of t raditional monolithic architecture and micro-service architecture,this paper proposes how to build micro-services from scratch and how to transform existing monolithic applications into micro-sravices,through which to achieve rapid and ef­fective model migration.

Key words:Scale Cube;micro-service^PI Gateway;Service discovery

1微服务的介绍

1.1微服务的定义

微服务(Microservices)概念的版本很多,这里选取维基百科上的定义作为本文的标准:微服务是一种软体架构风格，它

是以专注于单一责任与功能的小型功能区块为基础，利用模

组化的方式组合出复杂的大型应用程式，各功能区块使用与语言无关的API集相互通讯叫

1.2Scale Cube

说到微服务不能不提到Martin L.Abbott所提出的的三维

图］伸缩立方体(ScaleCube)

X轴伸缩是指通过部署多个相同的应用来实现事务的快速扩展。以餐厅厨房为例说明X轴扩展：厨师为了做出一道美食,需要经历选择食材、处理食材、调配酱料、烹饪食材、成品装盘五个步骤。餐厅为了更高效的服务顾客，请来了多名厨师来的完成这些过程，厨师之间制作美食的过程是相互独立的。显而易见，虽然餐厅服务顾客的效率变高了，但是餐厅的成本也大大提高了，同时厨师完成这些过程的复杂度并没有改变，而且为了让厨师提供无差别服务，就需要在厨师之间

“同步数据”，这就需要保持数据的一致性。所以X轴伸缩的不足在于每份都克隆需要访问所有数据，这就需要更多内存实现缓存，运维的成本过高叫

Z轴伸缩，也称为分片，指根据用户的属性对服务进行拆

分。它与X轴伸缩有些许类似,不同之处在于Z轴伸缩只对应用和数据进行分片，每个应用负责对应属性的数据子集。还

是餐厅厨师的例子，厨师制作美味还是需要上面五个步骤，但

是不需要每个厨师都要会做川菜、粤菜、湘菜,根据客户喜好

合理的分配不同菜系的厨师的数量。Z轴伸缩常用在大型数据类集或者差别服务，它不仅提高了缓存的利用率,还提升了

事务的可伸缩性，实现了不同客户群体的故障隔离。这样在

一定程度上提升了餐厅的效率并且减少了餐厅的成本，但是

还是没有减少单个厨师的工作复杂程度，并且对于顾客点单

到分配到具体厨师的过程也提高了复杂度，所以Z轴伸缩不仅没能降低开发和应用复杂度，反而在路由策略上还提高了系统的复杂度，并且涉及到数据重新分区的时候，又将会是一个令人头疼的事情。

与X轴和Z轴的“复制”的做法不同,Y轴伸缩按功能将应用分解成一组具有一定松散耦合度的协作服务，每个服务

实现单个或多个相关的功能。Y轴伸缩基于不同的业务来分解工作职责。比如餐厅老板意识到降低厨师的工作流程的复

杂度才是提高效率、降低成本最有效的手段，于是请来配菜师

傅员责选择食材、调配酱料，砧板师傅员责处理食材，这样厨师就只需要烹饪食材和成品装盘两个步骤了。这样就降低了厨师的工作复杂度,同时对于餐厅也可以减少一定量的厨师,增加的只是薪资远低于厨师的配菜师傅和砧板师傅，餐厅的成本也就降低了，大家都能更专业更有效的完成自己的工作。

三个维度特点各不相同，各自独立,但每个维度都可以按

各自的需要扩展。X轴扩展能够解决系统的事务员载压力,但是如果系统的复杂度或面对的吞吐量不断增加，或者需要差

异化服务时,X轴扩展就无法满足需求了。此时可以分别通过

Y轴扩展和Z轴扩展来处理来解决系统复杂度增长的问题和差异化服务问题，而Y轴扩展就是所谓的微服务。这里的三维伸缩模型分别代表了单体模型、多应用模型及微服务模型。目前，互联网应用框架的演进过程，逐步从传统的单体模型、

演进过程

图2互联网应用架构演进过程

1.3微服务的优缺点

微服务架构有利于降解大项目体量，将原有大型项目拆解成若干个小项目的集合，降低版本控制和沟通成本;同时也有利于提升代码复用度，提取公共逻辑独立实现，避免各团队重复造轮子。微服务对于开发人员来说由于只需关注自己的服务所以相对容易理解的多，同样也不会出现开发工具不堪重负的情况;每项服务都可以独立部署，大大简化了部署新服务版本的流程;而且提供了不同客户群体的故障隔离,某个服务出现内存溢出只会影响到服务本身，其他服务能够继续正常处理请求。而单体架构中的单个服务故障则会拖垮整个系统。

当然微服务是把双刃剑，对于小团队开发的应用架构建议慎用，传统的单体架构有其天然快速落地部署的优势。架构设计者必须应对创建分布式系统时产生的例如分布式事务问题、服务间通信机制等各种额外复杂性;不同的服务的技术栈选择也是不得不面对的问题;最后部署微服务时，多种存在依赖关系的服务共同构建的系统如何进行部署与管理也是个难题。

2从零开始构建微服务

2.1为构建微服务做准备

在选择单体架构还是微服务架构时，首要挑战在于如何把握好微服务切入的时机。在开发项目最初版时，微服务架构不是必须的，使用分布式架构在前期反而容易延缓开发。对于新公司，其面临的最大的难题在于如何快速地完成业务模型获取利润，而Y轴功能分解使项目的快速迭代更加困难。但若等项目运维出现困难急需扩展时再进行功能分解，那时服务间杂乱的依赖性很难将应用分解为一组微服务。

如何将业务系统拆分成多个合理的微服务集变得格外重要。可以参考单一责任原则(SRP)进行设计类的思路。SRP 会用单一变更理由去定义一个类的职责：_个类的状态变更只能由一个原因导致③。在微服务设计中也可以使用SRP的设计思路。同样的还有Unix工具的设计思路,Unix大量的工具选项包中，每种工具功能独立，员责实现某一个功能。

2.2开始构建微服■后端服务Y轴扩展

基于Y轴扩展的原则来进行微服务的构建。比如一个商品详情页，有店铺概要，商品信息，价格信息,库存信息,评价

概要,类似商品，店铺其他热卖商品等等，可能需要十几甚至上百个后端服务分别来处理这些不同的请求。那客户端访问这个页面就需要调用十几甚至上百个接口来请求不同的服务,一旦后端服务有接口的调整修改，客户端也需要跟着一起变动,如果是APP端，改动如果不能通过热更新解决，那还需要

更新整个APP,—定程度上延迟了项目更新迭代的周期;而且在公网环境下，这种众多后端服务的调用带来的延迟是难以

接受的，更何况可能是在不稳定的移动网络的情况下,用户的体验是简直是糟糕透顶；另外客户端的某些直接请求协议可能不是类似HTTP/HTTPS/WEBSOCKET这种浏览器或防火墙友好的。一个服务可能是通过RPC来进行服务间的通信,

而另一■个服务可能是使用基于MQ的消息队列来进行服务间的通信，这就导致客户端也需要通过_系列编码来适配后端服务可能用到的各种进程间通信方式。

2.3API Gateway的使用

为了解决上述的几个问题,需要采用APIGATEWAY(API SERVER)来集中管控后端服务。API Gateway是一个独立的服务进程(也可是独立的服务器)，是客户端登录整个系统的

统一入口。API Gateway弁于客户端和微服务之间，封装了系

统的内部架构的复杂性和差异性,为用户提供粗粒度的APL 它还可以进行用户授权、限流降级、行为监控、路由、负载均衡、

日志统计、页面级缓存等。

API Gateway对微服务中的公共功能进行了抽象，客户端

的请求都通过API Gateway接入再路由到对应的后端微服务。API Gateway可以暴露出一个粗粒度API给客户端。以前文提到的商品详细页使用场景为例,API Gateway提供一个API 使得客户端可以在一个请求中得到商品详细页面的全部数据。API Gateway根据业务逻辑进行原子服务的组合包装，并最终返回给客户端，这样客户端只需要一个公网请求就能完成商品详细页的数据需求，大大减少了网络延迟。而且如果有后端服务有接口调整修改，只需在API Gateway层做调用修改即可，加快项目迭代更新的同时也简化了客户端编码的复杂度。

2.4不可或缺的服务发现(Service Discovery)

一套完整的微服务体系除了后端服务的Y轴扩展和API Gateway,服务发现也是不可或缺的。可以通过让客户端读取一份预先配置好的服务实例的静态地址来实现，可是由于线上的动态扩展、升级甚至失效等情况，服务实例时常会出现变动，所以客户端需要使用一种更完善的机制来动态的获取服务实例变动后的地址。

一般服务发现需要实现两个部分，第一就是服务注册(Ser・vice Registty),服务实例完成自我注册,向注册中心注册及注销服务，另外服务实例也需要向服务注册中心发送心跳来及时更新自己的健康状况，以保证服务注册服务能够更准确地提供负载均衡策略。第二即负载均衡(Load Balance),负载均衡用于向调用者(客户端或者API Gateway)提供最合适的服务实例地址，负载均衡可以使用缓存策略来提高自己的响应速度,同时搭配一致性哈希算法以提供更为良好的单调性，使整个架构的容错性更好。

最后，与服务发现节点之间的通信,最好采用http+restfoK like的模式统一通信模型，这样可以使得服务发现节点本身更为纯粹，更为轻量。服务发现同样是独立节点,也一样需要高可用以及额外的开发、部署和管理。

自此，一套完整的微服务架构就很清晰了,API Gateway,