数据中心性能指标采集及汇总需求开发经验

在这次开发中吸取到的最重要的经验就是 关于软件架构的设计，及面向对象的思想。

在最开始的设计中，我将数据中心的存储，CPU，内存的使用率当作对象去设计，而没有考虑到他们本身是数据中心的属性，而我最终要汇总分析的是各个数据中心的所有属性，而不是将每一个属性进行单独的计算。所以在代码进行到一半时，就是开始变得庞杂并且缺乏条理性和逻辑性，感谢我的同事提醒了我，否则代码很快将会彻底崩坏，继续开发和维护的可能性极低。

在同事的帮助下，重新进行梳理，我最终需要写入到表中的内容是数据中心的各种指标的平均及总量，而这些指标应该是做为数据中心的属性存在的，所以最顶级的对象应该是数据中心，而数据中心并不直接管理存储，与数据中心想关联的是数据中心底下各个资源池，而在资源池就可以管理存储，CPU，内存性能资源。所以以存储为例，存储性能的采集应该分为三层结构：

数据中心 - 资源池 - 存储

存储层将各个存储的具体指标数据汇聚到资源池中，而资源池层将各种池中的数据汇总返回给相应的数据中心，在数据中心层，汇聚出各个数据中心的具体指标，将结果放入数据中心对象的List中返回。这样的分层结构简洁清晰，后期进行时，日，周，月的数据汇总和CPU，内存的指标开发都是简单可靠。

那么，我的设计失败在什么地方。

首先，我在设计之初，并没有考虑到向数据中心进行汇总的需求，我一开始以为只是拼接出查询SQL和写入SQL，然后JDBC执行就可以了。这应该说是软件工程方面的经验和见识太过浅薄。

其次，单纯地考虑这个以存储为对象的设计，在这个对象中，我定义好了利用率属性，也就是说，最后写入到数据库中的是存储对象的属性，那么，又如何保证写入的是相应数据中心的存储呢，如何在存储对象中添加数据中心属性，那也就是将数据中心-资源池-存储是三层映射关系改为了数据中心-存储的简单映射关系，这样的设计，代码难度和可靠性都不尽如人意。我真的怀疑，靠我那样写法，我可能连一个需求都无法开发完成。

总结，从本次开发任务中学到的经验：

第一，在进行面向对象的软件设计时，首先应该思考这次开发需要实现的功能有哪些，为了实现这些功能应当怎样去设计所需要的对象(我认为这是最重要也是最难的一点，虽然表面是只是一个积累和思考的过程，但是要随时保持一个大局观)。洞悉所有需要用到的对象和属性，并理清他们之间的关系，每一个对象应该有什么样的属性，而每一个对象又实现了怎样的功能，最后，这些对象如何有机地结合起来完成所要的需求。这需要不断地练习，思考，进步。

第二，是关于数据库设计的。在本次需求中，有很重要的一点就是汇聚的时间控制，当所采集指标的时间跨度拉长到周和月时，如何保证每个属性的每个指标在相应的跨度中只存在一条记录。这个如果单纯用代码实现，会很复杂，而负责数据库的同事用一张time_map表解决了这个问题。每个跨度在该表中有唯一id，根据当前时间查找该id，然后去记录存储表中的aggregation_time字段寻找该id，有则更新，无则插入。这样一个精巧的数据库设计解决了很多代码上的问题，这实在让我喜欢，并且意识到，在软件领域，我的路还有很长，相应的，我能看到的风景同样很多很美。