问题背景：
系统的模块划分为平台和业务，分别由平台组和业务组各自维护各自的代码。
typedef struct plat_container
{
int a1; /*平台用*/
int a2; /*平台用*/
....
int *p_an; /*平台用*/
int serv11; /*业务1用*/
int serv12； /*业务1用*/
.....
int servn; /*业务n 用*/
}plat_container_s;
如上所述，大量的业务数据引入导致该数据结构非常庞大。上面是举例，实际上肯定更复杂，还有指针及并发保护机制。
如下缺点：
1、数据结构庞大，可维护性差
2、大量的业务可能会通过这个数据结构和平台产生耦合。
这种大量的业务数据往里塞,就像我们吃火锅时不断往锅里加料一样,于是我笑称这种数据结构就是"火锅模式".
此种数据结构可能很多人已经习惯了，都是这么写的，不怕笑话，我现在项目组正是这么做的，所以我想先自行做个实验优化这种数据结构，
降低这种业务和平台的耦合度。
我的想法如下：
typedef struct plat_container
{
int a1; /*平台用*/
int a2; /*平台用*/
....
int *p_an; /*平台用*/
struct list serv_list; /*业务链，业务可以动态扩展，当然也可以考虑用指定长度的数组，比如最多支持1024个业务特性*/
}plat_container_s;
平台提供业务注册接口，业务初始化时，调用该接口平台为业务分配空间，然后把内存地址返回给业务。平台把该业务节点挂在平台锁维护的
业务链表中。业务得到平台分配的内存空间后，爱存放什么数据随业务怎么放。业务数据完全对平台透明。平台也看不到业务的数据结构。
这是我的想法，我很少看到有人这么做的。所以发出来和大家讨论下，如果您有更好的实现则欢迎指教。
