应用的架构演变（2）
应用的架构演变图
上图描述了从单一应用架构-->垂直应用架构-->分布式服务架构-->流动计算架构，应用的发展演变过程
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架（ORM）是关键
单一应用架构图
适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。
缺点：
- 性能扩展都比较差
- 协同开发问题
- 不利于升级维护
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率，此时，用于加速前端页面开发的Web框架(MVC)是关键。
垂直应用架构图
当一个应用拆分为几个小应用，部署到不同的服务器上，并且每个小应用都是完整的，从页面到业务逻辑到程序和DB，当某一个应该访问量比较大的时候，可以对这个应该多增加几个服务器
通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理性能扩展也更方便，更有针对性
缺点：
- 每个应用的完整性，比如页面的修改都要重新部署，没有做到界面+业务逻辑的实现分离
2.每个应用无法做到完全的独立，比如订单可能要用到用户的信息，每个应用之间有交互的需要
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合分布式服务框架（RPC）是关键
分布式服务架构图
分布式服务架构拆分不同的功能业务，并且不同的功能页面又将界面与业务逻辑分离，业务逻辑和界面是部署到不同服务器，不同的服务器之间的服务调用通过RPC(远程过程调用)调用(同一台服务器是简称件通信)
分布式服务架构带来的问题，是如何进行远程过程调用，以及如何拆分业务提升业务的复用程度，通过RPC(分布式服务框架)可以解决远程过程调用，但其他问题是，随着业务拆分越来越多，可能会有成千上万的服务器在运行不同的服务，会出现资源浪费的情况，是否可以提高资源的利用率，通过访问量来动态分配服务器
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调用和治理中心(SOA)是关键
流动计算架构图
流动计算架构引入调度中心，维护注册中心的所有服务调用关系，实时管理服务集群，根据不同的服务的访问请求量调整服务器数量，并且根据相同服务不同服务器请求的数量调整下次访问哪台服务器处理请求，以此提高集群利用率