不要让基础技术设施成为稳定性瓶颈

昨天星球群里大家聊起了云服务性能测试相关的话题。有同学提出了这两个问题：

1、为什么压测集群和被测服务要保持在同一个网段？

2、为什么网络作为基础技术设施需要保持资源冗余？

看似是两个问题，其实本质上是同一个问题，即测试环境服务部署和网络带宽如何配置。

简单来说，无论是测试环境还是网络带宽，本身都可以视作基础的技术设施建设，所有的研发和测试活动都是基于此展开的。

如果基础技术设施不够稳定或者频繁出问题，则会在很大程度上影响研发活动的开展，以及最终的交付质量。

这篇文章，聊聊基础技术设施相关的话题。

 

先回答本文开头的第一个问题：为什么压测集群和被测服务要保持在同一个网段？

可能会有同学说，实际的用户请求来自于多个网段和IP，测试要模拟真实场景，因此在压测时也要模拟这种多网段和IP的场景。这种想法没错，但在真实测试活动中，更需要考虑系统实际的请求调用逻辑。

诚然真实的用户请求来自于多个不同的网段和IP，但用户请求的入口基本都是固定的，即域名(通过负载均衡将用户请求路由到不同的应用服务)。

简单来说就是：用户请求来自外部，但请求通过网关进来之后，都是在系统内部各个服务之间流转。

对于一个复杂的IT系统来说，内部服务之间的调用频次是很高的。

为了降低内部互相调用(这里也分短链接和长链接，现在大多数微服务架构下的内部请求都是通过RPC协议和相关组件实现)之间的时延，在环境搭建和服务部署时，都会尽可能的将应用服务集群部署在同一个网段或可用区。

当然，有时候为了提高系统可用性和出于容灾方面的考虑，会将同一应用服务集群分批次部署在不同可用区或者机房，这就是另外一个范畴了，此处暂且不表。

基于上述原因，在开展日常的测试活动时，应尽量将测试服务(或者压测集群)和被测服务部署在同一网段。

 

再聊聊第二个问题：为什么网络作为基础技术设施需要保持资源冗余？

以盖房子为例，都是先设计定义好各项指标和图纸，然后才是施工。根据对房屋设计的高度和使用建筑材料的不同，房屋地基的宽度和深度也会不同。在地基之上，才是墙壁门窗和各种软装硬装。

切换到IT系统建设视角，网络带宽、服务配置、环境搭建就可以视其为地基。而业务运营的载体，即各种前后端应用服务则是在基础技术设施之上的墙壁门窗，高性能高可用和良好的用户体验则是精装修。

建筑物在设计时都会保留一定的冗余空间，即设计阶段定义的指标需要超过实际使用所需。比如一座学校所在区域可能发生的地震强度为8度，则学校设计和建设的抗震能力需要在8度以上(比如9度)。

同理，切换到IT系统视角，作为基础技术设施的网络带宽、服务配置和环境稳定性，也需要大于业务稳定性的要求。只有保留一定的冗余空间，才能更好的为业务运营和商业目标达成提供支撑。

 

以电商双十一大促为例，聊聊我们日常工作中经常涉及的一些技术实践。

假设预估的网关总QPS为10W，则整个网关集群的处理能力一定要大于这个值，且要在此基础上有一定的冗余空间。

确定入口QPS的技术指标后，接着就是按照业务场景、调用链路，对涉及到的各个技术组件进行容量评估工作(即为了满足预期技术指标，最少需要多少服务资源)。然后才是各项技术改造、性能测试优化和监控告警。

现在很多企业的服务都部署在云服务上，类似网络带宽等资源都支持弹性伸缩容。而服务器硬件配置很难临时升配置，只能横向扩容。特别是数据库这种存储组件，想要升配扩容，最好的办法就是提前操作。

问题来了，升配置升到多少，扩容扩多少，都需要通过性能测试验证和不断优化，才能得到一个明确的数值。

最后才是线上的容量规划，以及服务治理和成本治理。

 

最后回到本文标题，基础技术设施对研发活动开展和交付质量的影响是巨大的，因此基础技术设施也需要长期持续的投入建设和不断迭代，这也是为什么很多技术团队到了中后期，会开展系统重构和各种技术治理的原因。