一转眼，入职X公司半年多了，工作上基本可以自己独立负责一部分业务。细细回想感悟，觉得互联网和传统公司确实有一些明显的区别... ...
最大的区别在于业务功能的快速迭代开发，大部分的需求都属于新功能，往往是产品经理说个需求，就让开发着手做，大部分是没有完整像样的需求文档，即便有需求文档也基本是不完善，不可行的，基本上都是边开发边改需求，甚至开发之前都没有做详细的方案设计。以前在一家业务比较成熟的企业，有时候需求也很多，但基本上每个需求都很明确，方案也是明确的。
上线流程也并不很好，基本上没有代码review环节，主要是需求多，业务体系复杂，人手相对较缺，基本上是每人负责一部分，其他人可能不是非常熟悉除了自己这块以外的业务，从业务角度来说，不具备审核代码的能力。
说说最近遇见的问题吧，业务高峰期，造成服务器瘫痪，略有收获，对于服务器来说，应该保证不对数据库和缓存（简称数据层）造成灾难性压力，即数据库连接池和缓存连接池的设置，即便是峰值，也要保证不把数据层服务器压垮，这样就能保证峰值之后，会自动恢复。调整连接池的参数是一个很重要的工作之一，连接池参数取决于服务器并发数量，集群实例个数，数据层服务器性能等有关！在数据层一定的条件下，web服务器集群并不是越多越好，总有一个最大并发承受量和集群最优数目。
高并发情况下，任何一个小的逻辑优化，都有可能对系统性能有比较大影响，甚至是一行日志。
另外，一件比较困难的事情是线上高并发情况下问题的查找，对此，只能找出其中一台机器，插入一些查找问题的代码。对于新功能上线，最好的选择当然是灰度发布，尽量在即使出问题的情况下，也只是影响少部分用户，这样的话，可以在负载均衡上做一些设置，如根据地区IP 不同的地区走到不同的机器，这样也便于观察。
高并发调优：涉及的调优参数 服务并发数目、线程池数目、实例数目；
QPS=并发数*(单位时间/单个请求耗时) 有时候，提高并发数，会使得单个请求耗时增加，反而使得并发数降低；
另外线程池的数目也并不是越大越好，合适最好！比如web服务器并发数目是50，那么就没必要设置线程池为1000；根据经验，设置成100左右即可
当然，最重要的一点还是尽量保证项目结构的合理，必要时，进行重构！