大型系统建设的一点经验

    进入公司，到今天，也已过去了两个春夏秋冬。匆匆过去的两年，在公司里参与的，比较自豪的项目也就是彩铃管理平台的建设了。在这里总结一下，对这个项目的一点粗浅的经验。    

    这个项目主要是要管理一个省级的彩铃系统，整合既有的华为中兴的彩铃系统，做一个门户的整合。对外主要包括，个人用户门户、系统管理员门户、SP门户、集团门户，其中个人门户还包含短信门户和IVR门户。        

     因为是一个省级项目，所以项目还算是比较大的，彩铃用户数在初期预估为 150w左右。在系统上线后，随着业务的宣传、推广，系统容量不断扩充，直到现在的近250w。在这里要说的是，虽然系统上线时，虽然客户对系统预定用户数不多，但考虑到后期系统扩容的可能性，我们是需要对将系统做成强可扩展性的。这就需要我们在系统建设初期就了解硬件系统、软件系统的各类限制，举例来说就是，硬件的如：E1数；软件的如：TTS并发线数、操作系统最大线程数、文件链接最大数、文件打开的最大数等。    

    举项目的真实案例来说。系统对铃音目录结构的安排如下

    第二级corp目录表示集团彩铃，一个集团创建一个目录来存放集团的彩铃。在系统不断扩容过程中，发现这种策略不能适应不断增加的集团数。在linux操作系统下，一个文件的链接数是有限制的，在目录下每增加一个目录都会将这个目录文件的链接数加一，这样当集团数到达文件链接数上限时，目录下就再也创建不了任何目录了。当在链接数到达最大限度的文件夹下创建文件夹时，linux操作系统会提示“过多的连接数”（too many links）。参看

    看了上图，才幡然悔悟，当时华为的铃音为什么要那样组织。看了上图的说明，也才知道，最初系统设计成为这个结构目录，也就是有欠考虑的了。

    这里顺便记录一下一段经典问答：

 

   除此之外，大型系统中日志的打印、结果正确性验证的策略、动态开关的机制、系统升级、版本回退等都有待讨论，待有时间慢慢写来。