架构演变
随着互联网的发展，网站应用的规模不断扩大，常规的垂直架构已无法应对。分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
架构演变
1.单一应用架构
当网站流量很小时，只需一个应用，将所有的功能都不是在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架（ORM）是关键。
2.垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的web框架（MVC）是关键。
3.分布式服务架构
当垂直应用越来越多，应用之间的交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键。
4.流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需要增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时用于提高机器利用率的资源调度和治理中心（SOA）是关键。
分布式架构
Dubbo
了解dubbo http://www.iteye.com/magazines/103
Dubbo是一个分布式服务框架，以及SOA治理方案。其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。
dubbo架构
节点角色说明
| 节点 | 角色说明 |
|---|---|
| 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开发者沙龙（北京站）
网友评论