用户高速发展阶段如何做好稳定性
围绕做好稳定性可以从几个角度做，而不是简单的监控，压测，告警和容量规划。
第一件事 ：设计方案尽量简单
做好架构很重要的一个原则是，大系统做小，精简设计方案。在众多可能的方案中选择出最实用的哪个。
设计一个方案总是很简单的，但是最好的方案是需要时间证明的。
所以一个合适的方案往往需要经过几轮思考，讨论，推翻，再迭代的过程，谋定而后动有很多好处，一方面可以避免那些华而不实的方案和过度设计，还可以提升效率，达成多方共识，防止知识盲点。
详尽而来的方案看似简单，但也往往是最可靠的。
第二件事 ：拆分服务，大系统做小
我们之前在流量网关那篇文章里面说了一个通用性很强的架构，如下：
在逻辑层的演进历史中，最开始的逻辑层只是一个服务模块，里面囊括了所有提供给客户端的相关接口和API，甚至还有一个pc的web站点。
脑补了这样一个场景之后，相信你已经对其是否可以快速支持业务快速迭代产生了严重的怀疑。
- 每个库或是接口的迭代演进都需要修改对应的硬编码，哪怕是改个参数，修改个接口名称都需要发版，严重影响迭代效率。
- 服务和接口调用错综复杂，出现问题也难以排查，如果在QA阶段出现问题，就有可能影响系统发版上线。
- 系统耦合在一起，随着业务迭代，某一个局部出现问题都有可能造成整个系统的crash，稳定性无法保障。
为解决以上问题首先想到的就是对服务进行拆解，模块分离术也是我认为比较专业的一个方向，在后续的系列文章中我会在务虚务实，宏观微观多个角度进行深入的阐述。
我们可以简单的将服务按照不同业务进行拆分，或是依重要程度不同拆分。比如网关的核心消息收发逻辑，可以拆分为：消息同步，文本消息，语音消息，图片视频文件系统服务。
每个服务可以独立开发，测试，部署上线，经过拆分和演进之后，网关后台对应数百个微服务了。
