分布式概述

1.1 分布式架构

1.1.1 JEE架构

JEE 将企业级软件架构分为三个层级： Web 层、业务逻辑层和数据存取层，每个层次的职责分别如下。

• Web 层： 负责与用户交互或者对外提供接口。

• 业务逻辑层：为了实现业务逻辑而设计的流程处理和计算处理模块。

• 数据存取层： 将业务逻辑层处理的结果持久化以待后续查询，并维护领域模型中对象的生命周期。

image-20200704110729810

在这一时期，由于在架构上把整体的单体系统分成具有不同职责的层级，对应的项目管理也倾向于把大的团队分成不同的职能团队，主要包括：用户交互UI 团队、后台业务逻辑处理团队、数据存取ORM 团队与DBA 团队等，每个团队只对自己的职责负责，并对使用方提供组件 服务质量保证。

因此，在分层架构下需要对项目管理过程中的团队进行职责划分，井建立团队交流机制。根据康威定律，设计系统的组织时，最终产生的设计等价于组织的沟通结构，通俗来讲，团队的交流机制应该与架构分层交互机制相对应。

JEE 时代下对传统的单体架构进行了分层，职能团队的划分也反映了架构的分层，架构已经在一定程度上进行了逻辑上的拆分，让专业的人做专业的事儿初见端倪，但是，每个层次的多个业务逻辑的实现会被放在同一应用项目中，并且运行在同一个只币4 中。尽管大多数公司会使用规范来约束不同业务逻辑的隔离性来解祸，但是久而久之，随着复杂业务逻辑的选代增加及开发人员的不断流动，新手工程师为了节省时间和赶进度，非法使用了其他组件的服务，业务组件之间、UI组件之间、数据存取之间的稿合性必然增加，最后导致组件与组件之间难以划清界限，完全祸合在一起，将来的新功能迭代、增加和维护将难上加难。

1.1.2 SSH架构

在JEE 开始流行但没有完全奠定其地位时，开源软件Struts 、Spring 和Hibernate 开始崭露头角， 很快成为行业内企业开发的开源框架标配（简称SSH), JEE 规范中的各种技术如EJB,迅速失去了进一步发展的机会。Web MVC 框架Struts 在用户交互的UI 层进一步划分了前端的职责，将用户交互层划分为视图、模型和控制器三大块（简称MV C 模型）。

image-20200704111905975

开源框架Spring 的发布，更加改变了JEE 一开始制定的战略目标。Spring 框架作为逻辑层实现的核心容器，使用起来简单、方便又灵活，几乎大部分开发者完全倒向了Spring 开源派。Spring 框架有两个核心思想： IOC 和AOP

• Spring IOC 指的是控制翻转，将传统EJB 基于容器的开发改造成普通的Java 组件的开发，井且在运行时由Spring 容器统一管理和串联，服务于不同的流程，在开发过程中对Spring 容器没有强依赖，便于开发、测试、验证和迁移。使用EJB 实现一个服务化组件Bean 时，需要依赖于多个容器接口，并需要根据容器的规则进行复杂的XML 配置，测试需要依赖于应用服务器的环境，有诸多不便；使用Spring 框架则不然，开发业务逻辑时每个业务逻辑的服务组件都是独立的，而不依赖于Spring 框架，借助Spring 容器对单元测试的支持，通过对下层依赖服务进行Mock,每个业务组件都可以在一定范围内进行单元化测试，而不需要启动重型的容器来测试。

• Spring 对AOP 的支持是Spring 框架成功的另外一大核心要素。AOP 代表面向切面的编程，通常适用于使用面向对象方法无法抽象的业务逻辑，例如：日志、安全、事务、应用程序性能管理（ APM ） 等，使用它们的场景并不能用面向对象的方法来表达和实现，而需要使用切面来表达，因为它们可能穿插在程序的任何一个角落里。在Java 的世界里， AOP 的实现方式有如下三种。

1. 对Java 字节码进行重新编译，将切面插入宇节码的某些点和面上，可以使用cglib 库实现。

2. 定制类加载器，在类加载时对字节码进行补充，在字节码中插入切面，增加了除业务逻辑外的功能， JVM 自身提供的Java Agent 机制就是在加载类的宇节码时，通过增加切面来实现AOP 的。

