软件架构的发展过程以及Apache Dubbo架构
软件架构的发展过程
介绍
软件架构的发展经历了从单体结构（集中式架构）、垂直架构、分布式架构到微服务架构的过程。
集中式架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
特点：
所有的功能集成在一个项目工程中。
所有的功能打一个war包部署到服务器。
应用与数据库分开部署。
通过部署应用集群和数据库集群来提高系统的性能。
缺点：
代码耦合，开发维护困难
无法针对不同模块进行针对性优化
无法水平扩展
单点容错率低，并发能力差
垂直架构
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分。
特点：
以单体结构规模的项目为单位进行垂直划分项目即将一个大项目拆分成一个一个单体结构项目。
项目与项目之间的存在数据冗余，耦合性较大，比如上图中三个项目都存在客户信息。
项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。
优点：
系统拆分实现了流量分担，解决了并发问题
可以针对不同模块进行优化
方便水平扩展，负载均衡，容错率提高
系统间相互独立
缺点：
服务之间相互调用，如果某个服务的端口或者ip地址发生改变，调用的系统得手动改变
搭建集群之后，实现负载均衡比较复杂
分布式架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
优点：
将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率
缺点：
系统间耦合度变高，调用关系错综复杂，难以维护
搭建集群之后，负载均衡比较难实现
集中式架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
流动计算架构：在分布式计算架构下，添加了监控中心与调度中心。
什么是SOA？
SOA全称为Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。
通过上面的描述可以发现SOA有如下几个特点：分布式、可重用、扩展灵活、松耦合。
原来的单体工程项目大多分为三层：表现层(Controller)、业务层(Service)、持久层(Dao)，要改为SOA架构，其实就是将业务层提取为服务并且独立部署即可，表现层通过网络和业务层进行通信，如下图：
下图以电商系统举例来说明SOA架构：
Apache Dubbo（一）介绍
Apache Dubbo是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源Java RPC框架，可以和Spring框架无缝集成。【RPC 表示远程调用的意思】
阿里-->当当dubbox--->阿里--->Apache
借助Dubbo可以实现基于SOA架构的软件设计。
官网：
Apache Dubbo（二）服务注册中心Zookeeper
介绍
-
Zookeeper 是 Apache Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 。
-
为了便于理解Zookeeper的树型目录服务，我们先来看一下我们电脑的文件系统(也是一个树型目录结构)：
-
我的电脑可以分为多个盘符（例如C、D、E等），每个盘符下可以创建多个目录，每个目录下面可以创建文件，也可以创建子目录，最终构成了一个树型结构。通过这种树型结构的目录，我们可以将文件分门别类的进行存放，方便我们后期查找。而且磁盘上的每个文件都有一个唯一的访问路径，例如：C:\Windows\zhangxf\hello.txt。
-
Zookeeper树型目录服务：
-
流程说明：
-
服务提供者(Provider)启动时:
向
/dubbo/com.foo.BarService/providers目录下写入自己的 URL 地址 -
服务消费者(Consumer)启动时:
订阅
/dubbo/com.foo.BarService/providers目录下的提供者 URL 地址。并向
/dubbo/com.foo.BarService/consumers目录下写入自己的 URL 地址 -
监控中心(Monitor)启动时:
订阅
/dubbo/com.foo.BarService目录下的所有提供者和消费者 URL 地址
-
-
Dubbo细节（一）通过main函数启动服务
启动服务的两种方式：
-
部署到tomcat启动，适合正式项目
-
通过main函数启动，适合开发阶段
-
Dubbo细节（二）dubbo配置说明
-
Dubbo细节（三）协议
协议一般在服务提供者一方配置，可以指定使用的协议名称和端口号。
其中Dubbo支持的协议有：dubbo、rmi、hessian、http、webservice、rest、redis等。
推荐使用的是dubbo协议。
dubbo 协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
-
Dubbo细节（四）启动时检查
配置位置：配置在服务消费者一方，如果不配置默认check值为true。
作用：Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题。可以通过将check值改为false来关闭检查。
-
Dubbo细节（五）负载均衡
什么是负载均衡？
负载均衡（Load Balance）：其实就是将请求分摊到多个操作单元上进行执行，从而共同完成工作任务。
在集群负载均衡时，Dubbo 提供了多种均衡策略（包括随机、轮询、最少活跃调用数、一致性Hash），缺省为random随机调用。
配置负载均衡策略，既可以在服务提供者一方配置，也可以在服务消费者一方配置
配置在服务消费者一方：
可以通过启动多个服务提供者来观察Dubbo负载均衡效果。注意：因为我们是在一台机器上启动多个服务提供者，所以需要修改tomcat的端口号和Dubbo服务的端口号来防止端口冲突。在实际生产环境中，多个服务提供者是分别部署在不同的机器上，所以不存在端口冲突问题。
-
Dubbo管理控制台
介绍
我们在开发时，需要知道Zookeeper注册中心都注册了哪些服务，有哪些消费者来消费这些服务。我们可以通过部署一个管理中心来实现。其实管理中心就是一个web应用，部署到tomcat即可。