问如何在快速变化的业务需求中，设计一个既能满足当前需求又具有良好扩展性的系统架构？

花点时间找一个合适的开源框架，高内聚，松耦合。

微服务就是一个典型的例子，很灵活，但复杂度也相当高。但不管怎样，选一个流行的框架开干就行。流行的框架之所以流行，那就是选的人多。

架构肯定需要分层，各司其职。这就像OSI七层结构一样，每一层都有自己关注的重点和要解决的问题，这样不仅能保证业务稳定，出了问题也好排查。对于一个长期运行的复杂业务来说，最重要的不是写代码，而是后期代码迭代，以及线上问题的排查。

过度设计就是一家小公司非要追逐大公司、大神、大牛分享的技术架构，而自己的业务量永远也跑不到他们的万分之一。适合的就是最好的，现在的开源框架都已经足够好，等真的遇到业务瓶颈了，公司有钱了，代码完全重写也没有任何问题。很多大公司的系统也不知道是重写了多少遍的。

确保系统的稳定性和业务快速增长、技术演进是相悖的，不同阶段有不同的架构抉择，当你只有10块钱的时候，尽量不要做1000块钱的决策。没有技术债务的团队一般公司都比较新 :)

我们首先还是要定义好，何为满足需求，何为良好扩展性。

你可能听过一句话，好的架构是演化出来的，而不是设计出来的。

业务本身在快速变化，预测需求已经很难了，如果对良好扩展性的期望是一劳永逸，基本不可能。 大概十年前的时候，我们的业务也经历了一轮指数级的增长，其中的架构演化与经验也在全球开发者大会上专门分享过

http://2015.qconbeijing.com/presentation/2604/ 其实经历过的都知道，一般这种时候，你的研发人力也是很不够的，团队需要扩张，人员需要培养。 我的第一个建议是，如何检验是否满足当前需求，那就看是否能承载3-5倍需求，性能上往前看3-5倍。

为什么不是更多？ 因为一个架构倍设计出来的时候，能被称为合适，就是它能够满足当前需求且能够保持一定的扩展性。这个一定，在经验里看就是10倍。即当你的业务量增加10倍（一个数量级之后），你大概率就要考虑重新设计。

因为业务变化都不会是理想的线性增长，在量变的同时，也会偏移，比如本来人少的时候大家都在小圈子里交流，人多之后，大家忽然习惯在广场上交流了，广播反而成了系统的瓶颈。

你设计能够容纳10倍业务需求的系统，抵不住一个变化出来的新需求，意味这个新需求的变化可能是100倍。

为了能够撑住突如其来的广播需求，你可能整个系统都面临重构。这个维持当前业务，又往新架构迁移的过程，这也是演化的意思。 更早在微博的时候，分享过单元化架构的设计，也是因为业务需求变化带来的新设计

https://cloud.tencent.com/developer/article/1619433

但我们当然也不是只能被动应对，所以我的第二个建议是，尽早服务化，分而治之。

通过服务化，我们可以服务级别的复用上打好基础，又不至于在服务优化上过度准备。

相当于为未来服务的扩展留好了积木，如果需求变化，那就重新搭建，如果某个服务变成瓶颈，那就独立优化，不影响其他部分。

而分治是最根本的策略，可以让我们在演化的过程中，将大问题转化为小问题，将整体问题转化为单一服务问题，解决起来就容易得多了。

以上，希望能够有所帮助。