概述
随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。互联网系统架构也因此也不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构等，还有在Google带领下来势汹涌的Service Mesh。
作为一名合格的架构师，有必要对架构的前世今生足够了解，这样方能把握现在，预见未来。下面一起看一看互联网系统架构演变的历程。
单体系统架构
这是最传统最原始的站点系统架构，互联网开启之初常用的架构。单体系统一般功能与流量都很小，只需一个应用，将所有功能都集中在一个系统中，并部署在一台服务器上，以减少部署节点和成本。例如，将用户模块、问答模块、考试模块等都做在一个系统中，以一个应用的形式部署在一台服务器上。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
单体系统架构
集群架构
当站点流量增加而一台主机已无法应对其访问量时，可通过搭建集群增加主机的方式提升系统的性能。这种方式称为水平扩展。
集群架构
分布式架构
当站点访问量逐渐增大，集群架构的水平扩展所带来的效率提升越来越小。此时可以将项目拆分成多个功能相对独立的子系统以提升效率。例如用户系统、问答系统、考试系统等。这种称为垂直扩展。此时，用于加速前端页面开发的Web框架(MVC)是关键。
分布式架构
微服务架构
当子系统越来越多时， 发现它们可能同时都拥有某功能相同或相似的模块，于是将这些在整个项目中冗余的功能模块抽取出来作为独立的系统，这些系统就是专门为那些调用它们的系统服务的。那么这些抽取出的功能就称为微服务，微服务应用称为服务提供者，而调用微服务的应用就称为服务消费者。这样的系统架构就是微服务架构。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
微服务架构
流动计算架构
随着功能的扩张，微服务就需要越来越多；随着 PV 的增长，消费者系统就需要越来越多；随着消费者的扩张，为其提供服务的提供者服务器就需要越来越多，且每种提供者都要求创建为集群。这样的话，消费者对于提供者的访问就不能再采用直连方式进行了，此时就需要服务注册中心了。提供者将服务注册到注册中心，而消费者通过注册中心进行消费，消费者无需再与提供者绑定了。提供者的宕机，对消费者不会产生直接的影响。
随着服务的增多，在一些特殊时段（例如双 11）就会出现服务资源浪费的问题：有些服务的 QPS 很低，但其还占用着很多系统资源，而有些QPS很高，已经出现了资源紧张，用户体验骤降的情况。此时就需要服务治理中心了。让一些不重要的服务暂时性降级，或为其分配较低的权重等，对整个系统资源进行统一调配。
于是便产生了流动计算架构，它是一种高可用、高性能、可伸缩的分布式微服务架构。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
这里的资源调配分为两种：预调配与实时调配。
预调配是根据系统架构师的“系统容量预估”所进行的调配，是一种经验，是一种预处理，就像每年双 11 期间的 PV 与 UV 都会很高，就需要提前对各服务性能进行调配。
实时调配指的是根据服务监控中心所提供的基于访问压力的实时系统容量评估数据，对各服务性能进行实时调配的方案。
流动计算架构
总结
架构并不是一成不变的，随着业务和技术的发展，不同的需求会催生不同的架构，不同的架构使用不同的业务场景。架构没有最好，重要的是合适业务需求，符合使用的场景就好。