分布式架构演进

分布式架构的演进(从上至下)

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。

缺点：

​ 1、性能扩展比较难

​ 2、协同开发问题

​ 3、不利于升级维护

所有应用都在同一个服务器中！ ORM {书城：jsp+servlet+tomcat [dao service servlet]} ORM：对象关系映射！Spring+SpringMVC+Mybatis！

mybatis–{半自动的ORM框架！ 封装的JDBC}

hibernate–{全自动的ORM框架}

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。

缺点： 公用模块无法重复利用，开发性的浪费

将应用拆分成几个不相干的应用独立部署 MVC

springMVC,struts2,jfinal（国内的）:这三个全是控制层框架

@RequestMapping("findAll")
public String findAll {

    return "list";
}

@RequestMapping("list.html")
public String list {

    return "list";
}

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

将各个应用通过分层独立出来，可以利用rpc实现web与service、service与service的互相调用，提高了代码的复用性。

缺点： 每个调用的模块要存储一份完整的被调用模块的位置和状态，一旦位置和状态发生变化，就要更新所有涉及的配置。

服务相对独立，我们通过RPC即可调用！！！

流动计算架构（面向服务的分布式架构）

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

随着架构不断增大，服务节点也越来越多，服务之间的调用和依赖关系也越来越复杂，需要有一个统一的中心来调度、路由、管理所有的服务，基于这个中心构建的这个星型架构就是现在目前最主流的SOA分布式架构。

目前的电商项目，如：淘宝、天猫、京东等都是SOA分布式架构

我们对于SOA项目的架构有如下几种方案：

SOA {服务的调用中心 – 注册中心！}

1. ssm + dubbo！

2. spring boot + dubbo+zookeeper（注册中心，Dubbo官网推荐）！

   dubbo！ 可以服务的调用中心！

3. spring boot + spring cloud + nacos！

   由于SpringCloud把Eureka停止更新了，所以我们使用nacos替换，它的功能性非常强，可以去官网查看