架构师的经典语录_架构师行话

孙立：如何搭建更加有效的测试环境？测试环境和线上环境毕竟不可能完全一样。

孙朝晖：我想分成两个方面来回应。

• 功能测试环境的建设：功能测试环境主要面对的挑战不是线上、线下系统结构不一致，而是测试数据的不一致，由于数据不一致导致某些边界条件没有测试出来。对于这个问题，需要保持线上、线下关键数据的增量同步，采用小时间粒度的定期日志备份方法解决，同时要保证活跃数据的规模，以便能够控制线下数据库同步的规模。

功能测试环境组建的另外一个要点是关注网络结构的等价性，通过虚拟机系统增加与现网等价的网络拓扑结构。尤其是在交换设备和域名系统上尽可能保持一致，因为有很多问题是由于物理部署结构引起的，从开发的角度很难发现，只有通过一个相对完整的功能测试环境方可发现这一类问题。

• 性能测试环境的建设：性能测试环境的建设主要用于发现性能问题和容量规划。对于发现性能问题的目标，只要保持数据库服务器尽可能使用物理主机，在物理主机上采用多实例隔离的模式部署，其他服务器可采用虚机化技术，这样可以保持测试数据的可用性。

需要解决的主要问题是容量规划这项工作，由于线上与线下服务器的硬件类型和规格不一致，网络拓扑结构也不同，也无法完全模拟线上环境。所以我们一般采用的方法是，对服务器进行角色类型划分，同一种角色的服务器在性能测试环境下必须有统一类型的服务器对应，有对应的确定性物理配置，在性能环境测试后，首先安排预上线测试环境，通过七层交换或者应用程序本身的流量复制，把线上的服务压力导流到预上线环境，进行小规模再测试，得出单机的性能数据与性能测试环境的对比，并根据单机的性能测算对比，做出线上的容量规划。按照容量规划进行系统实施后，根据实际的测试数据再调整，有可能因容量估计过高，服务器能力有冗余，需将服务器标记为空闲，留待后续部署使用。

孙立：要变更数据库结构，有什么经验可以分享？

孙朝晖：这个问题是互联网行业的通用难题，数据量大，数据结构变更的代价太大，对于这个问题，我想从四个方面进行介绍。

• 在技术方案评审阶段，充分考虑数据存储方式的合理性。不是每种数据都适合采用数据库存储，有些数据适合采用JSON，或者采用缓存中的List对象存储，而不适合分解到数据单元，这样的数据就没有必要设计成为关系型结构。

• 在数据结构设计过程中，保留适当的冗余字段，尤其是预估有动态变更的数据结构，而且状态标志尽量组合成为数据位结构，即典型的Mask应用。需要扩充状态位时，采用位扩充。

• 对于数据量很大的数据结构，比如我们业务当中的Feed数据，保持数据按照代龄进行分层，并且有合理的归档结构，保持活跃数据所在库的规模不过度，对于活跃数据库需要紧急调整的时候，变更代价也是可控制的。

• 对于数据量非常大的数据需要调整数据结构，那么只能靠数据库架构解决。我们采用的数据库架构都是M-M-S-S架构，需要进行大规模数据迁移，所以会利用备份库进行轮换下线（或半下线）维护变更，通过轮次的数据结构调整，最终达到数据结构完全变更。

上面的论述也是我在近期思考的方面，特把架构师经验分享保留在自己博客中。