基于微服务架构的信息系统开发技术研究

张进猛 苏健 柴立岩

摘要：在传统单体架构的实际使用过程中，存在着项目过于臃肿、资源无法隔离、无法灵活扩展等问题。微服务架构把业务拆分成多个小的微服务、支持独立部署、可以动态的实现横向扩展和纵向扩展，可以解决上述问题。目前国内外存在很多微服务架构，微服务架构的选取和实际应用是该文研究的重点。

关键词：单体架构;微服务;独立部署;动态扩展

中图分类号：TP311.52 文献标识码：A

文章编号：1009-3044（2020）10-0273-02

1背景

一直以来在项目中使用的都是传统单体框架，在使用过程中，遇到了以下问题：1）所有的业务依赖相同的数据库、内存等资源，如果某个新手开发者写了一个慢语句，如果访问比较频繁的话，整个系统都会被拖垮;2）无法灵活扩展，一个业务系统包含很多业务模块，经常碰到的现象是只有一个或两个业务模块访问用户量比较大，比如考试模块访问量比较大，单体系统只能把所有模块部署在多台机器上组成集群，而不能针对考试模块单独部署。而采用微服务，可以把用户管理、班级管理、学习和考试等模块分成不同的微服务，采用不同的数据库，如果现在考试的人多，可以灵活地把考试系统的服务进行扩展，以保证考试的流畅性。

2微服务架构的选择

微服务是系统架构的一种设计风格，它的主旨是将一个独立的系统拆分成多个小型服务，服务之间通过基于HTTP的RESTful API进行通信协作，这些微服务可以用不同的语言编写，采用不同的数据库。微服务架构包括配置管理、服务治理、断路器、智能路由、微代理、控制總线、全局锁、决策竞选、分布式会话和集群管理等。

从表1可以看出，Spring Cloud是一个微服务综合解决框架，选择它就像选择了一个品牌机一样，否则我们只能自己针对各个问题去DIY自己的框架了。而且我们的单服务框架开发一直使用了spring，Spring Cloud基于Spring Boot，选择springCloud可以说已经具有了一定的学习基础，上手要容易得多。

3微服务架构的实现

3.1服务的划分

无论采用什么技术，都是为了实现特定的业务。使用微服务，也是为了更好的业务运行，给用户更好的使用体验。所以合理的划分整个业务为多个微业务，是实现微服务的关键一步。根据业务划分了用户管理、课程学习、课程考试、竞赛考试、证书管理等微服务。

3.2微服务的实现

整个微服务的实现包括下列组件的使用：服务治理、网关服务、负载均衡、容错保护、分布式配置中心、消息总线、分布式服务跟踪等。

3.2.1服务治理

使用的服务组件为Spring Cloud Eureka，实现服务注册和服务发现，包括服务注册中心和服务提供者。服务注册中心需要引入swing-cloud-starter-eureka-server依赖，然后在程序中引入@EnableEurekaServer。因为微服务要考虑高可用问题，所以需要搭建服务注册中心的集群，每个服务中心都向另外的服务中心注册自己，以实现服务清单的互相同步，达到高可用的效果。

3.2.2网关服务

使用的服务组件为Spring Cloud Zuul，主要包含两方面的功能：1）实现路由规则和服务实例的维护;2）通过过滤器实现签名校验和登录校验等。

3.2.3负载均衡

使用的服务组件为Spring Cloud Ribbon，主要用于实现客户端负载均衡，主要有随机策略、线性轮询策略、重试策略、最低并发策略、可用过滤策略、响应时间加权重策略、区域权重策略等。

3.2.4容错保护

使用的服务组件为Spring Cloud Hystrix，当某个服务单元发生故障时，通常需要经过长时间的等待，然后返回connectiontimeout等错误信息。加入Hystrix后，服务发生故障时，通过断路器的故障监控，向调用方法返回一个错误响应，而不是长时间等待，这样不会使得线程因调用故障服务被长时间占用不释放。

3.2.5分布式配置中心

使用的服务组件为Spring Cloud Config，分为服务端和客户端两部分，实现配置的集中管理、动态调整配置、自动的更新配置。

3.2.6消息总线

使用的服务组件为Spring Cloud Bus，通过整合RabbitMQ实现消息的接收和发送。

3.2.7分布式服务跟踪

使用的服务组件为Swing Cloud Sleuth，通过整合Logstash或者Zipkin对请求链路跟踪快速发现错误根源以及监控分析每条请求链路上的性能瓶颈等。

4结束语

微服务架构可以解决单体架构的项目过于臃肿、资源无法隔离、无法灵活扩展等问题，它的敏捷开发和自动化部署等优点备受开发者青睐。但同时对开发人员尤其是项目管理者提出了更高的要求，对业务的划分、接口的一致性、分布式的复杂性、运维的新挑战，需要更多的开发者参与到项目中。