从0到1架构项目

一、架构的理解

架构是业务、技术开展工作指导，优秀的架构在系统可以轻松面对各种的不确定（系统不可靠、网络不可靠、业务快速发展、需求变更），良好的设计可以规避大量技术债，在技术转型、业务转型中发挥重要作用。

架构是开发工作纲领，在开展业务、研发前，需要进行项目评估，选择合适架构类型，可靠的实现方案，为发开工作进行指导。

架构方案确定可以控制项目风险，将各种不确定纳入可控的范围内。

架构也可以协调不同部门之间工作，需要多少硬件资源、每个部门需要做那些事情、一个部门的工作开始节点始于于上一个部门完成，各部门工作量分配等等提供参考，各部门职责明确，项目经理可以关键节点进行验收，为进度提供保障。

二、成熟度模型

架构工作不是一蹴而就，是根据业务不断演进。在项目初期选用简单架构可以快速满足业务需要，在业务不断增长中，不断迭代，完成单体到分布式，分布式到微服务，微服务到serverless演进。

2.1 初期阶段

在项目初期可能团队人员就只有几个人，要直接上到微服务架构，主要的挑战是：

  1. 人力不足
  2. 技术储备不够
  3. 时间不充裕
  4. 过度设计，业务规模没有达到量级
  5. 风险不可控

初期阶段技术负责人需要关注的几个要点：

  1. 制定开发规范
  2. 制定工作流程
  3. 技术培训
  4. 业务培训
  5. 项目文档化
  6. 项目整体架构方案选型，架构演进预留适配设计
  7. 争取尽量多开发时间
  8. 不招聘新手

2.1.1 开发规范

  1. 书籍
  • 《阿里巴巴Java开发手册》
  • 《重构改善既有代码》
  • 《Effect Java》
  • 《HeadFirst设计模式》
  • 《并发编程实战》
  1. 开发插件
  • P3C
  • SonarLint

2.1.2 工作流程

  1. 需求评审
  2. 技术方案评审
  3. 开发排期
  4. 测试
  5. 需求变更评估
  6. 项目验收
  7. 上线计划
  8. 灰度发布
  9. 线上BUG热修复
  10. 数据订正

2.1.3 技术培训

  1. 通用模块分析
  2. 接口设计
  3. 数据模型设计
  4. 协议选择
  5. 技术选型分析
  6. UML、流程图、架构图绘图方法
  7. 技术预研
  8. 典型错误分析

2.1.4 业务培训

项目开发人员随着业务发展不断，同时也伴随这人员流动，一套完成业务培训流程可以让开发快速了解公司的业务，找到核心关键人员，识别项目可能出现的风险，对现有业务不熟悉，在技术方案设计时会有所遗漏。

业务培训一般是产品、项目经理、技术负责人负责编写，也采用迭代的方式，每个周期，更新现有培训文档，避免文档过时、遗弃。

2.1.5 项目文档化

开发人员不光要避免口头需求，同时开发内部也应该避免口头讲解项目。

当接收到复杂需求，做技术实现方案时，主导人员需要将实现方案文档化。

文档化主要指：

  1. 服务架构图
  2. 数据模型图
  3. 系统交互图
  4. 状态变更流程图
  5. 关联表结构、字段说明
  6. 接口设计
  7. 时序图
  8. 类图
  9. 操作栈数据流转图

优秀的文档，开发人员拿到手即可进行开发，开发与开发之间、开发与运维间、乃至开发与产品、开发与业务方的沟通语言，基于文档、图、视频的方式，减少口头信息传递造成的误差。

2.1.6 顶层适配设计

敏捷开发，并非是完全抛弃架构、详细设计，完全使用最简单最快捷成本最低的方案，反而是前期没有评估好，造成后期迭代困难，架构无法快速支撑业务，付出几倍于以前的成本完成改造，改造过程也同样充满风险。

举个例子：

在项目前期中，不同领域模块之间进行交互的方式，可以基于Pub/Sub发布订阅模型完成，达到模块解耦，后期项目拆分微服务，也可以很快完成切换。

​​Spring​​​的事件监听​​EventListener​​

​​Guava​​​的事件总线​​EventBus​​

​​RabbitMQ​​的消息队列

普通非报表查询，将多表关联拆分为单表查询，在后续数据库分库分表能做到最小变更，报表查询可以使用​​CQRS​​​读写分离模式，单独写一个查询服务聚合多数据源多表数据关联查询，在项目业务达到一定规模，实现数据中台，离线分析、实时分析，​​ETL​​输出结果表、维度表。

项目前期单体应用锁的设计

顶层抽象​​ILock​​​继承​​Lock​​​，增加​​leaseTime​​超时释放，简单死锁规避、注解式等等

常见锁的方案

  1. 基于​​RDS​​
  2. 基于​​Reetrantlock​​
  3. 基于​​Redis​​
  4. 基于​​Zookeeper​​
  5. 基于​​Etcd​​......

在单体到集群过度，可以选择不同方案，注入实现类，即可完成切换

2.1.7 尽量多开发时间

上述很多工作都是需要正常开发之外的时间完成，如果在项目排期时仅仅考虑需求开发时间，是无法完成架构设计工作，需要技术负责人与产品、业务进行沟通，正常开发时间乘上一定系数，指定排期计划。

2.1.8 新人成本误区

项目初期，第一版的成本关系着项目组是否还存在，新人的成本远远高于高级开发，并且新人常常对于项目评估、自身能力判断是不够准确的，项目经验、风险把控几乎是零，再则上述很多事项，并不是一个新手就可以在紧凑的开发周期抽出时间完成。

2.2 中期阶段

ing..