动力节点CRM项目开发【准备篇】

CRM项目开发【准备篇】

（参考B站视频CRM项目）

01-基本技术框架

• 视图层（View）：展示数据，负责跟用户交互

  html,css,js,jquery,bootstrap

• 控制层（Controller）：控制业务处理流程，（接收请求，接收参数，封装参数；根据不同的请求调用业务层处理业务；根据处理结果，返回响应信息）

  Servlet、SpringMVC

• 业务层（Service）：处理业务逻辑（处理业务的步骤以及操作的原子性）

  Spring、JavaSE

• 持久层（Dao）：操作数据库

  MyBatis

02-项目开发流程

1. 招标

   甲方、乙方、标书

2. 可行性分析——可行性分析报告

3. 需求分析——需求文档

   产品经理：需求调研

   项目原型：主要是静态网页，方便确定需求

4. 分析与设计

   • 架构设计——架构文档（架构师）

     物理架构设计：如应用服务器、数据库服务器的设计

     逻辑架构设计：代码分层（视图层–控制层–业务层–持久层–数据库）

   • 项目设计——项目设计文档（项目经理）

     物理模型设计：表、字段、关系

     逻辑模型设计：类、属性、方法、返回值和参数、类之间的关系

     界面设计：企业级应用一般要求朴素、互联网应用一般要求炫酷一些

     算法设计：算法设计文档

5. 搭建开发环境——技术架构文档

6. 编码实现（程序员编码常在的阶段）

7. 测试（程序员编码常在的阶段）

8. 试运行——使用手册

9. 上线—实施时文档

10. 运维——运维手册（国内软件能用到5年的就已经很不错了，运维基本上留个2年就挺好了）

11. 文档编纂

    该流程贯穿于上述过程之中，包括标书、可行性分析报告、需求文档、架构文档、项目设计文档、算法设计文档、技术架构文档、使用手册、实施文档、运维手册

03-项目核心业务

1. CRM项目的简介：Customer Relationship Management 客户关系管理系统
   企业级应用，传统应用；给销售或者贸易型公司使用，在市场、销售、服务等各个环节中维护客户关系。
   CRM项目的宗旨：增加新客户，留住老客户，把已有客户转化为忠诚客户。

   • 传统应用相对的就是互联网应用。

2. CRM是一类项目，我们的CRM是给一个大型的进出口贸易公司来使用的，做大宗商品的进出口贸易；商品是受国家管制的。

3. CRM项目的核心业务：

   • 系统管理功能：不是直接处理业务数据，为了保证业务管理的功能正常安全运行而设计的功能。

     比如：用户登录、安全退出、登录验证等，给超级管理员，开发和运维人员使用。

   • 业务管理功能：处理业务数据

     • 市场活动：市场部，设计市场活动营销活动
     • 线索：销售部(初级销售)，增加线索
     • 客户和联系人：销售部(高级销售)，有效地区分和跟踪客户和联系人
     • 交易：销售部(高级销售),更好地区分和统计交易的各个阶段。
     • 售后回访：客服部,妥善安排售后回访。主动提醒。
     • 统计图表：管理层，统计交易表中各个阶段数据量。

04-主键id的生成方式

关于分布式id问题的小总结

• 分布式id：在数据量不大的时候，单库单表完全可以支撑现有业务，数据量再大一点搞个MySql主从同步也可以。数据量增长，到后期，需要进行分库分表，显然，这个时候需要一个全局唯一ID，而这个订单号就是分布式ID。
• 需要满足的条件：全局唯一、高可用、高性能、简单可用
• 方案：

算法	优点	缺点
UUID/GUID	容易实现、ID唯一、无需中心化服务器、不会泄露机密	可读性差、占用空间过多、影响数据库性能
数据库递增	容易产生、可读性好、存储空间小	需要中心化的服务器、ID暴露不安全、需要访问数据库获取id
随机数	可以有可读性、存储空间小、随机且安全	需要中心化的服务、需要两步操作
随机字符串	短、可读性高、随机且安全	ID可能不唯一
雪花算法	存储少、可读性高、性能好	时间回拨会出问题、ID生成有一定规律不安全
MongoDB的ID	可读性高、性能好	占用存储过多、时间回拨有问题、ID生成有规律

1. 数据库自增

   利用数据库主键可以设定为自增的特点来设置对应表的id字段。

   【缺陷】运行效率低、并发场景表现很差

   【优势】开发容易

2. hilo算法

   转载自HILO

   private class HiloOptimizer {
   
       private String prefix;
       private int maxLo;
       private int lo;
       private long hi;
       private long lastValue;
   
       public HiloOptimizer(String prefix, int maxLo) {
           this.prefix = prefix != null ? prefix.replace("{", "${") : "";
           this.maxLo = maxLo;            //最大低位
           this.lo = maxLo + 1;           //最低初始位
       }
   
       public synchronized String generate() {
           if (lo > maxLo) {                    //当低位超过最大高位
               lastValue = getLastValue();  //表示hi位的进位次数，从数据库id管理表获取
               lo = lastValue == 0 ? 1 : 0;     //低位归0
               hi = lastValue * (maxLo + 1);    //高位进位
           }
           return String.valueOf(hi + lo++);    //低位最后自增lo++
       }
   }
   

   为了避免每次的生成都从数据库中查询，开发了该算法，不使用synchronized也能产生不重复的序号。

   基本公式：
   $$hi\ast (ma{x}_{l}o+1)+lo$$

3. 雪花算法SnowFlake

   参看原文

   定义：一种分布式的id生成算法，核心思想是使用64位的long数字作为全局唯一id。

   64位的含义（0-63）

   0：无意义，仅仅为了标识是正数，负数部分我们不使用

   1-41：时间戳（时间范围在69年，以毫秒为最小粒度）

   42-46：机房id（32个机房）

   47-51：机器id（每个机房内可表示32个电脑）

   52-63：序号（这一毫秒内的第多少个请求，最大支持4096个）

   将上述各个逐次拼接，就可以得到一个基本上唯一的分布式id。

   【优点】高性能、高可用：生成时不依赖于数据库，完全在内存中生成；容量大：每秒能生成百万的自增id；id是自增的：存入数据库中的索引效率比较高。

   【缺点】依赖与宜通世纪间的一致性，如果时间被回调或者改变，就会造成id冲突或者重复。

4. UUID

   参考原文

   • UUID的基本定义：Universally Unique Identifier，一定的范围内（从特定的名字空间到全球）唯一的机器生成的标识符。

   • 基本特点：经由一系列的算法机器生成、非人工指定和识别的、在特定的范围内重复的可能性极小

   • 基本模式：是一个16字节共128位长的数字，通常以36字节的字符串表示，如：3F2504E0-4F89-11D3-9A0C-0305E82C3301

     128位的含义（0-127）

     0-59：时间戳

     60-63：UUID版本号

     64-76：clock sequence

     77-79：保留字段

     80-127：节点标识

   • UUID的版本包括基于时间的和DEC安全的。

   • java中的使用：

     import java.util.UUID;
     String uuid = UUID.randomUUID().toString();
     

   【优点】能够保证独立性，程序可以在不同的数据库间迁移，效果不受影响；保证生成的ID不仅是表独立的，而且是库独立的，这点在你想切分数据库的时候尤为重要。

   【缺点】比较占地方，和INT类型相比，存储一个UUID要花费更多的空间；使用UUID后，URL显得冗长，不够友好。

5. 共享主键

   由另一张表的类型和长度决定。

6. 联合主键

   由多个字段的类型和长度共同决定。