If you have a RAID-0 array then the file system runs on top of this and will effectively just see a single disk. For example an EXT4 file system on top of software or hardware RAID has no idea what disks make up the array and can't make decisions about which disk data should go to.
There are file systems that manage redundancy/RAID themselves, but I'm not aware of any that can be configured to always write whole files to a specific disk.
However as hinted at by @MadHatter, this is a strange requirement and seems like the wrong solution in the first place. I'm not sure what problem you are trying to solve and I'm also wary when people mention RAID-0 as it's more often that not the sign of a beginner or a bad choice. If you specify why you require this functionality maybe we can provide some better suggestions.
The alternative is to do this at the application level, and have your software choose from a list of disks to put each file on. However, this obviously relies on you having the ability to modify whatever is writing the files. In a more robust design the application may write each file to multiple disks, storing location information in a database, thus being capable of retrieving files when requested even if some disks have failed. This is similar to how some large scale cloud file storage systems work.
fileA
is on one disk, reading that one file won't affect the performance when readingfileB
from another disk. In actual implementations I've worked on, each "disk" is a RAID array presented by a storage system. If you're streaming video to a lot of customers, for example, it will significantly reduce contention. AFAIK, the only Linux file system that implements this is IBM's GPFS. On Solaris, you could use QFS/SAMFS.