基于云原生微服务实战：叫车系统场景.pdfVIP

本文由简悦SimpRead转码，原文地址

本我将带你学习“示例应用与用户场景分析”。

作为云原生微服务应用开发的实战课程，其中最重要的就是课程中所使用的实战项目了。实战项目是贯

穿整个课程的主轴，一个好的实战项目应该是的、完备的和易懂的，这也是本课程与其他课程的主

要区别之一。

项目的性是指项目于实际存在的需求，而不是虚构的，性意味着可以把实战项目中所学到

的知识直接应用到实际的项目开发中。

完备性意味着项目的实现是完整的，案例中涵盖主要的用户场景，并且不会对项目的场景做过多

的简化，过多的简化会使得项目的实现与实际相差太远，起不到实战的效果。实战项目并不是玩具项目

（ToyProject），有些课程会使用多个小项目来作为示例，这种做法的问题在于每个小项目都只包含了

完整项目的一部分，没办法得到项目的全貌。

易懂意味着项目在实现中并不涉及复杂的业务逻辑，只需要就可以对应用的场景进行分析了。有些

应用，比如和等，有着相对复杂的业务逻辑。如果选用这样的案例作为示例，则需要花费比较

大的篇幅来解释相关的业务逻辑。因此，选择业务逻辑简单易懂的应用。

基于上述这三个原则，本专栏选择了叫车服务来作为案例，开发的是一个类似滴滴打车和优步的叫车服

务，称为快乐出行，叫车服务的示例应用符合上述的三个原则。叫车服务是实际存在的应用，于真

实的需求。大部分人都使用过叫车服务App，对于其中的使用场景比较熟悉，并且该示例应用实现了叫

车服务相关的重要用户场景。

下面对示例应用的重要用户场景进行介绍。

用户场景

快乐出行应用的用户场景是围绕叫车这一业务展开的，除了叫车这一业务之外，还包括其他相

关的辅助业务。

###

叫车服务

叫车动作由乘客发起，当乘客在叫车时，需要行程的起始地址和结束地址，地址以关键字搜索的方

式。

在行程创建，系统会在起始地址附近的特定范围内，搜索当前可用车辆。当找到可用车辆时，系统

会发送给。

接收到新行程创建，可以选择接受行程，在发出接受行程的请求，系统会从所

有愿意接受行程的中选择一个。选择的算法有很多，简单的选择算法是采用先到先得的策略，

谁先接受行程，谁就被选中；复杂的算法可以设定一个等待的时间段，在这个时间段内应答的，选

中距离的。

被选中的会获取到乘客的相关信息，以方便联系乘客。在接到乘客，开始行程；当达到目

的地，行程结束。

###

乘客管理

乘客管理负责乘客相关的信息，乘客的基本信息包括乘客的、Email地址、等。典型

的场景包括乘客和乘客信息更新。

除了乘客的基本信息之外，乘客还可以添加常用的地址，比如和工作单位地址等，这些地址可

以帮助乘客快速选择行程的起始和结束位置。

乘客在系统中有自己的状态，有些乘客的可能因为不恰当的行为，暂时被系统封禁，或处于受限状

态。被封禁的乘客无法创建行程，而受限的则限制了可以创建的行程长度和金额，比如，受限

不能创建长度超过20公里，或是金额超过100元的行程。

###

管理

管理负责相关的信息，的基本信息包括的、Email地址、等。典型

的场景包括和信息更新。

管理的另外一个重要功能是管理的车辆，车辆的基本信息包括车辆的厂商、型号、出厂日期和

牌照号码等。正规的叫车服务对有严格的背景审核流程，这些审核流程是