2019-08-12

中心思想：

发现即解决根本（单点），不做临时反复性补丁

解决方案

责任明确划分
增加临时性补丁模块（适配器模式）
增加消息中心
删减重构部分模块
Web端 基于 项目合并或切割及ABP处理结果 进行删减合并性重构
项目增加readme 描述接口使用方 调用节点，方便删减整理 排除无效卡点
查阅整理所有项目代码，做到对各个项目至少有基本业务理解，这是一个排坑的过程，防止之后出现临时问题当场懵逼

1、部署问题

• 1.1 为什么每次部署都那么难?
  是缺少文档性说明，还是缺少自动化工具? 部署过程的参数 是不是不够清晰。

• 1.2 开发环境不稳定
  假设生成环境部署成功可以稳定运行，那是什么原因导致开发环境的不稳定？
  每次解决都要几分钟至跨天不等，是某些问题反复发生，还是发现不了问题的本质原因？
  不能每次都是临时性解决

• 1.3 版本问题
  应该从git、docker镜像到系统展示层面有完整一致的版本标识
  不能问题解决即发版，一般性问题应该积压发版列表，统一发布

• 1.4 快速还原生产到开发或测试环境

2、肯叟机制问题

• 2.1 app接口配置 改成 通配（押后）

• 2.2 这玩意不能再手动处理了 一定要提供工具
  比对
  发布生成
  目标：不再手动重复性创建配置

3、Web结构问题

SystemWeb
PlatformWeb
CompanyWeb
BrokerWeb
是不是有必要整理合并

4、ABP

• 4.1 转发一切请求
  本身是一个前后对接的事，为什么搞成了三方对接

• 4.2 对基础层面的限制
  比如 组织机构啥的

5、数据库问题

有没有可能统一只用 pg 或者 sql server

6、统一风格

• 5.1 UTC
  对UTC提出完整性解决方案（前后端），遇到即处理
  当前过滤数据因UTC产生的问题有多少 不可预估

• 5.2 KV 传递问题，影响统一封装
  统一获取源头
  只存K、只存V、还是都存、
  模型是 key,value，name,value，id, name

7、消息链路

发送时机、用途不清晰，影响系统的扩展性
建立消息中心做 消息复制分发和数据处理

8、不安全、不确定的模块

租赁二手房 的电子合同 -- 基本没使用过吧
实勘 -- 觉得有些复杂
经纪人 -- 数据结构需要重新考量
统计 -- 有疑问啊 是不是要再重新来过
客源 -- 对于归属 重新设计和明确一下
组织机构 -- 整个拿出来说一下嘛

9、重复性太高

Web的组件封装
Web的重复性代码
kv的重复性接口
组织机构的重复性存储

10、数据的不一致性

数据的出处不一致，导致的数据不一致，比如某处的经纪人列表 和详情