Largrange项目架构与设计回顾 (一)
项目背景
从去年年底开始一个老客户希望在他们的一个传统的机械设备(后面略称 E机关 )上外装一个Android设备。 Android设备和 E机关 之间通过串口或是RJ45接口进行数据交互，主要是Android设备获取 E机关 内部的数据，并不会通过接口来控制 E机关 。 Android设备则通过4G 来和平台交互，上报Android设备的状态数据，同时接受平台的控制。以此来实现让传统机械设备也能拥抱物联网的概念。
最后围绕着客户的需求分成了3个项目来并行推进
- Android设备的硬件设备的设计、选材、样机制作与量产规划
- 在Android设备上,进行与
E机关以及平台进行交互的APP开发 - 用于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的镜像仓库服务)
最后
以上基本是项目最早做设计时候的各种考量。暂时先写这么多，过两天再回顾一下当初设计上有哪些觉得不足的地方。
Largrange项目架构与设计回顾 (一)