系统架构演变

1.1系统架构的演变****

2008年以后，国内互联网行业飞速发展，我们对软件系统的需求已经不再是过去”能用就行”这种很low的档次了，像抢红包、双十一这样的活动不断逼迫我们去突破软件系统的性能上限，传统的IT企业”能用就行”的开发思想已经不能满足互联网高并发、大流量的性能要求。系统架构走向分布式已经是服务器开发领域解决该问题唯一的出路，然而分布式系统由于天生的复杂度，并不像开发单体应用一样把框架一堆就能搞定，因此各大互联网公司都在投入技术力量研发自己的基础设施。这里面比较有名的如阿里的开源项目dubbo, Netflix开发的一系列服务框架。

*1.1.2 单体架构*

单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式。

存在的问题：

1. 代码耦合：模块的边界模糊、依赖关系不清晰，整个项目非常复杂，每次修改代码都心惊胆战
2. 迭代困难：每次功能的变更或bug的修复都会导致重新部署整个应用，随着代码的增多，构建、测试和部署的时间也会增加
3. 扩展受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩
4. 技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多不坏不修
5. 阻碍创新：单体应用往往使用统一的技术平台或方案解决所有的问题，要想引入新技术平台会非常困难

*1.1.3 分布式架构*

分布式：需要按照功能点把系统拆分，拆分成独立的功能，单独为某一个节点添加服务器，需要系统之间配合才能完成整个业务逻辑。

分布式架构优点：

1. 不同的团队负责不同的子项目
2. 可以灵活的进行分布式部署
3. 可以为某一模块单独加集群

分布式架构缺点：

1. 模块之间有一些通用的业务逻辑无法共用。

*1.1.4 soa架构*

SOA：Service Oriented Architecture（面向服务的架构）。也就是把工程拆分成服务层，表现层两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现，使用ESB（Enterparise Servce Bus企业服务总线，代表技术：Mule、WSO2）提供表现层和服务层之间的交互。

存在的问题：

1. 不支持集群、臃肿

1.2 dubbox框架****

1.2.1 dubbox简介****

Dubbo(读音[ˈdʌbəʊ])是阿里巴巴公司开源的一个基于Java的高性能RPC（Remote Procedure Call）框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。后期阿里巴巴停止了该项目的维护，于是当当网在这之上推出了自己的Dubbox。

1.2.2 dubboX架构

节点角色说明：

Provider: 暴露服务的服务提供方。

Container: 服务运行容器。

Registry: 服务注册与发现的注册中心。

Consumer: 调用远程服务的服务消费方。

Monitor: 统计服务的调用次调和调用时间的监控中心。

调用关系说明：

1. 服务容器负责启动，加载，运行服务提供者。

2. 服务提供者在启动时，向注册中心注册自己提供的服务。

3. 服务消费者在启动时，向注册中心订阅自己所需的服务。

4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。