大型工程微服务架构设计拙见

本是古典何须时尚 2021-11-16 08:32 261阅读 0赞

现在大型项目的设计架构都是进行服务精细化、微服务的设计。最近也是接触到真实亿级流量项目，大致记录一下较为优秀的项目结构设计。不过师傅也说，总有更精妙的架构设计，只是目前我还没有见过，所以本文只是记录一些粗鄙之见。

为了方便说明，这里举个例子，比如我们有个简单的网售咖啡网站，网售咖啡平台项目名为 祺平（qpcoffee）。我们整个咖啡零售分为管理后台、首页门户、订单支付、发货售后等等服务，每个服务我们可以对应创建一个微服务项目，来实现所有的功能。

![服务架构图][2019073101181738.png]

我们四个服务对应设计八个微服务，每个微服务最终都可以进行打包构建成Docker镜像，启动多个容器实例，整个系统部署成分布式集群应用，最终支撑起整个咖啡馆的业务流量。

所有的工程服务分别如下：

<table> 
 <thead> 
  <tr> 
   <th align="left">服务名</th> 
   <th align="left">工程名</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">门户核心接口服务</td> 
   <td align="left"><em>qpcoffee-api</em></td> 
  </tr> 
  <tr> 
   <td align="left">门户核心任务服务</td> 
   <td align="left"><em>qpcoffee-task</em></td> 
  </tr> 
  <tr> 
   <td align="left">管理后台接口服务</td> 
   <td align="left"><em>qpcoffee-console-api</em></td> 
  </tr> 
  <tr> 
   <td align="left">管理后台任务服务</td> 
   <td align="left"><em>qpcoffee-console-task</em></td> 
  </tr> 
  <tr> 
   <td align="left">订单支付接口服务</td> 
   <td align="left">qpcoffee-order-api</td> 
  </tr> 
  <tr> 
   <td align="left">订单支付任务服务</td> 
   <td align="left"><em>qpcoffee-order-task</em></td> 
  </tr> 
  <tr> 
   <td align="left">发货售后接口服务</td> 
   <td align="left"><em>qpcoffee-delivery-api</em></td> 
  </tr> 
  <tr> 
   <td align="left">发货售后任务服务</td> 
   <td align="left"><em>qpcoffee-delivery-task</em></td> 
  </tr> 
 </tbody> 
</table>

对于任意 *qpcoffee-xxx-api* 和 *qpcoffee-xxx-task* 一组的两个微服务，我们可以在一个项目/工程 *qpcoffee-xxx* 中进行实现，*api* 负责暴露 *http* 接口，*task* 负责一些后台任务，比如经常执行类似统计分析用户消费习惯等调度任务（这一块可以涉及一些分布式任务调度）。

以 *qpcoffee-console-api* 和 *qpcoffee-console-task* 两个微服务举例，我们需要搭建一个名为 *qpcoffee-console* 的工程，该工程下所包含的模块如下：

<table> 
 <thead> 
  <tr> 
   <th align="left">模块名</th> 
   <th align="left">功能</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left"><em>qpcoffee-console-api</em></td> 
   <td align="left">负责最上层暴露http接口</td> 
  </tr> 
  <tr> 
   <td align="left"><em>qpcoffee-console-core</em></td> 
   <td align="left">负责核心业务实现，主要包括service层业务逻辑实现</td> 
  </tr> 
  <tr> 
   <td align="left"><em>qpcoffee-console-contract</em></td> 
   <td align="left">负责暴露一些RPC服务接口，DTO，相关枚举类，以及请求本服务的出入参数等</td> 
  </tr> 
  <tr> 
   <td align="left"><em>qpcoffee-console-intergation</em></td> 
   <td align="left">负责调用其他服务的RPC接口，引入其他服务的contract包，封装调用方法</td> 
  </tr> 
  <tr> 
   <td align="left"><em>qpcoffee-console-repository</em></td> 
   <td align="left">负责封装数据层的操作，包括db、缓存、大数据等的操作</td> 
  </tr> 
  <tr> 
   <td align="left"><em>qpcoffee-console-domain</em></td> 
   <td align="left">主要包含一些领域模型，比如数据库的实体映射等等</td> 
  </tr> 
  <tr> 
   <td align="left"><em>qpcoffee-console-common</em></td> 
   <td align="left">主要包含一些通用性组件，比如工具类、自定义异常、常量</td> 
  </tr> 
  <tr> 
   <td align="left">qpcoffee-console-task</td> 
   <td align="left">负责最上层实现一些后台任务</td> 
  </tr> 
 </tbody> 
</table>

我们在项目搭建时，需要考虑模块间的依赖关系。根据上面描述的模块职责，可以较为统一的设计出模块间的依赖关系如下：

![模块依赖图][20190731005922242.png]  
以上是对整个项目的一个结构设计，具体在各个模块间的数据流动则依靠各种领域对象。对于各个层之间的交互的领域对象，主要可以分为以下：

<table> 
 <thead> 
  <tr> 
   <th align="left">领域对象</th> 
   <th align="left">含义</th> 
   <th align="left">使用</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">DO（Data Object）</td> 
   <td align="left">数据对象，和数据库字段一一对应</td> 
   <td align="left">用于Repository层，由于ORM的存在，DO在这一层作为数据交互的对象</td> 
  </tr> 
  <tr> 
   <td align="left">DTO（Data Transfer Object）</td> 
   <td align="left">数据传输对象，用于RPC层的对象传输</td> 
   <td align="left">用于Core模块中的Service层暴露RPC服务时的传输对象</td> 
  </tr> 
  <tr> 
   <td align="left">VO （View Object）</td> 
   <td align="left">视图对象，用于展示视图的对象</td> 
   <td align="left">用于API模块中的Controller层暴露HTTP接口时返回的视图对象</td> 
  </tr> 
  <tr> 
   <td align="left">BO （Business Object）</td> 
   <td align="left">业务biz使用对象，可能会组装多个其他对象</td> 
   <td align="left">可能业务需要，进行组装多个对象中的属性</td> 
  </tr> 
  <tr> 
   <td align="left">Request</td> 
   <td align="left">请求参数对象</td> 
   <td align="left">前端POST请求传入参数封装对象</td> 
  </tr> 
 </tbody> 
</table>

配合我们的项目结构，具体的使用如下：  
![项目结构图][20190731010305460.png]

所有微服务开发完毕后需要进行部署运行。我们这样设计的一个微服务架构，其实是较为方便解耦的。

首先我们利用打包工具将所有的 *qpcoffee-xxx-contract* 进行打成jar包，便于上游其他服务调用RPC接口；然后将所有的微服务构建成容器镜像，并部署到多台机器即可；最终整个分布式集群的应用跑起来，提供服务。

[2019073101181738.png]: /images/20211116/04fad6483b11400a9d8a21608c6549bb.png
[20190731005922242.png]: /images/20211116/b0d7a457e7a744cf97d027af94affca3.png
[20190731010305460.png]: /images/20211116/2090da35d7354c46b5622fde58050bb6.png