典型互联网应用

大型互联网应用系统的建设不是一蹴而就的，是在不停的解决问题中，不断成长起来的，而其中的核心是业务的持续增长，从一棵小树苗茁壮成长为一可参天大树。

初次茅庐

这时的问题是如何快速的实现核心的业务，因而一款好用的开发框架是关键，同时机器也可以尽量简单。

崭露头角

随着喜欢我们的应用的用户逐渐多起来，已经有不少用户反馈，应用越来越慢。

这个时候，一般我们通过先将应用服务器、文件服务器和数据库服务，分离开来，独自占用完整的服务器资源，此时文件服务器也可以使用第三方服务，为了使应用高可用，一般将应用服务做至少两个服务器，做一个集群，同时我们要引入分布式缓存服务，一是用作session的存储，二是缓存热点数据，缓解数据库的读压力，数据库也可以做主备模式。

这种模式，在未来的一段时间内，都可以通过增加应用服务器来扩展系统的整体性能。

青云直上

业务进一步扩大，通过扩展应用服务的数量已经无法有效提升系统的处理能力。

此时的瓶颈通常出在现数据库，单台的数据库读写的性能都总是有极限的，系统可以吞下大量的用户请求，数据库却无法快速的响应这些请求。应对这种情况，可以做读写分离，常见使一主多从，主库负责写入数据，多个从库并行处理读数据，从而缓解数据服务的读压力，但要额外留意数据同步延迟的情况；读写分离只是解决了读取压力，存储压力还是存在的，如果对业务非常有信心，团队技能能力也不错，可以一步到位上分布式数据库，这样即可以缓解访问压力，也可以减轻单台服务的存储压力，但是事务怎又怎么做呢？这又是一个值得探讨的问题了。不管如何，做到这个程度，数据库在未来一段时间内也可以无忧，随着访问压力的增加，也可以同步增加应用服务器来缓解。

纵横四海

到这一步，我们只要有足够的服务资源，就可以一直水平扩展我们的系统，从而提升系统能力。那这一个阶段的瓶颈在哪里呢？应用服务过于臃肿，导致团队协作，发布服务极为不便。这个时候就可以将服务拆分成多个业务服务，拆分后的服务可以使用HTTP，也可以使用DUBBO或者GRPC进行通信。拆分后，团队工作效率可以提升，服务器资源也可以按需合理分配，后续随着拆分的业务进一步细，也可以微服务化。

举个例子：支付宝应用

单体应用

这一阶段的重点是快速实现，瓶颈是单机的性能和容量容易到达上限。

单数据库实例分布式服务

通过水平扩展业务服务来增加系统的容量与性能。

读写分离的DB主从分布式服务

缓解单台数据库访问压力，而随着用户量的进一步增加，主库的写操作也逐步摸到极限。

分库分表分布式服务

通过垂直分库，水平分表的方式，扩展数据库，缓解读写压力，也缓解了存储压力。

单元化分布式服务

可以说绝大多数的应用做到上个步骤，系统的性能与容量已经足够好了，可以支撑万级别的TPS了。但是对于支付宝这样级别的应用来说还会存在问题，这时候再按照典型的应用演化路劲来参照，就显得捉襟见肘了。这种方式的做法，我还没有理解透彻，就不多说了，贴上连接，供大家一观看。



https://mp.weixin.qq.com/s/qW7npuXIESvfAZdYDApArg