小饭店原来只有一个厨师,切菜洗菜备料炒菜全干。后来客人多了,厨房一个厨师忙不过来,又请了个厨师,两个厨师都能炒一样的菜,干一模一样的事,这两个厨师的关系是集群。
为了让厨师专心炒菜,把菜做到极致,又请了个配菜师负责切菜,备菜,备料,厨师专门负责炒菜,配菜师专门负责打下手,厨师和配菜师的关系是分布式.
单一应用架构
当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
垂直应用架构
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的 Web框架(MVC) 是关键。
分布式服务架构(SOA架构)
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
-
上图将服务独立出来,形成服务层,给表现层共享。这样做服务部署更加灵活,哪个服务压力大,就将对应服务加大集群数量。
但是问题也随之而来,这个时候表现层和服务层不再是在同一台服务器上,而是在不同服务器上,怎么实现他们之间的远程调用呢?
我们可以选择dubbo、dubbox、GRPC等远程调用框架,这些框架都是对RPC协议的封装。
节点角色说明:
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。解决调用混乱
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明:
0. 服务容器负责启动,加载,运行服务提供者。
1. 服务提供者在启动时,向注册中心注册自己提供的服务。
2. 服务消费者在启动时,向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连 接推送变更数据给消费者。
4. 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调 用,如果调用失败,再选另一台调用。
5. 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次 统计数据到监控中心。
Dubbox扩展特性
1:支持REST风格远程调用(HTTP + JSON/XML);
2:支持基于Kryo和FST的Java高效序列化实现;
3:支持基于Jackson的JSON序列化;
4:支持基于嵌入式Tomcat的HTTP remoting体系;
5:升级Spring至3.x;
6:升级ZooKeeper客户端;
7:支持完全基于Java代码的Dubbo配置;