3. JVM 本身提供了动态代理组件，可以通过它实现任意对象的代理模式，在代理的过程中可以插入切面的逻辑。可以使用Java 提供的APIProxy.newProxylnstanceO和InvocationHandler来实现。

到现在为止， SSH 开源标配框架中有了四交互层的Stru也框架和业务逻辑实现层的Spring框架，由于面向对象领域的模型与关系型数据库存在着天然的屏障，所以对象模型和关系模型之间需要一个纽带框架，也就是我们常说的ORM 框架，它能够将对象转化成关系，也可以将关系转化成对象，于是， Hibernate 框架出现了。Hibernate 通过配置对象与关系表之间的映射关系，来指导框架对对象进行持久化和查询，并且可以让应用层开发者像执行SQL 一样执行对象查找。这大大减少了应用层开发人员写SQL 的时间。然而，随着时间的发展，高度抽象的ORM 框架被证明性能有瓶颈，因此，后来大家更倾向于使用更加灵活的My Batis 来实现ORM 层。

这一时代的SSH 架构与JEE 时代的架构类似，可分为三个层次：实现交互UI 接口的WebMVC 层、实现业务逻辑的Spring 层及实现对象关系映射的Hibernate 层，每个层级的实现比JEE对应的层次更简单、更轻量级，不需要开启整个应用服务器即可测试和验证，极大提高了开发 效率，这得益于Spring 框架的控制翻转理念。由于这一时代的企业级软件服务的对象仍然是企业，用户量并不大，因此，大多数企业里 的SSH 架构最终会被打包到同一个JEE 规范的War 包里，并且部署在Apache Tomcat Web 容器里，因此，整个结构还是趋向于传统的单体架构，业务逻辑仍然糯合在一个项目中，即使通过规范来约束模块化组件的精合度，效果也往往适得其反。

1.1.3 服务化架构

从JEE 时代到SSH 时代，服务的特点仍然是单体化，服务的粒度抽象为模块化组件，所有组件精合在一个开发项目中，并且配置和运行在一个口叫进程中。如果某个模块化组件需要升级上线，则会导致其他没有变更的模块化组件同样上线，在严重情况下，对某个模块化组件的变更，由于种种原因，会导致其他模块化组件出现问题。传统JEE 和SSH 无法满足对海量用户发起的高井发请求进行处理的需求，无法突破稿合在一起的模块化组件的性能瓶颈，单一进程己经无法满足需求，并且水平扩展的能力也是很有限的。

为了解决上述问题， SOA 出现了。SOA 代表面向服务的架构，俗称服务化，后面所说的SOA 、服务化、SOA 服务化若没有特殊说明则指SOA 。SOA 将应用程序的模块化组件通过定义明确的接口和契约联系起来，接口是采用中立的方式进行定义的，独立于某种语言、硬件和操作系统，通常通过网络通信来完成，但是并不局限于某种网络协议，可以是底层的TCP膺，可以是应用层的HTTP ，也可以是消息队列协议，甚至可以是约定的某种数据库存储形式。这使得各种各样的系统中的模块化组件可以以一种统一和通用的方式进行交互。

对比血E 和SSH 时代的模块化组件后发现， SOA 将模块化组件从单一进程中进一步拆分，形成独立的对外提供服务的网络化组件，每个网络化组件通过某种网络协议对外提供服务，这种架构下的特点如下：

1. SOA 定义了良好的对外接口，通过网络协议对外提供服务，服务之间表现为松耦合性，松耦合性具有灵活的特点，可以对服务流程进行灵活组装和编排，而不需要对服务本身做改变。

2. 组成整个业务流程的每个服务的内部结构和实现在发生改变时，不影响整个流程对外提供服务，只要对外的接口保持不变，则改变服务内部的实现机制对外部来说可以是透明的。

3. SOA 在这一时代的数据通信格式通常为XML ，因为XML 标记定义在大规模、高并发通信过程中，元余的标记会给性能带来极大的影响，所以后来被JSON 所取代。

4. SOA 通过定义标准的对外接口，可以让底层通用服务进行下沉，供多个上层的使用方同时使用，增加了服务的可重用性。