架构演变
随着互联网的发展,网站应用的规模不断扩大,常规的垂直架构已无法应对。分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进。
架构演变
1.单一应用架构
当网站流量很小时,只需一个应用,将所有的功能都不是在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是关键。
2.垂直应用架构
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的web框架(MVC)是关键。
3.分布式服务架构
当垂直应用越来越多,应用之间的交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式服务框架(RPC)是关键。
4.流动计算架构
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需要增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时用于提高机器利用率的资源调度和治理中心(SOA)是关键。
分布式架构Dubbo
了解dubbo http://www.iteye.com/magazines/103
Dubbo是一个分布式服务框架,以及SOA治理方案。其功能主要包括:高性能NIO通讯及多协议集成,服务动态寻址与路由,软负载均衡与容错,依赖分析与降级等。
节点角色说明
节点 | 角色说明 |
---|---|
Provider | 暴露服务的服务提供方 |
Consumer | 调用远程服务的服务消费方 |
Registry | 服务注册与发现的注册中心 |
Monitor | 统计服务的调用次数和调用时间的监控中心 |
Container | 服务运行容器 |
Dubbo VS SpringCloud
- Dubbo,SpringCloud都是优秀的RPC框架,网上有许多对比Dubbo和SpringCloud的文章。在我自己看来SpringCloud提供的功能更加全面,包括了ConfigServer、eureka注册中心、Zuul网关、Feign负载均衡、netflix熔断降级、zpkin分布式链路追踪等,拥有完整的微服务解决方案。而Dubbo更强调服务治理(SOA),提供的功能相对轻量,像网关,链路追踪还需要自己实现,但是上手十分简单,扩展也非常容易,是一个高性能的RPC框架。
- 单纯从RPC的使用姿势来说两者的差距也不小。SpringCloud将每个节点(EurekaClient)视为一个微服务,需要使用Feign指定服务名和调用带有注解的API接口来发起远程调用,用起来相对繁琐。而Dubbo将每个接口视为一个provider,直接将共享的API接口动态生成代理来远程调用和服务暴露,这个过程对用户来说是完全透明的,从这一点来说Dubbo相当清爽。
- 总的来说,如果业务场景较单一、追求简洁轻量和高性能就选Dubbo。
最后晒一张Dubbo开发者沙龙(北京站)的活动合影
Dubbo开发者沙龙(北京站)
网友评论