之前弄过一个门户系统，其最初每天只有几百个用户会访问使用，后来在公司业务各种推广后，这个门户系统在最高峰的时候，每秒并发1000，
而在这期间，进行了许多分析和优化，作以此文记录。
本文将从代码层面，硬件层面进行分析
代码层面：
许多业务系统性能不够，其在代码层面其实有很大的优化空间。
例如一个对常用业务进行分析，很多时候，我们开发这个功能的时候，并没有考虑到其性能，尤其是在当初功能急着上线的时候，这类只实现功能，却性能比较差的模块，到处都是，面对庞大的功能模块，我们如何定位是哪里消耗时间最多？
这个时候，我们可以用最古老的方式，打印时间，通过对常用业务流程，进行记录进入代码的时间，和离开此段代码的时间，就可以得出业务执行消耗的时间。一般超过5秒才执行完的业务就要仔细分析，CPU的处理业务能力的很强的，如果一段逻辑需要处理5秒，就得考虑这个模块是否存在优化空间，可以从业务场景去分析，例如如下的场景：
1.此模块频繁对数据库进行IO
分析是否有相关属性值可以预存到内存中，而不用每次都从数据库去获取。
2.是否有些业务并非需要实时
许多业务，只是为了更新数据库做记录，类似场景不需要实时去处理，可以考虑延时处理。即弄个定时器，每次数据过来，先存在缓存，一定时间再存回数据库。
3.代码是否写的性能低下
如果一段简单的功能，当初实现时可能只为了赶时间，可能会写的复杂离谱，可以考虑重新写过，尽量减少多层循环。
4.功能剥离
有些高并发的场景，可能只是一个特殊的场景，如抢红包功能，每天只是某个时候，特别多人前来，可以考虑将这个功能单独抽离出来，这样即便红包出现严重高并发，对原系统都不会什么影响。
5.恶意攻击：
如果一个系统有金钱派送，可能会有许多羊毛党通过一些恶意刷工具，进行攻击套利，这个时候需要考虑能否从业务场景去限制流量，或者对用户进行拉黑处理，终究不能因小失大。
关于代码层还有很多优化空间，前面只是列举了大方向。真正对于系统的优化，还需要具体问题，具体分析。
硬件层面：
如果对于代码层的优化已经达到无能为力的时候，硬件层还是需要扩展，终究你不能在一台小霸王机器上运行windows。
集群的方案在网上已经有相当多了，这里就不说什么，只是提醒各位，在对硬件进行集群升级的时候，原来代码层面还是有许多地方需要考虑更改，例如写在内存的变量和定时任务等等这些。
今天就先更新到这里了。