vlambda博客
学习文章列表

准备阶段 -- 架构设计

架构设计和项目管理一样需要考虑范围，时间，成本，质量，是一个综合考虑的结果。

范围：

范围划定了需求的边界，有所为，有所不为，只有边界确定了才能有稳定的设计，一种架构设计一定不会是适应所有需求，所有范围的。是产品还是平台，是独立系统还是有上下游，是ToB还是ToC，是供几万人使用还是上千万用户同时在线，这些范围上的差异，也势必会造成架构的差异。稳定的范围是避免架构设计调整，项目交付风险的基石，调整范围从而改换架构设计，对项目交付的影响甚至比推倒原有架构设计重新来过还要大。

时间：

在实际项目中，客户会对方案的最终上线有一个比较确定的时间点，一般来说都是比较紧急的。软件工程中，增加人手对于工期的减少是有限的，主要原因涉及项目的复杂程度，沟通，协作，技术水平等方面，从而造成大量重复的沟通，时间利用率低，《人月神话》（《The Mythical Man-Month》）中讲得很明白。

因此架构设计需要选取清晰明了，易于沟通，协作，符合大多数软件工程师水平的技术框架，由此来满足项目对工期的要求。

顺带说一句关于软件项目管理方面的，对于软件进度的安排，这本书的作者给出的经验法则为：

三分之一为计划；

六分之一为编码；

四分之一为单元测试等早期测试；

四分之一为系统集成测试；

"In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose."

而在现实中，很多项目并没有为测试留出一半的时间，也没有为计划留出三分之一的时间，反而大部分时间是给了编码这种确定性较高的工作，造成反复的调整，大量的重复或无效的劳动，这是项目中很多问题的一个症结所在。

成本：

开源和节流，这是一个企业所要关注的两个方面，节流就对应着对于成本的控制。成本在软件项目中与资源，及利用资源的时间相关，上一项里面提到的“人月”（Man-Month）本身是成本的概念。人员是资源非常重要的组成部分，不同技术水平的人员必然对应不同的人天单价。

怎么合理地在不同时间节点安排不同的人员以达到最优化使用资源是项目管理的范畴，而实际项目中资源是有限的，技术框架的选择必然需要考虑是否有足够数量技术水平合乎要求的人员，人员能否快速上手，能否并行开发，并行开发量等等。

质量：

软件质量的高低直接决定了维护费用和使用成本，甚至会产生责任风险及灾难性的后果。

国际标准化组织（ISO）对质量的定义：质量是反映实体满足明确和隐含需要的能力的特性总和。

软件质量除了具有一般产品的质量特征以外，还具有六个方面的质量特性，每个方面包含若干个子特性：

1. 功能性：适合性、准确性、互操作性、安全保密性、功能依从性；

2. 可靠性：成熟性、容错性、易恢复性、可靠依从性；

3. 易用性：易理解性、易学性、易操作性、吸引性，易用依从性；

4. 效率：时间特性、资源利用性，效率依从性；

5. 维护性：易分析性、易改变性、稳定性、易测试性，维护依从性；

6. 可移植性：适应性、易安装性、共存性，易替换性，可移植依从性；

要完全满足这些特性非常难，质量管理并非是一蹴而就的，而是一个不断改进逐渐完善的过程，也是一个经验积累的过程。

软件技术的演化时间轴就是围绕质量这一主题不断前行的历程。

根据项目的范围，时间，成本，质量的要求，审时度势地做出的技术选型及设计才是合适的设计，不分情况死板地、为了技术而技术地使用某一些技术，必然会给项目的顺利推进造成障碍。

综上，根据实际情况挑选出一个具备可行性的当前最优架构设计，就是这个阶段架构师应该要完成的工作。

为了讨论本方案的架构设计，先放一个Flowable样例出来：

对应的一些API伪代码：

通过在Flowable设计模块中简单拖拽，少量的配置

可以完成以下页面的创建：

同时完成通知邮件的发送：

另外Flowable还支持决策表用于业务逻辑判断，简便地创建新的菜单项，定制化页面样式及布局，消息队列的发送和接收。

对于本方案选择Flowable作为一个可视化业务调度平台，加上Java后端应用的架构设计，在以下几方面可以匹配：

范围方面：

本方案主要的服务目标是供企业内部雇员使用，非核心业务，系统独立，因此有以下特点：

1. 相比于那些针对消费者客户的系统来说使用人数不多；

2. 非高频使用场景；

3. 无系统间的耦合；

4. 不涉及企业安全信息，不涉及资金往来，涉及个人信息也有限；

5. 无系统间的耦合；

6. 信息量相对较少；

7. 大部分交易数据无需长时间存储；

8. 移动社交场景较多；

假设一个大型企业有三十万员工，每天有十万员工使用，每人使用十次该系统，每次使用发生十次交易，高峰时段为早上8点到10点，中午12点到1点，下午18点到22点，对系统的要求也不超过500TPS，Flowable在性能测试中使用16线程能达到超过6000流程实例/秒，搭配的数据库MySQL5.7在4虚拟CPU，16GB内存，SSD存储的情况下能达到20000行/秒的写入效率，远远超出需求。

数据库表间关联不多，定期清理历史数据情况下，单体应用即可满足。

时间方面：

通过Flowable的设计模块，利用统一的建模语言，业务需求分析师（BA）或者产品经理（PO）可以快速地整理出业务需求，该输出结果对于不了解具体技术的业务人员也能很容易地看懂，同时也能作为开发人员理解需求的输入，即使需求变更了，也能立即在统一的一个地方得到表现，避免需求来回中的理解，沟通的遗漏和偏差，有效地改进对工期的影响。

成本方面：

这套架构不需要太多太复杂的技术，相关基础服务也都由Flowable提供了，因此对于开发人员的技术水平要求不高，也能快速上手，主要工作将集中在业务的实现上，有较大的并行开发量，同时在一次性定义好整个前端页面的样式和布局后，前端开发人员的工作量也不多。

质量方面：

Flowable能提供实现业务需要的相关服务和接口，Java后端代码实现较复杂的业务处理和调用；

Flowable设计模块能帮助业务用户在项目开始之初就清晰明了的知道最终成品，避免因沟通理解而产生的偏差；

Flowable提供的业务流程和页面，让业务人员能清晰准确的理解使用。

Flowable使用标准的BPMN，CMMN，DMN，学习成本可控，并使用成熟稳定可靠的安全框架SpringSecurity，安全系数高。

Flowable的安装部署简单，提供了相关的基础服务，可减少因安装配置造成的失效。

Flowable能达到超过6000流程实例/秒的处理能力，性能瓶颈一般在别处。

Flowable还提供调试工具，便于开发人员快速分析定位问题。

目标放长远点来看，未来企业员工如果人数大增，又或者本方案需要作为服务提供给多个企业，该架构设计可以通过提高单个服务器的配置，也可以进行少量代码调整后实现分布式部署，从而提高响应能力。

2020年11月24日