在业务高速发展的时候，后端的压力慢慢变大，服务器扩容在所难免。今天就聊聊扩容相关的问题。
首先我们看数据库的扩容，到底是加实例还是直接升配？
在创业初期，基本上都是单库的形式。比如最开始是4C8G的配置，到了某天数据库扛不住了，但是数据量其实没那么大，只是请求量上来了而已，或者由于研发写了很多复杂的Sql导致数据库性能下降了。
数据库加实例
这个时候最快的解决方式就是扩容了，首先我们来看加实例的方式，比如我们可以加N个从节点来提高查询的性能，可以对库进行垂直拆分或者水平拆分。
以上这些都是提高性能的方式，但是都有一个问题就是得改代码，还得测试，时间成本较高。
数据库升配
数据库升配指的是直接升级硬件层面的配置，比如4C8G升级到8C32G，性能直接大幅度提升。好处是应用代码都不用做任何改变，数据库层面直接升级即可。
当然也有需要注意的地方，如果你们是自建数据库的话，得进行数据迁移之类的操作。如果代码中的IP链接数据库的话得看IP会不会变，如果会变还是得改配置，重启应用程序。
如果用的云服务，一般都是用域名进行连接数据库，升配后连接断开也能重连。数据也不用我们操心，只需要在控制台点点按钮即可完成升配，就是有点费钱而已。
云服务升配特别需要注意的是一定要选择凌晨进行升配，在白天升配会有一定的影响。我们之前在白天升配过一次，升配失败，导致数据库无法响应。
服务器加实例
服务器加实例相对于数据库来讲会更简单，我们的后端服务都是无状态的，扩容也只需要有新的服务器，装个环境就可以直接部署了。如果用了Docker之类的容器就更方便了。
数据库加实例程序还得调整，后端服务加实例，不用改动代码。如果是服务层本身就用注册发现的机制，如果是web层，也只需要修改Nginx的配置即可。
所以建议大家在服务器需要扩容的时候尽量直接加机器，不用了也可以撤掉。
服务器升配
如果刚开始你的机器配置很低，比如2C4G这种，我建议你先升配。至少也得搞个4C8G的配置，不然性能太差了。
机器升配跟数据库一样，如果是自建的还好，直接将应用部署到新机器即可。如果是云服务，那么还是得选择凌晨进行升配，不能影响业务。
总结
创业初期，数据库尽量先升配，节约开发时间。数据量大了后在拆分多节点。
服务器配置低先升配，保证所有相同业务的部署机器一样的配置。如果配置不是很低，那么选择扩容节点，对业务没有任何影响，前提是服务需要无状态。
关于作者：尹吉欢，简单的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》作者, 公众号猿天地发起人。
