基于微服务的高校网上订餐系统设计
2021-09-29韩立峰亓雪冬
韩立峰, 亓雪冬
(中国石油大学(华东) 信息化建设处， 山东 青岛 266580)
0 引言
目前，高校普遍建设了校园一卡通系统，它集成了身份认证和电子支付的功能，师生在餐厅等消费场所通过刷卡，就可使用个人账户资金进行支付。随着互联网应用的普及，为了支撑校园一卡通的互联网应用，我校建设了校园一卡通开放平台[1]。平台提供了一系列有关一卡通查询、转账、支付功能的Rest API，第三方应用系统通过调用这些接口，就可将一卡通认证和支付功能嵌入到自己的系统或业务流程里。
1 网上订餐系统
当前，网上预订和网上支付逐渐成为师生的行为喜好。建设网上订餐系统，师生可提前获知当日餐品供应并根据个人口味预订；餐厅销售方可根据预订情况合理安排餐品供应。同时在后疫情时代，线上自主预订、线下分散取餐，可有效减少人员现场聚集，避免交叉传染。
因此我们设计了基于微服务架构的网上订餐系统，系统将用户认证、预订、支付等功能抽取为相互独立的微服务，供前端PC、手机、自助点餐机等客户端调用，同时系统以校园一卡通开放平台为基础，通过调用平台接口，实现基于一卡通的身份认证和网上支付功能。
2 微服务架构
随着互联网应用规模的不断扩大，传统的垂直应用架构已经无法应对。微服务架构[2-3]是一种新兴的互联网应用架构，它将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务之间通讯采用轻量级的通讯协议。微服务架构可以根据应用的需求，动态扩充服务资源，具有很强的伸缩性。
微服务架构带来了服务治理的问题，面对数量庞大的服务，如何实现服务的动态注册和发现，明确服务间的依赖关系，合理调整服务的容量，Dubbo解决了以上问题。Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡、以及服务自动注册和发现[4]。Dubbo框架对系统各种服务的运行过程进行管理，管理架构如图1所示。
图1 Dubbo服务管理架构
图中共有5个角色，各角色之间调用关系为：服务提供者在注册中心注册其提供的服务；服务消费者从注册中心订阅自己的服务；服务容器负责启动运行服务进程；监控中心负责统计服务调用的次数和时间。
3 网上订餐系统架构设计
网上订餐系统的整体设计分为三层架构，其设计思想为：最底层是数据访问层，数据访问层作为服务支撑的基础保障，由一卡通开放平台提供功能支持；中间层是业务层，里面对业务模块进行细化和拆分，将系统用户所需的功能抽取成多个微服务，微服务向下调用基础服务层一卡通开放平台的API，向上对用户访问层提供微服务接口；用户访问层包括PC、手机、自助机等各种类型终端调用微服务接口，实现相应用户功能，系统架构如图2所示。
图2 网上订餐系统架构
本文重点说明业务微服务层设计，订餐系统业务非常明确，将其拆分成5个子服务，分别是餐品发布服务、餐品查询服务、餐品预订服务、用户支付服务和商户结算服务。每个子服务都是独立的功能设计单元，其代码实现不同但技术架构相似。以支付微服务为例，支付微服务首先构建好实现代码，然后将其部署到服务器上运行，这里可根据实际访问量来进行服务器数量的选择。初期可以先搭建一台服务器，然后通过ZooKeeper对服务模块的提供方进行注册，此时一个灵活的、可监控、可管理的子业务就初步完成了。后期随着业务量上升，可以复制原有的代码，完成新服务器的部署搭建，只需将新的服务提供者注册到ZooKeeper中，就形成了一个最轻量的负载集群。由于系统采用Dubbo的服务治理框架，随着数据量和访问量的上升，Dubbo可以使用权重算法分析负载，动态调配系统资源。另外非常重要一点是对服务进行管理和监控，它可以保证系统长时间的在各种复杂的情况下正常运行。
4 网上订餐系统微服务实现
4.1 订餐系统运转整体流程
用户通过网页、微信、App等方式，首先对菜品进行浏览，在选择好需要的菜品后，进行支付，最后系统自动根据对每日支付的订单为商户进行结算，如图3所示。
图3 订餐业务流程
如本文前面所述，订餐业务划分成很多子服务，任何一个子服务都是可供其他程序独立调用的，在前置条件充足的情况下子服务之间完全解耦，这是本系统设计的核心思想，也旨在建立起一个健壮而又可扩展的现代化网络应用系统。本文以支付微服务为例，阐述采用Dubbo框架对子服务进行管理，同时采用微服务的设计思想，由服务提供者创建微服务、由ZooKeeper注册微服务，并通过服务消费者调用微服务的设计理念。
4.2 支付微服务的设计
网上订餐系统作为服务提供者创建支付微服务，首先需要定义服务接口，继而实现服务接口。这里笔者创建了支付微服务PayService，提供线上支付扣款功能。
(1) 服务端定义支付微服务接口
public interface PayService {
int Pay(String account, double tranamt, string meraccc, string order_no);
}
Pay方法中，参数account表示学工号；tranamt表示扣款金额；meraccc表示商户号；order_no表示订单号；返回值为0表示支付成功，非0表示支付失败。
(2) 服务端实现支付微服务接口
public class PayServiceImpl implements PayService {
int Pay(String account, double tranamt, string meraccc, string order_no) {
String jsonStr = JSONObject.toJSONString(inJsonObject);
HttpClient httpClient = HttpClient.newBuilder().build();
HttpRequest request = HttpRequest.newBuilder()
.POST(HttpRequest.BodyPublishers.ofString(jsonStr))
.uri(URI.create("https://一卡通开放平台IP/…/card_pay"))
.build();
int retcode=Integer.parseInt(outJsonObject.getString("retcode"));
return retcode;
}
}
接口PayService的Pay方法在实现时需调用基础服务层一卡通开放平台的支付接口card_pay，实现基于一卡通账户的支付，接口地址https://一卡通开放平台IP/…/card_pay，数据交换格式为JSON，请求方法HTTPS POST，一卡通开放平台执行完扣费操作后，返回JSON格式的处理结果，retcode和errmsg分别表示返回码和错误信息，返回值0表示扣费成功，否则表示扣费失败，调用过程如图4所示。
图4 一卡通开放平台支付接口调用
(3) 声明暴露支付微服务
配置provider.xml文件，在网络中暴露支付微服务：
interface="com.hanlifeng.Dubbo.provider.service.PayService" ref="payService"/> (4) 服务消费者调用支付微服务 用户使用PC、手机等客户端与订餐系统发生交互，调用支付微服务，客户端程序首先根据消费者配置文件consumer.xml建立应用上下文context，然后通过context.getBean()语句获取远程支付微服务的代理对象payService。接下来代理对象的GetOrderInfo方法获取扫描订单二维码得到的订餐信息，包括学工号、订餐金额、商户号、订单编号等。最后调用支付微服务payService的Pay方法完成支付。 根据订餐系统架构，实际部署方案为：1.前端部署2台Nginx用于应用反向代理，服务器配置成主从模式，单台Nginx并发数可达3万，足以满足学校高峰时使用。2.部署1台ZooKeeper服务器用于服务的注册，保存服务列表地址。3.部署1台RabbitMQ[5]服务器，消息队列主要负责处理高峰时段订单的下发，将其排队并按序推送给支付微服务网关，从而实现高峰时段对集中请求分发的处理要求。4.部署1台 Redis服务器和1台MySQL服务器，高峰订餐时段菜品的查询会非常频繁，如果采用通过关系型数据库直接查询，可能会导致数据查询缓慢。系统采用在餐品发布完成后，记录到MySQL数据库的同时，在Redis内存中也生成一个餐品的数据高速缓存，高峰期所有的查询都是直接通过内存中的高速缓存来进行查询，这样可以保证查询速度在毫秒级别，满足师生在订餐时段的用户体验。5.部署2台微服务业务的服务器，将微服务Java源文件进行编译，并打包成mealOrdering.jar分别拷贝到两台服务器的tomcat / webapps目录下，启动tomcat即可，程序会把微服务的节点(各个子服务提供者)注册到ZooKeeper服务器的树状节点中，此时服务消费端可以通过ZooKeeper服务器的树状列表找到自己需要的服务，从而实现分布式微服务的功能。 网上订餐系统采用微服务架构设置，在业务层将餐品预订、支付、商户结算等功能抽取拆分形成一个个微小的子服务，借助校园一卡通开放平台和数据平台提供的基础用户认证和支付能力，同时利用Dubbo框架对系统子服务进行治理，有效解决了微服务的注册、调用、监控、追溯以及高低峰负载均衡等设计问题，使系统具有很高的并发处理能力和伸缩扩展性，可以有效应对校园师生在订餐中大规模使用的场景。5 系统部署方案
6 总结
