系统架构设计案例总结
我运维出生，对于开发的工作，以前也就是写些脚本，或者是对别人写好的或现成的东西修修补补。和朋友聊天，他们说呀，没有独立开发一个新功能的能力，就不算是懂开发。听人劝，吃饱饭。2021年我通过了全国计算机技术与软件专业技术资格（系统架构设计师）考试，其实目的只为技能水平的提升。考试是通过了，但对于系统架构的设计还是概念模糊。这两年也尽力的去学习系统设计方面的知识，上周完全自己设计的一套简单系统正式投入生产。自我感觉还行，就是很简单的系统，我从可用性，可扩展性，可维护性几个方面思考，完成了功能设计和代码编写。
现在将该案例做个总接，一是对整个设计过程做一个梳理，二是希望业内的同仁或前辈提出改进意见，我虚心接受，再次完善。
1. 系统介绍
该系的功能是对现有两个系统（一站式自动化集成测试系统和自动化CI系统）接口的调运，使用户能自定义完成CI与测试的闭环，进而实现产品质量保证。因为产品的业务场景不同，调运两个系统接口的参数也就不同，而且参数还有交叉。这就使得手动实现很复杂，而且很多工作都是冗余的，对于配置好的测试品类多，相互依赖，维护起来费时费力。功能上大概如下：
一站式自动化集成系统，以下简称（集成系统）
自动化CI系统，以下简称（CI系统）
该系统简称（Free Test of Combination, TFC系统）
用户通过TFC系统完成对集成系统和CI系统的参数自由组合。
2. 系统设计
2.1 设计思路
接口的调运考虑到系统的可可扩展性以及对产品参数的约束，采用了抽象工厂模式设计。
因为两个系统的参数要交叉混合混合使用，并且实现步骤可以固定的，于是对于参数组合采用了建造者模式设计。
每一个系统接口的调运都需要认证，而且多处认证，所以对于认证模块采用了原型模式。
因为两个系统的参数相互作用，需要人工调解，所以定义一个parse模块，以反射的形式完成对原始参数的修改与调解。
原始参数独立定义，在方法实现前，掉用户接口，完成修改。
2.2 设计架构
2.3 架构实现
BaseAPI ：完成对接口的抽象与接口方法的约束
Server_API: 接口抽象方法的继承，具体接口调运方法的实现。
BaseIntergra： 继承系统接口抽象
BaseCI：CI系统接口抽象
Integra_Server_API : 集成系统接口调运
CI_Server_API : CI系统集成接口调运
Mate：不同操作的原始数据定义
Auth：接口认证
Parser： 接口参数解析
2.4 架构评价
该设计功能实现上没有问题，扩展性强，便于维护；但是底层单个系统接口的应用太依赖与上层的封装，有待进一步完善。
