Sslvpn 三期总结
一 预研阶段
缺点
1) 对于可实现性的实验做得非常的不充分;
多连接、带宽有限、上下限不一致、优先级不相同等因素没有全面考虑和实验证明,导致后来的实现和预想的不是完全一致,尤其是优先级这一块。
2) 对于流量控制的原理没有更加深入的了解。
在预研期间,这方面我一直重视的不够,我一直认为只要我配置下规则,就一切 ok 了。由于没有对流控原理有个深入的理解,有一个问题在设计和实现的时候才暴漏出来。
如果用户没有关联流控规则,如果不给它指定一个默认流控规则,它会走一个现有的流控规则,导致默认流控规则的用户跟有流控规则的用户流控均等的问题。在预研和需求阶段,我一直认为如果用户不关联流控规则,它的流控会走 fifo 队列。其实这是错误的。一个接口只能配置一个流控队列类型。不可能既是 htb qdisc 又是 fifo qdisc 。
3) 对于性能的考虑不够全面。关于流控规则的下发对性能的影响,没有一个量化的考虑。这个实验不能在我的开发机上做,要在公共机上做;结果我在我的开发机上做,没有太大的意义。
优点
1) 比较及时的验证了该方案的可行性
二需求阶段
缺点
1) 需求最核心的地方是数据对象,包括数据的属性,方法,对外的通信接口和互斥等等。
要建立以对象为中心,面向对象的方式做需求分析,写需求。
2) 需求写的很不细致,很多异常情况没有考虑到。
例如
第三方同步用户时,要关联流控策略
生成用户证书时,添加用户
Tc filter 的优先级不能配置为 0
流控规则的下限不能为 0
用户和用户组的属性的改变的各种情况
等等。
3) 写需求同时要考虑实现的架构,并进行评审。
这个地方我认为是这期工作最大失误。因为没有考虑要实现的架构,直接导致设计的全面更改。以后在需求编写和评审时,一定要想好实现的架构,并跟需求一起评审,非常重要。
4)
三设计阶段
缺点
1) 设计写的过于粗略,异常考虑的太少。
设计文档要写到各个异常的分支有明确的处理过程。
2) 设计的耦合度太高,依赖性太强。
第一轮的设计 sslvpn 跟流控功能耦合度太高,不适合软件设计的可维护、可扩展的原则。
3) 对于模块间通信采用的方式不够明确,一定要明确。
对于配置管理来说,到底采用异步还是同步的方式操作,一直没有明确,导致后来工作的反复。虽然不同人有不同的意见,我应该尽早请求仲裁,来确定最终的实现方案。
4) 对于不同步的情况,考虑的不够周到,引入了一些 bug 。
为了避免配置的阻塞, tcuser 采用异步操作,结果跟数据库不同步,引入了一些 bug ,这些都是考虑不够周全的地方,因此,以后出现异步的情况,不根据操作来进行分析。要根据对象来进行分析,判断哪些对象会出现哪些不同步,该如何处理。
5) 无论是内核的设计还是应用层的设计,都要考虑到互斥。
四编码自测阶段
缺点
1) 对于预研时候写的代码不能直接拿来用,要根据设计走查,看看是不是符合设计要求。
内核崩溃的 bug 可能就是因为我在内核的消息接收端没有设置互斥锁引起的。这段代码是预研时候写好的,以后就再也没有怎么关注它。
2) 重用代码一定要做到尽可能的紧凑。
要对代码进行聚合,将重用的代码进行单独的封装。
3) 复制粘贴的代码一定要走查一下,看看是不是做了相应的修改。上期出现了这个问题,没有想到这期我又出现了。
4) 对那些异常流程。在自测阶段就要想方法去覆盖到,不能把它遗留到测试阶段。