Largrange项目架构与设计回顾 (一)

项目背景

从去年年底开始一个老客户希望在他们的一个传统的机械设备(后面略称 E机关 )上外装一个Android设备。 Android设备和 E机关 之间通过串口或是RJ45接口进行数据交互，主要是Android设备获取 E机关 内部的数据，并不会通过接口来控制 E机关 。 Android设备则通过4G 来和平台交互，上报Android设备的状态数据，同时接受平台的控制。以此来实现让传统机械设备也能拥抱物联网的概念。

最后围绕着客户的需求分成了3个项目来并行推进

1. Android设备的硬件设备的设计、选材、样机制作与量产规划
2. 在Android设备上,进行与E机关以及平台进行交互的APP开发
3. 用于Android设备交互的平台的架构、设计与开发

我们平台Team就负责 3.用于Android设备交互的平台 并命名Lagrange (拉格朗日) 。

设计&架构

整个平台这块不仅需要向Android设备的APP提供数据交互接口，还需要有一个供相关运营人员使用的前端Web应用，以及与云平台(主要是Aliyun) 交互的功能。所以考虑到多方面使用微服务的架构来实现整个平台端。
由于E机关的工作工况不能保证长期较的稳定的连接到4G网络，所以我们并不考虑使用Socket长连接的方式来做APP和平台之间的数据交互，要实现平台对Android设备进行反控的话，只能实现推送方式来把控制命令下发给Android设备,所以还需要有一个第三方推送服务商交互的服务。同时控制推送也有实时和非实时以及定期推送的需求，所以可能还需要一个任务调度的服务。

根据对上述业务进行梳理，我们将项目分成几个服务

• 提供Android设备的交互接口的 App Service
• 提供运营人员使用前端Web应用 Platform Web Service
• 前端Web应用使用到的一些接口 Platform Service
• 负责第三方推送服务商交互的 Push Service
• 提供云平台鉴权用的 Auth Service
• 用来管理任务调度的 Cron Service

由于前一个项目实施的时候没有使用容器部署，每当访问量峰值的时候，我们这些码农兼运维就各种加班，所以这次项目决定直接将服务容器化，同时选择了Kubernetes来管理容器。由于客观原因线上的Kubernetes直接购买了Aliyun的托管版Kubernetes服务。 内部的开发测试环境则使用了 Rancher 2.0 来构建Kubernetes集群。

技术选型

a. 后端服务选型

由于不考虑长连接的原因，所以在后端服务在技术选型上基本就不考虑Netty了，直接上Spring大礼包。

• Spring Boot 开发接口
• Spring Data 配合 JPA 来进行数据的持久化
• Spring Cloud Kubenetes 来做数据的Config的autoreload
• Quartz 负责处理任务调度

服务之间调用都使用HTTP服务, 服务发现也有Kubernetes的DNS机制支持。服务网格则选择了比较成熟的Istio，主要还是Aliyun的Kubernetes可以集成Istio，部署和使用都相当方便。

b. 前端Web应用选型

因为前端Web应用主要是给运营人员使用，所以我们考虑使用Single Page Application来做个前后端分离的Web应用。框架这块由于团队成员基本上没有什么前端开发经验，基本都是后台写Java的码农，所以框架选择有点随性，直接就点名了vue.js。前端控件库则用的是阿里系的Antd。

c. 数据持久层

主数据库选择了mysql，缓存用的redis。这些都是团队比较熟悉的。由于一些特殊的业务需求和使用场景，我们还加了一个mongodb来做为一个副数据库，主要存放一些特殊业务使用的数据。

d. DevOps

用了相当传统的GitLab CE 加上Jenkins的组合，实现前后端代码的自动编译，推送到私有的镜像仓库(使用Aliyun的镜像仓库服务)

最后

以上基本是项目最早做设计时候的各种考量。暂时先写这么多，过两天再回顾一下当初设计上有哪些觉得不足的地方。