从用户功能开始构架系统框架

本文讨论一下从用户功能开始做系统构架的细节问题。

我在前面有一篇博客讨论了如何在开源项目上制造真空,有人在下面说,这得这个项目牛逼才行。我们这里就来讨论一下怎么样才能让“项目牛逼”。

一个软件项目怎么样才会牛逼?良好的架构?优秀的算法?优雅的代码组织?不是的,一个软件项目牛逼是因为它有用,并且把它的竞争对手都逼死了,它就牛逼了。

所以,研究一个项目是否有前途,第一研究它是否必须的,第二研究它如何保证它相对别人的优势。这是要守(关于“守”的概念,参考这里)的第一级要素。比如用OpenSSL加密数据,用Libz压缩数据,这是个刚性要求,你做了一个这样的库,它就具有生存的基础。但实现一个优雅的,计算把《道德经》进行SHA-1加密的库,无论做成什么样子,它都不会牛逼起来。

在架构设计上,保证竞争力,很大程度上是对资源进行控制。

其实,不但开源项目需要制造真空,所有的架构设计都是在制造真空。作为架构师,你经常需要体验那种从一两个人开始项目,然后慢慢扩展到几十到上百人的规模的经验。我的体会是,你觉得你一开始有满满的自由度,然后你就要面对激烈的冲刷。人力规模一上来,你代码都看不过来,你前期的所有准备,都是怎么防住这些冲击。如果你没有很好的控制逻辑,这些快速增加的代码量,会很轻松冲跨你当初简单的设计,让你的理想落空。而缺乏控制的洪水,是形成不了力量的,这样的项目就不会牛逼。

所以,当你只有一两个人的时候,你要花所有的精力来构筑水道,保证洪水进来的时候你能够控制这些资源都转化为你的竞争力。

我们还是拿前面这个OpenSSL和Libz为例,假设你要给这样的库做一个加速器的框架,你首先控制什么?

显然不是你的硬件做成什么样子,那个不是你这个框架生存的原因,你的框架生存的原因是能让libz和OpenSSL跑得更快(由于这两个东西的概念可以互相借用,后面暂时先用比较简单的libz来推演),不是因为你有一个加速器硬件。

所以,控制这个框架应该做成什么样子,守的是libz这个库的使用模式,然后才是你硬件的限制。所以,你的接口最优雅的方式应该是这样的:

acce_compress(algorithm, input_buffer, output_buffer)

但这样从libz库来说就不好用,因为压缩算法就有很多种,而且每个算法有参数,更合适的做法是这样的:

init_algorithm(algorithm, parameter);
acce_comparess(algorigthm, input_buffer, output_buffer);

很多人上来就开始考虑设备管理,考虑打开设备。但这些是错误的方向,设备管理是你硬件本身的事情,不是我libz引入的事情,我可没有要求你有“设备”啊,我只是要压缩,你设备打不打开关我鸟事?

我们从libz这个角度守,就能尽量降低我们自行引入的,破坏最优竞争力的要素,这样我们才不会被后续增加的复杂度所有了方向。所有破坏最优竞争力的要素,就必须有合理的理由,并且保证其他对手找不到更好的手段来超越我。

我们下面来推演一下几个不得不引入的几个破坏性要素:

1. 设备数量限制:如果通过加速器加速,加速设备不足怎么办?

2. 数据传递成本:把数据送入硬件,再从硬件中送出来如何处理

3. 系统调用成本

4. 硬件升级引起的绑定问题

(太晚了,存个盘,明天接着写)

软件架构设计稿源:软件架构设计 (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 后端存储 » 从用户功能开始构架系统框架

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录