我现在将谈到项目中涉及到的一个费率设置问题。这个费率指的是电费的设置。如果说，按照我们日常家用的电费一样，全天24小时就一个固定的费率，那么我们这里也就没有必要继续往下说了。
    费率的策略也在反应商业的变化，统一的费率显然无法满足不同的商业策略，比如促销。如果我们要在指定时间段内，进行促销，自然也就是要降价。如果我们要在指定时间内疏通拥挤，那么自然也就是涨价。谁叫我们都是那么轻易被价格支配的动物呢？但是调整价格确实是一项非常实用的策略。
    然而价格的调整，可能变化很快，也就无法通过人工的方式来维持。我们所处的行业就是充电桩行业，也就是生产提供电动车充电的充电桩设备。充电桩将电网的电流转化输入到电动车中，从中收取电费和服务费，达到服务电动车和赚取利润。如果统一采用同样的价格，必然会导致交通便利的地方爆满，交通不是很便利的地方，人烟稀少。还有一些地方，你也无法预测充电的流量如何。在运营充电桩的时候，商家需要根据运营的情况来调节不同地方的电费价格来进行压力调整，从而让整个充电桩网达到平衡，实现利益最大化。
    充电桩上可以进入后台设置电费，充电桩支持很多个时段的电费设置，这样就可以实现不同时段采用不同的价格，用来避开高峰期，确保全天候都能够有车来充电。但是充电站分布广泛，我们不可能一个个的去人工设置不同站点的充电费率。而如果要实时调整不同时段的充电费用，来实现促销分流之类的，不可能还要派人去充电站到各个充电桩设置一下费率。
    所以这就是需要充电桩后台系统的存在了。就是对于一个站点来说，上百台充电桩的费率设置，也是很费力的。那么我就是做这样的一个后台，来与充电桩通信，来远程接管充电桩的工作。而费率设置就是其中一项很关键的功能。
    那么现在要讨论的问题就是，如何来实现费率的设置和相关的技术问题。
    业内对于电费的策略的做法是根据三种状态来分的，分别是高峰期、普通期和低谷期。比如上下班高峰期，车主上班时车会停着充电，下班回家后也会停着充电。普通期是在上班后一段时间和下班前一段时间，白天是人员流动还算多，但不是集中的时间，所以有一些人会充电。而低谷期就是深夜寂静无人的时间了。此时充电的人会偏少。或许我的理解不完全正确，但是大致上是这么几个情况，针对不同的情况，为了能最大化吸引和控制流量，在电费价格上就加入了不同时间的电费。高峰期人多好赚钱，普通期不多也不少，而低谷期大甩卖，能赚多少是多少。所以高峰期价格会偏高，而普通期一般不高不低，而低谷期则很便宜。当然，大部分情况，用户都会选择晚上充电，充满后白天能够支撑很长时间，实在没有办法也会错开高峰期充电。这样可以节省开支嘛。
    那么如何定义高峰期、普通期和低谷期呢？不同的时期也就是24小时内不同的时间段而已，一开始使用的是48个时段，一个时段30分钟，也就是说，商家可以精确定义到30分钟，比如从0:00-0:30就可以定义一个价格。这样可以定义出48中电费哦。而对于一般充电而已，需要的时间也是比较长的，30分钟算是很小的单位了。而不同时期的定义也就是基于这个30分钟的单位划分出的不同的时间段。比如你可以定义11:30-13:30为一个高峰期。你就可以在这个时间段中指定一个价格，就作为高峰期的电费了。一开始的格式就是预先排好24小时，挨个填写费率就行了。你只需要在对应的时间段内（30分钟）填写一个价格。如果连续几个小时内价格一样，那么填写的费率都是一样的。
    这样的费率格式，显得不那么方便了。虽然实现直接，但是在通信的时候数据量大，很笨重。所以后来协议就进化了。采用自定义起始-结束时间段，然后在后面带一个费率。这样我们就可以将一段时间指定一个费率就行。所以一下子将48个费率条目降低到了8个。我们依据的是，早上上班、上午、中午、下午、晚上下班、晚上加班(21点)下班、深夜到凌晨，一共7个时段。所以设计了8个时段，可以满足大部分的需求，多余的一个可以再定制一下。所以8时段的设计基本够用了。但是如果要加上促销时段，那么这个就显然不够了。商户如果要临时多指定一个时段作为促销时间，那么8时段显得够呛。深圳市的标准是12个时段。所以我们的协议后来又升级支持12个时段了。
    而最开始做的48个时段，就作为内部存储的时段，而对外开放设置的是12个时段。所以我们需要在12时段和48时段进行转换，存入数据库是48段，30分钟一段。而取出来时我们得按照12时段进行合并处理。而当我们在界面设置好或者后台设置好了12个时段时，程序就会将12个时段转化为48时段存储。当然，我们此时的时段并不是说将精度降低到了1小时，而是支持自由的时段起止，精度依然是30分钟。12个时段你可以设置为统一的电费，那么就指定0:00-24:00，然后指定一个价格，就可以了。程序内部会自动拆分为48个时段存入数据库。你还可以设置更多的时段数，如0:00-12:00 12:00-24:00。这样就分了两个段，可以为两个段指定不同的价格。但是需要注意的是，必须覆盖24小时，而且多个时段之间不能重叠。
    这一切看似也挺好的。然而之前做好的管理系统，使用的还是48个时段的界面设置费率。而协议是12个时段的。所以在设置完费率之后，要进行48-12段的转换。问题就是，我们协议只有12个段，连续的段是相同的价格，就合并。这样可以把48个段合并形成很少的段。如果48个段全部是一个价格，那么程序就自动将其合并为0:00-24:00.但是这个合并最多只能支持12个段，因为协议只有12段。超出的段就无法传送了。
    所以在做界面设置费率的时候，要么将设置界面改成12时段，自定义时段的起始和结束。要么就要预先检测48个段合并之后有没有超过12个段。如果超出了12个段，必然导致无法覆盖24小时。而我之前接手的web管理后台实现的就是48个时段直接设置费率的。我也没有改，就基于这个来做了转换。这个设置费率不会出现时段重叠的问题，但是如果不同的费率超过12个就产生了无法覆盖24小时的问题。我没有做个检测，不过检测起来也很简单。那就是直接统计48个段电费费率的个数，如果不同的费率超过了就提示设置电费个数（不同的价格）不能超过12个。如果不提示，那就约束为使用方法说明一下就可以了。
    而我另外做的服务器客户端（Windows版），则采用的是自定义的费率设置方式，直接在界面上可以自定义不同的时段，既要检测时段重叠，而且还要检测没覆盖24小时的问题。检测方法很简单，也就是在转为48时段的过程中，如果重复设置了一个时段，那么就有时段重叠，如果最后还有时段没有设置到位，那么就表示没有覆盖24小时。我们预先将要设置的每一个段的值设置为-1，来检测有没有被设置过。如果要设置的时段是-1，就设置。如果设置的时段不是-1，就表示设置过了，那么本次设置就是重复设置，时段重叠。最后设置完后再检测一遍，如果存在-1，就表示24小时没有完全被覆盖。
    所以费率的设置，两种处理方式都各有利弊。不管怎么样，检测都是可以很简单的，只要思路走的好，不要掉坑里了。