注：该项目是公司项目，在此仅仅是自己作为开发人员在开发项目的总结，不涉及具体项目，发出这边总结在博客上仅仅是自己这2个多月的总结。
项目大体介绍
简介
GA1400项目是公司按照公安部GA/T 1400《公安视频图像信息应用系统》要求进行设计开发，《公安视频图像信息应用系统》主要分为下面4个部分：
GA1400项目是作为公安视频图像信息数据库(简称视图库)，内部代号xxxx，并有对接深目产品使得深目产品符合公安部GA/T 1400标准的xxxx-deepeye项目。
开发时间
项目从9月13号开始，计划至11月23日，开发时间在65天左右。项目计划如下图所示：
实际上，项目延迟4天，期间共加了5天班，共计开发75天左右。
项目技术
项目使用公司基于Spring Cloud封装的微服务架构，可以说就是Spring Cloud全家桶，然后加了一些其他开源项目，比如携程分布式配置中心Apollo、当当的分布式任务调度平台Elastic-Job-Lite、统一日志平台ELK。
项目使用到了其他部门提供的数据服务(Ifaas-data)组件以供存储数据，该服务使用mongodb存储数据，提供基本的CURD能力。
主要使用了如下技术：
- 服务治理：Spring Cloud Eureka
- 服务调用：Spring Cloud Feign、Spring Cloud Ribbon、Spring Cloud Hystrix
- 配置中心：Apollo
- 任务调度：Elastic-Job-Lite
- 日志服务：ELK(当前版本未使用)
- 消息服务：Spring Cloud Stream、Kafka
- 权限服务：Spring Security OAuth2(目前该版本未做细致的权限管理，仅仅做了角色管理)
- 会话管理：Spring Session、Redis
- 数据库管理：Flyway
项目开发
自己主要做了视图库相关的设备管理、联网服务管理、布控/告警、订阅/通知以及xxxx-deeyeye的布控转发等接口的开发，布控/告警、订阅/通知相关文档的编写。
设备管理
设备管理主要按照GA/T 1400标准来的，主要管理一下对象：
- 联网服务器对象
- 采集设备
- 采集系统
- 应用平台
- 视频图像分析系统对象
数据存储
这一部分使用的是MySQL数据库进行存储。自己在设计数据库的时候，由于后面三个对象属性基本相同，所以设计在一个表中，其它的基本都是按照标准来的，没有需要多说的。
相关接口
开发接口方面，基本就是CURD，还有就是Excel导入导出等常规接口。在就是由于是按照GA/T 1400标准开发的，所以在后台管理方面的接口属性不是按照常规标准来的，所以多了许多对象属性转化方面的操作。
联网服务管理
联网服务管理主要涉及：
- 向上级视图库自动注册保活
- 支持多个下级视图库的联网接入
- 支持逐级查询下级视图库卡口、采集设备等信息，构建视图库联网拓扑结构
相关接口
主要涉及到提供注册保活接口，这一块是同事开发的。自己主要做了两个定时任务去自动向上级注册保活以及查询下级视图库采集设备等信息。
布控/告警、订阅/通知
自己写的逻辑主要集中在这一部分，包括布控、告警、订阅、通知对象的CURD操作，还需要根据布控区域、布控卡口、订阅区域、订阅卡口等向下级视图库或应用平台进行分发，以及接受到告警、通知会回调告警、订阅接收地址。
数据存储
这一块的数据存储使用的是MongoDB进行存储，具体就不多说了，有点小坑就是加索引，不好加。
项目总结
这个项目是我来公司后，开发的第三个项目，开发时间最长的一个项目，项目中遇到了许多的问题，经常一个坑填了又进了另一个坑，真正的开发其实没有用到多久的时间，填坑花了太多的时间。下面我从项目、产品、开发这三个部分进行项目总结。注：这三个部分主要是我接触到的部分进行总结。
项目方面
这里就说说整个项目过程中，遇到的一些问题，主要是流程问题。
- 私下讨论的问题以及提出的解决方案，尤其是需要修改的东西，需要给整个团队说明。
- 项目的配置项，应该意义明确且需要告知团队中所有人。
产品方面
这个项目是按照公安部GA/T 1400标准进行开发的，最开始项目评审时，产品就给了公安部这四个标准文档和这一期需求说明书(这个说明书就是从这四个文档中拷贝了我们需要做的东西，没有其他说明，有点小坑)。
需求不明确，关键流程未梳理清楚，项目排期不合理，导致项目开发中的前松后紧，最后以至于加班严重。
由于需要和其它项目进行交互，所以需要先了解其它项目的大体逻辑，比如这个项目需要深目和引擎。
开发方面
这个项目是和其它小伙伴一起进行开发的，这之中涉及到团队协作的问题。然后这个项目由于需求不太清晰，关键流程未梳理清楚，导致在分配任务是所有的关键逻辑都在我这里，所以后面加了好多班(笑着活下去^_^)
使用新技术：这个项目用Spring Cloud全家桶，这是自己第一次用，所以还是爬了许多的坑。
技术选型未明确：在项目开始时，没有说要使用其他团队提供的数据服务(ifaas-data)，所以写了许多的无用代码。
设计数据库：在设计设备管理相关表，考虑使用数据库自增Id还是设备Id作为主键的方案时犹豫不决，在代码写了许多的时候又改了，导致浪费许多的精力。
未考虑性能：在开发时，仅仅考虑业务逻辑的实现，而未考虑性能问题。比如在异步选择Kafka消息，而不是本地异步，这就导致性能瓶颈在发送Kafka消息。
团队合作：这个项目是几个小伙伴一起开发的，由于每个人负责不同的模块加上仅统一了返回对象，导致每个人有不同的编码风格+实现逻辑。比如说：日志打印规范不统一(这个项目还未使用ELK)。
自测不充分：开发人员开发完代码或者修改bug后自测不充分或者不自测就转给测试。当然由于这个项目有一定的特殊性，导致开发人员不好测试。
及时抛出问题：在开发的时候有时候遇到问题，就想着自己解决不麻烦别人，结果一直蒙在那里，严重影响项目进度，所以在阻塞性问题发生时，如果自己在一点时间内还没有解决问题，一定要及时抛出。