国内存储界现在是百花齐放，非常热闹。软件定义存储，云存储，超融合等各种创新企业也在各自领域快速的发展。关于各方面的概念解释和技术分析很多，但是我感觉关于存储系统的开发方面，实践性的文章非常少。我就据自己多年的存储开发经验，写几条原则，希望能抛砖引玉，让各位开发人员和架构师能进行更广泛的讨论。

1. 重视元数据的冗余安全。很多人说存储的稳定性是第一位的，其实任何人为的系统都是有可能出错的，存储的数据安全性才是第一位的。出错不可避免，宕机不可避免，任何软件都是有bug的，但是一定要避免出错后数据丢失，特别是元数据丢失，要把这个概率降到最低最低。所以，设计元数据方案就像造飞机一样，要有2套以上的独立冗余方案。这个是架构师第一个要考虑的问题。

2. 产品有定位，功能有取舍，要简单突出。存储的稳定性非常关键，复杂的东西很难稳定，除非不计成本。所以，我们首先要清楚产品的定位和市场应用，针对这个定位和市场应用来设计开发，其他的辅助功能一定建立在这个基础之上。如果一个产品开始设计的时候就考虑到了很多功能都要做到最好，那么很有可能主要的架构设计复杂，影响稳定性，最后影响最主要的功能点。所以，研发要对产品部门和销售部门的要求有取舍，并且一定要坚持，这个在设计中非常关键。

3. 抽象，抽象，再抽象。其实这个和上一条的简单原则有关系，抽象了，那么架构就会非常简单。模块之间的耦合度就低，这个其实是软件开发的共性。存储软件的基础架构其实是和协议，和OS，和硬件驱动都是无关的。如果相关了，那么这个架构一定出了问题。

4. 数据驱动，不是功能驱动。这个可以参考linux内核设计，内核负责功能机制，但是用户态负责数据驱动来做出各种应用。应用一定是和数据相关而不是和功能相关的，功能是非常共性的东西，由上层的数据来决定了具体的应用。

5. 我们能碰到的所有的问题都是别人解决过的问题，碰到架构或者其他方面的问题参考现有的linux内核架构，block/scsi中间层，各种协议，看看他们是如何解决的，参考这些业界标准基本不会出错。发明创造是科学家的工作，不是工程师的工作。

6. Debug系统做好了，产品就不会做不好。这个是软件开发的共性，不用多费笔墨。只是存储开发有两个问题debug起来非常难，一个是一致性问题，一个是性能问题。由于它的难度和全局影响性，这两个debug系统最好要由系统架构师亲自设计甚至编写。

7. 适当打补丁，但是最后要勇于承认架构有问题，要勇于重新来过，长痛不如短痛。真正稳定的软件是不会一版成功的。

【编者按】

向程序员致敬!

作者介绍：江松，Storwind创始人，具有超过16年的国内外企业级存储系统研发经验。Storwind专注于软件定义存储，相继研发和发布了LeadIO SSD缓存加速软件，IPSAN/NAS软件，商业级软RAID, 对象存储和云存储网关Cloudstation，获得了众多合作伙伴和客户的高度认可。

本文作者：江松

来源：51CTO